Connecting Multiple Clients to the Same Mobile Service

Pretty frequently we are asked if or how you connect multiple clients to the same Mobile Service.  The great thing about Mobile Services is that it’s meant to be the backend for your cross-platform apps.  One app on several platforms with just a single Mobile Service backend.  To facilitate demonstrating that fact, I’m going to review a sample I put out for iOS and Android a little while back: Feedback.  The application allows your users to enter feedback (let’s say about the application) and then records it into Mobile Services.  This is a really simple sample but demonstrates how we can use the same backend in both apps.  You can access both the Android and iOS source code on GitHub.

What about other platforms?

This sample is just done in Android and iOS right now.  However, we could also connect a Windows Store or Windows Phone or HTML/JS app using their SDKs to the same service.  In fact, using the REST API that is exposed by the Mobile Service, we could connect any application we want as long as it’s capable of doing an HTTP Post to our service.  All of these clients and we can use the same single backend.

Creating a Mobile Service

The first step is to create a new Mobile Service.  Before you can do that, you’ll need a Windows Azure account.  If you don’t have one already, you can sign up for a free 90 day trial here.  Once you’ve done that, you can follow the steps listed here under the Setting up the app header.  Once you’ve created your Mobile Service, click into it click the MANAGE KEYS button at the bottom:

Here you can copy your APPLICATION KEY which you’ll need in your client applications along with the name of your Mobile Service.  Before we move on to the clients, go to the DATA tab (in the top of the portal) and click the CREATE button at the bottom.  Name the table Feedback and leave the permissions as Anybody with the Application Key.

The Client

Regardless of whether you’re working with the Android or iOS repositories, all you’ll need to do is set the Mobile Service URL and Application Key before you can run the apps.  We’ll be working off of the source/end folder for these samples.  If you’re doing the Android app, open the FeedbackService.java and set the URL and Key in the constructor:

If you’re doing iOS instead, open up FeedbackService.m and set the URL and Key in the init method:

Now before we run the application, let’s look at the code that will actually handle inserting the feedback to our Mobile Service.

Inserting data

The code for inserting data is actually incredibly similar between the iOS and Android apps (outside of syntax of course).  For Android, we have this code (also from the FeedbackService.java file):

And for iOS (also from FeedbackService.m) we have this:

There are two real differences between these two method calls.  The first is that the iOS version uses an NSDictionary which is essentially an array of key-value pairs.  The Android version uses a strongly typed object named Feedback.  Behind the scenes in the Mobile Services SDK, the same thing ends up happening: the data is serialized into JSON and sent up to the Mobile Service.  The second difference is that the Android version just calls the callback sent into it where the iOS version attempts to log an error, if there was one, and then calls whatever completion handler was sent into it. 

Running the Apps

I’ll go ahead and start up both versions of the app.  The first thing we’ll see on both is a screen with a single button to Send Feedback.  Tapping on that takes us to the Feedback screen:

Before we fill out the forms and hit submit (not visible on the Android version on the left, you have to scroll down a little), let’s check out the portal for a second.  Go back to the DATA tab and click on your Feedback table.  It should currently say “This table contains no records.”  Go back to your application and fill it out.  I’ll go ahead and do so for both versions and submit:

Now after submitting, let’s return to the portal.  Hit the REFRESH button at the bottom of the screen and you should now see your data showing up in the portal:

Portability

The Feedback portion of these apps were designed so that you could take the Feedback forms and drop them into your applications very easily.  From the Android side, you just need to take the Feedback, FeedbackActivity, FeedbackService classes and activity_feedback layout and drop them into your application.  Once you’ve configured FeedbackService to use your Mobile Service URL and key, you just need to launch the FeedbackActivity and it will record your feedback (you’ll also need to make sure FeedbackActivity is in your manifest).  For iOS, there is a MSFeedback file group that you can copy over to your project.  The UI for the feedback form is put into xib files, so even if you’re using storyboards, you can easily drop the feedback stuff into your own application.

Conclusion

Today we saw how easy it is to use the same Mobile Service as a backend for apps running on different platforms.  In this case it was iOS and Android, however, you could continue to connect other clients to this Mobile Service or choose a different mix of clients if you wanted.  With Mobile Service’s official support for Android, iOS, HTML/JS, Windows Phone, and Windows Store apps, you’re easily able to use the same Mobile Service as a backend for most different app platforms.  Finally, we saw how easy it is to use Mobile Services to gather feedback on your application even if this is the only way you’re using Mobile Services.