Sunday, December 30, 2012

A short guide to the layers of MvvmCross Assemblies

MvvmCross (Mvx) is very modular in design.

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 -

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.


Just Mvvm

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

Adding DataBinding

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

These assemblies:
  • 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


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:

Another is provided in this slide deck:

A quick start on creating an mvvmcross application

MvvmCross (Mvx) is very modular in design.

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.

One other thing to note: PCL support in the MonoDevelop tools is particularly 'alpha' still right now - so you may find you need to implement 'workarounds' like only using PCLs built in MonoTouch for use on MonoTouch. This situation is slowly improving... but in the meantime, sorry!

This article provides a QuickStart on creating an MvvmCross application.

If this is too shallow, then maybe try the more in-depth guide -

A QuickStart...

Before you start - get your development environment ready for Portable Class Libraries - see


Create a typical mvvmcross 'core' application:
  • Create a PCL project - named MyApp.Core - make sure it is in the magic 'Profile104'
  • Add a reference to the assembly - Cirrious.MvvmCross.dll
  • Add a 'main' App.cs which will own the Services, ViewModels and other classes in the application.
  • Add a Trace.cs file - so that your application trace is easily identifiable.
  • Add a StartupApplicationObject.cs class - which identifies which ViewModel will be shown on app startup.
  • Add a ViewModels folder.
  • In this folder, place BaseViewModel.cs, derived from MvxViewModel
  • In this folder, place HomeViewModel.cs, derived from BaseViewModel
This will give you a set of files something like:

A WindowsPhone UI

