Thursday, January 31, 2013

How do the new Swiss Bindings syntax work? MvvmCross Badge Of Awesome - CheeseBaron

Swiss Bindings have been explained... and they've also been documented and drawn!

Check out:

Totally awesome!

And totally deserving of a Badge of Awesomeness!

Besides which, if ever you are after a MonoDroid control, check out - from ActionBars to HorizontalListViews to SignatureCapture controls - he's got it :)

And he also sent me a Pull request with a spinner fix in it this morning :)

Wednesday, January 30, 2013

Batch Build - Visual Studio can help!

If you've got a complicated solution (like MvvmCross) which has lots of different projects, lots of different configurations and lots of different platforms, then check out 'Batch Build' on the BUILD menu - it helps a lot.

This is now what I use for quickly (well, fairly quickly) building MvvmCross:

Looking at the Code Map

As well as playing with Code Metrics, I've also had fun with the Code Map (new in VS2012 Update 1).

These views all feel a bit complex at the high level:

However, if you look at a lower level - at a class - it can help you get a feeling for what a class does and what the relationships of its methods are.

For example, here's the code map inside the new Swiss Parser:

If you want to have a play, then right-click in Solution Explorer and choose "Code Map"...

One bit of advice: I would start in a fairly small solution if you can - the "Code Map" seems to do several builds and several index operations - so on the whole of MvvmCross it can be a bit slow at times!

MvvmCross is 90% Maintainable?

Following on from last night's WPUG talk by @lawrencegripper I've been having 'fun' with some of the Visual Studio tools, including the Code Metrics.

The good news is that everything is Green:

Now, I don't think this is something to take too seriously... but:
  • at least it 'smells right',
  • at least there's nothing orange or red here,
  • at least even the really complex modules like Binding look OK
  • at least it only took a few seconds to generate
  • and at least it gives me some quantitative suggestions about where I might look to improve the code in the future

If you want to get these sort of stats out of your own projects, choose the ANALYZE menu in VS2012:

If PCLs will not build for you in MonoDevelop for MonoTouch

If you find Portable Class Libraries will not build for you in MonoTouch - especially if you find you get messages about Func, Action, "method not available System.Linq.Extensions.Aggregate" and all sorts of other mscorlib type errors, then the fix for this may be:

This has been reported and fixed before:


But it doesn't seem to want to stay fixed :/

The fixed file is available on:

Monday, January 28, 2013

Why oh why oh why has no-one ever mentioned the Android HierarchyViewer to me before?

The Android HierarchyViewer is a superb tool for debugging Android layout issues.

Warning - this video sounds like an Android...

Thanks especially to Matt at Sequence for teaching me how to use this!

Sunday, January 27, 2013

UITableViewCell - using the XIB editor and MonoTouch

Over the last 3 years of MonoTouch I've seen quite a few posts about how to use the Interface Builder and then later the integrated xCode4 XIB editor in order to create UITableViewCell's for MonoTouch.

Some of my favourite XIB and cell articles have been:

Using these as inspiration, and using my own Mvvm-slanted view on C# mobile architecture, I've developed my own way of working with XIBs. 

This post (and the accompanying video) describes the way I work.

Pleas note that I'm nowhere near brave as Alex York was - I'm not going to call this post 'the correct way'. Instead, I just hope you find it helpful.

If you have some other way of working, please let me know :)



tl;dr - can I watch?

If you want to watch instead of read, then I've uploaded an hour long video (sorry it's so long!) to YouTube:


tl;dr - I can see the code?

If you want to see the code.... then it's in GitHub in:

But for the readers....

This walkthrough is all about a demo Pet Shop Management app

1. Create a basic application

To start with, we have a simple MvvmCross MonoTouch app - just putting everything in one single project.

