In maintaining and building any large scale application, you need to develop with low dependencies and develop silo’s of responsibility and control. This lends the application to easier testing, less repetition of code, easier debugging and much easier to work on in larger teams.
MVVM Pattern
One of Microsoft’s awesome patterns that fits in so well with XAML and keeping the View and Code completely separate. If you come from a Web background or non-WPF background, get an overview of the MVVM Pattern first.
A brief side note: I highly recommend using XAML for views. For the same reasons you wouldn’t ask someone to code a website in C#, they would use HTML and CSS. XAML is built purely for Views, C# is not.
There are many MVVM libraries to use for Xamarin and each comes with their own opinions.
Low Dependencies
There are more and more packages coming out every day for Xamarin and it really helps in having a package that you can install on all 3 platforms and just use with Dependency Injection.
You can download NuGet packages or go to the Xamarin Component Store.
However as with any packages, if they are free or not part of the core Xamarin experience, there can be problems.
- They go stale – the project owner or even Xamarin might leave the components for months if not over a year without updates or fixing critical bugs.
- They reference Xamarin.Forms. If they do, then each time Xamarin updates the main version line, e.g. 1.4.0 to 1.5.0 then all the references in these packages need to be changed. Some package owners eventually get busy and don’t update their projects.
- If you use a package or SDK to connect to an API, you are restricted in what you can do and also are subject to many breakages. Some large corporation SDK’s are nowhere near as reliable and secure as you might think.
Know Your Dependencies
Dependency Injection is almost essential in cross platform development with Xamarin, however there are 2 main ways to do it.
- Service Locator
- Constructor Injection
The ServiceLocator pattern lets you get an instance of an object from just referencing the type or interface of the object anywhere in your code. But there is a major problem with this approach. It hides dependencies throughout your code and if you don’t initialize or change something, it is very hard to find out where the dependencies for these interfaces or types are, without some effort each time you change it.
Constructor dependency is my preferred approach because it shows you in the constructor what this service depends on. The objects are initialized before they run enter the class and are ready to use. Any errors of an uninitialized service will be very apparent very quickly with this approach.
Silos
One of the main issues to overcome in mobile app development is the flow of information around the app, which is why I like to silo as much as possible leaving communication to another component as limited and infrequent as possible.
While I will explain this in much more detail in future posts, a common silo is the View, ViewModel and Model, talking up and down the chain, no bypasses, and talking to services at the end as needed.
5 Common Pitfalls In Enterprise Mobile Development
Based on my experience, of over 9,000hrs of Xamarin.Forms development, check out some of my hard learnt lessons, in enterprise Xamarin.Forms development.
<< Introduction | Navigation Service (Day 2) >>
Cross platform mobile developer who loves delving deep into frameworks and solving problems.