ViewModels, messages and lifetime

Question

I have modified one of @slodge's samples for a problem I have with my ViewModels lifecycle.

I've modified N26 a little: https://github.com/csteeg/NPlus1DaysOfMvvmCross/tree/viewmodeldisposesample/N-26-Fraggle

This branch uses the mvxmessenger plugin to be able to show you where things go wrong. The code isn't pretty, but shows you wat is incorrect. You can see how SubViewModel with Id = 0 keeps receiving messsages, even when it's view is long gone. And also (at some point) how HomeViewModel stops receiving messages.

Steps to reproduce (including a cleaned up version of the debug output):

start the app

HomeViewModel:Warning:HomeViewModel 0 received: Created HomeViewModel0

Click on button '1'

HomeViewModel:Warning:HomeViewModel 0 received: Created SubViewModel0 SubViewModel:Warning:SubViewModel 0 received: Created SubViewModel0 HomeViewModel:Warning:HomeViewModel 0 received: Created FirstViewModel0 SubViewModel:Warning:SubViewModel 0 received: Created FirstViewModel0 FirstViewModel:Warning:FirstViewModel 0 received: Created FirstViewModel0

Click on back

HomeViewModel:Warning:HomeViewModel 0 received: Destroyed FirstView for viewmodel 0 SubViewModel:Warning:SubViewModel 0 received: Destroyed FirstView for viewmodel 0 FirstViewModel:Warning:FirstViewModel 0 received: Destroyed FirstView for viewmodel 0 HomeViewModel:Warning:HomeViewModel 0 received: Destroyed SubFrag for viewmodel 0 SubViewModel:Warning:SubViewModel 0 received: Destroyed SubFrag for viewmodel 0 FirstViewModel:Warning:FirstViewModel 0 received: Destroyed SubFrag for viewmodel 0 HomeViewModel:Warning:HomeViewModel 0 received: Destroyed DubFrag for viewmodel 0 SubViewModel:Warning:SubViewModel 0 received: Destroyed DubFrag for viewmodel 0 FirstViewModel:Warning:FirstViewModel 0 received: Destroyed DubFrag for viewmodel 0 You can see the views getting destroyed here, I'd expect the viewmodels to go with them

Click button '1' again

HomeViewModel:Warning:HomeViewModel 0 received: Created SubViewModel1 SubViewModel:Warning:SubViewModel 0 received: Created SubViewModel1 FirstViewModel:Warning:FirstViewModel 0 received: Created SubViewModel1 SubViewModel:Warning:SubViewModel 1 received: Created SubViewModel1 HomeViewModel:Warning:HomeViewModel 0 received: Created FirstViewModel1 SubViewModel:Warning:SubViewModel 0 received: Created FirstViewModel1 FirstViewModel:Warning:FirstViewModel 0 received: Created FirstViewModel1 SubViewModel:Warning:SubViewModel 1 received: Created FirstViewModel1 FirstViewModel:Warning:FirstViewModel 1 received: Created FirstViewModel1

Here you see, subviewmodel 0 is still receiving messages. Can I somehow tell it should stop sending messages to viewmodels not attached? OR could the viewmodel know about not being attached