Within this basic application we have:
  • Core
    • Interfaces - defining the interfaces for our business logic
    • Models -  some Animal classes - Kittens and Dogs
    • Services - some business logic - providing implementations for IAnimalSupplier and IPricingModel
    • ViewModels - we provide 2 simple ViewModel's here 
      • PetShopAnimalViewModel - links an Animal to its Price and also provides ICommand's to allow the Animal to be sold and the Price to be adjusted.
      • PetShopViewModel - provides some ICommands to allow the pet shop owner to buy animals, and provides an ObservableCollection of PetShopAnimalViewModel's 
    • App.cs - a very simple IoC bootstrapper registering AnimalSupplier and PricingModel singletons.
  • UI
    • Empty to start with (no Views)
    • A Setup.cs which just creates the App from Core, and which tells MvvmCross where to find the plugins it needs for File and for DownloadCache (both of these are used in showing images from the web). 
    • A slightly modified AppDelegate - the modifications change the UIKit app startup so that it will create a Setup.cs instance and will then ask MvvmCross to 'NavigateTo' a PetShopViewModel.
  • I never write commercial apps this way - for commercial apps I split the logic out into testable, reusable PCL class libraries -  but for demo, this approach is OK here.
  • The ViewModels here contain too much logic - normally, you'd put the logic in a Model or Service behind the ViewModel - but for demo, this approach is OK here.  

2. Create a Kitten Cell

We want a UITableViewCell which will be used to display Kittens when they are in a Table

2.1 Create a C# class

In order to create the Kitten Cell, the first thing we do is to create an empty class, KittenCell.cs

In that class, we then:
  1. Make the class partial
  2. Change the inheritance of the class to MvxBaseBindableTableViewCell
  3. Add a [Register("KittenCell")] attribute - registering the cell with iOS/UIKit
  4. Add a NSString Identifier for cell reuse
  5. Add an empty BindingText constant string
  6. Change the default constructor so that it passes BindingText to base
  7. Add a IntPtr constructor which passes BindingText and the IntPtr to base
This should create something that looks like:

2.2 Create a KittenCell XIB

With the KittenCell.cs class created, then we can now create an XIB. To do this we use one of the iPhoneView or iPadView templates in File|New - doesn't matter which we choose - they both just create an XIB for us:

2.3 Replace the KittenCell XIB contents with a TableViewCell

With that XIB created, double-click it to open it in xCode4.

It will look like a full page...

We don't want a full page - so we delete it.

Then we use the library (bottom right) to drag a Table View Cell on to the design surface instead:

2.4 Link the TableViewCell back to the KittenCell

We now want to link this Table View Cell back to our C# class - the one with the [Register("KittenCell')] attribute. 

To do this we use the Custom Class property:

NOTE: the xCode property editor has a nasty little trick of losing things you enter into text boxes - to avoid this, please make sure you switch the focus away from text boxes before you change tabs within the property inspector.

2.5 Set the reuse Identifier to KittenCell

This is easily done using the ReuseIdentifier field - this needs to be set to the same as our NSString Identifier used in C# earlier:

Note: generally, I just recommend trying to keep all your names aligned - if you use "KittenCell" for all of the file name, the reuse identifier, the XIB name, etc, then you will find it easier to avoid slippy-finger-typo mistakes.

2.6 Place subviews and set their properties in order to create your cell layout

This walkthrough isn't about how to use the XIB editor itself...

It's just drag/drop and property setting...

So I'll just fast forward to the cell I created:

2.7 Open KittenCell.h in the Assistant Editor

Because of the work we did in 2.1 when we created our C# class, and because of some magic that the Monkeys inside MonoTouch and MonoDevelop do for us, then Xcode will have a file called KittenCell.h available.

To see this file, highlight the TableViewCell in Objects (left middle), and then choose View|Assistant Editor|Show Assistant Editor in the menu.

The Assistant Editor will show the KittenView.h file like:

2.8 Create Outlets for the subviews we've created

As far we we're concerned here, Outlets are just links from the XIBs back to private C# properties back in our KittenCell.cs class.

To create them, choose one of the following mechanisms in order to find the "New Referencing Outlet" option:
  • Right-click (or Ctrl+Click) on the child view in the Objects pane
  • ... or ... Right-click (or Ctrl+Click) on the child view in the design surface
  • ... or ... Select the child view in either the Objects pane or the design surface, and then choose the Outlets tab of the Properties pane

