The scenario in question is that in a WP7 app, a view model (a Conductor for example) has an Items collection, which may contain other view models. The user can add new items on the fly, and therefore we don't have specific design-time knowledge of them. However, we want to be able to persist them using CM's tombstoning support.
We should be able to, in the storage handler for the conductor, specify that the Items property (or any other collection) should get persisted. Ideally, the storage mechanism should then look up any available storage handlers for the view model types contained in Items (or other specified collections) in order to persist them.
Currently, the storage mechanism simply attempts to serialize the objects in the collection in their entirety, which typically results in an exception. I've worked around this in my app using a custom implementation of IStorageHandler that does its own binary serialization; but I'd rather use the same mechanism for everything.
Comments: I'm open to any architecture recommendations that you think would make this more pluggable.
We should be able to, in the storage handler for the conductor, specify that the Items property (or any other collection) should get persisted. Ideally, the storage mechanism should then look up any available storage handlers for the view model types contained in Items (or other specified collections) in order to persist them.
Currently, the storage mechanism simply attempts to serialize the objects in the collection in their entirety, which typically results in an exception. I've worked around this in my app using a custom implementation of IStorageHandler that does its own binary serialization; but I'd rather use the same mechanism for everything.
Comments: I'm open to any architecture recommendations that you think would make this more pluggable.