To add a windows phone UI:
  • Create a WindowsPhone App project - named MyApp.UI.WinPhone
  • Target 7.1 or 8.0 (or later?!) according to your preferences
  • Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.Plugins.Json.dll and Newtonsoft.Json.dll
  • Add a reference to Cirrious.MvvmCross.WindowsPhone.dll
  • Add a reference to the Core project in your solution
  • Change the App.xaml.cs file so that App inherits from

  • Change the end of the App.xaml.cs constructor so that it creates a Setup object:
            var setup = new Setup(RootFrame);
  • Change the App.xaml.cs file so that ApplicationLaunching looks like:
        private void Application_Launching(object sender, LaunchingEventArgs e)
            RootFrame.Navigating += RootFrameOnNavigating;
        private void RootFrameOnNavigating(object sender, NavigatingCancelEventArgs navigatingCancelEventArgs)
            RootFrame.Navigating -= RootFrameOnNavigating;
            navigatingCancelEventArgs.Cancel = true;
            RootFrame.Dispatcher.BeginInvoke(() =>
                                                     var start = this.GetService<IMvxStartNavigation>();
  • note that for this code to compile, then you will need to add using statements for:
using Cirrious.MvvmCross.ExtensionMethods;
using Cirrious.MvvmCross.Interfaces.ServiceProvider;
using Cirrious.MvvmCross.Interfaces.ViewModels;
  • add a Setup.cs file:

  • add a Views folder
  • create a new page in the Views folder - call it HomeView.xaml
  • change the HomeView.xaml.cs file so that it inherits from a BaseHomeView class which in turn inherits from MvxPhonePage

  • change HomeView.xaml similarly - so that the page inherits from BaseHomeView

A Droid UI

Note: If you haven't already done so, set up your MonoDroid PCL environment - see

To add a MonoDroid UI:

  • Create a new MonoDroid App project - name it MyApp.UI.Droid
  • Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Binding.dll and NewtonSoft.Json.dll
  • Add a reference to the android specific libraries of Cirrious.MvvmCross.Droid.dll, Cirrious.MvvmCross.Binding.Android.dll, System.Net.dll and System.Windows.dll
  • Add a reference to the Core project in your solution
  • Delete the Activity1.cs file 
  • Add a copy of the MvxBindingAttributes file in Resources/Values folder - from - make sure this is marked as an AndroidResource
  • Add a Setup.cs file a bit like:

  • Add a SplashScreen activity and /Resources/Layout/SplashScreen.axml file like:

  • Add a Views folder
  • In the Views folder and in the Resources Layout folder, add a HomeView like


Note: On the Mac to target iOS, you need a different set of MvvmCross binaries - in the release folders on you will generally find 2 sets of binaries - one for using with VS for Droid/RT/WPF/etc and one for MD on the Mac for iOS.

Note: If you haven't already done: You must edit your targets file. See here:

To add a MonoTouch UI:
  • Create a new MonoTouch App project - name it MyApp.UI.Touch
  • Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Binding.dll and Newtonsoft.Json.dll
  • Add a reference to the Touch specific libraries of Cirrious.MvvmCross.Touch.dll, Cirrious.MvvmCross.Binding.Touch.dll, System.Net.dll and System.Windows.dll
  • Add a reference to the Core project in your solution.
  • Add a Setup.cs file a bit like:

  • Change your AppDelegate.cs so that it looks like:

  • Add a Views folder:
  • In the Views folder, add a HomeView using the XIB UIViewController option, but then modify the view controller's inheritance and constructor like:


To add a Windows RT UI:

  • Add a new Windows Store project - Casino.UI.WinRT
  • Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Plugin.Json.dll and NewtonSoft.Json.dll
  • Add a reference to the WinRT specific libraries of Cirrious.MvvmCross.WinRT.dll, Cirrious.
  • Add a reference to the Core project in your solution
  • Add a file for Setup.cs like:

  • Modify the App.xaml.cs file to provide setup initialisation like:

  • Add a Views folder:
  • In the Views folder, add a HomeView like:

  • In the Common Files folder, edit the LayoutAwarePage.cs file:
    • Change it so that it inherits from
    • Change the OnNavigatedTo method so that it calls the base method
    • Change the OnNavigatedFrom method so that it calls the base method


To add a WPF UI:

  • Add a new WPF project - Casino.UI.Wpf
  • Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Plugin.Json.dll and NewtonSoft.Json.dll
  • Add a reference to the Wpf specific library of Cirrious.MvvmCross.Wpf.dll
  • Add a reference to the Core project in your solution
  • Add files for Setup.cs, SimplePresenter.cs, and Program.cs
  • Modify the App.xaml.cs and MainWindow.Xaml.* files

  • Add a Views folder
  • In the Views folder and add a HomeView using 'New User Control' to produce a file like:

  • Because we have added an extra Main to our project, go to project properties in Visual Studio and modify the startup application in the Application tab. Set the startup object to Casino.UI.Wpf.Program

Friday, December 21, 2012

DataBinding dynamic Collections/Lists in Monodroid (and beyond)


The way data-binding works is through an interface called INotifyPropertyChanged

What happens in this interface is that the ViewModel sends the View a message whenever a property changes - e.g.


With a list, this doesn't help if the contents of the list itself change - e.g. when the list has an item added or removed.

To solve this, the .Net Mvvm implementation includes another interface INotifyCollectionChanged.

A collection - such as a list - can implement INotifyCollectionChanged in order to let the View know when the contents of the collection change.

For example, the collection might fire events containing hints such as:
  • everything has changed - NotifyCollectionChangedAction.Reset
  • an item has been added - NotifyCollectionChangedAction.Add
  • an item has been removed - NotifyCollectionChangedAction.Remove
  • ...
There's a short introduction into this interface about 12:30 into the MvvmCross Xaminar


To use this interface for a small in-memory list - e.g. less than 1000 'small' objects - all you have to do is to change your List for an ObservableCollection - the ObservableCollection is a class from the core .Net libraries (from Microsoft or Mono) and it will fire the correct events when you Add/Remove list items.

You can see the source for the Mono ObservableCollection implementation in: - it is worth taking some time to look at this implementation so that you can understand a bit more about how Mvvm works with INotifyCollectionChanged.

If you use the ObservableCollection class, then your code will become:

    private ObservableCollection<MyType> _testList;
    public ObservableCollection<MyType> TestList
        get { return _testList; }
            _testList = value;
            // in vNext use RaisePropertyChanged(() => TestList);


    local:MvxItemTemplate="@layout/my_item_layout" />

  • that the binding is OneWay - this means that binding is still only going from ViewModel to View - there are no updates going from View to ViewModel.
  • that ObservableCollection is designed to be single-threaded - so make sure all changes to the collection are done on the UI thread - not on a worker thread. If you need to, you can marshall work back onto the UI thread using InvokeOnMainThread(() => { /* do work here */ }) in a ViewModel.
  • that in Android, the way lists work (through the base AdapterView) means that every time you call any update on the ObservableCollection then the UI List will ignore the action hint (Add, Remove, etc) - it will treat every change as a Reset and this will cause the entire list to redraw.

For larger collections - where you don't want all the items in memory at the same time - you may need to implement some data-store backed list yourself.

There is a brief example of one simple sqlite data-backed store in

This virtualizing of collection data is common in WP and WPF apps - e.g. see questions and answers like Is listbox virtualized by default in WP7 Mango?

Thursday, December 20, 2012

One awesome thing I forgot to mention.... Flights of Norway MVVM from Jonas Follesø

One of many things I forgot to mention during the recent Xaminar was the Flights of Norway app and tutorial that Jonas Follesø (@follesoe) put together in 2011 -

You can see the code for this in

It would be a good place to start if you wanted to think about rolling your own Mvvm framework.

It is definitely deserving of:

I wish I'd seen that code and talk before I started MvvmCross...

The video is on or embedded below:

Wednesday, December 19, 2012

Cross-Platform, WinRT, MonoDroid, MonoTouch, MonoMac, PCLs and VS2012

I've been asked on Twitter about the latest state of PCLs, VS2012, VSMonoTouch, etc.

There's no way I could do that in 140 characters... so here's a longer answer....

Before you start...

The Productivity tools for VS2012 are essential - install them - tools like 'right-click to edit the csproj file' are incredibly useful!

Loading MonoTouch, MonoDroid, WP, WindowsStore, WPF, MonoMac projects in Visual Studio 2012

By Visual Studio 2012, I mean Professional Edition or better - give up on Express as there is no addin support in the free version.

WindowsStore and WPF projects are all supported out of the box by Visual Studio 2012

WP7.1, WP8 can be supported by adding on the WP SDK -

MonoDroid projects can be supported by buying (or evaluating) the Mono for Android -

For the best MonoDroid experience, you probably want to get the x86 Android emulator working - see instructions at,_Testing,_and_Metrics/Configuring_the_x86_Emulator

Unfortunately I've had a lot of problems getting this running on the same machine as Windows 8/Windows Phone 8/Hyper-V... I hope you have better luck than I do - as a good emulator is a wonderful tool to have.

MonoTouch projects require a little tinkering to make them load - they require VSMonoTouch2012 - a completely unsupported installer for this is available on my SkyDrive account - - some hint at where it came from are on - obviously you install this at your own risk.

To complete the install of VSMonoTouch you also need to follow the steps in the readme of
  •  "Copy the MonoTouch binaries from your Mac development environment..."
  • "Add a RedistList-folder ..."
Warning: See section below on some known issues in VSMonoTouch in VS2012.

For MonoMac/Xamarin.Mac I'm not aware of any way to load these in VS2012 at present.

For older targets like Silverlight and WindowsForms I've not tried anything yet.

Some known issues for VSMonoTouch 2012

I have found VSMonoTouch2012 to be *very* slow when VS first loads a new solution/project - eg. it took *hours* to load MvvmCross_All the first time. After this, however, it seems to work quite well.

The way MonoTouch references mscorlib is slightly different to the Microsoft way, so you may find you need to explicitly reference the MonoTouch mscorlib - see

There are some arguments that VSMonoTouch and MonoDevelop/MonoTouch have over project files. These especially seem to concern the TargetFramework - the fact that VSMonoTouch is set to 1.0 does confuse things (I think). I have seen some projects where I have had to hack in a build step for "The type or namespace name 'TargetFrameworkAttribute' does not exist" - see

One very bizarre problem I've had is with one of my System.Windows surrogate DLLs - for some reason this refuses to pick up my MonoTouch references at compile time (it is OK in intellisense). This has only occurred in one place so far - see the HACK_DO_NOT_FORWARD_ICOMMAND in - background to this is in

Using PCLs

PCL v2 support is included with VS2012.

This includes support for WindowsStore, WP, XBox, etc.

To add MonoDroid, and VSMonoTouch PCL support, you need to add some files (based on

  • Install a file called "MonoAndroid,Version=v1.6+.xml" in "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile104\SupportedFrameworks" with content:

  • Install a similar file called "VSMonoTouch,Version=v1.0+.xml" in the same directory and for its content use:

Note: the VSMonoTouch file is slightly hackier than the MonoDroid one - it points the portable tools at Full .Net v1.0 exactly as the VSMonoTouch plugin does - but I think this can cause some tool confusion sometimes.

After creating these xml files, then you should be able to use PCL projects of profile 104 across all platforms.

There are however some small additional problems you may need to solve at build time:

  1. If you share solutions back to the Mac, then MonoDevelop currently only likes Profile1 at Build time. To work around this, you may find you need to force Profile104 across to Profile1 using a conditional statement in your csproj file. Jon Pepper found this solution - thanks -

    Note that this problem is marked as solved in bugzilla - see - so this fix might be available in an alpha, beta or full release soon.
  2. If you share solutions back to the Mac,and if you have an older MonoDevelop installation, then you may also find that it fails to open .sln files. This bug has been around since May, but is almost fully fixed now. To workaround it you can manually change the .sln to say 11 rather than 12 - see
  3. To make use of some of the namespaces included in PCL you may need to setup shim assemblies to redirect DLL references. I've done this for System.Net, System.Windows and part of System.Xml.Serialization - see

    Note that these projects are quite simple - they just do type redirects from the full .Net assembly names to the Silverlight equivalents (Silverlight/MoonLight is where MonoTouch and MonoDroid started life)

    However, also note that there are some quirky things like public key signing and file renaming that we've had to do in order to get round some issues - see and

    I hope that these Shim assemblies become standard somewhere sometime soon - my versions are MS-PL and I would love to see someone (MS or Xam) take them and ship them more officially.

    For more on why Shim assemblies are needed see -

PCLs and Mono for Android

Using PCLs in Mono for Android inside VS2012 is very straight-forward.

You can easily reference Profile104 projects

You can easily reference Profile104 pre-built assemblies.

Sometimes you need to add the shim DLLs to add support for things like System.Net - but this is a solved problem - just reference the shims from the MvvmCross project and you are there.

However... there are two major problems with Mono for Android and PCLs right now - see
  1. Sometimes you seem to need to build a solution twice to make it work
  2. You cannot debug (breakpoints, step into, etc) inside a PCL
Neither of these problems occurs currently in VS2010 using PCLs and Mono for Android - so maybe it is better to code there if you can.

PCLs and MonoTouch

Using PCLs in VSMonoTouch inside VS2012 is very straight-forward.

One word of warning - if you want to share PCLs at a binary level - then build these PCLs in the VisualStudio tools - not in MonoDevelop. This I think is because of code signing and reference assembly issues.

PCLs and Playstation Studio

I've briefly tried reusing PCLs with Playstation Studio/PSVita.

Project files wouldn't load in PSS

PCL assembly files could be referenced but I got serious errors at runtime - e.g. trying to use JSON.Net failed with horrible Type Exceptions. See

PCLs and Xamain.Mac

I've briefly tried reusing PCLs with MonoMac/Xamarin.Mac.

Project files would load in MonoDevelop, but I couldn't reference them across to MonoMac projects.

PCL assembly files could be referenced but in MonoMac projects, but I got errors at compile time - see

I have been informed that PCLs should definitely work in .Mac - so will try some more.

PCLs and Async/Await

This is not an area I've touched yet - I'm waiting for MonoTouch/Droid official async/await support - then I will work out how to add it into PCLs....

If you are interested, then here is what I know:

PCL v2 does not support async/await.
You can add async/await support to PCL v2 using a nuget package -

But this nuget package does not like the MonoDroid and VSMonoTouch additions. If you want to add the package then the advice is:
If you've modified your profile to support MonoTouch and MonoDroid, then a NuGet package typically won't install because the package doesn't list those platforms as supported.
The workaround is to quit VS, go to the profiles directory and rename the xml files you added, re-launch VS, and then reference the NuGet package
Daniel Plaisted did lots of work around this for his BUILD talk - - the resources for this project include a working MonoDroid async/await sample.

Using nuget

nuget does now contain Portable Library support, but there are some limitations to extending this to monotouch and monodroid targets.

From v2.3 nuget will also contain some monodroid, monotouch and monomac support.

However, this support is very early days - I expect the tools will need some more work to make the experience really fly. I personally intend to invest some time in this - maybe in lobbying, but hopefully in coding (nuget is open source). If anyone wants to join this effort, please do.

I believe nuget when fully working across PCLs, MonoMac, Mono for Android and MonoTouch will be *amazing*

Is it worth the effort? Can't I just use file linking?

Yes, you can just use file linking.

Only you can decide if it's worth the effort.

A very good summary of the pro's and con's is in this Q&A -

I personally love PCLs because they have definitely improved my speed of writing and refactoring code. I'm not claiming that progress is easy... but I am loving using them - so thanks to all in MS, in Xam and in the community (VSMonoTouch and beyond!) who are helping make these better. Indeed, much of the input from MS and Xam seems to have come while 'off duty' :)

The future

I've heard ongoing rumours that Xamarin may have a VS plugin for MonoTouch in development. I believe this was even demo'd live in early 2012... but maybe I was imagining it. Certainly Xamarin have some lovely new products lined up for 2013 - I'm hoping this is part of one of them.

Being able to build all of of PCL, WindowsStore, MonoDroid, MonoTouch, WP, WPF and MonoMac projects within one solution is already amazing today.

Making this support more official (without the VSMonoTouch and PCL reference hacking) and then adding full nuget support would be *fabulous* - I'm so looking forwards to doing single machine binary release and publishing.

Honestly I don't expect this future to arrive in the next month or three... so I do expect anyone who wants to build cross-platform solutions to need some patience and to do some considerable swearing... but the progress in the last year has been remarkable - and we are moving forwards.

MvvmCross today is a single solution containing 120 projects from 7 different project types - it builds, it supports refactoring and it offers me a really stable development environment.

I have gone through setup pain in the past, but this work means I can now spend my time coding - which makes me happy :)


Tuesday, December 18, 2012

Still speechless... the Xamarin Showdown win

Huge thanks to Xamarin for choosing Sphero Ball Control as the Grand Prize winner in their first developer showdown.

To win a prize is always great :)