Once you've done this you can then drag the + across from the "New Referencing Outlet" into the KittenCell.h file shown in the Assistant Editor:

When you drop this link, you will be asked for a name - use a sensible C# Property name - e.g. KittenImageView for a UIImageView which we will use to show the Kitten's Image from the web:

Once we've done that for all the subviews in our current design, the Xcode display should look a bit like:

2.9 Back to MonoDevelop and C# - a designer file

By this stage, our Cell is pretty much finished :)

So now, we need to choose File|Save in Xcode.

Then we can switch back to MonoDevelop.

When you do, you'll notice that MonoDevelop is a bit sluggish to respond...

... and if you look at the status bar, then you may see some messages about things like 'Updating from Xcode'

After a couple of seconds this sluggishness will end, and you'll notice that the Xamarin monkeys inside MonoDevelop have now created a KittenCell.designer.cs file which contains properties which map to the Outlets we created in the designer:

2.10 Bind the UI to the ViewModel

In this walkthrough, we simply add some C# public properties and some simple MvvmCross Swiss-format binding text to hook up the C# cell to these properties.

This creates code like:

  • we haven't hooked up the UIImageView yet - we'll do that 'soon'
  • we have just used very simple int and bool Properties here in our KittenCell for things like Price and IsLitterTrained. In full maintainable code, I would often use ValueConverter to help with some of these - but that's a separate article.
  • If you aren't using MvvmCross, then you'll have to replace this step with some alternative - e.g. you could just use some kind of SetKitten(Kitten kitten) method which you can code to set the UILabel properties like Text, Hidden, etc.

3. Add a DogCell

To add a second type of cell, we just repeat the same steps...

At the end you'll end up with something like:

With C#

4. Adding the 'View' UIViewController - again using XIBs

We now have our:
  • Core code with Models, Services and ViewModels 
  • KittenCell - XIB and C#
  • DogCell - XIB and C#

So the next step is setup a 'Page' or 'Top Level View' - an MvvmCross 'View' to show a UITableView in which we'll list the pet shop's Stock.

4.1 Create the iPhone UIViewController

Use File|New in MonoDevelop to create an iPhone View Controller called PetShopView

This will create a UIViewController - which is three files:

  • PetShopView.cs
  • PetShopView.designer.cs
  • PetShopView.xib

However, because we're using MvvmCross with binding, we want to change this to an MvxBindingTouchViewController

To do this we edit PetShopView.cs so that:

  • the class inherits from an MvxBindingTouchViewController templated on a PetShopViewModel
  • the constructor in  so that it uses an MvxShowViewModelRequest.

4.2 Design the UI - edit the XIB for the PetShopView

Double-click on PetShopView.xib in order to open the XIB in Xcode.

This time, we will keep the basic 'full page' layout handed to us by the wizard.

For content design, we'll then add two subviews - a UIButton at the top and a UITableView beneath.

If you watch the video, you'll also see how we 'dock' these so that the UI can be used on 4" iPhones as well as 3.5" ones.

4.3 Create an Outlet... and also an Action

Within Interface Builder (Xcode) we can use the Assistant View again along with Right-Clicking in order to add:

  • an Outlet for our UITableView called TableView
  • an Action for the UIButton sent event TouchUpInside called AddButtonClicked

With this done, our interface design is complete - so choose File|Save in Xcode 

4.4 Back to MonoDevelop - let the Monkeys generate a designer file

Switching back to MonoDevelop, you'll see another short delay while the Xamarin Monkey's do their wonderful work.

They'll regenerate the PetShopView.designer.cs file for us - and it will now contain:

Note that the Action has been integrated as a C# partial method - these are 'optional' methods in C# partial classes. This is not a commonly used language feature - well, I've never used them much - but they're a very nifty way of working here with these Interface Builder actions.

For more on partial methods, see

4.5 Handling the Add Button press

To handle the Add, we simply implement the partial Action method in our main PetShopView.cs class file.

In this sample we choose to implement this using an UIActionSheet:

4.6 Implementing the TableSource

All UITableView's need a UITableViewSource to supply their data and their cells.

