Portable Class Libraries in MvvmCross vNext

The first version of MvvmCross provided an excellent way to share ViewModel, Model and Service code between WP7, WindowsRT, MonoTouch and Mono for Android.

This was achieved using solutions where every project platform had:

• a platform specific UI project containing code unique to that platform (e.g. UI widgets and views)
• a platform specific class library which was exactly the same code across all projects – the only difference between the different platforms was a difference in the project library/build type.

For example, see the TwitterSearch hierarchy:




This type of solution works really well as a cross platform development architecture - it encourages code reuse, its easy to work in and it delivers product :)

However, there are a few things that I feel could be done better:

1. Maintaining the different projects requires manual cut and paste maintenance which is tedious and error prone. There is a tool that can help with this – the Project Linker Synchronization Tool - http://msdn.microsoft.com/en-us/library/ff921108(v=PandP.20).aspx – but it only helps a bit…
2. While the tools from Microsoft and Xamarin were first class, and while plugins like VSMonoTouch and VSMono help fill some gaps, there are still issues with refactoring. Fundamentally the above code architecture forces the project hierarchies to be independent, and this means it is impossible to do automated refactoring across all the hierarchies – and I find automated refactoring a very important tool for development.
3. Because there are separate project hierarchies and separate build projects, it encourages developers to add non-portable code and to add things like ”#define”
4. I expect this architecture will become less maintainable when I try to add Silverlight, WPF, WP8, MonoMac and PlayStationStudio to the MvvmCross platform. 

These portability ideas and questions are of course not new – they have been highlighted and discussed before by many other developers, including lots of notable “big fish” in the cross platform development community:

• http://mono-for-android.1047100.n5.nabble.com/sharing-code-between-mono-touch-and-mono-for-android-td5441681.html
• http://jonas.follesoe.no/2011/07/22/cross-platform-mobile-ndc-2011/
• http://www.slideshare.net/Xamarin/crossplatform-mobile-development-12658651
• http://mono-for-android.1047100.n5.nabble.com/net-versions-why-different-td5521103.html#a5528317

My personal hope for vNext for me is that MvvmCross will be able to achieve portability using the next generation of Portable Class Libraries.

What is a Portable Class Library?

The Portable Class Library tools provide:

• a special class library project type
• a set of portability profile definitions – each of which defines an “API level” which libraries must conform to in order for them to be portable. 

When a portable library project is built, then it builds against a given profile, but it only when the code is linked that the platform specific implementations of those APIs are actually located.

To understand PCLs more, Jeremy Likeness did a great 3 part blog post – see http://csharperimage.jeremylikness.com/2012/03/understanding-portable-library-by.html

What’s needed in PCLs for MvvmCross?


The profile I’ve been using in MvvmCross for my PCL work is “Profile 104”

This profile includes:

• mscorlib 
• system.core.dll 
• system.net.dll 
• system.runtime.serialization.dll 
• system.servicemodel.dll 
• system.servicemodel.web.dll 
• a very small part of system.windows.dll 
• system.xml.dll 
• system.xml.linq.dll 

Almost all of these are supported directly in the MonoTouch and MonoDroid platforms, although a very small amount of type redirection and substitution is needed for System.net.dll and system.windows.dll

This is achieved through using dedicated “shim” assemblies which simply redirect the Type load calls from (for example) System.Net.IPAddress in System.Net.dll to System.Net.IPAddress in Monodroid’s System.dll

You can see this redirection in action for MonoDroid in:

• https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/System.Net
• https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/System.Windows

By using this profile 104, then I have managed to get the solution down to a much smaller size:

 

Moreover, within this solution above:

• builds for all of WP7, Droid and Touch within VisualStudio 
• allows automated refactoring 
• has no manual cut and paste steps required 
• the build executables run on WP7 and Droid straight from the VS2010 environment. 
• Behind the scenes there is now a superb new MvvmCross library and plugin architecture which also uses PCLs – and this makes producing and extending MvvmCross much easier. 

So… what’s remaining to do?


There's one major challenge remaining:

• I can’t yet get this project to build and run within MonoDevelop on the Mac – so I can’t deploy onto an iOS device. 

This is obviously quite a serious problem!

However, the good news is that the latest Beta versions of MonoDevelop do seem to contain some new support for PCL :)

Currently I’m still playing with this support but the initial result looks good – I can at least load the same VS2010 solution inside MonoDevelop - and the PCL projects and their references all look to be present and correct.

I’m currently investigating some problems with incompatibilities between some core System.Core definitions – especially around System.Action and System.Func - and I do still have to find a way to get System.Windows.dll (touch) and System.Net.dll (touch) into the MonoTouch GAC.

However, this feels really close now…. The future is close… and it’s already looking awesome :)