But in this case it's even more special:
  • because the prize is for code 
  • because the voting was done by a great bunch of developers who I have so much time and respect for; from a team who frequently release totally jaw-dropping awesome software - both in product and in source code form.

To be honest, I hoped I had a shot at winning the Windows Phone prize, but I genuinely thought I had no chance at the big one. Especially when you look at some of the apps I was up against:

Evolve from Bill Holmes - using all 3 Xamarin.Mobile parts on iOS:

Wsh Lst from Jonathan Dick (@Redth) - supporting all 3 platforms, plus web services, plus bar code scanning, plus a website - wow:

Prattle from John Heerman - an Android group messaging app I need (and I love the Darth Vader party invite in the video):

Congratulations to all of the above on their prizes - and more importantly on your great apps and code.

All 3 of the apps above are open source - helping everyone to build apps - check them out:

Today I'm definitely wearing:

Thanks again for the prize!

And while I'm saying thanks.... there's also again to Xamarin for hosting the MvvmCross Xaminar - it's awesome to see them embracing and promoting so many different flavors of C# development.

Today I look at the Xamarin blog and I'm all over it :) Thanks, monkeys!

However.... actually the stuff just off the bottom of the page is much more interesting - check out:
On with the code!

Monday, December 17, 2012

Getting started with Bluetooth development on WP8

