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.