For a recent presentation, I developed a ninja locator app, where I demonstrated how to achieve code-reuse and write cross-platform applications in Visual Studio, using Xamarin’s offerings and Microsoft’s Azure Mobile Services. The demo features two applications – one iOS app and one app for Windows Phone 8.
As the user starts either of the apps, they are presented with an option to log into their favourite login provider, whereafter they’re able to share their geographical position with a selected group of friends, thus enabling them to keep track of each other when travelling together, or – in our scenario – keeping track of your fellow consultant colleagues as they roam the streets:
When building cross-platform applications, one’s dependency graph is of paramount importance. Luckily, this gets easier all the time, with Portable Class Libraries (PCL) getting a wide-spread adoption. In a cross-platform application, you’ll want as much code as possible in one or several PCLs, creating suitable abstractions for native calls as needed.
In our particular scenario, I achieve code reuse in two ways: First, I’m relying on Azure Mobile Services and am using their client libraries to access their services. The client libraries are available both for Windows Phone and – through Xamarin’s Component Store – for iOS and Android. Secondly, I’ve created a Portable Class Library that contains all interaction with said client library, thus having the Business Logic of this application in one spot. Let’s take a look at the solution explorer in Visual Studio:
The solution features five projects – a core project with the shared business logic, a library each for the native implementations (I’ll get back to that later), and a native binary per platform. For the core library, I chose to create a PCL to ensure that I didn’t take dependencies on libraries that were not supported across the board. I configured the PCL like so:
… basically picking the top-tier targets, but excluding Xbox (since that severely limits your available APIs as outlined here).
<< Secret dev. challenge!! Writing this blog entry, I identified a number of logical errors/inconsistencies. But instead of fixing them, I thought I’d make a competition out of it! See if you can find them and point them out in the comments! >>
In the core library, I have a set of classes, containing shared logic:
- Configuration: Contains static application settings, such as the Mobile Services Url, its Application Key, shared color settings etc.
- UIDefinitions: Abstract class that utilizes the Configuration to relay native color objects:
- Ninja: The single model class in this project defining a trackable resource.
- IMobileServiceTable: An abstraction over the MobileServiceTable class provided by the Azure Mobile Services Client API:
- ServiceClient: Our Azure Mobile Services interface. This client contains the shared logic we want to execute on each platform, but is kept abstract so that each platform can provide its own implementation of the Azure Mobile Services client API:
Looking at the Service Client, we see that it offers four extension points: Initialize, two versions of LoginAsync (one for the initial login, and one for repeated logins (“keep me logged in”-scenarios)) and a GetTable method that returns an IMobileServiceTable<T>. Using these extension points, the Service Client can successfully orchestrate its business logic and provide one asynchronous method that:
1) Initializes the native client API
2) Log into the Mobile Service through a selected provider
3) Perform a read operation (more on that later)
4) Perform a write operation (again, more in a bit)
5) Perform a callback, passing the list of fetched records.
Using these abstractions, I ensure that the core library is not dependent on anything else than what the core .NET libraries provide me. It’s worth pointing out that – at the time of writing this demo – a PCL version of AMS was not available. It is now, however that doesn’t help this particular scenario much, since we still need to compile our code with separate compilers.
So, why do we just read the entire ninja table from the service and then insert an arbitrary Ninja entity? Well, let me start off by saying that there’s more going on than meets the eye. An Azure Mobile Service is a service endpoint which act as an intermediary to the data we have chosen to store in the cloud. As such, we can intercept calls to its operations to make it act more like a service. Starting with the read operation, it is defined as such:
As can be seen above, the read operation only selects the entities whose group correspond to the requesting ninja’s group, thus enforcing the business rule that a ninja only are able to see ninjas in its own group.
Similarly, the write operation does more than just inserting an entry: .
The insert operation first adds a LastSeen field to the entry being inserted, that could be used for later housekeeping (removing all ninjas that haven’t been seen for a month or what-not). Then, it modifies the given group name, ensuring it’s always stored in upper-case (to make things easier for the select operation). Finally, if a ninja entry with the given user id already exists in the table, it is updated, rather than inserted anew.
OK, back to the world of C#!
How do we implement the ServiceClient and the UIDefinitions? I have chosen to implement the shared code into platform-specific libraries so that my native clients doesn’t have to worry about any details, but instead can focus on their user interface and interaction logic. Also, I have chosen to create links between the core library’s source file and the native libraries instead of binary references. This is because – although I have no external dependencies – the iOS-library (and app) still needs to be built using the MonoTouch/Xamarin.iOS toolchain. However, creating these links is easy and provides you with the same value, as far as code reuse is concerned, as a binary reference. You, simply, create a folder in your project (calling it “Core” in this case), right-click on it and choose to Add – Existing item and then create a link to your source file:
Adding a link means that there is only one source file in your project, but you have two entry points for them. In our case, it means that we can refer to pre-written code in our libraries. If you prefer, you can also ALT-drag files from one project to another, which creates the same links.
Back to the native implementations:
Starting off with the Windows Phone implementation of UIDefinitions, we can see, that all it does, is to simply convert its’ base class RGB-values to a Color instance:
Unsurprisingly, the iOS counter part does the same, but for Cocoa Touch:
Not much code in either of these, but that is also the main idea – the bulk of the code should reside in the core library, so that you – in essence – have one code base that you are able to test with one set of unit tests.
Moving on to the service client implementations, we see that they – too – are kept thin; basically being a wrapper around the Azure Mobile Services native client API:
Although the mostly consist of similar code, note that how we in the iOS library need to pass a View Controller whose View is currently visible to the client API when we are calling the Login methods, so that the client library can properly display the required UI to the user.
The GetTable methods of the ServiceClient returns an IMobileServiceTable<T>. It is defined as such for Windows Phone:
… and as such for iOS: .
That’s it! Now, all we have to do, is to consume our respective libraries in our apps. Both the native libraries (NinjaLocator.WindowsPhone.Core and NinjaLocator.iOS.Core) and the apps themselves (NinjaLocator.WindowsPhone and NinjaLocator.iOS) both reference the Azure Mobile Services client library. In the case of Windows Phone, it was added using Nuget:
And in the case of iOS, it was added using Xamarin’s new Component Store:
Using the libraries we’ve written is as easy as setting the login provider, passing a constructed Ninja entity and then acting on the result set. In the Windows Phone case, we choose to utilize our library as a response to the user navigating to the Page featuring our map control: . We also bind the the foreground color of our Title styles to NinjaLocator.Core.UIDefinitions.ForegroundColor:
Similarly, in the iOS case, we call on our library to retrieve graphics directives and to invoke the service client:
I hope this gives you an idea of how to think when writing cross-platform applications!