I don't know about you.... but I use the WindowsPhoneGeek website a **lot**

.... so I thought it was time I gave a little back!

To help, here's the first article I've written for them - it's about getting started with Bluetooth:

It's mainly based on my BallControl project - but I hope it's a bit easier to follow than the main project - a bit gentler as an introduction into Bluetooth, WP8 and Sphero.

Saturday, December 15, 2012

Sphero under Windows Desktop using WPF

Took about 3 hours to get this running - mainly sorting out lots of MvvmCross plugins - now checked in to

If anyone with some Xaml skill wants to work it better, then please do :)

A second Node Garden experiment

A second Node Garden experiment...

An experiment in node democracy :)

Friday, December 14, 2012

WPF and MvvmCross

Yesterday there was a question on StackOverflow about PRISM....

Although actually it wasn't really about PRISM - instead it was more about 'Could MvvmCross be used in WPF?' and 'Could MvvmCross support more complicated Composite UIs?'

I was pretty sure MvvmCross could - especially given our PCL base and our presenter-based Show mechanisms.

So I set about providing it....

And a few hours later - I've checked in some code :)

More details in the answer:

And a video of it in action:

Thursday, December 13, 2012

MvvmCross Video Presentation - Xaminar today

Xaminar today....

Video at:

Slides at:

