Se está llamando nuevamente al constructor de ViewModel en la navegación, por lo que las suscripciones de Messenger se están suscribiendo nuevamente

Estoy construyendo una aplicación móvil multiplataforma usandoMvvmCross marco de referencia.

Como me gustaría compartir información entre ViewModels, estoy registrando notificaciones dentro del constructor de ViewModel, usando el comando incorporado.MvxMessenger.
Asumamos un mensaje llamadoShowAdsMsg, y luego el ViewModel se ve de la siguiente manera:

public class AdsViewModel : BaseLookersViewModel, IAdsViewModel
{
    private MvxSubscriptionToken _showAdsMsgToken;

    public AdsViewModel()
    {
        _showAdsMsgToken = MvxMessenger.Subscribe<ShowAdsMsg>(message => onShowAdsNavigation(), MvxReference.Weak);
        MyMessenger.PublishLastMessage();
    }
    private void onShowAdsNavigation()
    {
        //Do Stuff
    }
}

Acerca deMyMessenger cosa:
La navegación real a ViewModel se realiza desdeMainViewModel.
Desde que en el momento mismo de la navegación elAdsViewModel No existe aún, los mensajes publicados desde elMainViewModel no puede alcanzarlo
Entonces, mi idea fue ingenuamente "recordar" el mensaje y publicarlo cuando el nuevo ViewModel esté listo.
Así que ahora la llamada de navegación de laMainViewModel tiene este aspecto:

    private void navigate()
    {
        MyMessenger.RememberMessage(new ShowAdsMsg(this));
        ShowViewModel<AdsViewModel>( );
    }

Ahora puedo navegar a ViewModel y todas las notificaciones se capturan correctamente.

Sin embargo...
Cuando presiono el botón ATRÁS en el dispositivo y vuelvo a navegar al mismo ViewModel,
Se vuelve a llamar al constructor y, por lo tanto, vuelve a ocurrir la suscripción del mensaje.
Como resultado, cuando llega un mensaje elonShowAdsNavigation() manejador se está disparando dos veces!

encontréesta publicación similar, discutiendo la cuestión de cómo disponer adecuadamente un ViewModel,
pero no contiene una solución directa a mi problema.

Lo que necesito es una solución. Puede ser uno de los siguientes:

Idea de cómo no suscribirse a los mensajes en el ctor de ViewModel.Orientación sobre cómo y cuándo disponer correctamente el ViewModel.Explicación de por qué se llama nuevamente al constructor y cómo evitarlo.Un enfoque completamente diferente para la mensajería de información de ViewModel.

Gracias de antemano por su ayuda!

Edit: he encontradoesta SO Respuesta, que básicamente responde al artículo número 3 en la lista anterior. Sin embargo, me pregunto qué enfoque debería tomar con respecto al tema de los mensajeros.

Otra edición: verifiqué que existe el mismo comportamiento con el tutorial de MvvmCrossN-05-MultiPage. Simplemente agregué un ctor a SecondViewModel, y alcancé un punto de interrupción dentro de él después de cada BACK + Renavigate.

Respuestas a la pregunta(1)

Su respuesta a la pregunta