In our case we add this using:
  • A nested class that inherits from MvxSimpleBindableTableViewSource
  • During its constructor
    • This source uses tableView.RegisterNibForCellReuse to register the KittenCell and DogCell XIB files (these get compile to NIB files)
    • This source also sets up some simple animations which happen during adding and removing cells - these animations are automatically triggered from ObservableCollection.
  • The Source overrides GetOrCreateCellFor 
    • in order to select the correct cell type Identifier based on the data to display
    • and then uses tableView.DequeueReusableCell() in order to ask the UITableView to either get a new cell or to reuse a pooled one.
  • The class also overrides GetHeightForRow in order to accommodate our different cell heights.
In code this is:

Note: this code may surprise semi-experienced MonoTouch developers. The reason is because these particular overloads of RegisterNibForCellReuse and DequeueReusableCell calls were new in iOS6.

If you want to learn more about the new API try the excellent UICollectionView seminar at

4.7 Data-Binding the TableSource

We now need to hook the TableSource up to the UITableView from the XIB, and to the Stock ObservableCollection from the PetShopViewModel

To do this, we just add some code to the PetShopView's ViewDidLoad method:

5. Run!

Finally we have our complete:

  • Core - with Models, Services, ViewModels, App
  • UI - with DogCell, KittenCell and a PetShopView

When we hit 'Run' we can see our UI and we can interact with it to add Kittens and Dogs:

Note that the Dogs and Kittens are displayed in different Cells with different heights:

6. Adding Images and UI for the PetShopAnimalViewModel ICommands

I'm not going to go through this in detail - you can watch the video if you need detail.

All I will say here is that:
  • we can now iterate over our XIB design and our CS code.
  • for images we can add an MvvmCross helper object - MvxDynamicImageHelper using UIImage - which can fetch the HTTP images for us
  • for the ICommand's we can use auto-properties on the Cell combined with Interface Builder Actions for button presses.  
For KittenCell, the interface and code that this editing creates is:

7. A Finished Sample

With everything completed, we now have:

  • testable, reusable business logic
  • a UI generated from XIBs 
  • including Cells
  • including a PetShowView 'Page'
  • dynamic delightful behaviour including simple animations and touch interaction


Want to know more?

I hope this walkthrough has been comprehensible - and fairly well self-contained.


If you have read, then it might be worth watching too - as I work I do talk about some problems I sometimes encounter - and you get to see some genuine problem solving while I talk.


If you want to know more about MonoTouch - or about iOS coding - then I recommend - their documentation team is superb.

Indeed, much of what I've learnt about how to use Tables, Cells, and Sources came from Mike Bluestein's articles, blogs and videos - thanks Mike!


If you want to know more about MvvmCross, then check out the repo - - or check out my Xaminar on the topic -


And if you've got questions, then please ask them on StackOverflow -


Thanks for reading!


Final note: Beyond UITableView...

This walkthrough is all about UITableViewCell and UITableView.

However, the same techniques can be used for the newer UICollectionViewCell and UICollectionView - and these CollectionViews are one of my current favorite toys - I love them!

Further, very similar techniques can be applied for any UIView you might want to load from an XIB rather than from code.


If anyone from MonoDevelop or Xamarin reads this...

There are some things you could do to which might make this process easier....

  • publish some additional UIView/XIB File|New templates which produce the partial classes and XIBs together (possibly even generating combined iPhone and iPad XIBs)
  • consider creating the Outlets as internal or public - then I can more easily bind to them in MvvmCross
  • consider changing the generated Actions to internal or public  ICommands or EventHandler delegates - then I can bind to them more easily :)
  • provide some buttons or menu options that allow me to manually request Xcode file regeneration (in both directions)
  • publish more documentation on this - to replace this shambles of an effort :)

Thursday, January 24, 2013

Data Binding to specific positions/keys in list and dictionary collections in MvvmCross (MonoTouch, MonoDroid, WP, WinRT)

An issue came in recently request we support indexing for databinding -

To support this, we added a new parser for the source property path binding and the end result is lovely.