I didn't say everything I meant to.... but I still overran by 30 minutes (on a 30-40 minute target)... long live the dinosaurs...

Update I've uploaded the middle part in HD to - hope that helps - HD:

Tuesday, December 11, 2012

2 spheros 1 lumia

Wrote this code when I had only one sphero - got together with a friend...

I was so happy when this code just worked :)

Friday, December 07, 2012

async and await were made for Sphero... and for psy #GangnamStyle

Still having fun with Sphero and C#

Today we decided to add some async/await automation... and to let Sphero dance....

Thanks to async/await, the code for dance sequence is easy - it looks like:

        private async Task Dance()
            await TailTo100Over10();
            await OneSecond();
            for (var i = 0; i < 5; i++ )
                await ZigZag();
            for (var i = 0; i < 3; i++)
                await Sequence1();
            for (var i = 0; i < 3; i++)
                await Sequence2();
            for (var i = 0; i < 20; i++)
                await Sequence1();
                await Sequence2();

We also added multiple Sphero control from the same phone - will show that as soon as the video arrives :) :) :)

Thursday, December 06, 2012

Sphero Ball Control in the Marketplace

Sphero Ball Control now live in the Marketplace

Here's the link:

Here's a demo:

And here's one idea for what we might try to do next:

28 Sphero Holiday Dance: Union Square NYC from Sphero on Vimeo.

Wednesday, December 05, 2012

Announcing MvvmCross Badges of Awesomeness

A lot of people are doing awesome things with MvvmCross.

To celebrate, I'm announcing today:

MvvmCross Badges of Awesomeness

I'm keen to award these out to anyone you know has:
  • developed an awesome app using MvvmCross
  • githubbed an awesome MvvmCross extension or plugin
  • blogged an awesome bit of MvvmCross information
  • presented an awesome session on MvvmCross
  • done something else Mvvm and/or Crossie which is awesome....

I'll be awarding the first batch of badges in the next week... and I'll be posting about each and every badge award here on the blog - probably on a special page.

I'm hopeful this will help spread the word about awesome things developers can do with MvvmCross and also help customers find skilled contractors too - because we are worth it!

If you think you deserve one or more badges - or if you know someone who does - please let me know! If you think someone is awesome, then they probably are.

Tuesday, December 04, 2012

Sphero Ball Control for Windows Store apps - a nice hack but a sad story :(

I've ported the Sphero Ball Control to Windows Store

However, because Windows Store apps can't access a very full Bluetooth stack, then I had to use a desktop element (a Windows Service) to make the code work.

This means that the app can not currently be submitted to the Windows Store.

If you want to see Sphero in the Windows Store, please write to Microsoft and comment and vote on this thread/issue now:

Here was the demo

Monday, December 03, 2012

How Deep Are Your Unit Tests?

This is one of my favorite StackOverflow questions and answers:

Kent Beck answers:
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we'll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.

As the first comment says:

The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don't always adhere to Test First religiously. But I'm surprised too.

In case you don't know who Kent Beck is:

Sunday, December 02, 2012

Sphero - Ball control - introduction video

Ball Control - hopefully coming soon to the Windows Phone 8 Store :)

Saturday, December 01, 2012

Sphero App submitted to Windows Phone Marketplace

I've submitted :)

My first WP8 app.

Don't know whether it will pass first time!

Below are some screenshots


Friday, November 30, 2012

BallControl - an open source Sphero C# controller - WP7, MonoDroid and hopefully MonoTouch (and WinRT?)

Meet my latest open source project - meet BallControl for Sphero:

Here's a first video I made for the project - sorry about the low audio volume!

Xamarin the Native, Sphero the Ball and Lumia the Phone....

After a long week of coding, this experiment in sleep deprivation reaches its inevitable conclusion....

- Xamarin.Mobile Picture capture
- Native voice control
- Native accelerometer control
- Native UI with lots of touch
- Native BlueTooth
- Guest Starring Sphero the ball
- Cross platform Mvvm

Xamarin the Monkey....  because going Native matters

Can I sleep now?

Here's the apps first public outing to a local user group:

Some technical info

The project demonstrates Xamarin.Mobile by using Xamarin.Mobile media picker.... But, beyond that it also extends Xamarin.Mobile tackling some elements of several Xamarin.Mobile requests on uservoice:

The Source

The source is on:

Currently, we have:
  • a working WP8 app
  • a working (but ugly) MonoDroid app
  • a non-working Windows Store app - it seems that Windows Store does not yet support BlueTooth SPP devices - which is so bad :(
I will get a MonoTouch app working soon....

I will also post to the WP8 app store soon.

And I will post some more videos soon....

If anyone is interested in how the app was built I did live blog the first 10 hours of coding... see PDF at (or email me for a Word doc). Sorry I didn't blog the whole lot - but there was a lot of code to write... and I did it in 5 days end-to-end while still holding down the day job too.

That's AmazeBalls! How do I get a Sphero:

If you want a sphero, then try:

If you cannot open your WP7 Project in Visual Studio 2012!

For the last month I've been swearing at the Visual Studio 2102 and WP8 teams...

The reason: because when I open my WindowsPhone 7 solutions, then it shows them as "unavailable" - which makes me very very sad - because I have to use VS2010:

However, last night @dsplaisted asked me if I'd tried right-clicking on them and reloading them.

It worked

I can now open my Windows Phone 7 projects in VS2012 :)

