何时保存应用程序的状态以进行逻辑删除？
我想知道什么时候保存单页的视图模型更合适。
我看到两种可能性：
- 每次您从页面导航时保存每个页面的状态（它是视图模型），以便在逻辑删除过程中应用程序恰好终止并重新激活时它已经被保存
- 在应用程序停用事件中，浏览所有页面位于导航堆栈中并保存其状态（其视图模型），然后将其重新注入到应用程序激活事件中。
哪种处理方式才是正确的呢？
谢谢 西蒙娜
I was wondering when is more appropriate to save the view model of the single pages.
I see two possibilities:
- Save the state of each page (it's viewmodel) everytime you navagitefrom it so that it is already saved if the application happens to be terminated and reactivated during the tombstoning process
- In the application deactivated event, go through all the pages that are in the navigation stack and save their state (their viewmodel) and then re-inject it in the application activated event.
Which is the correct way of handling it?
Thx
Simone
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想这取决于您的需求，但您不太可能需要偏离文档，文档表明应用程序停用事件是保存持久性和瞬态（状态）数据的适当位置，而关闭应该只保存持久性数据。
执行模型概述（请参阅控件激活下的流程图）
这个文章还通过应用程序生命周期和逻辑删除的示例给出了不错的解释，区分了退出/关闭、停用和逻辑删除。
您无法预测用户何时会在页面更改之间更改前台应用程序。但是，您可以预测关闭或停用时会发生什么。因此，在视图之间保存页面状态似乎是无关紧要的。
I suppose it depends on your needs, but it's unlikely you need to stray from the documentation, which suggests the application deactivated event as the appropriate place to save persistent and transient (state) data, while close should only save persistent.
Execution Model Overview (see the control flow diagram under Activating)
This article also gives a decent explanation with examples of the app lifecycle and tombstoning, differentiating between backing out/closing, deactivating, and tombstoning.
You can't anticipate when a user will change the foreground app between page changes. You can, however, anticipate what will happen when closing or deactivating. Therefore, saving your page state between views seems extraneous.
不幸的是，保存状态的“最佳”时间取决于： 应用程序；每个页面使用的模型的复杂性；每个页面支持的交互；以及页面之间共享模型的复杂性（在应用程序级别）。
作为一般规则，我尝试在应用程序级别使用单一模型，并在激活/停用时保留该模型。页面的模型是对应用程序级别模型的一部分的引用，我仅保留有关从/到页面的导航的页面特定信息。
我保留的页面特定信息的示例有：已输入但未保存的数据；和滚动位置。
Unfortunately the "best" time to save the state will depend on: the application; the complexity of the models used by each page; the interaction that each page supports; and the complexity of models shared between pages (at the app level).
As a general rule I try and have a single model at the application level and persist that on activation/deactivation. The model for a page is a reference to part of the app level model and I only persist page specific information on navigation from/to a page.
Examples of page specific information I persist are: entered but unsaved data; and scroll positions.
我无法投票支持之前的答案，因为我没有足够的“声誉”，但是任何瞬态信息都应该保留在 Application.Deactivated 事件中，然后在 Application.Activated 事件中恢复以获得逻辑删除支持。
如果您需要在应用程序会话之间存储任何内容，那么您可以使用 Application.Closing 事件，但根据您需要存储的内容，您可以在变化时存储它。同样，根据您需要存储的内容，您可以在 Application.Launching 事件中恢复它，也可以在需要时读取它。
I can't vote up the previous answer because I don't have sufficient "reputation", but yes any transient state information should be persisted in the Application.Deactivated event and then restored in the Application.Activated event for tombstoning support.
If you need to store anything between application sessions then you could use the Application.Closing event, but depending on what you need to store, you could just store it whenever it changes. Again, depending on what you need to store, you can either restore it in the Application.Launching event, or just read it when you need it.
这也是我曾经思考过的事情。
我对此的看法概括如下。
尽早保存。
这意味着，在没有任何其他必要条件促使您推迟保存的情况下，请尽早进行保存。您可以直接保存到主存储，也可以保存到专门用于处理逻辑删除的临时状态。您可以在页面打开时在后台保存。当用户请求在页面之间导航时，您可以保存。
在可能发生意外情况的情况下，例如断电、需要用户注意的异常（如果停用，请注意没有时间这样做），尽早保存可以为用户提供更多的可靠性。
可能促使您推迟保存的命令可能包括：
This is something I have given some thought to as well.
I've generalised my view of it to this.
Save as early as you can.
What this means is, short of any other imperatives, which motivate you to defer your save, do your save at the earliest available opportunity. You might save directly to your main store, or you might save to transient state specifically for handling tombstoning. You might save in the background while the page is open. You might save when the user requests to navigate between pages.
In situations where something unexpected can occur, such as loss of power, an exception requiring the users attention (noting no time for this if being deactivated), saving early offers a bit more dependendability to the user.
Imperatives that might motivate you to defer saving, could include