• Article

June 2016

Volume 31 Number 6

[Mobile Development]

Speed Up Your Mobile Development Using an MBaaS Platform

By Paras Wadehra | June 2016

A very large percentage of mobile app development cost comes from back-end integration. Moreover, most apps have a core set of features that vary little across them. So instead of building the same features and components over and over again from scratch for every application, what if you could focus on what makes a great mobile app—the UX—and consume (instead of build) the other critical app features? That’s exactly the theory behind Mobile Backend as a Service (MBaaS), which provides those important but common app features as a service for you to consume, allowing you to save massive amounts of time (and therefore money) on app development while focusing on delivering a great experience to your users.

Not only do you not have to reinvent the wheel for every app, the MBaaS platform also allows you to use a “de-coupled” development approach for the app front end and back end. This means building the front end and the back end at the same time is now possible, and connecting the two just takes “flipping the switch” when both sides are done.

I’m going to walk you through the major steps of a sample enter­prise app’s development process using both “do it yourself” (DIY) and MBaaS approaches, and then compare the two and see in what kind of scenario one makes sense over the other. The high-level requirements of this use case are as follows:

  1. The app needs to authenticate its users against Active Directory Federation Services (AD FS).
  2. The app should connect to and display data from a SharePoint instance, but needs to filter the data rather than display the full record set from SharePoint.
  3. The app should allow the user to browse the data while offline.
  4. The app should allow the user to add new records while offline and automatically synchronize these records with the server when the app is online.
  5. The app should receive a push notification confirming the new or updated record was successfully saved in SharePoint.
  6. The app should allow the user to take a picture and upload it to the server attached to the record being created.

Now imagine you’ve just been handed these requirements and asked to build a mobile app. Where do you start? Let’s look at the choices.

One option is to get all the back-end services like AD FS and SharePoint up and running, along with a server to host your files—pictures in this case. You’d also need to build services on top of AD FS and SharePoint to let you connect and talk to them from the mobile app. Then you’d be able to build the front-end mobile app to connect into these back-end services.

You could also start by building the front-end mobile app, having it talk to mock data and authentication sources first, then updating the mobile app to talk to the actual data and authentication sources once the back-end services are up and running. However, this requires you to create mock data and authentication systems or services you can use to build the mobile app.

With either of these DIY options, your front-end app will need to talk the same language as the back end and has the potential to break if the back end changes, requiring you to make expensive and time-consuming fixes to the app.

In contrast, using an MBaaS platform means the front-end mobile app and the back-end services can be created at the same time by two different teams—meaning faster time to market—and the two can be connected to each other using the MBaaS platform itself. One of the several benefits of this approach is that you don’t need to worry about creating mock services to mimic data and authentication sources.

An MBaaS platform provides you with SDKs for both native and hybrid platforms. You simply integrate the SDK for the platform of your choice into your development environment and code against it to make it easy to consume back-end services. One of the most important features of MBaaS your apps will consume is integrating with back-end data and identity sources. The MBaaS platform also provides an abstraction layer, thereby hiding the complexities of the back end from the front-end mobile app.

Let’s take a more detailed look at what each of these options entails. I’ll examine each of the required features of the app and focus first on the DIY way of implementing that feature, then compare that to the MBaaS way of doing things. In the end, I’ll do an overall comparison of the two approaches.

Authentication

With the DIY approach, you first need to build up the connector to AD FS and then use that connector to authenticate the user. The connector must be consumable from a mobile app, and allow the passing of a username and password from the app back to Active Directory for authentication. Once Active Directory successfully authenticates the user, it returns an authentication token that will need to be parsed, encrypted and stored for use in future calls. In addition, if an authentication provider supports refresh tokens, code will need to be written to automatically refresh the authentication token when it expires.

With MBaaS, in contrast, you make an authentication call using the client SDK to authenticate the user, something like:

MBaaS.login(redirectURI);

Depending on the type of authentication, the provider might present you with its own login screen (OAuth style) or an MBaaS provider might present its own version of the login screen. All MBaaS providers offer at least some no-code connectors into enterprise identity sources, including, but not limited to, AD FS. You simply supply a few configuration parameters in the MBaaS cloud portal and configure MBaaS to talk to your instance of AD FS. The types of configuration parameters you provide include provider login URI, logout URI, certificate text and name ID format URI along with redirect URIs and time-to-live (TTL) for the authentication token. You should be able to get all these values from the AD FS administrator in your enterprise. Just by setting up these configuration parameters you create a connection to your AD FS instance.

The complexity of implementing the whole authentication process has now been simplified to that one line of code. All the back-end complexities, like the authentication handshake, retrieving the authentication token, encrypting and storing it, and so forth are now taken care of by the MBaaS platform and the corresponding SDK.

Data Access

