A penny for your thoughts on Windows Phone 7 tombstoning

A penny for your thoughts on Windows Phone 7 tombstoning

Rate This
  • Comments 27

One piece of feedback we hear from Windows Phone developers is that "tombstoning is hard," but there are many ways of interpreting that statement and we'd like to understand it more. We have some theories about what might be hard, but I don't want to skew any results by mentioning them here.

If you have an opinion on tombstoning in Windows Phone 7 - good or bad - please leave a comment and be as detailed as you can in the reply so we can better understand the feedback.

Thanks!

P.S. I'm joking about the penny.

  • Hi,

    I've built a couple of apps for windows phone 7, at work and at home, and my experience with tombstoning is this:

    1. If you consider tombstoning from the start and during the design of the application it's not rocket science, and is in fact pretty simple

    2. If you've completely ignored tombstoning while building your app, and your customer asks for tombstoning support later, then,as Josh Topolsky will put it, it's a nightmarish hellride

    Tombstoning can be difficult to grasp at first, and I felt there are a few inconsistencies with the implementation. For e.g consider this

    - my app starts and Mainpage.xaml is showing

    - user navigates to SecondPage.xaml

    - now user presses the start button and then presses the back button to navigate back to SecondPage.xaml

    In this scenario there is no way to know if the constructor of SecondPage.xaml will be called or not. If the user presses the back button too soon, before the app is actually "tombstoned", the constructor will not be called. But if the back button is pressed after a long time, then the constructor gets called. This, of course, is trivial to solve by using flags etc, but I feel it makes the handling of page local data messy.

    Prabhu

    www.techtwaddle.net

  • 1. I don't see any good solution for saving unrelated data during tombstoning. For example I want to save texts from text boxes, check boxes status and other states of UI elements on current app page, but also I want to save some "model" data unrelated to current page. Putting it all in single dictionary is not elegant solution IMHO, not everything fits into key-value pair paradigm.

    2. For some reason tombstoning does not allow you to save images and throwing exception. Why not? This is especially problematic with downloaded images (think avatars in twitter app). This means I need to use some other mechanism for storing transient images (probably Isolated Storage API) leading to additional complexity - some data is stored in dictionary and some on isolated storage.

    I'd love to see more "real world" examples\tutorials on tombstoning. Currently there aren't any complete solutions to this, but only few disconnected code samples that give you basic understanding, but are not that helpfull in actual development, leaving a lot to be figured out by programmers.

    Just my 0.02$

    Hope this helps

    -Dennis

  • In my experience, tombstoning is hard for two main reasons:

    1. It requires some fastidious code to save and restore the application's transient state. This is especially cumbersome for page transient states for which the SDK does not always provide easy-to-use APIs (TextBoxes with bindings, ListBox scrolling offsets, DataTemplates) or, in some cases, no API at all (Panorama current item).

    2. It requires all pages of an application to be independent of each other, because only the current page is reinstantiated when the navigation stack is restored upon activation. It's not difficult to handle once you understand the constraints and it leads to better code architecture, yet this is a counterintuitive requirement.

    Another minor (yet confusing!) reason is that an application sometimes won't be tombstoned at all between deactivation and reactivation, like when the user presses the Home button followed immediately by the Back button.

  • When I've asked people it basically comes down to the fact that it requires more than drag and drop. :(

  • I think it's pretty hard to tombstone correctly. Most apps I downloaded/bought have tombstoning issues.

    I don't know what Apple did to solve this issue is iOS, but it looks like their system works better. Also currently it isn't always clear when tombstoning is happening. Sometimes WP7 saves the state by itself in memory and other times you have to do it yourself. Of course this behaviour is documented, but it would be better to have a consistent approach, IMHO.

  • I really think tombstoning should be automatic, but also allow us to turn this feature off if we would like a custom implementation.

  • Thank Peter.  It is actually tricky coming up with a decent answer here.  One of the hard things about Tombstoning is that it exists, and needs to be accounted for.  Having to deal with the nuances of tracking state of possibly every part of your application at nearly every moment and account for any random termination eventuality is quite a shift from development where termination is a (fairly) fixed ocurrence.

    Outside of that broad swath, a few specific things jump to mind:

    * The Chooser Model is inherently broken when it comes to Tombstoning.  The fact that the Completed event fires before the Page's OnNavigatedTo method - meaning that PageState is inaccessible to Choosers - is painful.  Yes, the Choosers have been optimized to not tombstone, unless someone brings up the Start page while in a Chooser and then hits the back button...so from a dev standpoint, there is no optimization - it is only a performance enhancement.  As a solid case, try to type some text into a textbox on a page, then give the user a button to send that text.  On button press, bring up a mail address chooser, and then feed that directly into a send-mail launcher.  You're stuck either using the App State  dictionary or ISO storage.

    * The App State Dictionary has a maximum size limit, but it isn't documented.

    * Exceeding size limits in the Page Dictionary throws a COMException, instead of something more specific

    * It might be nice for pages to participate more directly in Tommbstoning - through direct overridable methods.

    * The Pivot Control has a big that makes setting the "last used page" difficult when restoring from Tombstoning.

    For even more fun, see Jeff Prosise's 4-part writeup on Tombstoning -  www.wintellect.com/.../real-world-tombstoning-in-silverlight-for-windows-phone-part-4.aspx (This is Pt 4, and has links to Pts 1- 3)

    There's an entry on MSDN offering guidance for how to restore state to controls (less of an issue when MVVM gets involved, but when exactly are you over-architecting a micro/phone-app?)  I am having trouble locating the prceise URL, but will update when I locate it.  The volume of work identified in that article alone will give you one heck of a start.

    Thanks for asking the question.  I hope this and subsequent answers help.

    --John Garland

  • I think that tombstoning is a given "fact" that needs to be considered when creating apps, however, it is not ideal for any kind of app unfortunately.

    In particular, games that have to load some content into memory before operating, will never load smoothy and will give the user a pretty bad experience.

  • The idea is good, but it should be polished.

    As people say it's not rocket science, but you've gone a long way of giving us a great dev experience for the Windows Phone, and polishing tombstoning is one thing that could make things even better.

    1. The current UI at the moment it tombstones should be serialized automatically. States and all. The dev shouldn't have to handle that really.

    2. Returning from whatever state should always demand only one set of code to execute, never leave room for ambiguity.

    If you have developed a fairly large app, going back and implementing correct tombstoning can be very messy. Managing to sort point 1 would remove a lot of hassle.

    But also there should be a design guide that puts focus on that you have to have tombstoning in thought when designing the app from day one. I think a lot of people miss this, and it's probably the reason you are getting so much feedback about this functionality.

  • my 2 cents :)

    When you are building an app especially one with lot of pages (especially enterprise apps), tombstone handling increases your development time significantly.

    A lot of effort is spent in testing all pages even when you make simple code changes.

    It is also a real barrier to get apps certified. ( One day I will write a book about app certification and there is certainly a chapter for tombstoning )

    I am sure there are folks who can be sure that it is trivial, but again, if you are not building one page apps, this increases dev and certification duration.

  • I agree that tombstoning should just happen.  It gets complicated when there are panos and pivots and user controls involved.  It would be great if it could handle user controls.  For example on a pivot where each pane is a user control.  When a pane is not visible I would like to store it, and all non visible user control / panes to current state, until it is visible again.  That helps keep the memory managable. But when tombstoning comes along it can't handle the temp stored user controls.

  • In my case it is not hard but is very boring and time consuming work.

    If I can focus more onto features of my app instead of tracking all the

    silly bugs of tombstoning, the joy of wp7 development is getting better.

    Android, iPhone have similar kinds of concept but

    WebOs programming has no multitasking special stuffs.

    I believe if we had developed DESKTOP PROGRAM like this way - i mean tombstoning -

    fewer app remains as quality app.

    Thanks.

Page 2 of 2 (27 items) 12