Navigating to a details page - shared view model or navigation query string?

Question

When navigating from a list page to a details page, there are two high level ways of passing the selection data between the pages: sharing a view model instance and passing an identifier in the querystring of the navigation Uri.

Which should I be using? Are there any issues with using one approach over the other (access to current Uri from the view model, timing of navigation events, etc)?

Commonable

Answer 1

Personally I would recommend passing an identifier as part of the navigation URI querystring. These URIs are restored to form the back-stack when your application re-enabled after tombstoning.

When your application is restored after being tombstoned, you re-create your applications view model from the application state, then use the URI querystring to 'marry' your newly created view with its required DataContext.

See the worked example here:

http://www.scottlogic.co.uk/blog/colin/2011/05/a-simple-windows-phone-7-mvvm-tombstoning-example/

Neurosurgery

How do you access the Uri from the ViewModel? – Commonable

Read the article referenced above! – Neurosurgery

Breaking MVVM? The two main tenants of MVVM are (1) developer-designer workflow and (2) a unit testable view model. How does this approach break MVVM? – Neurosurgery

Because you can't test the page's interaction with the view model – Commonable

FYI: meta.stackexchange.com/questions/100157/… – Crenelate

Answer 2

the two approches are quite well.

the real difference is in the tombstone process.

when you go back to your application, the id of your object will be parsed :

• in the querystring. (native)
• with your specific isolated storage management.

if you choose the shared viewmodel, you will have to save the id when you navigate to.

a mix of the two seems to be the best : you navigate with queryString, and use a sharedViewModel, so when you navigate to a new page, you got the id from queryString and get the data from the sharedViewModel with that id !

you can manage your SharedViewModel to save datas in the IsolatedStorage to recover web loaded datas when tombstonned

Nonillion