Apparently, the problem was:
  • I first tried to open this solution before the WP8 SDK was installed
  • Visual Studio 2012 didn't know about how to open these - so it marked them 'do not open' in my solution options.
I am sooooooooooooo glad I can open all my projects in VS2012 again!

Wednesday, November 28, 2012

If you cannot see WP8 packages in nuget....

Then you need to install a newer version of nuget -

I just wasted 30 minutes of my life trying to work out where the Phone Toolkit had gone and why I couldn't install it... ah well....


An awesome sample - Wish List from Redth

An awesome sample of using Azure Mobile Services, Azure Web Sites, MvvmCross, ZXing.Net bar code scanning and Xamarin.Mobile too:

Source code is on

There might be some blogging on it at and some tweeting from @Redth
  • if I were being critical:
    • it is currently a bit 'code heavy' in the UI layer, 
    • there are some #if things in the core code
    • the lack of portability support in Azure Mobile Services and in Xamarin.Mobile has forced it away from PCL which is a shame
  • but overall:
    • it's amazeballs - check it out!

Tuesday, November 27, 2012

A simple multitouch view for MonoDroid

I needed a multitouch view for MonoDroid (Mono for Android), so I built one :)

I based it on

It seems to work quite well - to see it in action, just include it in your project and then you can use it in your axml or in your C#

The code:

Monday, November 26, 2012

MvvmCross on the TabletShow :)

Thanks to @MrLacey for this tipoff:

What they said (about 30 minutes in):
It's basically an Mvvm framework using the Xamarin tools. It takes it all the way up to the UI layer, so that the only thing you are building is, for example on the Windows 8 side, just the XAML; on the iOS side just the XML that describes the screens; and the same thing on the Android side.
And you're binding - that's it!
Everything else from that UI definition down is all shared code - so you're basically building almost your entire app with shared code. You're just defining the views each time.
There were plenty of "So Cool", "pretty exciting" and "Awesome" comments thrown in - and some inciteful remarks about:
  • the importance of native UI
  • how MvvmCross provides you a native UI
  • how it allows you to swap out views on each platform
  • how it helps lower the cost of native development
  • and about how MvvmCross is ideal for business apps

Thanks to John Sonmez and the Tablet Show team for the nice comments about the 'huge potential for cross-platform development' :)

Sunday, November 25, 2012

Happy 1st Birthday to MvvmCross - How hard can it be...?

It's official: MvvmCross is 1 year old this week!

The MvvmCross story started early in November 2011 when I started work on the Star Wars Kinect social app.

I had a plan to technically build that app using WindowsPhone, MonoTouch and Mono for Android, and I had a basic WindowsPhone prototype that I'd hacked together using TweetSharp and some code-behind... but, beyond that, I really didn't know what I was building or how I was going to do it.

Luckily, towards the middle of the month, MonoCross 1.0 was released. I downloaded it eagerly, and also struck up some online conversations with some of the MX guys, especially Kenny Goers who patiently and skillfully dealt with all of my queries.

Over the next week or two I talked, walked and typed through lots of code. There were lots of prototypes written, lots of emails and code exchanges back and forth, and lots and lots of time spent swearing at compilers, debuggers and phones.

I *loved* what the MonoCross guys had done in trying to put down a rigid MVC structure for their apps - in trying to provide a formal structure for sharing code cross-platform. However, I also hit a few problems with the MVC pattern itself, with the way MonoCross memory management was architected and with the static nature of the MX code base.

To try to work around these problems somewhere around the 25th November, I checked in my first Cirrious.MonoCrossExtensions commit - and Kenny and I again exchanged some emails - especially about memory management, about IoC and about charging forwards...

It was also at about this point that we had a technical meeting inside the Star Wars Kinect project... and at some point during that meeting one of myself or John McLoughlin (imaji on Twitter) said something like:
We could just go the whole way with Mvvm. How hard can it be?
That question hung there for a while....
How hard can it be....?

And so... on the 28th November I ended up abandoning Cirrious.MonoCrossExtensions and commiting the first files into Cirrious.MvvmCross

This was the first proper MvvmCross commit - 'OMG! What haz I done?' - just 280 changed files and 60,000 additions...

The rest, as they say, is history :)

Happy Birthday Mvx!

Thursday, November 22, 2012

ThanksGiving post - Thanks for more Portable Class Library/Portable Library Project solutions for MonoTouch/MonoDroid

On this day of ThanksGiving in the US....


I'm really grateful for some of the input I've gotten recently from Microsoft and Xamarin.


1. Daniel Plaisted at Microsoft has just heroically supplied a detailed idiot-proof solution to the strong naming issues for ICommand, ObservableCollection, etc.

This solution is:

I think this is what you need to do to get around the type sharing / strong name signing issues for portable libraries on Mono:

-> Extract the public key of System.Windows.dll, and put it in the project directory for the Droid System.Windows project:

 Sn –e "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile104\System.Windows.dll" system_windows.snk  

-> Modify the Droid project to delay-sign using the extracted key. Put the following in a PropertyGroup in the csproj file:

