How Xamarin.Forms Can Take Your Mobile Apps to the Next (Cross-Platform, Data-Driven) Level update from July 2015

This blog focuses on data-driven mobile applications and using Xamarin.Forms as a way to rapidly develop for specific targets (iOS, Android, Windows Phone). In large part, applications that seek to interact with their audience/users need to keep their content rich and fresh. Dynamic-driven content is one way to do this, which makes managing continuous data entry and real-time release of content key concerns.

Xamarin is a solution platform that permits C# developers (admittedly, such as myself) to build rich cross-platform mobile applications using a programming language and integrated development environment (IDE) that are very familiar, thus reducing the learning curve and time to market. Xamarin--which works well across the Microsoft Cloud stack, with templates and packages for Office 365 API, SharePoint, OneDrive for Business and Windows Azure Mobile Services-- certainly offers more than a coders' avenue to mobile development. It also has a testing platform, its own university for learning and much more.  This primer will set the stage for carving out the user interface components (screens, if you will) that will tie back into whatever back end you choose to build against.

Shared Code Base

One of Xamarin's strengths its flexibility.

With most traditional mobile development techniques, you have to code in a specific way for specific platforms.

For example:

In this model, to build one mobile app that targets multiple platforms you will need (a) a team of developers with a discipline in each platform's coding style or (b) a single developer who is (or can become) versed in all of these coding styles. In any case, as you move from development, release and then maintenance, you will have to maintain separate code bases. When it comes to enhancements, not all will be full fidelity--or even needed, for that matter--on all platforms, so you will have different build versions for one application.

Enter Xamarin.

As you can see from the image below, with Xamarin you have one huge “shared” code base that can satisfy all three of the major mobile platforms. This code base accounts for roughly 75 percent code reuse across the platform boundaries.   

While this is all well and good--and will get your applications to market a lot faster than coding for each platform--the question you may be asking yourself is: So, what about the other 25 percent?

The blocks you see in the above image that reference the iOS, Android, and Windows environments need platform-specific code to build out elements that cannot be shared. Usually, these are centered on the user interface (UI) and the uniqueness that comes when dealing with Controls--that is, Views, Layouts and Pages. (We will get to all those in detail later, and you can read more on my personal blog. 

With Xamarin.Forms, you have not only shared back-end code, but also a shared UI code section (see image, below). These combined gains, in terms of shared code, now account for roughly 90 percent to 95 percent of code reuse. That means, in one fell swoop, you can now write code once and build against all three of the most popular platforms. 

It's All about the UI

I think we can all agree that the UI is what sells the app and promotes adoption. After all, it is what the end user sees and interacts with. No matter how good that back end is, no matter how much magic you put in the data layer tier or middle tier, it is the snappiness of the UI and how much you make it pop that will be most remembered and judged.

Xamarin brings to the table:

So with that, let's break out the elements of that UI:

Pages

A page is what you see when you look on your device. It contains a single child element that returns as content. To put this in context on the major mobile platforms:

In the above image you can see a few different pages to choose from; each brings its own level of usability and effectiveness, depending on what you need your application to do.

It's a good idea to mix and match the pages. I've often seen a combination of the Navigation Page as the landing screen, then a Tabbed page with Master Details stemming from that. , in fact as I build my Apps now, I tend to use that strategy. 

Layouts

A layout is a subclass of Views that acts as a container for other Layouts and Views. It typically contains logic to set the position and size of child elements within the Page.

As with Pages, Layouts can be mixed and matched. I tend to put a StackLayout inside a Scroll View so that I can maintain the look and feel of my apps, and have scrolling off the page. The rest of the Layouts are pretty much self-explanatory; more information can be found here on Xamarin's website.

Controls (Views)

Controls, also known as Views, are all the  items you put on the page--things like buttons, labels, entry fields (text boxes) and images. The beauty of Xamarin.Forms is that it compiles all these controls down to each respective platform's specific controls when they are built. There are quite a few Controls available now (see below), and more keep coming out all the time.

 What Xamarin.Forms Gives Us

So now that we have the fundamentals of Xamarin.Foms down, let's take a look at the impact when you pair the platform with a database back end.

As we mentioned earlier, to really make a mobile app take off and gain adoption, you need to provide rich, fresh and up-to-date content. While Xamarin.Forms does not offer everything by way of Control/Views, it is certainly more than enough to create robust, data-driven, cross-platform applications that can be released to market in the space of just a few hours.

Using a Model View ViewModel (MVVM) pattern, you can basically map the elements of Xamarin.Forms with Data Objects and Data Services to perform Create Read Update Delete Query CRUD-Q operations against both RDMS and NoSQL database back ends.  

In the next installment of this post, we will create a real-world use case against a SQL and MongoDB database back end hosted in Microsoft Azure.