As a result, the tip of MvvmCross vNext on Mono for Android now supports Array/IList[T]/ObservableCollection[T] indexed bindings like:

And Dictionary[T1,T2] bindings like:

On iOS/MonoTouch those same bindings look like:

If you want to see this in action, check out the 'specific positions' demo on (some info at

Work In Progress - MvvmCross lists sample

I'm working on some new sample code (slowly!)

A preview of this content - with very bad audio - is at:

I will blog more fully about this soon... and I will add some CollectionView as well as TableView code... but in the meantime, here's a screenshot and the code behind it:

Special thanks due to Mike Bluestein for his Xaminar on iOS6 and UICollectionViews - I learnt a lot watching and listening to it - - and need to watch it a few more times yet!

Monday, January 21, 2013

Introduction to the new "Swiss" Binding Syntax


The syntax in this post was from the prototype.

We've now fixed on a new slightly different syntax - which is basically:

    Target Source.Path.Here, Converter=name, ConverterParameter=value, FallbackValue=value

You can see this in use in

More details in a more detailed blog post "coming soon"...



As I'm sure many of you know, binding in MvvmCross is declared using JSON syntax - parsed using the PCL version of the wonderful JSON.Net

I love this JSON binding syntax - as it's reliable, robust, easy to learn, and because it gave me a powerful parser (including things like character escaping) for "free".

However, over the last few months, there have been a few suggestions about ways to make the binding syntax more readable for MvvmCross on Droid and Touch 

A couple of us - @opendix and myself - have taken these ideas and evolved them into a prototype - into "Swiss Binding".

This prototype is available today within the vNext MvvmCross tree.

In it, you can choose to switch the binding syntax from:

                  'Converter':'Converter Name 1',
                  'ConverterParameter1':'Converter Parameter 1', // a quoted-string, Int64, double, or bool
                  'FallbackValue':'FallbackValue1', // a quoted-string, Int64, double, or bool
                  // etc


    TargetName1 * Source.Property.Path1 
          Converter='Converter Name 1',
          ConverterParameter='Converter Parameter 1',
          FallbackValue='Fallback Value 1'

Where the * is a choice between:

- although there is also the option to use (Mode=BindingModeName) instead if you prefer not to use these symbol shortcuts.


To show you the effect of this, let's look at some sample code.

The TipView bindings in JSON are:

in Swiss these bindings become:

or you could use spaces to specify default binding if you wanted to - in which case the above example becomes:


Similarly in Droid a xml, the switch would be from things like:


or (if you are happy using default binding modes) just to:

If you want to experiment with this… then:

  • You can do this quickly and easily using a line in your app initialisation like:

  • You will need to switch your entire project over to the new format - you can't mix old and new.

An example project using this syntax is TwitterSearch - check out both Touch and Droid in


What if I have some feedback?
What if I don't like this syntax?
  • If you don't like it… then don't use it!
  • The old reliable, well-documented JSON syntax is still available
  • Or you could quite quickly write your own syntax too… the source is there if you want to try and Dependency Injection gives you an easy way to inject your implementation…

100% Awesome - MvvmCross on Xamarin.Mac - definitely an MvvmCross Badge of Awesomeness moment!

Kevin Knoop's posted this video:

He's also posted the code as a pull request - but I'm not pulling at the moment because there are some blocking problems with PCLs in Xamarin.Mac - - will pull as soon as we can get these sorted :)

Kevin Knoop - @deapsquatter - wow - thanks - definitely an MvvmCross Badge of Awesomeness!

Sunday, January 20, 2013

New year, new projects - and loving it!

For the last couple of weeks I've been kicking off a new big project - it's top secret for now so I can't tell you much about the actual contents of it…

What I can say, though, is that it's an MvvmCross project built on top of all of WinRT, WP7/8, Mono for Android and MonoTouch.

It's being built with a .Net dev team - some young guys who've clearly got a lot of Win8 and WinPhone expertise and who also know their ASP.Net Mvc, know their Umbraco and know a wide breadth of Azure too - not just web and blob, but also more specialist things like the shiny new Media Service APIs.


