You can clone with
HTTPS or Subversion.
To reproduce the error just run the Mono profiler on the Sample - CirriousConference. Select the "Sessions" tab and then select a day and go back, select a day and go back ,.... and then loak at the memory allocation and you will see that even with GC.Collect the memory will not be released and the number of instances of SessionListViewModel will increment.
Is this actually a problem... are you getting out of memory errors occurring?
The MvvmCross framework on MonoTouch frees up these objects when the ViewDidUnload method is called by iOS and then MonoTouch frees up the objects (including ViewControllers and referenced ViewModels) when iOS releases the underlying ViewControllers.
However, there's no guarantee I can see from iOS about when this might happen...
I've looked a bit further... and there is a small leak caused by an Action holding on to a reference too long - will check in a fix for that soon...
BUT... there is also quite a lot to understand about when ViewDidUnload is called - and when View's are "disposed" - it's not when you expect - and not really very predictable...
One thing that might help - in the Simulator you can force some additional garbage collection, by artificially calling Simulate Memory Warning - this causes some ViewModels to get collected (but arguably it effects too many!)
Fix for memory leak - #19
I've pushed the small change - the change is making the WithCommand disposable - see 8fc1af3 - I'm not sure I entirely understand why the Action<> and Func<> were holding up ViewModel garbage collection, but they were...
However, please do note that the garbage won't get collected until iOS decides its time to collect it - the easiest way to get this to occur is using the "Hardware > Simulate Memory Warning" menu item in the simulator.
Thanks. That was really quick answer.
Closing - assuming fixed... but sure there will be other leaks!