<SignAssembly>true</SignAssembly>  <AssemblyOriginatorKeyFile>system_windows.snk</AssemblyOriginatorKeyFile>  <DelaySign>true</DelaySign>  

-> Change the assembly version of the Droid System.Windows project (in AssemblyInfo.cs) to:   

In my testing, I didn't seem to need to disable strong name verification. So I don't think it will present any extra barriers for newbies – once you have these changes made they'll just need to get your code and it will build correctly.

However, if you do run into problems, try running the following from an admin VS command prompt:

 sn -Vr *,7cec85d7bea7798e   

Let me know how this works!

I've tested it - it seems to work really, really well :) This solution is now pushed into vNext at

It seems to solve:

2. The Xamarin team for solving all the issues caused by sln file changes in VS11/VS2012 -

These changes may sound trivial, but they've been making code sharing very hard since May this year - and it's great that I can now dropbox/skydrive share my projects and solutions again now between Mac and PC :)

3. Michael, Alan, Jeff (and others) within Xamarin for fixing the problems with building the new Profiles - including 104 -

I hope by naming a few people I haven't upset anyone else who's helped.

I really am grateful to everyone who's helping  :)

Now... I'm going back to write some more PCL code... :)

Tuesday, November 20, 2012

Merging vNextDialog back into vNext

Firstly.... apologies if these changes cause you any problems... but I've tidied up the source tree in vNextDialog and I think these changes will have positive benefits for all users. So I'm merging the changes back into vNext.

The key details of the changes are:
  • Dialogs
    • I've added a version of Android.Dialog/MonoDroid.Dialog to the source - this is in CrossUI.Droid
    • I've added a PCL library - CrossUI.Core - which contains the shared Dialog/Menu/List code
    • I've moved the MT.Dialog code out of MvvmCross Dialog and back into a CrossUI.Dialog class
  • AutoViews
    • I've added projects for AutoViews - these aren't finished yet... but are a very good step in the right direction!
    • I've added an AutoView sample - based on CustomerManagement. This isn't a 'best practice' sample - it's more a 'here's 3 ways of using autoviews' - so may not be easy to follow yet.
    • AutoViews currently only exist for MonoTouch and MonoDroid
  • Build Paths
    • I've changed the build paths so that all the DLLs build into /bin/debug and /bin/release 
    • Importantly this means it should be easier to do a binary release of MvvmCross again soon :)
    • One side effect of these changes is that you probably won't be able to build both of Droid/Touch at the same time - this is because they will fight over the System.Windows and System.Net Assembly names - but otherwise they should still build individually.
  • MonoTouch project configurations
    • The MonoTouch library projects are now switched to simpler Debug/Release only - I'll try to maintain this as we move forwards! 
If these changes break your code.... sorry

The main things that will need changing to get you back building are:
  • If you were using MonoTouch.Dialog, then you will need to add the CrossUI.Core and CrossUI.Dialog projects and you will need to change some Cirrious.MvvmCross.Dialog.Touch.Elements namespaces to CrossUI.Touch.Dialog.Elements
  • If you were relying on the iPhone/iPhoneSimulator project configurations, then you will need to use the Configuration Manager to adjust these back to simpler Debug/Release dependencies.
Sorry again for making these changes so suddenly... but I was informed today that a new user was having problems building the main tree... and I wanted to fix these problems.

This merge back seemed like the best way to fix them and to provide the best possible platform moving forwards.

Monday, November 19, 2012

Cross Platform .Net Podcast from Jesse Liberty, Jon Galloway and Miguel de Icaza

@JesseLiberty, @jongalloway and @migueldeicaza discuss open source and Mono things including a couple of discussions around MvvmCross and MonoCross :)

Worth a listen - there's lots of good technical info; interesting questions like 'what does Miguel do all day?'; some great phrases like 'the delight of using Native APIs'; an intriguing comment right at the end about a major product launch next year - "a universe of goodness"; plus some interesting background on the relationships between Mono, Ximian, Novell, Xamarin, MonkeySpace, Microsoft and ... of course ... Monkeys :)

For the audio:

For a background post:

Thanks for the mentions :) I really want to know what the product next year is now :)

Saturday, November 17, 2012

AlphaLabs Node Garden - adding speech

My first attempt at a play with the AlphaLabs Node Garden.

I thought using the screen was too much like manual labour - so I thought I'd try voice control.

The verdict - wow, is it simple to add voice control to your apps!

wp8: speech is off until your new language pack has been installed

If you see the error 'speech is off until your new language pack has been installed'

Then this might just be because you've switched your phone from one language to another.

To get over this problem...
  • go to Speech in Settings
  • tap on the language box
  • choose your language (even if it's your existing language)
  • you'll then be asked to download it.... (needs WiFi really)
  • after the download, the phone will need  a reboot...

The speech privacy policy was not accepted prior to attempting a speech recognition

If you are trying to use SpeechRecognition and you see this general Exception - "The speech privacy policy was not accepted prior to attempting a speech recognition" - or possibly you see the "The text associated with this error code could not be found."...

Then the answer is

Basically - try pressing and holding the start key - then getting the user to accept the terms and conditions...

Also, in your own app... it seems like maybe you need to be sure you are requsting the speech recognition in an async call on the UI thread?

Some low light pictures taken with a Nokia 920

I took a Nokia 920 out for a run this morning.

It was a real Autumn day... rainy... overcast... gloomy...

Which made it perfect to test out the PureView floating lens in the 920 :)