DIY data fetching seems straightforward—until you sit down and try it. It’s not too bad for data sources that expose a consumable Web service on top of the data by default. It might even be easy to connect directly to the data source from a Web-based app. However, mobile platforms typically do not have the same connectors to enterprise data sources available as Web apps. This means a custom connector needs to be written, most probably as a Web service that talks to the data source and exposes its data using normal HTTP verbs like GET, PUT, POST and DELETE. Moreover, this connector will need to be hosted somewhere. In most cases, your app will be accessed from outside your network, which means the Web service you create must be able to talk to both the outside world, as well as the inside-the-firewall enterprise world, and that means a hole probably needs to be poked in the firewall. After the custom connector has been created, you can connect to it from the mobile app and perform all the data operations accordingly. But what if you have to let the user fetch only certain record sets based on their queries? This requires building querying capabilities in the Web service, which can get complicated, especially if you need to allow the users to make complex queries.

Most MBaaS systems provide out-of-the-box connectors to several enterprise data sources, which means you simply configure them instead of creating them. For the sample use case, you’d configure the connector for SharePoint by providing configuration parameters like the host URL and username and password to connect to your instance of SharePoint. Consuming the data from SharePoint within the mobile app is as easy as writing this one line of code:

MBaaS.data.get(NameofDataCollection [,QueryParams] [,Options]);

This would normally return an array of JSON objects from your data source. One of the benefits of using an out-of-the-box connector from an MBaaS provider is that such connectors provide a way to discover all the objects in your data store so you can simply discover all SharePoint lists and select the ones you want to provide access to from the mobile app. You can also filter and orchestrate the fields being returned by SharePoint to just the few that are needed in the mobile app so that large amounts of data sets aren’t sent to the mobile device when only a small percentage might be actually useful to the app. Again, filters can be applied without having to write any custom code—a huge value proposition for mobile developers. Without an MBaaS providing such a feature set, the entire burden of filtering and orchestrating the data comes down either to the mobile app (which means greater bandwidth and battery consumption on the device—never a good experience for the mobile user) or to using a server-side script that you’ll need to write, host somewhere and manage (which means ongoing work and maintenance for you). The QueryParams input to the method in the previous line of code allows you to pass in query-based parameters to allow searching and filtering of records based on the need or input of the user.

An MBaaS platform generally also provides data and file stores built into the platform itself, so apps that don’t have their own data source can use the built-in MBaaS data store to store and consume data.

Offline Data

Just making the data available for offline consumption is actually pretty easy with the DIY approach. All you need to do is store the data on the local device, either in local storage or in a data store like SQLite, and read it from there when the user tries to access that data within your app.

However, it’s not so easy to enable offline editing of existing data or adding new data and then synchronizing it with the server while taking care of conflicts that might happen along the way. As anyone who has ever tried implementing conflict resolution code will tell you, it’s not the most fun thing to do. You need to check which entities were modified locally and which were modified on the server at the same time, then figure out what attributes of each entity were modified, and if the same attributes of the same entity were modified on both the client and the server, decide which change takes precedence and save that as the value of record.

Using a client SDK from an MBaaS provider should make it much easier to enable offline data consumption within your app. Using the data consumption example from the previous section, you’d simply pass certain option values to the call, as follows:

MBaaS.data.get(NameofDataCollection [,QueryParams] , Data.Offline, Data.EncryptFull);

In this code, I enable offline data storage on the device, as well as encryption of the data. How the SDK stores the data for offline consumption varies from provider to provider, but the implementation of that shouldn’t affect how you interact with the MBaaS SDK. The SDK will take care of all the complexities around offline implementation for you. Even better, enabling encryption should be just as easy and simply involves setting up an option. This makes the offline data store secure, a key requirement for most enterprise apps. The MBaaS SDK automatically decrypts data for user interaction or display on the screen and encrypts user-entered data before storing it on the device. The SDK generally takes care of enabling offline editing and the addition of new data, as well. For this to work as expected, though, the back-end systems must have LastUpdatedTime implemented for each record. Similarly, setting up further options for conflict resolution determines whether the changes on the client or the server win when a record is updated simultaneously on both sides.

Push Notifications

Setting up push notifications for a DIY project can be a challenge. As shown in Figure 1, multiple steps must take place for a successful push notification channel to be set up and a push notification to be sent. (See bit.ly/UWPPush for more information.)

  1. The Universal Windows Platform (UWP) app requests a push notification channel from the OS.
  2. A new notification channel is created by Windows Notification Service (WNS) and returned to the calling device in the form of a Uniform Resource Identifier (URI).
  3. The notification channel URI is returned by Windows to your app.
  4. Your app sends the URI to your own cloud service, where it’s stored so you can access the URI when you send notifications.
  5. When your cloud service has a notification to send, it informs WNS using the URI registered earlier. This is done by issuing an HTTP POST request, including the notification payload, over Secure Sockets Layer (SSL).
  6. WNS receives the request and routes the notification to the appropriate device.

Flow for Setting Up and Sending Push Notifications
Figure 1 Flow for Setting Up and Sending Push Notifications

