Recently I’ve been doing some Xamarin development and naturally once a mobile app project reaches a certain size you need to factor it away from just a hacky prototype app towards a sustainable design that ticks all the SOLID boxes.

I researched a handful of various approaches to adopting the MVVM pattern, which included:

MvvmCross (OSS, also known as “Mvx”)

ReactiveUI (OSS, built on top of the excellent Reactive Extensions / RX library)

At this time the project didn’t warrant spending $999 on Crosslight (and I only assume it must be very good at that price). So I veered towards an OSS solution. ReactiveUI is by far the more elegantly designed when compared to MvvmCross. However its mobile platform support is relatively new and very focused on solving only the MVVM problem. MvvmCross however is more of a framework that helps you in a number of different ways concerning mobile app development, including providing a dependency injection / IOC layer, and numerous platform-specific extensions for Android, iOS etc. MvvmCross is however, in my opinion, a little “rough around the edges” and most definitely has been put together more like a Panzer Tank than a Lotus Elise.

Ultimately I adopted MvvmCross though as it has the greatest level of momentum in the Xamarin ecosystem and this is important I feel.

One big issue with MvvmCross is that it seems to take on the responsibility of providing a really rather crap IOC container implementation. I’m not sure why it doesn’t just depend upon Autofac or TinyIoc or something like that as it seems like 30% of the code in the MvvmCross codebase could be stripped out if it just farmed out that responsibility to another OSS project. Literally everywhere you look in the MvvmCross codebase there are “factory” and “registry” and, uh, “singleton” components everywhere. Maybe Autofac has spoilt me over the years but I honestly can’t remember the last time I had to “hand roll” such a boilerplate component.

So I set about solving this problem by writing a Autofac adapter for MvvmCross. It turned out to be a lot simpler than I first thought, after working through various nuances of MvvmCross.

AutofacMvxIocProvider.cs

I chose to place this type in a separate assembly intended for all my “Autofac for MvvmCross” related extensions. It is a PCL assembly, since Autofac is fully PCL compatible, even with Xamarin.

Setup.cs

public class Setup : MvxAndroidSetup {
private static Assembly CoreAssembly { get { return typeof(App).Assembly; } }
public Setup(Context applicationContext) : base(applicationContext) { }
protected override IMvxApplication CreateApp() {
return new App();
}
protected override IMvxIoCProvider CreateIocProvider() {
var cb = new ContainerBuilder();
// I like to structure my app using Autofac modules.
// It keeps everything very DRY and SRP compliant.
// Ideally, these Autofac modules would be held in a separate PCL so they can be used
// by Android / iOS / WP platforms without violating DRY.
cb.RegisterModule<InfrastructureModule>();
cb.RegisterModule<FeaturesModule>();
// This is an important step that ensures all the ViewModel's are loaded into the container.
// Without this, it was observed that MvvmCross wouldn't register them by itself; needs more investigation.
cb.RegisterAssemblyTypes(CoreAssembly)
.AssignableTo<MvxViewModel>()
.As<IMvxViewModel, MvxViewModel>()
.AsSelf();
return new AutofacMvxIocProvider(cb.Build());
}
}

Conclusion

This enables me to use Autofac unhindered from my Xamarin mobile apps. It allows the codebase to remain consistent by only using one IOC container, which helps minimise complexity, encourages more DRY code and in the future would lower the barriers to getting more developers up to speed with the whole codebase. Autofac is by far the best IOC container available for .NET and having it available for using in Xamarin when coupled with MvvmCross provides a major improvement in productivity for me.