These photos are just 'snaps' taken on the run... and the deer in Bushy Park weren't being at all friendly... but I'm definite that 'yes, the 920 has a quite nice camera!'

Friday, November 16, 2012

Aviva - Drive.... An MvvmCross Testimonial

Back at the end of the Summer I got this email through from a Solution Designer in Aviva - a very large UK Insurance company:

Thought you'd like to know that we are using MvvmCross in our RateMyDrive app that is currently being Beta tested:
There's been a fair amount of press about it, and it's even been on the telly:  (fast forward to 9:08)
So a big thank you for the major contribution your framework has made to this project. It has allowed us to share the complex algorithms for deriving the driver rating scores between Android, iOS and Console/Test apps. In fact 90% of the code is shared and easily testable.

This project is still ongoing - - and I think the above quotation says everything you need to know about MvvmCross.... :)

If you've been using MvvmCross, and you have any feedback, then please do send it to me :)

Hackery and WitchCraft - First AutoViews running on MonoTouch too

Following on from the MonoDroid work, I've started pushing some MonoTouch changes now for AutoViews too...

And after only a few hours - mostly filled with Reflection swearing - I now have this list view:

and this Dialog view:

These screens generated from the exact same code and JSON as the Droid UIs in Another update on the Default UI work for MvvmCross....

There's still a lot of code to write... and lots of debugging to go...  especially when I move to release builds on real devices....

But so far so good :)

Thursday, November 15, 2012

Free icons for ASP.Net, WinRT and WP development...

These are some of the icon sets I've used in the past - generally Creative Commons - and always used with attribution.

For maps:

For general use: - preview at:

For WinRT/WP7

- plus SyncFusion have a free set which is growing big now -

- plus BootStrap from Twitter has some interesting icons built-in

Wednesday, November 14, 2012

Updated: Flurry Analytics in MonoDroid

This is a follow up to an earlier post on using Flurry Analytics in MonoTouch and MonoDroid:

The community has spoken and one kind individual (I think it's this one) has contributed this gist back to the community with an extended Flurry API covered:

Excellent stuff - thanks "anonymous" :)

Lists in MvvmCross AutoView - first code :)

I've just completed the first stab at a List AutoView :)

This code still needs a little tinkering with - it will change as we go across to the other platforms, but a basic first pass is in this Gist:

Next up MonoTouch, and then WP and WinRT

Then back to Droid for Tab UIs too :)

Question: Should we try to shorten/simplify some of the MvvmCross class names?

I've done a few demos lately where I've had to write code live...

Doing this has made me pause and think when it comes to writing down names like: MvxBindableLinearLayout

These names seem overly verbose... e.g. wouldn't MvxLinearLayout do just as well?

Some of the names are unavoidable - e.g. MvxBindingTouchTableViewController inherits from MvxTouchTableViewController - but even these could be shortened to remove the Touch part of the name (the namespace already gives us that).

And then... of course... another question is whether Mvx should stay in place as a prefix? It is useful in places to know when you are using an MvvmCross class... but it's not very pretty and can make the code less readable.

There's nothing planned on this in the very short term, but what do people think?
  • Should we go on a big clean through the naming?
  • Should we try to shorten some names?
  • Should we try to remove the Mvx prefix?
  • Should we just focus on getting more code and better code (e.g. tests) in place?
Interested to hear any thoughts people have. Please feel free to leave comments here if you have any


P.S. The main class name which made me pause and think on this topic was MvxActionBasedBindableTableViewSource - it's a good descriptive name, but something like MvxFuncTableViewSource might be easier on the eye ?

Sunday, November 11, 2012

More work on AutoViews for MvvmCross

I've been looking some more at the AutoView code.

In addition to hand-crafted Json, I'm looking at the idea of allowing users to provide a simple description within each ViewModel.

I initially started this by looking at using Attributes, but now I'm moving more towards getting the user to provide descriptive methods, like the one below. This code is now working on Droid - but some refactoring is still needed to properly integrate it and to make it really beautiful.

SSL problems with Microsoft Azure Mobile Services on Mono for Android (MonoDroid)

My main test Android device - a SIM-unlocked Galaxy Note upgraded to ICS - doesn't like any 'Microsoft Secure Server Authority' certificates. e.g. it doesn't like or

This is a problem if you try to use Azure Mobile Services - because https connections to a service like will result in an AggregateException within which (several layers deep) will be a MobileServiceInvalidOperationException with a message saying just 'Send Failure' (derived from ServiceFilterResponseStatus SendFailure)

If anyone else encounters this issue... then below is some hacky code I transplanted from an old demo project. It seems to work.... but could probably be improved to work with just Microsoft Secure Server Authority messages.

This code hacks the ServicePointManager to allow it to accept all HTTPS/SSL addresses regardless of whether or not the certificate is trusted. Don't use this in your banking apps please :)

Saturday, November 10, 2012

Resources from Azure Mobile Services talk - MonoTouch and MonoDroid

I'm just pushing some resources for the Mvvm Azure Mobile Services sample shown at #SixStepsAzure yesterday to:

I'm afraid there's not too much info on this demo available yet and I've only included MonoTouch and MonoDroid code - there is a little in the but generally I'll need to get together with @AzureCoder to sort out more - I don't know how he did the server side wizardry :)