Tombstoning WP7 model classes?

Apr 22, 2011 at 1:58 PM

My MainPageViewModel class is a wrapper around my main application logic class, and I'm trying to tombstone the app logic class without success. I've been able to get tombstoning working on several viewmodels without much trouble, so I suspect the <code>[SurviveTombstone]</code> attribute only works for viewmodels.

Is there a good way to grab this application logic class and save it off when the app tombstones? I'm thinking it might be doable in the bootstrapper if I override <code>OnDeactivate</code> and use the <code>Tombstone()</code> method. (Guessing on the names here--I'm not in front of my dev machine.)

Will that work? Is there a better/easier way to tackle this?

Apr 23, 2011 at 1:51 PM
Edited Apr 23, 2011 at 1:58 PM

I was working on a similar can to make persisting data even if the application closes. I copied the [SurviveTombstone] attribute implementation and modified it to save to ApplicationSettings instead. Its still very early prototype but in therory it should be able to be used for any class. To store you can call the StoreInIsolatedStorage method of the PhoneBootstrapper class and pass the objects you want to persist. It will automatically do this for viewmodels but you still need to manually restore the persited data by calling RetrieveFromIsolatedStorage at the moment. take a look at my post and see if this would be helpful at all. 

http://caliburnmicro.codeplex.com/discussions/254611

There is probably something we can do to make it easier to persist classes that are not view models. i'd be interested in hearing some ideas. 

Storing would look something like this. (i just noticed this method is marked protected in the sample so you will need to expose it first)

 

            var bootStrapper = Application.Current.Resources["bootstrapper"] as PhoneBootstrapper;
            bootStrapper.StoreInIsolatedStorage(objectName); 

 

Retrieving/Populating would look something like this.

            var bootStrapper = Application.Current.Resources["bootstrapper"] as PhoneBootstrapper;
            bootStrapper.RetrieveFromIsolatedStorage(objectName);

Coordinator
Apr 23, 2011 at 3:21 PM

I've got some new ideas about how to handle tombstoning for vNext. I'm thinking of creating something a little like Fluent NHibernate that is built on top of the SimpleContainer, PhoneState and IsoStore which would allow you to synchronize with the container and phone lifecycle the persisting of various classes either only across tombstoning or across full app restarts (that would also include the persisting of only certain properties of classes as well). Thoughts?

Apr 23, 2011 at 4:27 PM

The hard part about managing state right now is that it ends up being really fragmented. (This isn't a CM problem so much as a WP7 problem.) I've got bits of persistence code in my application settings manager class, my bootstrapper, and my viewmodels. It seems like it's all doing the same thing, really--writing XML to isolated storage.

I'd be in favor of anything that simplifies this. Creating one central persistence class, performing a function similar to what the bootstrapper does for setup, would be really nice. I wouldn't mind if it was more of a manual process--i.e. grab an object and specify which properties should be persisted in the persistence manager.

One other problem I've encountered is related to restoring data when resuming from tombstoning. At the time, I was putting a lot of application logic into my <code>MainPageViewModel</code> because it was easy to tombstone. I had to use <code>OnViewLoaded</code> to create a model object and restore its state, and this was causing my app to flash the default data on the screen before loading the restored data. Now I'm trying to load a model object first and restore its state, then load the viewmodel and display the already restored values.

It seems like making it easier to persist model classes would lessen the need to save and restore chunks of the viewmodel.  There will still be stuff like selected pivot items and list items, but it would be minimal view-specific state. The current model seems to encourage devs to use the viewmodel as the real application driver instead of allowing it to function as more of a bridge to the model classes.

All that is to say, what you're suggesting sounds great. :) Thanks for working on this problem. Looking forward to seeing what you come up with.