It's deliberately made up of lots of small assemblies rather than a few big ones.
The advantages of this are that it keeps the runtime image size smaller, and that it makes the platform more easily extensible.
The disadvantages, however, are that it can make mvvmcross look a little complicated initially, and that adding 'using' namespace statements in code can feel a bit more awkward, especially in environments where tools like resharper are not available.
This article provides some detail on the assemblies used in an MvvmCross application.
If this is too in-depth, then maybe try the Quick Start - http://slodge.blogspot.com/2012/12/an-quick-start-on-creating-mvvmcross.html
The layers of MvvmCross
The layers of mvvmcross are:
- Cirrious.MvvmCross - the core mvvm and IOC library.
- Cirrious.MvvmCross.Binding - provides binding functionality for platforms which don't have built-in data-binding. Currently this means for all non-xaml platforms.
- Cirrious.MvvmCross.Dialog - provides a link between MvvmCross and CrossUI. CrossUI itself is a branch of MonoTouch.Dialog and MonoDroid.Dialog projects - hopefully these will be joined soon by WP.Dialog and WinRT.Dialog.
- Cirrious.MvvmCross.AutoView - provides an initial implementation of our cross platform user interface definitions. Currently this is an 'alpha' level of functionality only...
- Plugins - each plugin provides functionality for a specific task. e.g. for geolocation, for json parsing, for accelerometer, etc. These plugins are really just a formalisation of how to do cross-platform IoC. Importantly, you can easily build and distribute your own plugins.
If you want to build a simple mvvm app, then you can build this just at the first Cirrious.MvvmCross level.
An app built in this way would:
- include view models and IOC;
- would be able to use
data binding in wp and winrt;
- in touch and droid, there would be no declarative data-binding, but you would instead be able to use C# code which manipulated the ViewModel and which listened to ViewModel.PropertyChanged events.
To add this level of functionality:
- your core app project needs to reference the portable Cirrious.MvvmCross.dll assembly. This portable class library contains the core trace, IOC and mvvm functionality.
- your UI projects need each to reference both the portable Cirrious.MvvmCross.dll assembly and the specific implementation for that platform - e.g. the MonoTouch UI needs to reference Cirrious.MvvmCross.Touch.dll
If you want to use data binding in Droid and Touch, then you need to add the Cirrious.MvvmCross.Binding assemblies to your UI projects.
- For Droid, this means you must add both Cirrious.MvvmCross.Binding and Cirrious.MvvmCross.Binding.Android
- For Touch, this means you must add both Cirrious.MvvmCross.Binding and Cirrious.MvvmCross.Binding.Touch
- enable you to use MvxBind statements in android axml;
- enable you to
use UIViewController-based data binding in Touch;
- include helpers for controls such as android listviews and ios table views.
If you wish to use the image controls within the MvvmCross binding projects, then you will also need to include some plugins within your UI projects - as the image controls rely on Cirrious.MvvmCross.Plugins.File and Cirrious.MvvmCross.Plugins.DownloadCache for downloading and caching image files from http sources.
Adding 'Dialog' UIs
If you want to take advantage of the code-constructed UIs similar (very similar!) to those offered by MonoTouch.Dialog and MonoDroid.Dialog, then you can get this by including both the CrossUI and the Cirrious.MvvmCross.Dialog assemblies.
Further, for the Droid projects, you will need to add the dialog definition files - see an example in https://github.com/slodge/MvvmCross/tree/vnext/Sample%20-%20CustomerManagement/CustomerManagement/CustomerManagement.Droid/Resources/Layout
Adding 'AutoView' UIs
Finally, you can add AutoViews to your app.
This is currently only available for Touch and Droid. And this is only available in Alpha - more testing and more dev is needed.
If you want to define some default dialog or list-based User Interfaces in your ViewModels, and to then let MvvmCross generate the client User Interface - then you can do this using Cirrious.MvvmCross.Autoview assemblies.
Plugins are a formalised method for providing cross-platform IoC.
Basically, each plugin comes with a core PCL project/assembly and then individual implementation projects/assemblies for each platform.
They are quite a large topic in their own right.
One introduction to plugins is provided in my answer to: http://stackoverflow.com/questions/12564272/making-mono-cross-platform-support-for-task-intent
Another is provided in this slide deck: