Oracle Mobile Cloud Service

Being a traditional eBS developer who touched mobile applications only slightly I had some trouble in understanding what Oracle Mobile Cloud Service actually was and offers.

I understand DBS (Database Cloud Service), which offers me a platform to run a database on so I don’t have to get myself a database and a server to run on it. I understand JCS (Java Cloud Service), which offers me a platform to run Java based applications, I also understand SAAS applications, so I don’t have to install and run ERP and Sales like applications on my own servers and maintain them.
And the nice thing is that in the cloud you have the newest features and monitoring is done in the service centers.

But now for MCS, Mobile Cloud Service (not that Messaging Cloud Service has the same acronym somehow).

 

You don’t run your mobile application on the mobile cloud service: you run it on a mobile device right. Like for an ADF application you would still build the app in your IDE, for example JDeveloper. For your ADF application you could deploy it on the Java Cloud Service and run the application from there. For your mobile application, assuming I would build it for example in MAF (JDeveloper with MAF extension) I would deploy it to the mobile device that needs to run it.

 

So why do I need a mobile cloud service then? What does it actually offer?
Like I said, your mobile app is not deployed on it, but it sort of runs through it. The main key here tying everything together being the mobile backend. It provides a layer between your mobile app

and the API’s you are calling and in the same time offers you common services like storage, (push) notifications, offline options and analytics on your services that are being called.

It’s also a kind of hub to register all the API’s you want to call. So rather than having to build in all kinds of methods to call services from external sources (in all kinds of different ways probably), you register the APIs in a uniform manor on the MCS platform and call the APIs through MCS using the URLs  exposed by MCS.

So your mobile app does not directly connect to the services outside anymore, but all through MCS and MCS provides you an abstraction layer so you can easily implement your mobile solution without worrying about how to call the services in the outside world.

And the nice thing is that the platform also monitors the calls made to the APIs. So you can see the response time and how often certain APIs are accessed.

Next to this standard monitoring it also provides you a mechanism to monitor events that you can raise through your app. For example how often a service call was delayed and for how much time. By coding these events in your app and flush it to MCS, MCS builds analytics on that.

So pretty cool right!

So on the one hand we have the services the MCS offer which we can take a look at and secondly we like to know what we need to do in our mobile app to make it work through MCS right? In this blog I will focuss on some of the features and briefly describe how to make a connection to your mobile backend in for example your MAF application to link to your mobile back end of MCS.

 

Feature Storage

 

One of the features, the analytics, I already touched briefly above. A second feature MCS offers is storage.

 

 

 

MCS offers you different ways to store data in an easy way to for example share data temporarily or to persist small data payloads off device (documents, pictures, preferences, etc).  The nice thing about putting this logic in MCS is that it can be used cross platform.
MCS offers three methods as depicted above

1.       As externalized REST APIs

2.       MCS mobile client SDK

3.       Internal to MCS using a custom API via Node.js

In MCS you simply define your storage under your Mobile Backend. It can be shared or user isolated.

 

 

Accessing the storage can be done again using REST calls as shown below.

You can also use parameters like ?limit=10 or ?offset=20, ?orderBy=contentLength:desc, etc.

So for example
{StorageURL}/collections/emp/objects?limit=10

To query the first 10 employees of your collection.

 

Feature Notification API

A second feature is the push notifications which are supported by MCS. Since each platform operating system has its own push solution (Android using Google’s Cloud Messaging service (GCM) and iOS using Apple’s Notification Services (APNS)), the MCS provides a generic notification service and provides a custom push server for multiple platforms. The MCS client SDK provides registration with APNS & GCM and displayes and handles the notifications.
The server side part provides tracking of the registrations, sending the messages, filterable distribution lists, schedule future messages and monitors delivery.
 

 

 

 

Tying your mobile app to the MCS mobile backend

 

In order for your mobile application to flow through MCS you need to tie it together. In your application XML you add these preferences. The Back End URL, the backend ID, the application key (same for Android and iOS) and finally the anonymous key to allow for anonymous access.

 

<adfmf:preferences>

    <adfmf:preferenceGroup id="mcs" label="Mobile Cloud Service Settings">

      <adfmf:preferenceText id="mobileBackendURL" label="Mobile Backend Base URL" default="https://ptsdev-usoracle88094.mobileenv.us2.oraclecloud.com:443"/>

      <adfmf:preferenceText id="mobileBackendId" label="Mobile Backend ID" default="781ec8e7-e306-460b-846c-5c4976a0caea"/>

      <adfmf:preferenceText id="mobileBackendApplicationKeyAndroid"

                            label="MBE Application Key (Android)"

                           default="cd3a8dca-6209-4431-bad4-7061a9f9b25e"/>

 

      <adfmf:preferenceText label="MBE Application Key (iOS)" id="mobileBackendApplicationKeyiOS"

      default="cd3a8dca-6209-4431-bad4-7061a9f9b25e"/>

      <adfmf:preferenceText id="mbeAnonymousKey" label="MBE Anonymous Key" secret="false" default="VVNPUkFDTEU4ODA5NF9QVFNERVZfTU9CSUxFX0FOT05ZTU9VU19BUFBJRDppaHpybTZrUW9kXzV1bA=="/>