Now, as you continue to to repeat these steps for quite some time, say 15 times in the emulator, some viewmodels will stop receiving messages (I guess they're garbage collected). Strange thing is that one of those views is HomeViewModel! The HomeView is never destroyed, yet the homeviewmdoel stops receiving messages, thus nog being able to update the view accordingly if you app requires that

score 5 · Answer 1 · answered Oct 22 '13 at 14:46

I had a similar situation, where MvxMessages were still being received and acted on by viewmodels which were no longer attached to views.

My solution is to add the following to the base viewmodel:

a Subscribe method
a list of unsubscribe actions (this is added to by the Subscribe method)
an UnsubscribeAll method

And in the Android activity OnDestoy, I call the viewmodel's UnsubscribeAll.

(As a bonus, as the tokens are referenced in the unsubscribe actions, I don't need to keep another list of them)

BaseViewModel:

    #region Messenger

    /// <summary>
    /// Must set the Messenger object before doing any subscribing
    /// </summary>
    public IMvxMessenger Messenger { get; set; }

    private readonly object _messengerLock = new Object();

    private List<Action> _unsubscribeActions;

    /// <summary>
    /// Subscribe to a message, and store in a list so can be unsubscribed automatically later
    /// </summary>
    /// <typeparam name="TMessage"></typeparam>
    /// <param name="deliveryAction"></param>
    public void Subscribe<TMessage>(Action<TMessage> deliveryAction) where TMessage: MvxMessage
    {
        var messenger = Messenger;
        if (messenger == null) { return; }

        var token = messenger.Subscribe<TMessage>(deliveryAction);

        Action unsubscriber = delegate()
        {
            messenger.Unsubscribe<TMessage>(token);
        };

        lock (_messengerLock)
        {
            if (_unsubscribeActions == null)
            {
                _unsubscribeActions = new List<Action>();
            }
            _unsubscribeActions.Add(unsubscriber);
        }
    }

    /// <summary>
    /// Unsubscribe to all messages which have been previously subscribed to
    /// </summary>
    public void UnsubscribeAll()
    {
        if (_unsubscribeActions == null) { return; }
        lock (_messengerLock)
        {
            foreach (var a in _unsubscribeActions)
            {
                a();
            }
            _unsubscribeActions = null;
        }
    }

    #endregion

BaseActivity:

    protected override void OnDestroy()
    {
        var vm = ViewModel as ViewModel.BaseViewModel;
        if (vm != null) { vm.UnsubscribeAll(); }
        base.OnDestroy();
    }

Thank you for this, this has saved my life after days of not finding a solution. Again my view was no longer attached to my viewmodel yet messages where being sent. Thanks!!! — PmanAce, Aug 07 '15 at 02:40

score 4 · Accepted Answer · edited May 23 '17 at 12:00

MvvmCross v3 doesn't expose the ViewModel to any View lifecycle events like ViewDidAppear/Disappear, OnNavigatedTo/From, OnPause/OnResume/OnDestroy.

The reason for this is because:

earlier MvvmCross versions tried to do this and came unstuck with iOS changes in ViewDidUnload and with iOS support in general (it was hard to work out when a view was dead for good)
when Views are not pages - but are instead tabs, flyouts, splitviews, popups, etc - then it was hard to support and confusing to developers

Instead, MvvmCross v3 makes use of Garbage Collection to tidy up the ViewModels. To assist with this Mvx always uses WeakReferences from ViewModel-to-View and from MessageHub-to-ViewModels. The general philosophy followed is:

the only thing that keeps a strong reference on a View is the operating system.
the only thing that keeps a strong reference on a ViewModel is its View.

With that said, if GarbageCollection isn't timely enough for your app, then MvvmCross does allow you to extend your ViewModels with new functionality. For example, you could easily add a new IViewLifecycleAware interface if you want to. This is easy to do, but once done then it's your app's responsibility to ensure that interface is called from appropriate View events/overrides on each platform you support.

There's a little more on this topic in:

For your specific problem with HomeViewModel stopping receiving messages, I think that is due to you not storing the subscription token.

Because the MvvmCross messenger uses weak referencing by default, you must store the subscription token - when that token is disposed or garbage collected then the subscription will be unsubscribed.

So your code:

public class HomeViewModel
    : MvxViewModel
{
    public static int IdCounter = 0;
    public int Id = IdCounter++;
    public HomeViewModel()
    {

        var messenger = Mvx.Resolve<IMvxMessenger>();
        messenger.Subscribe<JustAMessage>(OnMessage);
        messenger.Publish(new JustAMessage(this) { Message = "Created HomeViewModel" + Id });
    }

    // ...

needs to be:

public class HomeViewModel
    : MvxViewModel
{
    public static int IdCounter = 0;
    public int Id = IdCounter++;

    private IDisposable _token;

    public HomeViewModel()
    {

        var messenger = Mvx.Resolve<IMvxMessenger>();
        _token = messenger.Subscribe<JustAMessage>(OnMessage);
        messenger.Publish(new JustAMessage(this) { Message = "Created HomeViewModel" + Id });
    }

    // ...

There's more about this in:

https://github.com/slodge/MvvmCross/wiki/MvvmCross-plugins#messenger

Thanks for the excellent answer Stuart, forgot to store the token indeed: doh! The problem with the real world app goes a little deeper though: -a list of items in a fragment -replace fragment -load list again The list is binded through an mvxadapter to an ObservableCollection The Adapter of the first loaded fragment, is still alive as long as the viewmodel is also alive (perhaps even after, but it's still attached to the viewmodel's collectionchanged event as long as the viewmodel's there). When the collection changes (through events of my datalayer) it crashes in notifycollectionchanged — Chris van de Steeg, Sep 26 '13 at 08:07
The adapter being kept around, was found after reading this issue!: https://github.com/slodge/MvvmCross/issues/390?source=cc I used an inflated layout with embedded mvxlistview and then later set the MvxLayoutDrivenAdapter on that listview — Chris van de Steeg, Sep 26 '13 at 12:39

ViewModels, messages and lifetime

start the app

Click on button '1'

Click on back

Click button '1' again

2 Answers2