WP7从墓碑恢复并返回到页 [英] WP7 recover from Tombstone and return to page

问题描述

是否有一个很好的/优雅的方式返回到页面的用户是从一个墓碑恢复时？我不知道如果我的应用程序或者它只是事物的方式工作，但我总是最后回到我的主页上。

Is there an nice / elegant way to get back to the page a user was on when recovering from a tombstone? I'm not sure if my app or its just the way things work, but I always end up back on my Main page.

我的应用程序设置一个主页具有透视控制和几个透视项目将导航到新的页面。我Naigation看起来是这样的，如果它是有道理的：

My app is setup with a main page that has a Pivot Control and several of the Pivot Items will navigate to new pages. My Naigation looks something like this if it makes sense:

PivotItem1 - >网页A结果
PivotItem2 - >网页B - > PageC结果
PivotItem3 - >分页 - > PAGEE - PageF（按后退按钮PageF将使用非线性导航服务回到主页）

PivotItem1 -> PageA
PivotItem2 -> PageB -> PageC
PivotItem3 -> PageD -> PageE - PageF (Pressing Back Button on PageF will use NonLinear Navigation Service back to Main page)

因此，如果对任何用户墓碑网页我想他们返回到该网页并获取BackStack所以导航不会被搞砸了。

So if the user tombstones on any of the pages I want to return them to that page and have the BackStack available so the navigation doesn't get screwed up.

我使用MVVM灯和非线性导航服务，如果。帮助或伤害什么，我试图完成

I'm using MVVM Light and NonLinear Navigation Service if that helps or hurts what I'm trying to accomplish.

推荐答案

@Tyler，Cyber​​herbalist：很遗憾，我不能只是'添加评论'到您的讨论就在这里。我还没有信誉或其他太低。我没有任何的博客张贴有它，给你一个链接到它，无论是。我就写在这里，是因为我认为这是值得注意的某处写，这样别人也可以检查从/使用/ permormanceprofit。

@Tyler, Cyberherbalist: I regret I cannot just 'add a comment' to your discussion right there. I'm yet too low on reputation or whatever. I dont have any blog to post it there and give you a link to it, either. I'll just write here, because I think it is worth noticing and writing somewhere, so others may also check/use/permormanceprofit from that.

..所以，借口我要这个offtopic文章在这里：）

..so, excuse me for this "offtopic article" here :)

虽然我不知道如何很好地解决这个问题 - 我的解决方案通常是收集手工导航历史堆栈，把它导入ISO，并在激活恢复并跳转到正确的/最后的地方 - 我可以告诉你的墓碑一点点

While I don't know how to solve the problem nicely - my solution usually is to collect the navigation history stack by hand, put it into iso, and restore on activation and jump to the right/last place - I can tell you a little bit about the tombstoning.

这个问题是，如果您的应用程序的停用的，但这不可以意味着它是逻辑删除。停用只是意味着你的aplication被换出的画面。在芒果版本，您可以点击并按住返回设备按钮，看看哪些应用程序正在打开，并跳转到任何。 激活是当你的应用程序被唤醒。即使在WP7 SDK +仿真器的早期版本中，我打电话从我的应用程序的外部媒体播放器，和我的应用程序几乎没有遭到人身死亡。停用/激活始终恢复我的应用程序只是在那里它被叫停。所有内存中的对象原封不动。

The matter is, that if your application is deactivated, that does not mean that it is tombstoned. Deactivation simply means that your aplication is swapped out of the screen. In the Mango release, you can tap&hold the "Back" device button and see what applications are opened currently, and jump to any. "Activated" is when your application is woken up. Even in the very early releases of the WP7 SDK+Emulator, I was calling external mediaplayer from my applications, and my applications almost never were physically killed. Deactivated/Activated always resumed my application just right there where it was 'halted'. All in-memory objects were untouched.

当设备资源不足，而且必须杀的背景任务，释放内存发生墓碑。我相信，当该设备的屏幕dropsdown，并且该设备处于待机状态的时间较长，也可能发生了。墓碑硬是将杀死你的应用程序，都在内存中的对象将被销毁/删除等。将生存的唯一的事情是的AppSettings和ISO商店。墓碑是保证发生的仅如果你的应用是在的停用的状态。

Tombstoning occurs when the device is low on resources, and must "kill" some background tasks to free up the memory. I believe it may also occur when the device's screensaver dropsdown, and the device is in standby for a prolonged time. Tombstoning will literally kill your application, all in-memory objects will be destroyed/removed and so on. The only thing that will survive is the AppSettings and the ISO store. Tombstoning is guaranteed to happen ONLY if your application is in deactivated state.

那么，什么生命周期你？可以看到

So, what life-cycles you can see?

1）冻结/待机/无焦点：

1) "Freeze/Standby/Unfocus":

• 启动


• ...（工作）


• 停用（移动到背景）


• ...（保存在内存中，也许进程/线程被冻结，但我怀疑）


• （...）


• 激活（移动到前台，没有导航出现这种情况）


• ...（工作）


• 关闭

• Launching
• ... (working)
• Deactivated (moved to background)
• ... (kept in memory, maybe process/thread is frozen, but I doubt)
• (...)
• Activated (moved to foreground, no navigation occurs)
• ... (working)
• Closing

2）逻辑删除：

• 启动


• ...（工作）


• 停用（移动到背景）


• ...（保存在内存中，也许进程/线程被冻结，但我怀疑）


