There’s no easy universal way to know when to dispose the ViewModel – especially once you start mixing and matching ViewModel presentation styles to include navigations, tabs, splitviews, flyouts, fragments, lists, etc. and as you include more and more platforms
As a result of this, a couple of ways I have shut things like timers down in the past are:
1. Sometimes I have used a specialised interface on the ViewModel and I ensure this is called appropriately on each client.
For example, I have done some starting/stopping of ‘page’ level Views using:
- OnPause/OnResume in Android
- OnNavigatedTo/OnNavigatingFrom in Windows
- ViewDidAppear/ViewWillDisappear in iOS
I have thought about adding this as a generalised pattern to do this (it is logged in https://github.com/slodge/MvvmCross/issues/74) – but so far I’ve not added this to v3 as I think it would lead to too much misunderstanding among users – it’s better to let them to do this in the very few situations where it’s needed.
Update: I have blogged about this and published a sample – see http://slodge.blogspot.co.uk/2013/11/n42-is-my-viewmodel-visible-can-i-kill.html
2. Sometimes I’ve just used Event Aggregation through the MvvmCross Messenger – and I’ve used it’s inherent WeakReference-based messaging to make sure the ViewModel can be garbage collected when the view has finished with it.
An example of this is in the InternetMinute sample – which has a single ‘Tick generation service’ which ViewModels can connect to via messaging for updates – see:
- the service – https://github.com/slodge/MvvmCross-Tutorials/tree/master/InternetMinute/InternetMinute.Core/Services/Tick
- a ViewModel that consumes the service – via https://github.com/slodge/MvvmCross-Tutorials/blob/master/InternetMinute/InternetMinute.Core/ViewModels/HomeViewModel.cs
You might consider this slightly inefficient – as the Tick messages will be generated even if the ViewModel isn’t present – but it’s only a small inefficiency.
3. I’ve considered using more final events – things like OnNavigatingFrom(BACK) and ‘onDestroy’ and some ‘final’ detection on the UINavigationController delegates … but I’ve not had a reason to do this ‘for real’ on any project yet.