So why am I teasing and boring you with this information?

Well, because it's **good news**.

It's been really interesting to step back and become a user of MvvmCross - to be working with some great .Net devs who've not seen MvvmCross before, and to experience some of the plans and pleasures of kicking off a new project. It's also been very interesting to find myself writing more of the iOS/MonoTouch code - spending more time in MonoDevelop and trying afresh to use things like the XIB designer in xCode.


What have I learnt:

1. The MonoTouch MvvmCross support had definitely slipped behind the other platforms a bit - a situation I've started to rectify by revisiting some of the View classes - especially things like Image, Table and Collection. I think we've now got already got much better support for those - and I'll be sure to keep doing more code and more samples in MonoTouch again from now on.

2. There are some pain points in setting up MvvmCross cross-platform - especially with all the nonsense surrounding PCLs. However… I've been really impressed with the fact that the professional devs I've been working with have just gotten on with it. If there's a 10 minute setup and that setup requires manually fixing something like the PCL build path on the Mac, then they just do it - and then they get on with coding their app.

Of course, one potential problem here could be the risk that 10 minute setup tasks can go wrong - and if 10 minutes ever turns into an hour or worse, then that's when there's a risk of the dev just giving up…

Clearly, Iweneed to think about this…. and we need to up the quality of the documentation and the setup instructions. If anyone else wants to help with this - especially by blogging about how they've got things working - and how they've solved any issues - then please do. If you share information that helps other devs get started, then 'the law of averages' (or Karma) will one day complete the circle - one of those devs will one day maybe post a sample, answer a stackoverflow question or somehow produce something that helps you out…

3. C# devs need resharper. Really they do. And if you're consuming code written using resharper,  then that's doubly true.

For example, the number of namespaces inside MvvmCross… means Alt+Enter for resolving namespaces is really needed!

If you don't have devexpress or resharper or similar, then buy it for your dev work today - it'll pay you back inside a couple of weeks (if not sooner)

4. The Mono toolflow isn't as good as VS2012 with Resharper. 

However…. it is actually really rather good :)

MonoDevelop has come a long way since I first used it 3 years ago - the built-in editors, intellisense, refactoring, designers, debugger, etc are all good - and even sometimes excellent. Obviously as a PC user I sometimes feel lost with the mac keystrokes… but the reverse is also happening - it's not that unusual to find me missing some of the Mono tools when I switch back to the PC….

Also, things like the XIB integration on MonoTouch are pretty good at the moment - I can design dynamic data-bound resizing new UICollectionViewCells really quickly and nicely right now. I'll post some blog posts on this soon!

5. MvvmCross really needs a build server and a binary distribution… I'm still working out how to do this - bear with me…. or volunteer to help!

6. The overall approach of MvvmCross/MonoTouch/MonoDroid/WindowsPhone is really good for dev - and it's really quick for existing Mvvm devs (from Prism, MvvmLight, Calliburn, etc) to pick up.

I really very much LIKE the way MvvmCross encourages users to separate out their code - it encourages us to use IoC, it encourages us to write tests, and it allows us to spend our time worrying about our code architecture. Really, this has been eye opening to me… it's reminded me of why we started using a framework in the first place.


So that's it. I just wanted to blog what I've learnt these past few weeks. It's basically a BIG THANKS to the dev team I'm working with - they've taught me heaps; and the project and team have helped me fall back in deep, deep love with MvvmCross again.


Now enough of that…. back soon to talk about some new features and more for the future :)

Thursday, January 17, 2013

Avoiding the VSMonoTouch/VS2012 slowness - deserving of a badge of awesomeness!

I've just received this advice from AlphaPage about how to avoid the very slow loading (3 to 4 hours) of the MvvmCross solution when using VS2012 with VSMonoTouch...

It's definitely deserving of....

Awesome - thanks - AlphaPage!


If you want to quickly open the solution in VS2012 for the first time or when you rename the solution folder, here is how I do:
  • in Run dialog box, open : "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" /safemode
  • open the solution (VS2012 will load Console or wpf projects only because of safemode)
  • close VS2012
  • open the solution in "normal mode"
  • reload projects in each folders except Samples folder You are done within less than 5 minutes.
