Regions, screen design question

Sep 18, 2012 at 10:35 AM
Edited Sep 18, 2012 at 10:36 AM

Hoping for some advice here...

I am using Jounce for prototyping a LoB app; I have a screen with a content control into which I will be swapping in views and removing them when done. In some use cases there may be more than one screen that I need to be able to swap between (e.g. search criteria -> search results -> back to criteria to refine them). I was thinking I could use a view that sat in my main content control that itself had a region into which I could load my criteria/result view and transition between them on navigation events. So the visual UI structure would look something like:

MainScreen->ContentControl->ItemsControl->CriteriaView (=>transitions to=>) ResultView (=>back to =>)CriteriaView

-> means contains here.

Am I on the right track here?

Sep 18, 2012 at 10:44 AM

That sounds correct to me. Do you have a copy of Designing Silverlight Business Applications? There is a sample application called the ToDo List that mimics the behavior. Basically, the views themselves hold no state - they are just a template to render data. The view models do maintain state, so if you have a criteria model the default Jounce behavior is to retain that, so if you go back to the criteria, you simply re-navigate to that view and the information is as needed.

Sep 18, 2012 at 1:01 PM

Thanks Jeremy,

I have the book and I'm working my way through dissecting the ToDoList project to see what fits where and how and slowly the mist is clearing... You said by default Jounce retains the view model. Is that controlled by the DeactivateOnUnload setting?

Sep 18, 2012 at 2:13 PM

That simply calls the method on the view model automatically when the control is unloaded. The lifetime is managed through the way you request the view model - if you use the fluent interface, you can request a non-shared copy instead of a shared on.

Sep 23, 2012 at 9:26 PM

Hi, me again with another question....I have defined a view and added the attribute [ExportViewToRegion(ViewIdentifiers.ContactSearchCriteriaView, "AppRegion")so it can sit inside the 'chrome' of a standard screen (toolbar, link panel etc). 

This view seems to be initialised when the app starts (i.e. its constructor runs), rather than in direct response to its navigation event. When the navigation is triggered, the view model is created and the two are wired together. Is this the expected sequence of events? I hope to use the Screen->region->subregion model of UI you talk about in the book, but I expect my final application to have 30 odd screens with 60 odd screen regions, so I'm concerned about the creation of all those views at startup time (maybe unnecessarily though?).


Sep 23, 2012 at 9:51 PM

Right, I think I have figured this out - it's because of the Binding being marked as [Export], if I wire the views and VM's together in the main module I don't see this happening.