This blog series is focused primarily on mobile development, with an emphasis on Microsoft Azure Services. It will go into detail about the structure of Azure Mobile Services, as well as what technologies are used to build mobile solutions that are themselves cross platform.
This post is designed to be useful for IT pros, architects and developers. We first look at the decision-making process that must take place even before you build your Azure Mobile Service. We’ll then examine the different platforms you can choose from, and, finally, we explore what a complete solution looks like end to end.
Series Index
Part 1 – Azure SQL as the backbone to Azure Mobile Service
Part 2 – Introduction to Xamarin as a Platform for Azure Mobile Services
Part 3 – Understanding the Building Blocks of an Azure Mobile Services Solution
Part 4 – Building a Azure Mobile Service Solution for iOS using Xamarin
Azure Mobile Services begins at the Back End
When you create an Azure Mobile Service solution, you start by designing what the back end will look like. After clicking New >> Compute>> Mobile Service >> Create, you can see clearly a back-end service being set up to run on Windows Azure. Your foundation begins here.
Next you will identify and provision where the cloud service will live [1], determine whether you will be using an existing database or a new one, or a new azure SQL instance all together [2], decide what Azure subscription will be billed/provisioned against [3], select what region or data center location you would like these items to be provisioned in (more on that later) [4], determine whether you prefer to build the back end with a .NET or JavaScript framework [5], and, finally decide if you want to configure advanced settings for push notifications should you wish to utilize them [6]. In this post we will focus on items 2 and 4, although they all will come together at the end.
Let’s explore the implications of your decisions when it comes to the database. One of the first is below:
These are the three choices you have when you provision your database. The first looks pretty good—at least, it’s free. The problem is that you can make this choice only once as you are allowed only one free 20 MB database per subscription.
But if I make a different choice, as you see below …
… I get a different result. (Notice the warning is gone.)
You can get around this limitation by using multiple Live IDs (email addresses) and signing up for the multiple free trials.
This leads me to two other options: I can use an existing database, or I can create a new SQL Database instance on an existing server.
There is another gotcha, however, relating to where you locate your mobile service. If you are going to use an existing database, you should line up this choice with where your database resides.
Based on this choice, and what I have outlined above, Azure will come back and bark at you …
So what we have seen so far, before we even stand up our Azure Mobile Services, are some of the limiting factors of our choices. And for good reason: We want to keep our database and the cloud service that will ultimately be talking to it in the same data center. That way, if we decide to scale out later on, (a topic for another discussion) we can architect it properly. In the end, I made the choice you see below because I want to limit my demo Labs to one region and on one subscription.
Because I chose an existing SQL Server and wired up my mobile service to be in that region, as well, I have to select that database to use. Note here I am selecting a database called “FabianPlayPenDB” on a server that is, for obvious reasons, redacted. You will also notice that you need to supply a login name and password, as well.
When you create a SQL Azure Database Server, you will need to provide a login name and password that have DBO and Sys Admin privileges. You can—and should—in turn create other logins for access to the varied databases that you will be creating.
So, what does this mean in the case of Azure Mobile Service and, in particular, this example? It means that the sample project that is created for you as a starter needs to be able to create a table for you in your SQL Azure database. This will be a “To Do” items table. This starter project and all its assets and dependencies are created for you regardless of the template or platform you go with for the creation of your Azure Mobile Service.
It is important to call out here that the structure of your Azure Mobile Service, as well as how you interact with the portal, is different based on the choice below.
As you will see soon, I decided to go with a .NET backend. I did this because I know C# much better than I know JavaScript, but also because JavaScript is client side. That means you get tools in the portal that you can execute in the browser, having an immediate impact on your Azure Mobile Service. Because of my choice, on the other hand, I will need to use an IDE and compiled managed code. The takeaway here is not negative: I just need to be better at JavaScript.
Finally, once you have made those selections, you are now able to commit that to Azure and have an instance of an Azure Mobile Service created for you.
You will notice immediately (below) that a service is being provisioned. The portal provides feedback as to its progress, and, when complete, the service joins the ranks of others in your subscription.
You have now created a Mobile Service!
Now it’s time to learn how to interact with the service. Let’s proceed according to the numbers in the screenshot above.
1. Once the Azure Mobile Service has been created, the name you see here is part of the URI for the Cloud Service hosted on Azure that points to this instance.
2. You have configurable and reporting areas for this; we will go into more detail on each later. Suffice to say, you will have a the ability to see everything in a snapshot via Dashboards; Scheduler will provide the ability to create jobs to run on the Mobile Service that may or may not affect persisting data to the database or just logic checks; you can send push notifications via Push; you can permit only Authorized logins via the Identity tab from Social Applications and Windows Azure Active Directory; and you can further configure, scale out, and manage logging of the Mobile Service with the other three tabs on the tool bar
3. As we mentioned in the intro, you have your choice of what platform you want to build against: Windows, iOS, Android, HTML/JavaScript or Xamarin. In this blog post series, we will be sticking to Xamarin.
4. The Get Started section lets you:
a. Create a new “Whatever your Choice in (3)” app
b. Connect to an existing “Whatever your Choice in (3)”app
What you have here is admittedly a very simple “To Do” items task application, but it really covers everything you need to know and provides a lot of scaffolding and sample code. In the end, if you are in Visual Studio and you press F5, you will have a functional app right out the gate. I cannot overestimate how much of a dent in the learning curve this will give anyone trying to become proficient in Azure Mobile Services.
Trust but Verify
Now, as I mentioned before and illustrated above, the back end to this will be a SQL Database in SQL Azure. Here are two approaches now to validate that claim. The first will be to verify that the database exists; the second will be to use the Azure Portal to interact with the database.
As you can see above, we have a FabianPlayPenDB database in the East U.S. region with a server name that is redacted using a Basic edition and max capacity of 2 GB. Now that we have established that, Azure Portal provides a means for you to interact and manage that database from the browser.
All you need to do to access it is provide an account with the requisite rights; you will then be able to perform any RDMS task you desire. You may choose, as I do from time to time, to extend the example by adding to the database schema beyond the two columns provided by the To Do example. Or you may create your own Tables.
As you can see above, you have access to do a lot from this portal. That said, if you, like me, are used to the Management Studio that SQL Server Provides, you can use it to access this SQL Azure Database. A point of caution, however: When you have an Azure SQL Instance, access is restricted by firewall rules.
Gotcha Alerts
When you make an attempt to access SQL Azure from the browser or from the SQL Management Studio, as shown below, you will need to have a firewall rule inplace; if you don’t, the system will bark at you. Provided you have the access and are logged into Azure Portal, you will get prompted to create one. All you need to do is say “yes,” and the system will then add you IP address.
One thing that is important that you do not see here in the database is any mention of the To Do table for this Azure Mobile instance. This is created upon first launch of the Mobile Application by virtue of the code that is there to seed the database. Again, we will get into this later on in the series, but for now, here is what I looks like.
As we leave this Part 1 of the series, we will get into how the application is formed from beginning to end. I will see you in Part 2.
Series Index
Part 1 – Azure SQL as the backbone to Azure Mobile Service
Part 2 – Introduction to Xamarin as a Platform for Azure Mobile Services
Part 3 – Understanding the Building Blocks of an Azure Mobile Services Solution
Part 4 – Building a Azure Mobile Service Solution for iOS using Xamarin