In addition, you need to request a channel each time the app launches because channel URIs can expire and there’s no guarantee a previous channel URI will still be valid. If the returned channel URI is different from the URI you’ve been using, you’ll need to update the URI in your cloud service. You also need to map the channel URI to the device ID for the user so you can update the appropriate channel URI on your server.

Any good MBaaS platform provides ways to simplify push notification setup. Remember the steps you just saw for sending a successful push notification to your UWP app? Now take a look at Figure 2, which shows what you don’t have to do if you use an MBaaS platform.

Push Notification Complexities Taken Care of by MBaaS
Figure 2 Push Notification Complexities Taken Care of by MBaaS

As you can see, MBaaS hides all the complexities of setting up, managing and sending push notifications to users. All this is handled with a single call made using the client-side SDK:

MBaaS.registerForPush();

and writing server-side business logic within the MBaaS platform that determines when to send a push notification and invokes the predefined method that sends out the push to the appropriate users.

File Server

Following the DIY path means you need to host and manage your own file server to allow users to take a picture from their device and upload it to the server, and also manage user access to those files so one user can’t access another user’s files. In addition, you need to manage the uptime of the server, as well as scalability, performance and security updates.

With an MBaaS platform, you probably won’t have to implement anything to be able to host files in the cloud. One of the features of MBaaS platforms is access to a file store out of the box. You get a fully CDN-backed file store to host all the common file types—PDFs, images, videos, office documents and the like. As with the other features, all you need to do is make a simple call to a method in the MBaaS SDK to work with files stored in the cloud. The Files API lets you upload, download, and stream files to and from the File Store, using calls like:

MBaaS.File.upload(FileName);
MBaaS.File.download(FileName or FileID);

This eliminates the headaches of managing a huge file server (depending on the number and size of the files being stored), including expanding and shrinking storage based on needs at any given point, and managing both uptime and the latency of file access.

Other MBaaS Features

I’ve described the feature set of the sample app at the beginning of this article, but I’d also like to highlight a couple of other MBaaS platform features that might ease your app development:

Server-side business logic enables you to run heavy processing on the server rather than consuming power on the client device. It also lets you filter the data being sent from the data source to send only what’s needed on the mobile device saving bandwidth for the user. Moreover, you can intercept any of the calls going through, to and from the MBaaS platform.

Server-side caching enables sub-second UX scenarios. Traditional enterprise data sources often take several seconds to respond to a query, but mobile users expect a much faster response and if loading an app takes too long, they’ll simply uninstall the app and go to a competitor. With the server-side caching feature, the data from the enterprise data source can be cached within the MBaaS platform for a quick response to the requests from the mobile app, and the cache can be silently updated from the original data source in the background.

Wrapping Up

Both DIY and MBaaS approaches have a place in app development. The benefits of using an MBaaS platform are clear, but in some cases just going with a DIY approach may make sense. Such instances include one-off app development projects that already have all the necessary services in place to connect to data and identity sources. For scenarios where the service connections into such data and identity sources haven’t been built yet and will need to be consumed from multiple apps, an MBaaS platform can really speed up mobile development by providing the most complex features of back-end integration out of the box. With the help of an MBaaS platform you can focus on your app’s UX rather than worrying about integrating data and identity sources, encryption, offline implementation, conflict resolution, push notification setup, and other basic but critical components of mobile apps.

In the end, it’s the abstraction an MBaaS platform provides that is the benefit, allowing you to change your back-end data and identity sources as often as you want. You can also change your server-side business logic without ever needing to rewrite a single line of code in your app. The mobile SDKs the MBaaS platform provide work with this abstraction to keep your app running and save you from updating, testing (including unit, integration and regression testing), and deploying the app and waiting for store approval again!

One drawback is that using an MBaaS platform might make it harder to change platforms, as the implementations of the connectors are abstracted from the user. In a DIY approach, you own the code for all connectors so it’s easier to further customize it for future needs.

MBaaS does offer significant cost savings when building mobile apps, both in terms of time and effort and also from the perspective of ongoing maintenance, security, and upkeep of the services and servers involved.

Paras Wadehra is an experienced software architect who solves problems while making applications that work across the Web, desktop and mobile platforms. He has experience developing for all major mobile platforms including iOS, Android and Windows. He writes code in C#, Node.js, JavaScript, SQL and Swift to name just a few. Wadehra is currently a Microsoft MVP in Windows Development. He speaks at various industry events and conferences and can be reached on Twitter: @ParasWadehra and on LinkedIn.

Thanks to the following technical experts for reviewing this article: Hermit Dave (Associated Press Limited, UK), Kurt Monnier (Kinvey, Inc.) and Arun Nagarajan (Uber)
Hermit Dave is a Windows developer with over 15 years’ experience working across enterprise and consumer space.

Kurt Monnier, Senior Director of Solutions and Customer Success at Kinvey, Inc., has been helping enterprise customers build mobile apps since 2007.

Arun Nagarajan is an Engineering Manager at Uber.

Discuss this article in the MSDN Magazine forum