If you follow Azure news on the web you might have noticed a new Azure service being offered in preview form called Mobile Services.
In this blog post we’ll be doing a high level overview of what Azure Mobile Services is and what it gives you. In subsequent posts we’ll dive deeper into how to get your hands dirty and actually use the thing.
With this initial preview the Windows 8 app development scenario has been enabled. We’re likely to see other platforms such as iOS and Windows Phone (my personal favorite) come on board as the Azure mobile team develops the new service.
Why should I Care?
The idea behind mobile services is to provide is quick and easy way to bootstrap client app development by providing a supporting backend. If you want to write client apps and don’t want write all of backend web service logic yourself from scratch then you should take look at mobile services.
So here’s what we get out of the box mobile services:
- Data storage
- Push notification
Like any other Azure service you also get a nice dashboard that shows a graph of your mobile service activity. In this case you’re able to see how the number of API calls, CPU time and data going out that service has made over time.
The data service is particularly interesting as it’s backed by Azure SQL Server and uses the JSON version of the OData protocol to communicate on the wire. One of the more interesting features of the data service is dynamic schema support which automatically updates the tables that backs the model as it changes. This makes it extremely easy to get up and running quickly as you no longer have to setup a database schema ahead of time, you can just let the service take care of creating the columns and choosing the appropriate data types in SQL server. Note that before you go into production you should turn off dynamic schema support to ensure that the schema can’t be changed outside of development.
The notion of dynamic schemas should by familiar to those who play with NoSQL document databases such as Mongo and RavenDB. The development experience is also very similar to that of entity framework code first if you ever used that before.
The C# primitives that mobile services is able to map out of the box include the following:
- Integer types (int, long, etc.)
- Floating points (double, decimal)
- DateTime and DateTimeOffset
For any other data type like TimeSpan or a custom type you will need to convert to string or provide a client side converter that implements IDataMemberJsonConverter and handles the JSON serialization for that type to simple JSON types.
One really nice thing about the mobile service is its client authentication support. To set it up all you need to do is register the web service with Windows Live, drop in your client id and secret with the mobile service and call a few methods on the client app and hey presto you’ve got authenticated calls going though.
The authentication service in mobile services is backed using Microsoft Accounts or Windows Live accounts if you haven’t got the branding memo yet. In order to make use of authentication in the client app you will also need the Windows Live Connect SDK. The Live SDK is responsible for displaying the sign in UI and eventually giving you an authentication token which you in turn hand over to mobile services client so it can perform authenticated requests to the backend. The code for this is actually simpler than it sounds.
And that’s all the code it takes to authenticate with our mobile service backend on Azure.
These scripts are responsible for creating push notifications will comprise the core of your server backend logic as well. They are responsible not only for creating push notifications but for validating and modifying in coming requests and performing authorization logic based on the incoming authenticated identity.
Under the covers, these scripts are actually being executed by node.js, Azure mobile services exposes a small subset of node modules that can be used by the scripts to do their work. We’ll go into more details in another blog post on how to use these scripts and what you can do with them. This is a pretty big topic in and over itself and a simple blub wouldn’t do the topic justice.
Anyways, now that we know where push notifications get created on the server we need to know the how. In order to leverage push notifications on the server the client app is responsible for obtaining the push notification channel URL from the PushNotificationChannelManager from within their app and uploading it to the service. Typically this gets saved as property on the model that you use to save data to mobile service.
The code for this would look something like this:
Once the notification channel is saved to the mobile service the server side scripts will then be able to use that push notification channel url to send push requests back to our app.
Hopefully this post gave you a good overview of how Azure mobile services work. In future blog posts I’ll be doing some deep dives on using specific pieces of the Azure mobile services like scripts, push notifications and the data service.