• ...（墓碑，从内存中删除，销毁一切）


• （...）


• .. （洁净应用对象构造）


• 激活（移动到前台）


• 导航的（我想，总是在设置第一个，默认页面明显的，但我现在不知道）


• （工作）


• 关闭

• Launching
• ... (working)
• Deactivated (moved to background)
• ... (kept in memory, maybe process/thread is frozen, but I doubt)
• ... (tombstoned, removed from memory, everything destroyed)
• (...)
• ... (clean application object constructed)
• Activated (moved to foreground)
• Navigated (I think, always to the first, default page set in the manifest, but I'm not sure now)
• (working)
• Closing

这意味着，立碑可能有点防不胜防，同时也意味着，你总有时间去尝试同贵国在停用，事件处理程序。

This means, that tombstoning may be a little hard to detect, but also means, that you always have a time to try to same your state in the deactivated-eventhandler.

这也意味着，（除非有我不知道的还有些通知服务），以检测是否简历 - 从 - 墓碑是依靠唯一的办法是...依靠它的最致命的/不愉快的效果：在有你的记忆中清除

This also means, that (unless there is some notification service that I do not know of yet), the only way to detect if a resume-from-tombstone is to rely on ... is to rely on the most deadly/unpleasant effect of it: on having your memory purged.

试想一个simpliest情况：您的应用程序对象有一个属性私人布尔_tomb_test。它可以是任何类型的任何属性/字段。您可以使用对象视图模型{获得;设置}，以及为

Imagine a simpliest case: your App object has a property "private bool _tomb_test". It may be ANY property/field of ANY type. You can use your "object ViewModel{get;set}" as well for that.

要记住的第一件事是，不会设置它。在构造函数中，并做不会指定一个内嵌的默认值。就让它浮动。每当创建应用程序对象刚新的编译器/运行时将其设置为默认为false。而这一点

First thing to remember is, NOT to set it in the constructor, and do NOT assign a inline default value. Just leave it floating. The compiler/runtime will set it to the default false whenever the App object is created freshly new. And that's the point!

现在：

• 在推出（而不是构造函数！ !!），将_tomb_test =真正的


• 在停用，保存持久的最低状态，ISO


• 在激活后，请检查：
  
  
  
  • 如果_tomb_test ==假的意思，你是墓碑。你的内存是干净的，所有的对象被摧毁。根据最后写入ISO数据恢复状态，然后开始所有作业填充/重新下载/重装/重新计算/等应用程序状态的所有其他部分
  
  
  • 但是，如果_tomb_test == true，则意味着没有发生立碑。你的内存是不变。也许只是在GC踢并收集死者。住所有对象都还活着。应用程序是免费的，只是跑，好像什么事也没发生过。
  
  
  • in Launched (not ctor!!!), set "_tomb_test = true"
  • in deactivated, save your minimum persistent state to ISO
  • in activated, check:
    • if _tomb_test==false that means, you were tombstoned. your memory is clean, all objects were destroyed. restore your state according to data last written to the ISO, and then start all jobs to refill/redownload/reload/recalculate/etc all the other parts of the app state
    • but, if _tomb_test==true, that means that the tombstoning did not occur. your memory is untouched. maybe just the GC kicked in and collected the dead. all objects that were living are still alive. the app is free to just run as if nothing ever happened.

    虽然它可能看起来漂亮，请原谅我这个漫长免责声明：的

    我成功地用它在100％的成功当前的应用程序，但我不能说这是保证平台的行为。我还没有找到时间为MSDN上的事实挖。所有从我的7.0和7.1 SDK发布的观测上述卡梅斯的。

    I use it successfully in current application with 100% success, but I cannot say that this is guaranteed platform's behaviour. I have yet to find time to dig for the facts on MSDN. All of the above cames from my observations on the 7.0 and 7.1 SDK releases.

    以上方法的小问题是，它的依赖在的（未经证实？）假设下，该内存清除工作在一个全有或全无的方式。

    The small problem of the above approach is that it relies on the (unproven?) assumption, that the memory purge works in an all-or-nothing fashion.

    也就是说，假定要么所有对象被清除，或没有清洗发生时（当前事实：应用程序对象，并观察到从头重新创建，并且发生甚至初始导航来重新创建的UI在其他情况下都不它发生）。

    That is, assumes that either all objects are purged, or no purge occurs (current fact: the App object and is observed to be re-created from scratch, and even an initial navigation occurs to recreate the UI. In other cases neither of it happens).

    有关的假设是错误的......我不能想象是谁，为什么会决定要实现.NET世界的部分记忆清除。完全清除意味着查杀应用程序。部分净化是指在GC代随机破坏对象的生活，离开所有的休息活着把手晃来晃去，或者用调零手柄。我无法想象它。我还没有发现它。因此，我以为这是全有或全无。

    For the assumption to be wrong... I just cannot imagine who and why would ever decide to implement partial memory purge in the .net world. Full purge means killing the app. Partial purge means destroying random living objects in the GC generations and leaving all the rest alive with dangling handles, or with nulled handles. I cannot imagine it. I have not observed it. Thus, I assume it's all-or-nothing.

    BTW。如果你观察一个局部清洗，并找到大多确定性的方式来引起，所以别人可能会看到它也请大声播放它！ ：）

    BTW. If you ever observe a partial purge and find a mostly-deterministic way to cause it, so others may see it too, please broadcast it loudly! :)

    这篇关于WP7从墓碑恢复并返回到页的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！