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