In my last article, I described how to use the Azure Mobile Services wizard to create a sample client application. In this article, we will look at the code created by this wizard.

I'll focus on the C#/XAML version of the sample app but all the principles apply for the HTML5/WinJS version as well.

Figure 1 shows the solution, which includes a Windows 8.1 project, a Windows Phone 8.1 project, and a project with files that are shared by the other two projects.

Figure 1

I always compile this app before running it, because that ensures that all NuGet packages are updated.

Because this is a Universal app, it contains both a Windows 8.1 and a Windows Phone 8.1 project. The two projects do pretty much the same thing but each has a user interface appropriate to its own platform.

A screen shot of each running app is shown in Figure 2 (Windows 8.1) and Figure 3 (Windows Phone 8.1). As you can see, this app keeps track of a  user's To Do List. The list of "To Do Items" is stored in an Azure SQL Database, which is exposed via Azure Mobile Services.

Figure 2

Figure 3

Most of the interesting stuff happens in the Shared project.

TodoItem.cs

Let's look first at the Model. It is in the Shared project because both apps use the same model. You can find it in the TodoItem.cs file in the DataModel folder (Listing 1).

   1: public class TodoItem

   2: {

   3:     public string Id { get; set; }

   4:  

   5:     [JsonProperty(PropertyName = "text")]

   6:     public string Text { get; set; }

   7:  

   8:     [JsonProperty(PropertyName = "complete")]

   9:     public bool Complete { get; set; }

  10: }

Listing 1

The three properties (Id, Text, and Complete) will map to columns in the SQL Server table.  Text and Complete are decorated with the JsonProperty attribute, which is found in the Newtonsoft.Json library and tells .NET how to name these properties when an object is transformed into the JSON format. Strictly speaking, this is unnecessary, but JSON objects tend to follow the
JavaScript convention of Camel casing.

App.xaml.cs

The shared App.xaml.cs takes care of some basic processing when an app starts up, suspends, or has a problem.

As far as Azure Mobile Services is concerned, the important line is the MobileService field declaration (Listing 2)

   1: public static MobileServiceClient MobileService = new MobileServiceClient(

   2:     "https://giard.azure-mobile.net/",

   3:     "MqJSWTabZlOTRHeFXPRBADoQcVtqvE41"

   4: );

Listing 2

The second parameter of the constructor is the application key generated by your Mobile Service. Passing the Application Key to the constructor of our MobileServiceClient is necessary if we set permissions to only allow calls to the mobile service by clients that provide the Application Key. Whenever we call the REST service with this object, the Application Key will be passed in the header of HTTP calls to the mobile services endpoints.

This static class is available throughout the application and contains methods to communicate with your mobile service. Its main use is to create an IMobileServiceTable by calling the static object's GetTable() method, which is done in the MainPage.

MainPage.cs

Notice that all three projects contain the MainPage class, which derives from the Page object. In both the Windows project and in the Windows Phone project, this class is in the MainPage.xaml.cs file, while the class is in the MainPage.cs file in the shared project. Notice also that these are all "partial" classes and that each is in the same namespace. At compile time, both the Windows and Windows Phone projects will pull in the class from the Shared Project and use its code.

At the top of the MainPage class is the creation of two sets of our model (Listing 3).

   1: private MobileServiceCollection items;

   2: private IMobileServiceTable todoTable = App.MobileService.GetTable();

Listing 3

MobileServiceCollection items is simply a collection on the client that is used to bind to a ListView control in our XAML named ListItems. 

The IMobileServiceTable interface has methods to interact with the REST API specified when the MobileService was created (which is our Azure Mobile Service API). So, the todoTable object has implementations of these methods specific to our service.

