Building a Azure Mobile Service Solution for iOS using Xamarin

Series Index

When creating a WAMS solution, you have two basic options, you can do it in the Azure Portal and you can do it through Visual Studio.  There are notable differences when you choose one over the other.  Take for instance when you user the Azure Portal, in that way, the provisioning process sets up the database, the geographic regions for both the database and the mobile services web API uri and creates "both" a sample project for the WAMS service and the client. The Visual Studio approach on the other hand sets up only the mobile service web API uri, so in essence it only comes with one project in its solution whereas the portal comes with two. 

Creating an Azure Mobile Services Solution in the Azure Portal

The process of creating a WAMS solution using the Azure Portal was described in the earlier post "Azure SQL as the backbone to Azure Mobile Service" so we wont go over it in too much detail in those post, what we want to highlight however is the code created by that process and dig a little deeper into the code that is ultimately created.

As you can see there are two projects created in one Visual Studio Solution, one of the projects is a Web API called "bravosocService" and the other is a Mobile Client iOS application called bravosoc which is a single page application.  Let us first look into the Web Service API.  As you can see, it follows a MVC pattern without the "V" in View, by default this example provides fields/properties that match what a ToDo sample will need basically a Text string field and a Complete Boolean field, in my example that you will see here, I have extended it to accommodate a bit more. See the Bravosoc project on github for a complete reference to this blog post code

Now you can certainly add more Data Objects as classes to represent other tables you want to have in the database and in turn create Controllers for them as well, for now we will just extend the ones we have there. Once complete, you can press F5 and debug this WebAPI, this will load the solution and persist the data to a local SQLite Database. I should have mention earlier that by default WAMS uses MobileServiceClient.SyncContext to sync between the local store (SQLite) and then persist to SQL Azure, this promotes a more responsive experience especially when internet or cellular is not available and you are offline.  

Creating an Azure Mobile Services Solution in Visual Studio

When you create a WAMS solution using Visual Studio you get all that you get above minus the project for the Mobile Client. There are a few reasons why this may be useful to you

Either way, picture the solution same minus the Client Project

Understanding the Sample Project(s) created by a new WAMS Solution

For the sake of accuracy to the sample and completeness, we will focus on a solution that is created from teh Azure Portal, as this will give us both a WAMS solution and a Mobile Client with it.  This section will focus on how both the WAMS tie into the Mobile Client natively. To do this we will be looking at the Data Objects and Data Services in the WAMS project and looking at roughly the same things in the Mobile Client, the key difference or the distinction I should say lies in the fact that in the WAMS it is seen as a producer of information and in the Mobile Client it is seen as a consumer of information. 

When you get this sample project you should be aware that you do not have all the packages installed in your environment, or perhaps, not the most up to date versions. As in the case of the WAMS project you can see evidence of this by looking at any of your data object classes and you will see you have issues, see the image below

In this instance we do not have the right NuGet packages for Entity Data or the NuGet for WAMS as well. Dont worry, a quick build of the solution (F6) will resolve all this for you.

One thing of importance is to know that the WAMS is basically a ASP.NET WebAPI project minus the View, and with that you get all that comes with that kind of project, so one of those items is the helper tools that permit you to debug your WAMS solution locally and provides a web site with helper aids along the way. Another thing that is done for you "for free" is that in the WebApiConfig.cs class we override the Seed Method of Microsoft.WIndowsAzure.Mobile.Service ClearDatabaseSchemaIfModelChange, one of the benefit here is that when you invoke either the helper aids or moreso and more importantly the Mobile Client, you dont have to worry about nothing being returned.

There is a controller [in this case a ToDoItemController.cs] that gives you all the CRUD capabilities you need to get the job done via this exposed URI Endpoint.  

Now, with the Data Object previously mentioned it is the AzureTableViewController that is used, the WAMS TableView Controller is just another WebAPI controller but this one specifically allows you to write back to tables in Windows Azure Databases. Indeed, if you are going to be adding your own objects and thus controllers make sure you choose the one below

As far as the client goes that comes OOB, you get a Single page Application as I mentioned earlier and seen below

you will spend quite a bit of your time in the last three classes boxed out, however if you do make changes other than extending the aforementioned classes, you may need to change where AppDelegate and Main.cs points to. Lets look at the last three classes individually

ToDoItem.cs

This class represents your Data Object that you want to work with in your Mobile Application and it can be a simplified version of what you have in your WAMS, indeed you may want it that way since you are working on a mobile device and not on a PC with ample real estate. Take a look at the ToDoItem.cs here where i extended the sample To Do that comes with WAMS by default. Now compare that with something that is more robust that I am working on here where AutoMappingConfiguration is uses to obfuscate a complex database into a Model that is better for a Mobile Application. Below is an example coming from a FieldEngineer example that the folks at Xamarin & Microsoft put together

and using Automapping as mentioned before, here is what is used in the mobile app

QSTodoService.cs

This guy is in the Data Service layer of our Mobile App, it is responsible for communicating with the WAMS by way of the URI and the Application Key. as an example take a look below. 

Beyond setting the Application URL and Application Key which you should put in a Config File and not have it like mine here [the only reason being that I will change or delete the Azure Instance of this later but keep the GitHub code] this Data Service class also creates an instance of the client as you seen in line 19 and also a SyncTable in line 20 representing the ToDo table that is both in localstore .db and in SQL Azure.  With this you have almost all you need and the final thing now is to create a View Controller in the Mobile Service to serve this up.

QSTodoListViewController.cs

This is the stock View Controller that comes with the Mobile Client [located here] and  besides setting layouts, views, cell properties, this class creates a private instance of the QSTodoService and execute calls against the database while serving or posting data through its UI.

Creating your Xamarin own Mobile Client Application

Now, you should also understand that you are not locked into using the Sample Code that comes with the WAMS solution, it is just there as a fully functional app that you can just press F5 and go to town. It is good as a learning aid, I used it in the very early stages of learning Mobile Dev by slowly and steadily extending it to do what I needed it to do while keeping the same classes so it would all connect and work.  What will happen however is that you will become stuck in that ViewController and cant grow, so, after learning what "I" consider the hard part of Mobile Dev 'actually learning the controls, layouts, and views', I am now able to create my own Storyboards/Layouts and have that coded to my backend WAMS.

In doing so, you can truly do Cross Platform development, as in my case using Xamarin.Forms I can now target iOS, Android, and Windows rather than keeping to that Simple Single Page Application that the Xamarin solution comes with.

This way you have more reach with your WAMS solution.

Summary

In conclusion I want to point you to two WAMS projects that have been referenced in this blog series

Hopefully, this has given you enough food for thought and examples that you too can take the next step and see how Windows Azure Mobile Services can be of benefit for you in your world.