xamarin - 检测 ViewModel 的关联 View 是否显示/不显示

Question

我有一些使用服务的 ViewModel，这非常占用带宽。但是，只有在查看应用程序中的特定 View 时才需要此服务。

在 MvvmCross vNext 中，我使用了 ViewUnRegistered/ViewRegistered检测何时发生 ViewModel 的事件显示，并有一个 BaseViewModel看起来像这样:

public class BaseViewModel 
    : MvxViewModel
    , IMvxServiceConsumer
{
    public BaseViewModel()
    {
        ViewUnRegistered += (s, e) =>
        {
            if (!HasViews)
            {
                OnViewsDetached();
            }
        };

        ViewRegistered += (s, e) =>
        {
            if (HasViews)
            {
                OnViewsAttached();
            }
        };
    }

    public virtual void OnViewsAttached()
    {
        // nothing to do here
    }

    public virtual void OnViewsDetached()
    {
        // nothing to do in this base class
    }
}

然后在我的另一个 ViewModel s 我将继承并覆盖 OnViewsAttached和 OnViewsDetached启动和停止服务。

现在在 MvvmCross v3 这两个 Event s 不再存在。据我了解，它们在 iOS 上也无法正常工作。 v3 还有一个新的 ViewModel生命周期，其中有 SavedState和 ReloadState .虽然据我了解 SavedState仅在 ViewModel 中调用被破坏，即使它没有显示，也可能不是这种情况。

至于检测关联的 View 是否正在显示，可以假设一个 View 在 ShowViewModel 时显示。被调用并有一些 Init View 中的参数，但这里棘手的部分是检测 View 何时不再显示。关于如何实现这一目标的任何想法？

Answer 1

在所有平台上确定 View/ViewModel 生命周期的这一领域相当棘手，尤其是当开发人员开始偏离“基本”演示模型并开始使用选项卡、 Split View、弹出窗口、弹出窗口等时

MvvmCross v3 目前没有通用的方法来处理这个问题。

当 ios6 删除 viewDidUnload 时，vNext 中的先前代码被破坏(但无论如何通常都被错误地使用了——因为 viewDidUnload 在 ViewModel 开发人员认为它会被调用时通常不会被调用!)

还有一个问题尚待讨论 future 可能的共同想法... https://github.com/slodge/MvvmCross/issues/74

话虽如此，我最近在这种情况下使用的一些模式是:

对于大多数 View 模型，我什么都不做——因为这些 View 模型不消耗任何资源，并且可以在系统需要内存时进行垃圾收集。

对于消耗低强度资源的 ViewModel - 例如计时器滴答声，我通常使用 MvxMessenger将 ViewModel 连接到这些资源。这个信使默认使用弱引用，它自己发出 subscription change messages当客户订阅/取消订阅

使用这种方法，我可以让后台资源监控 View 模型是否在内存中(并被 View 引用)——这样后台资源就可以自行管理。

...虽然实际上经常(例如对于计时器滴答声)然后我让后台资源不断运行，无论 ViewModel 是否正在监听。

对于那些非常需要资源监控的罕见情况 - 例如对于需要维护事件蓝牙 SPP channel 的 SpheroViewModel - 然后我在 ViewModel 上实现自定义接口(interface) - 例如IActiveViewModel - 然后我从各个平台上的 vie 连接到该界面

通常，我从 ViewDidAppear/Disappear、OnNavigatedTo/From、OnRestart/Pause 执行此操作 - 但这个确切的时间是否适合您取决于具体情况。

我怀疑，向前看，这些资源密集型 View 模型将是异常(exception)而不是常态，但我希望我们会看到一些示例/食谱发布，展示一些处理它们的方法。

我们也很可能会看到一些人在尝试其他正在进行的资源情况 - 例如。应用程序需要执行后台网络操作或需要在单个 View 模型的生命周期之外(甚至可能超出应用程序)监控地理位置。以跨平台的方式做这些事情是一个值得考虑的“有趣”模式!