Reaching the broadest possible audience and customizing their experience has always been challenging for businesses developing a mobile app. Investing in and supporting all major platforms comes with its set of obstacles that developers need to overcome to deliver experiences worth remembering and sharing.
From the developer’s perspective, it would be incredibly efficient to write code once and deliver it across every device. While that certainly slims build cost, consider the experience from the user’s perspective.
People are different. They like different things. They drive different cars. They wear different clothes. Experiences delivered on mobile phones are no exception to the degree of personalization users expect. Forcing people to consume an experience that was not tailored for their device (no matter how great) could frustrate them and drive them away. How can development teams tailor the UI for each platform to make the user feel at home?
So much happens beneath an app’s UI.
The code transforms data to present it and help users interact with the functionality. The app communicates with services and devices. It reads and writes files. It keeps track of its state, so users aren’t starting from square one every time they close and reopen it. The Xamarin platform combined with MvvmCross is uniquely positioned to help development teams maximize code sharing by using the Model-View-ViewModel (MVVM) pattern and the .NET Framework.
How MvvmCross Increases Shared Code
According to its documentation, MvvmCross “is a cross-platform MVVM framework that enables developers to create powerful cross platform apps.” The framework is designed for businesses who want to increase the impact of their investment by maximizing code shared across platforms. MvvmCross supports Xamarin.iOS, Xamarin.Android, Xamarin.Mac, Xamarin.Forms, Universal Windows Platform (UWP), and Windows Presentation Framework (WPF).
A typical Xamarin app architecture often looks like this:
This structure allows the business and data access logic to be used across platforms but requires each platform to implement its own presentation logic, impacting how users view the experience. After a while, this can lead to unwieldy UI components that are hard to maintain or objects doing the same presentation tasks on different platforms, the very definition of inefficient.
MvvmCross transforms this model to:
This new structure allows developers to reuse the presentation logic while ensuring the UI components are clean and easy to maintain.
Want to support a new platform? Easy, since developers just need to build the code that presents the UI. However, if the presentation logic is just a small part of the app, the additional amount of code that can be shared could be insignificant. I have seen a lot of charts promising 70-80% code reuse when using MvvmCross. That doesn’t sound unrealistic, and in an average app it is achievable.
Know that achieving the promise of MvvmCross depends on so many variables. In an app that emphasizes UI and has little business logic the view models could be less than a third of the code. So the gains in code reuse are insignificant.
If we are gaining 5-6% code reuse, is it necessary to add all of those dependencies and use a pattern that is not native to iOS and Android?
Apart from code sharing, using MVVM with Xamarin provides a host of benefits designed to increase efficiency.
6 Reasons to Use MvvmCross on Your Next Xamarin Project
Save Repetition with Data Binding
I have lost count how many times I used to write a line like the following to update a UI element:
label.Text = someTextValue;
While the code is relatively minor, when you have multiple connected inputs and changing a value in one of them triggers changes in another, it starts getting a bit repetitive. Databinding helps connect UI elements to the data in a single operation. That way, when the data changes, the UI is automatically updated. This eliminates calls like the above and helps save time in the debugging process.
More Creativity with Value Converters
Data converters allow virtually any type of data to be databound to any type of UI element. It sounds weird at first since it means you can bind a ColorPicker to a Date Object, but sometimes that’s what you want. Converters help when using third-party UI elements, too. For example, if you found a beautiful slider that works only with integers, but you need fractional numbers.
Data converters provide teams freedom and creativity implementing the UI.
Access to Native UI Tools
That is not specifically an MvvmCross feature, but it’s helpful that MvvmCross allows you to use the native designers to create your layouts with tools that are specifically made for this task. With MvvmCross, Xcode Interface Builder and Android Studio can be used with the Xamarin designer.
Better Visibility in Agile Project Management
Being able to separate the UI from the presentation logic enables project teams to write and track more specific tasks. Specificity enables more developers to work on the same functionality. It becomes easier to see progress, identify defects, and resolve issues.
Simplicity Unit and UI Testing
The loose coupling between view models and UI allows viewmodels to be tested as a single unit. Since they do not contain any platform specific logic, there is no need to set up additional platform testing tools on the build server. Any automated UI testing can be handled with Xamarin.UITest locally or on Xamarin TestCloud.
Different UI, Same View Model
This means we can use the UI component that feels native for each platform like UISegmentedControl for iOS and RadioButtons for Android, but it doesn’t end there. We can customize the UI not only per platform, but also per language. Localizing an app always leads to UI that looks great in some languages but has issues like text clipping, wrapping etc. on others.
Being able to show different UI for another language means that you can improve the user experience for a group of users without changing it for everyone.
Should You Use MvvmCross?
Sounds great, right? Well, as with everything, MvvmCross isn’t infallible. Databindings can be hard to debug, so finding a misspelled binding declaration is an event worth celebrating. Having large data sets can consume more memory for the databindings thаn for the data itself. There are ways to avoid this, but they all eliminate databinding which is one of the reasons for using MVVM. MVVM is not a native pattern for iOS and Android which makes writing some glue code necessary.
MvvmCross is promoted mostly for maximum code reuse, but it brings much more to the table.
Even if code sharing is not a priority, I would still consider it a viable option when developing a new app. And with great support and an active community, the library is constantly improving and expanding.
Image Source: Unsplash, Daniel McCullough