If you want to open projects in Samples folder, disable VS2012Monotouch addin, restart VS2012 and proceed.

Then enable VS2012Monotouch addin, restart VS2012 and load the Touch UI project only when needed.


Touch library load quickly (no problem), but Touch UI project uses IphoneSimulator or Iphone configuration instead of AnyCpu.

I don't know why those projects are so slow to load, but if you change config to AnyCpu the project loads quickly (bug 1).

But another problem is if you don't unload all Touch UI projects, any project (even non Touch UI project) will reload very slowly (bug 2).

I mean if all UI Touch projects are unloaded, you can unload/reload other projects quicly except UI Touch project of course. But as soon as you load 1 UI Touch project, loading/unloading another project except UI Touch project becomes very slow.

Finally, I suspect VS2012 to reload all (or some) projects each time you reload 1 project resulting in cascading reloads and unnecessary loops (bug 3).

When you open the project for the first time, another feeling is that VS2012 is also waiting for some dialog box results in the background delaying the process depending on a timeout foreach dialog, but this is my opinion.

Hope this helps.

Friday, January 11, 2013

Help collecting VSMonoTouch VS2012 performance issue data

Anyone who wants to help with reporting the slowness of VSMonoTouch inside VS2012 to Microsoft. The slowness seems to be to do with the number of configurations.
If you want to help, then you can run the same steps I'm going to - getting multiple traces may help nudge MS along :)
Greetings from Microsoft Connect!
This notification was generated for feedback item: Really slow to load solutions when using many projects with many profiles. which you submitted at the Microsoft Connect site.
Hello, to help us further investigate could you our feedback tool while opening the solution?
To use the tool:
1. Install the feedback tool (restart VS)
2. Load the solution
3. Choose "Report Bug" on the help menu (login with Live ID)
4. Choose existing feedback, and enter this bug number (775466)
5. Choose "Performance" from feedback type
6. Close the solution
7. Open the solution
8. Stop recording and submit the bug
Be sure to open the solution before choosing "Report Bug" to ensure we get details about the solution itself.
Thank you for your help.
You may receive a general "Feedback Item Updated" notification as well, if any other changes were made by Microsoft.
Thank you for using Microsoft Connect!

I will run the tool - but if others want to as well, then please do :)

Monday, January 07, 2013

Almost portable binaries....

I'm sure that those who've followed the mvvmcross story so far are already well aware of my ongoing campaign to get more and more portable class library code running across all the Mono platforms - Touch, Droid, Mac, PSVita,... :)

One thing I'm worried I may have mis-stated recently is the binary compatibility of portable class libraries right now.

It is true that I've successfully used the portable Newtonsoft JSON.Net as a binary across a lot of platforms - and it's worked well for me - that's what I meant to state.

What I shouldn't have implied was that all portable binaries will work well for you - they won't... not yet...

For mvvmcross binaries, in particular, please do *not* try to use the MvvmCross dlls built on Windows (for WP, WinRT and MonoDroid) on the Mac for MonoTouch. These sadly, don't work, because:

