Understanding the Building Blocks of an Azure Mobile Services Solution

Series Index

As close as you will get to a Full Service Turnkey Mobile Development Experience

That is a bold statement, yes, I know, but when you look at everything that you get from Azure Mobile Services Out of Box (OOB), I am sure you will agree with me too, or at the very least, be thinking long and hard about what is better out there at the time this blog post is written. By now the screenshot should be familiar to you, it’s what you see when you click any of your Azure Mobile Services or if you click on the little lightning bolt in the cloud depicted in the [1] call out below, from here you can decide what platform you want to build against and download the sample code. We will be spending most of our time in this post discussing what you can do with the tabs in the [2] callout below.

I won’t be re-creating the wheel here in this post, Microsoft and the technical community provides quite a bit of written guidance on what all these tabs do, I am going to provide some additional perspectives and highlight areas where I think the messaging is not as deep as it should go.

Dashboard

The dashboard provides exactly what it sounds like it does, refer to the screenshot below

It’s a quick view into how your Azure Mobile Services is running and a launch pad for configuration and increasing the scale (size) of the servers and services running the Mobile Solution, it does that by sending you to the Configure or Scale tab within the Azure Mobile Service you are currently on which we will cover in more detail when we get to those respective tabs. By clicking on call out [1] that takes you to the configure tab where you can configure things such as ALM, Databases, Debugging experience, Hybrid connections, Analytics, etc. Clicking on call out [2] takes you to the scale tab where you are scaling the availability of the cloud service as well as the database it ties back to. Whereas callout [1] and [2] take you to configurable elements inside the Azure Mobile Service you are working in, call out [3] takes you to the “Management Services” node on your Azure Subscription where you can set up Logs and Alerts for just about anything on your Azure Subscription.

In the example above, you can see I have set the dates for 1 calendar week and by default since I click from my Azure Mobile Service, the name is defaulted to that already. By clicking on the check mark I get to see all the reported activities in the grid pane below, were you to click on “Alert” it would show you any pre-configured alerts you set up prior to clicking on the callout.
By far what I use most from the dashboard is call out [4] where I download the publishing profile so that depending on how I entered into this process… if I go into Visual Studio, I can use the profile to lock in all I need to publish from Visual Studio back to Azure.

Scheduler

This little nugget in Microsoft Azure Mobile Services is really facinating to me, I have just only recenlty had an opportunity to use it in a production athmosphere.  With Schedule Jobs, you have the ability to do some pretty amazing things with your Mobile App's data, or information tangential to the data, for instance:

You have the ability to run multiple scheduled jobs in the portal against the Mobile Service, on the FREE tier however, you are limited to one (1) job at a time, however, in the paid tier, you can have up to ten (10) jobs running at once.  

These jobs may be run coded in JavaScript or .NET in the case of .NET, you will create and register a class that inherits from ScheduledJob. In the above example you see a Scheduled Job I created for a Mobile App I am using for a Session I am delivering at the Evolutions Conference in London where you can Tweet for Swag. Here I am utilizing the Logging feauture as well to see the work the job is doing.

Push

When it comes to engaging with your Mobile Application users in real time, nothing works better than Push Notifications by providing contextually aware in app messaging across all platforms and across all mobile devices, whether it is Windows, iOS or Google. using the Notification Hub permits this seemlessly.  In this way you can send either a broadcase wide or tailored individual notifications to permit the end users to truly engage with the whole mobile experience wheter they are actively engaged with the app, or even at times when they are away from the app.

Using the notification hub and the mechanism each platform requires for its own notification is real easy, the only issue that I found is when you move out of the free tier, you also have to scale your notification hub presence as well which may incur additional cost/azure credits.

Identity

I think this goes part in parcel with Push Notifications as well when it comes to engaging with your mobile application users.  What do I mean by that? Well, consider that you woud like to ensure proper security and also individualize your app right? So, a really good option that Azure Mobile Services gives us is the ability to use is Windows Azure Mobile Services (WAMS) Social Identity with Auth0. By creating and registering your app with these various Social Providers like Facebook, Twitter, Google, Windows Azure AD or Windows ADS it is simple as addign client/api ID's and client/api secrets. Once you have done that, it is as simple as decorating your Classes or Methods with the [Authorize] level of permissions to lock down the access to only authenticated users.  You can see an example of this that I also did for my Tweet for Swag App in my GitHub repository.

Configure and Scale

I am going to lump Configure and Scale into one section because they integrate with one another, by that I mean, when you tell the Azure Mobile Service that you want to scale your application, the next things it asks you to do is alter the configuration, even though you can alter the configurations without affecting the scale of you mobile application.  In terms of configuraiton some of the items that you may manage are

Logs

When it comes to Logs, well that is pretty much self explanatory. In my example again using the case of my Tweet for Swag App, I use Logging to spit out the occurences of caputred information from my scheduled jobs.  I want to see success and failures without having to look into my code or Azure Sql.  You ofcourse can use it for a million and one reasons up and beyond my use cases. 

Summary

So, in conclusion of this third installment of my series, this should provide you with a good start in understanding the various parts that make up an Azure Mobile Service solution besides the actual code, which is what comes next.