Xamarin: The conflict between the mobile developer and the .NET developer

One of the recent project’s that we’ve been working on is a Xamarin application. In short, Xamarin is a package for the C# and .NET core framework that allows you to write cross-platform applications.

At it’s core, Xamarin reminds me of some of the technologies of the past that I quite enjoyed and as the majority of my work is MVC, it evolves around the web protocols; so I found the change to MVVM and it’s NotifyPropertyChanged methods quite refreshing.

However the main thing that worries me with Xamarin is one little nark, and its a conflict for me. How do I code it?

On one hand, Xamarin is at its core — a mobile application framework. Which means that one side of my head is to code it like a Java developer. On the other hand, we have the greatness of the .NET framework at our disposal, and it seems a waste to do some of the things that I don’t particularly like in commonplace Android development.

With dependency injection in the project, the first thing that comes to my mind is persisting items between screens. Do I pass properties from one to the other, or do I opt for a singleton object whereby I can store these fetchable properties, and ofcourse I could store the object in the application.current.properties too if needs be. This little scenario had our little team divided on how to implement our code.

On one hand passing through objects from screen to screen was simple to implement, and we could then work with private fields inside our class to do whatever logic was needed. However the .NET developer inside me didn’t like the lack of test-ability in this method, that dependencies on each model could be tested more easily if they were held in a singleton that you could mock on the back-end. That way the assignment of fields would only be the responsibility of the constructor of the class and we could go ahead and make the fields readonly too.
It was similar to how we had used actions throughout the rest of the codebase, passing through an action that would be invoked whenever a certain action happened (for example custom things could happen to a page’s OnDisappearing method, because we invoked the action in a base view model class. This felt a bit more like android development with regard to overriding methods inside other classes, which is commonplace.

On the other hand passing through a singleton made testing easy, and mockable objects could be used to simulate different scenarios for private fields on the underlying view model. The problem with this however was that it added extra bloat to our constructors.

The decision ended up coming down to a mobile vs .NET decision and we opted for the passing of objects from screen to screen. In general this has made our application harder to test, and now it feels that more implementation is hidden away in other classes and actions inside parent classes that it takes a lot more class navigation to find the functionality you were looking for. Someone somewhere will be reading this thinking ‘this wouldnt have happened if you wrote your tests first’. Which leads me to the following little statement to take away from this.

When developing an application, use the best practices for the language you are using, not the medium in which the application will be represented in. TDD will help you achieve this, as the tests will dictate exactly how you can write your code.

We are now covering the testing of navigation between screens with automation only.

Lesson learned. Refactor in progress.