how ViewModel LifeCycle, when does it get disposed?



In mvvmcross v3 ViewModel

public class TimerViewModel : MvxViewModel
    System.Timers.Timer timer;

    public TimerViewModel()
        timer = new System.Timers.Timer(500f);

        timer.Elapsed += HandleTimerElapsed;



    void HandleTimerElapsed (object sender, ElapsedEventArgs e)
        Debug.Log( "Time Elapsed" );

As MvxViewModel doesn’t implement IDisposable, where should I put the following code ?

timer.Elapsed += HandleTimerElapsed;

I find that mvvmcross code have some MvxWeakEventSubscription, is it used to solve my problem ?





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 – 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

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:

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.


Facebook Comments

Post a comment