For example, the InsertTodoItem method makes a call to todoTable.InsertAsync() and passes an instance of the TodoItem. This calls our Azure Mobile Service REST endpoint (in this case, that endpoint is https://giard.azure-mobile.net/Tables/todoitem), using the POST Verb and passing

We can use Lync extension methods of todoTable to retrieve specific data into the todoTable object as in Listing 4 (from the RefreshTodoItems() method), which retrieves only todoItems for which the Boolean field Complete is false.  

   1: items = await todoTable

   2:     .Where(todoItem => todoItem.Complete == false)

   3:     .ToCollectionAsync();

Listing 4

The shared code takes advantage of the fact that the events fired in Windows and in Windows Phone are very similar and that the similar objects with similar names and events are created in the MainPage.xaml of each project. Because of this, the shared project can even contain event handlers that are appropriate for either project.  For example, Listing 5 is the event handler when you click a checkbox next to an item on either the phone or your Windows PC/Tablet to mark that item as "Complete".

   1: private async void CheckBoxComplete_Checked(object sender, RoutedEventArgs e)

   2: {

   3:     CheckBox cb = (CheckBox)sender;

   4:     TodoItem item = cb.DataContext as TodoItem;

   5:     await UpdateCheckedTodoItem(item);

   6: }

Listing 5

This event handler passes the checked item to the UpdateCheckedTodoItem method, which uses the todoTable object to call the REST endpoint (Listing 6).

   1: private async Task UpdateCheckedTodoItem(TodoItem item)

   2: {

   3:     // This code takes a freshly completed TodoItem and updates the database. When the MobileService 

   4:     // responds, the item is removed from the list 

   5:     await todoTable.UpdateAsync(item);

   6:     items.Remove(item);

   7:     ListItems.Focus(Windows.UI.Xaml.FocusState.Unfocused);

   8: }

Listing 6

The entire MainPage class is shown in Listing 7.

   1: sealed partial class MainPage: Page

   2: {

   3:     private MobileServiceCollection items;

   4:     private IMobileServiceTable todoTable = App.MobileService.GetTable();

   5:  

   6:     public MainPage()

   7:     {

   8:         this.InitializeComponent();

   9:     }

  10:  

  11:     private async Task InsertTodoItem(TodoItem todoItem)

  12:     {

  13:         // This code inserts a new TodoItem into the database. When the operation completes

  14:         // and Mobile Services has assigned an Id, the item is added to the CollectionView

  15:         await todoTable.InsertAsync(todoItem);

  16:         items.Add(todoItem);

  17:     }

  18:  

  19:     private async Task RefreshTodoItems()

  20:     {

  21:         MobileServiceInvalidOperationException exception = null;

  22:         try

  23:         {

  24:             // This code refreshes the entries in the list view by querying the TodoItems table.

  25:             // The query excludes completed TodoItems

  26:             items = await todoTable

  27:                 .Where(todoItem => todoItem.Complete == false)

  28:                 .ToCollectionAsync();

  29:         }

  30:         catch (MobileServiceInvalidOperationException e)

  31:         {

  32:             exception = e;

  33:         }

  34:  

  35:         if (exception != null)

  36:         {

  37:             await new MessageDialog(exception.Message, "Error loading items").ShowAsync();

  38:         }

  39:         else

  40:         {

  41:             ListItems.ItemsSource = items;

  42:             this.ButtonSave.IsEnabled = true;

  43:         }

  44:     }

  45:  

  46:     private async Task UpdateCheckedTodoItem(TodoItem item)

  47:     {

  48:         // This code takes a freshly completed TodoItem and updates the database. When the MobileService 

  49:         // responds, the item is removed from the list 

  50:         await todoTable.UpdateAsync(item);

  51:         items.Remove(item);

  52:         ListItems.Focus(Windows.UI.Xaml.FocusState.Unfocused);

  53:     }

  54:  

  55:     private async void ButtonRefresh_Click(object sender, RoutedEventArgs e)

  56:     {

  57:         await RefreshTodoItems();

  58:     }

  59:  

  60:     private async void ButtonSave_Click(object sender, RoutedEventArgs e)

  61:     {

  62:         var todoItem = new TodoItem { Text = TextInput.Text };

  63:         await InsertTodoItem(todoItem);

  64:     }

  65:  

  66:     private async void CheckBoxComplete_Checked(object sender, RoutedEventArgs e)

  67:     {

  68:         CheckBox cb = (CheckBox)sender;

  69:         TodoItem item = cb.DataContext as TodoItem;

  70:         await UpdateCheckedTodoItem(item);

  71:     }

  72:  

  73:     protected override async void OnNavigatedTo(NavigationEventArgs e)

  74:     {

  75:         await RefreshTodoItems();

  76:     }

  77: }

Listing 7

Conclusion

Notice how much of the application logic was moved into the Shared project. This isn't surprising because both the Phone app and the Windows app do the same thing - but with different user interfaces. It should be your goal to push as much of our app as you can into the Shared project.

When you build your own app, you will almost certainly use a different model and a different user interface. However, the samples code in this generated application should provide you a template for how to do basic operations on your mobile service, such as Read, Write, Update, and Delete. Make sure you understand the sample; then copy the appropriate code into your application and modify it to fit your model.