1. There are often problems at build time - with 'reference assemblies' that MonoTouch MSBuild doesn't yet understand
2. There are then problems at run time - with things like mscorlib issues (see

Instead... you must build the portable libraries for MonoTouch instead....

If you don't want to build - if you want an unofficial set of debug binaries instead... then today these sit in a skydrive folder: - note that there are two portable folders: portablePC for VisualStudio projects and portableMac for iOS MonoDevelop projects.

Some new year's resolutions for you:
  • I will try to work on getting official releases of mvvmcross out and published
  • I will try to get these released via nuget too
  • I will keep reporting issues to MS and Xam about PCLs - in the hope this leads to better and better support.
Sorry, the PCL situation isn't yet really good. The situation today is way better than it was a year ago... but there's definitely still things to do!

Friday, January 04, 2013

Overriding the view lookup convention used in MvvmCross

Following on from a question on StackOverflow -

If ever you want to override the default viewmodel-view lookup setup, then you can do so by overriding the GetViewModelViewLookup method in your Setup class.

The default lookup table is generated by:
  • enumerating all the Types in the Setup.cs Assembly
  • removing any which don't implement IMvx-platform-View
  • removing any which are abstract
  • removing any which start/end with the word Base
  • removing any which are marked with the Unconventional attribute
  • removing any which are marked with the ConditionalConventional attribute and who's condition fails (this is used for e.g. iPad vs iPhone selection - see Sharing ViewModels for different Views)
  • finding the ViewModel property on each remaining Type
  • removing any who's ViewModel PropertyType starts/ends with the word Base
  • removing any who's ViewModel PropertyType is an interface
  • listing the remaining {ViewModel PropertyType, View Type} as a Dictionary lookup.

If you wish to replace this algorithm, you can - just override GetViewModelViewLookup

For example, at a trivial level, you could just hard code the ViewModel-View list:

This hard-coded list is actually what the very first versions of MvvmCross did - and it does have a small performance advantage - it makes app startup a bit quicker.

For a slightly more complicated example, you could generate an alternative list based on several assemblies, and could then supplement that list with some conditional logic:

MvvmCross Badge of Awesomeness #2 - a Sqlite plugin for Windows

This morning I woke up to a pull request from Dave Leaver in NZ.

It was for a SQLite plugin implementation that will work for Console projects - but which will also work on Wpf projects too :)

And  Dave's also given a quick bit of help on how to use it:

I'm delighted to say that this earns Dave Leaver from ironshod, the second ever MvvmCross Badge of Awesomeness!


Thursday, January 03, 2013

A Mono for Android WrapPanel/FlowLayout

I needed an Monodroid WrapPanel... and luckily revcom and CheeseBaron had already done one on - using the original (under Apache) from Romain Guy's code on Google Code:)

All I needed to do to make it work in MvvmCross was to add the binding code from the LinearLayout :) 

Wednesday, January 02, 2013

Navigating between ViewModels by more than just strings...

One of the questions that has come up a few times on StackOverflow is about why MvvmCross insists on using Strings for ViewModel navigation parameters.

The answer to this has always been that these are used in order to ensure that the navigation can be serialised down into a Xaml Uri or into an Android Intent. e.g. see the question and answer in

The good news is that from a checkin on New Year's Eve, strings are now not the only option - you can now use:
  • string
  • long
  • int
  • double
  • your own custom enums

To see the changes that enabled this, see the commit at:

For an example of integer use, see the way I modified the Conference sample:


These changes, however, still ask the user to use lists of parameters.... and these parameters lists can get quite long...

One request on Jabbr was:

  • gshackles:

    one of the things I don't like is that i'm just passing these anonymous objects around with magic properties

    would prefer to have a class for the parameters to a view model and just pass that in

    would also make it much more resistant to refactoring too

This seemed like a very reasonable request.... and the good news is that you can add this yourselves by:
  • overriding the way navigations are requested 
  • and overriding the way ViewModels are located.

Here's one way to achieve this:

First, create the base type for all your navigation parameter objects

Then modify your BaseViewModel (or ViewModelBase) in order to allow it to support this parameter object navigation

Now modify each of your view models so that they have a new NavigateTo method - which either take no argument or which take a class derived from NavigationParametersBase:

Now, create a default ViewModelLocator which can deserialise the incoming NavigationParameters and can initialise the ViewModel:

Note that this method uses a new deserialise method - only just added:

Finally, to make sure that the locator is used, override CreateDefaultViewModelLocator in your MvxApplication:

That's it.

Obviously, there's more that could be done - and different ways in which the ViewModel could be initialised - but this is a basic start which others can build on if they want to.

Tuesday, January 01, 2013

MvvmCross Badge of Awesomeness #1 - fixing the CheckboxElement

Happy 2013 to everyone out there.

I'm delighted to say that the first ever MvvmCross Badge of Awesomeness goes to Jason Waterman - h2oman

Thanks Jason for analysing and fixing a bug in the Mvx CheckboxElement port from MonoTouch.Dialog port -