从墓碑中恢复时，是否有一种很好/优雅的方式可以回到用户所在的页面？我不确定我的应用程序或其应用程序的工作方式，但我总是回到主页面。WP7从墓碑中恢复并返回页面
我的应用程序设置了一个主页面，该主页面有一个数据透视控件，几个数据透视项目将导航到新页面。我Naigation看起来是这样的，如果它是有道理的：
PivotItem1 - >网页A
PivotItem2 - >网页B - > PageC
PivotItem3 - >分页 - > PAGEE - PageF（按后退按钮PageF将使用非线性导航服务返回主页）
因此，如果用户在任何页面上的墓碑我想返回到该页面，并有BackStack可用，所以导航不会搞砸。
我正在使用MVVM Light和NonLinear导航服务，如果这有助于或伤害我想要完成的。
我有一个类似的导航沉重的应用程序在那里，它做你想做的（也使用非线性导航服务）。在我的情况下，我将用户的当前页面/数据透视表项存储在独立存储中，以及用于指示应用是否从墓碑归来的令牌（或布尔）。当用户导航到页面时，页面加载将在iso中设置当前页面值，并且如果页面具有透视，则还会将当前透视设置为第一个透视。 pivot_changed事件有代码将新的当前数据透视更改为用户刚更改的数据。
当应用程序处于逻辑删除过程中时，会触发app_deactivate事件，并且在此处将isTombstoned值设置为iso。
当用户从逻辑删除返回时，主page_load首先检查应用是否从逻辑删除（IsTombstoned = true）重新激活，如果是，则立即导航到名称存储在iso中的页面。当现在当前的page_load触发时，它检查IsTombstoned是否为true，如果是，则将其设置为false（恢复正常），并且如果页面上存在透视，则将选定的透视项目设置为存储的当前透视。如果页面没有透视控件，则当前的透视为空白。如果页面中存在动态内容时，您还需要提供其恢复。
对不起，我没有显示你的代码，但远离工作站，我无法到达它。
我曾经想过要做这样的事情，但是由于我在导航中深入了一个PhotoChooserTask，所以我最初描述的内容变得更加棘手。PhotoChooserTask也会导致应用程序Tombstone（应用程序停用/激活），但奇怪的是它能够返回正确的页面并且有导航历史记录。 – Tyler 2011-05-23 23:28:19
我不认为停用是非常相同的类型。我有其他的应用程序没有墓碑处理程序，可以从市场调用中正确地返回，例如，这是一个任务调用。我怀疑像我描述的逻辑处理程序不会被你的PhotoChooserTask绊倒，反之亦然。嗯。 – Cyberherbalist 2011-05-23 23:39:48
Application_Activated和Application_Deactivated触发常规墓碑和PhotoChooserTask，我没有看到任何有用的DeactivatedEventArgs来区分这两个 – Tyler 2011-05-24 00:40:44
@Tyler，Cyberherbalist：我很遗憾，我不能只是在那里为你的讨论添加评论。我对声望或其他方面的评价过低。我没有任何博客发布它，并给你一个链接。我只是写在这里，因为我认为这是值得注意和写作的地方，所以其他人也可以从中检查/使用/表达利益。
..所以，请原谅我这个“offtopic文章”在这里:)
虽然我不知道如何很好地解决这个问题 - 我的解决方案通常是收集通过手工导航历史堆栈，把它变成iso，并在激活时恢复并跳到右侧/最后一个地方 - 我可以告诉你一些关于墓碑的信息。
的事情是，如果你的应用是停用，但这并不意味着它墓碑。取消激活只是意味着你的应用程序被换出了屏幕。在芒果版本中，您可以点击&按住“返回”设备按钮，查看当前打开了哪些应用程序，然后跳转到任何应用程序。 “激活”是当你的应用程序被唤醒时。即使在WP7 SDK +模拟器的早期版本中，我也从我的应用程序中调用了外部媒体播放器，而且我的应用程序几乎从未被实际中断。取消激活/激活总是恢复我的应用程序就在那里'停止'。所有内存中的对象都未改动。
当设备资源不足时会发生逻辑异常，并且必须“终止”某些后台任务以释放内存。我相信当设备的屏幕保护程序下降并且设备长时间处于待机状态时也可能会发生这种情况。墓碑将逐字杀死您的应用程序，所有内存中的对象将被销毁/删除等。唯一能够幸存的是AppSettings和ISO商店。墓碑保证发生只有如果您的申请是在停用状态。
那么，你可以看到什么样的生命周期？
1） “冻结/待机/无焦点”：
2） “墓碑”：
这意味着，墓碑可能是有点防不胜防，同时也意味着，你总是甲肝一段时间来尝试在停用事件处理程序中使您的状态保持一致。
这也意味着，（除非有一些通知服务，我还不知道），唯一的方法来检测是否从墓碑恢复是依靠...是依靠最致命/不愉快的影响：清除你的记忆。
想象一下最简单的情况：你的App对象有一个属性“private bool _tomb_test”。它可以是任何类型的任何属性/字段。你也可以使用你的“object ViewModel {get; set}”。
要记住的第一件事是，不设置它在构造函数中，并做不分配直列默认值。只是让它漂浮。编译器/运行时会将应用程序对象创建为新的时将其设置为默认值false。这就是要点！
现在：
虽然它可能看起来很好，请原谅我这个漫长免责声明：
我在用100％的成功当前应用程序已成功使用它，但我不能说这是保证平台的行为。我还没有时间在MSDN上挖掘事实。以上所有内容都来自我对7.0和7.1 SDK版本的观察。
上述方法的一个小问题是它在上依赖于（未经证实的）假设，即内存清除以全有或全无方式工作。
也就是说，假设要么清除所有对象，要么不清除（当前事实：应用程序对象并且被观察为从头开始重新创建，甚至初始导航发生以重新创建UI。案件都没有发生）。
对于假设是错的......我无法想象谁和为什么会决定在.net世界中实现部分内存清除。全面清除意味着杀死应用程序。部分清除意味着摧毁GC世代中的随机生物，并让所有其他生物随着摇晃的手柄或无柄手柄而活着。我无法想象它。我没有观察到它。因此，我认为它是全有或全无。
顺便说一句。如果您观察到部分清除并找到一种大致确定的方式来引起它，那么其他人也可能会看到它，请大声播放！ :)
只是一个简短的说明，但也许这可以帮助吗？我还没有尝试过，但它看起来很有希望。 http://tombstonehelper.codeplex.com/ – 2011-05-24 14:12:26