We’ll then create our ShellViewModel, it will need to contain a collection of our characters as well as the currently selected character. We’ll also need a property that indicicate whether the master menu is currently available. A first draft looks something like:

The most interesting things in here are populating the data in the constuctor, really this is only things specific to characters in the entire view model, but could easily be abstracted away. The other is that when the SelectedCharacter is set we update MasterListAvailable depending on the value. What this will do ultimately in the UI is that when a character is selected in the master list the UI will switch over to the details view.

We already have a conductor in the framework that can handle this Conductor<T>.Collection.OneActive leaving us with.

Our ShellView comes next, an important point to note here is that no where in the view do we declare how a character should be display we simple style the master list and the container for the detail content. This view could be reused across any master / details view in the application.

The imporatant part to note here is we’re using View.Model in the same way as our last post about TabbedPage. Normally this would be since both the master data template and details content page are both being bound to a CharacterViewModel then a CharacterView could be injected.

This wouldn’t be desirable since we don’t want the same view for both places. Instead we use View.Content to provide some extra view location.

For the master list item we provide a context of MasterView, this means when resolving the view for MasterDetail.ViewModels.CharacterViewModel the result will not be the typical MasterDetail.Views.CharacterView but MasterDetail.Views.Character.MasterView and MasterDetail.Views.Character.DetaisView for our details panel. We now have two views for the same view model based on their context which can significantly reduce the complexity of our view models.

So there we have it, by making use of View.Model and View.Context we can create conducting view and view models that can be responsible for only the flow between master and details and not be mixed up with the data or display of the items themselves.

We can use contexts to have multiples views for a view model even further reducing this complexity.

The code for all of this is up on a new GitHub samples repository where I plan to post more of the code from posts like these.