Practical .NET

The 5 Essential Patterns in Xamarin Applications

• By Peter Vogel
• 08/31/2018

Back to WinForms
You'll need, for example, to start using the pattern Microsoft calls Model-View-Presenter (MVP). MVP is the default pattern used in Windows Forms, ASP.NET Web Forms and WPF applications (though, of course, you can use other patterns with all those frameworks). Creating native Android and iOS apps in Xamarin using the dedicated iOS/Android UI tools requires that you use the MVP model when building your application's pages.

Applying best practices is essential in MVP because it has several downsides. In MVP, page code contains multiple references to the widgets that make up the user interface: The names of the UI widgets are embedded in the application's code; page code spends much of its time reading and writing UI widgets' properties; page code is often embedded in event handlers tied to widget events.

This tight coupling creates two problems. First, of course, changes to the UI often ripple through the application code, forcing numerous changes in application code. Replacing a textbox widget that accepts a numeric value with a slider widget that generates a numeric value can result in significant changes to code because the two widgets have very different event and property APIs. Second, automated testing becomes very difficult.

To deal with these problems, the best practice in MVP is to put very little code in any individual page and, instead, have page code call methods in Standard Class Library projects. Moving code to a Standard Class Library has the added advantage of allowing you to share code among multiple projects. Recognizing the issues with automated testing in MVP, Xamarin tools include a UI-driven automated testing facility.

Beyond Widgets
While you must still use the MVP pattern if you're using Xamarin.Forms to generate the UI for iOS and/or Android applications, you can limit the amount of tightly coupled code using the Model-View-ViewModel (MVVM) pattern. Unlike the MVP pattern, in the MVVM pattern the UI references properties on a class containing the page code (the ViewModel) but that ViewModel class contains no references to the UI. Changes to the UI just require adjusting the names of the properties defined in the ViewModel class.

When using MVVM, you'll also want to investigate the Command Object pattern. This pattern allows you to bind UI events to ViewModel properties that hold Command objects. Those Command objects, in turn, act as wrappers for methods in the ViewModel.

You can't (yet) completely avoid the MVP pattern in Xamarin.Forms, but your MVP code can be as little as a single line of code to associate your UI with its ViewModel. In addition, there are some activities that will require you to use the MVP pattern when building an app (requesting runtime privileges in Android applications will force you into the MVP pattern, for example). However, those are the exceptions rather than the typical case.

Communicating Between Models
All these patterns can make it difficult to communicate between the pages that make up a smartphone application. The various platforms allow you to pass values between pages as the user navigates from one to another (though you may be limited to the simple data types -- strings, dates, integers and so on -- in some platforms). However, sharing data among pages can become awkward if the pages aren't directly related.

If, for example, you're holding common code in a .NET Standard Library project you'll find that you don't have access the ConfigurationManager object, the typical tool for holding common data like connection strings and URLs. Also not available in Standard Library projects is the MemoryCache object for holding shared data. And, at least for now, the application-wide DEBUG constant doesn't seem to work in Standard Libraries (this may itself be a bug).

There are a couple of patterns that solve these problems. Xamarin.Forms provides support for the Publish/Subscribe pattern through MessagingCenter, for example. This allows one part of your application (your Preferences page) to publish a notice to other parts of the application when "something happens" (for example, the user changing a display option). The main page of the application can subscribe to the Preference page's notifications so that it knows when it must re-arrange its display to reflect a change in the user's preferences.

Sharing data among pages can also be handled through the Singleton pattern. While the Singleton pattern is easy to misuse (some call it "anti-pattern") it makes sense in the single-user environment of a smartphone application when used as a property-rich object holding resources that either never change over the life of the application or are shared among pages.

The easiest way to implement the Singleton pattern is through a static class that exposes properties. These properties can hold constant values including, for example, the URL of a Web Service (or a DEBUG constant). This static class can also have a property that returns a cached object created the first time the property is accessed. This cached object can then hold data retrieved by different pages but, because the holding class itself is static, the cached object provided by the holding class is shared among all pages.

More patterns than these will be required by any application that's more than a demo. However, these five patterns (MVP, MVVM, Command, Publish/Subscribe and Singleton) are the ones that you'll need in virtually every smartphone application you build.