What’s hard about activating screens?

Posted by Jeremy Miller on August 2, 2009

’m moving on to thinking about the “Screen Activation Lifecycle” section of my book and getting ready for my VAN presentation this week.  I’m defining “Screen Activation Lifecycle” as the process of, wait for it, activating and deactivating screens within an application shell for applications with multiple screens.  As I’m starting this subject I have my own laundry list of topics and patterns to discuss, but I’d really love to hear from you what would be helpful to you.  This topic is not very well documented anywhere except a bare handful of blog posts, but it has to come up on a lot of applications.  Moreover, there is very little framework support.  Caliburn has some support for a “Screen Activation Lifecycle,” but as of the latest code drop, Prism v1 doesn’t address this concern at all.

Here then is what I am planning to discuss:

  • View First vs. Presenter/ViewModel First navigation
  • Modularity.  How can I structure the application to make it easier to add all new screens?
  • Starting screens
    • Connecting Presenter/ViewModel to the View
    • Locating the proper view
    • How to activate a screen
    • How menus and other screens can start a new screen
    • Tracking the open screens
  • Closing screens
    • Cleaning up resources
    • Doing the nagging screens for “But wait, you have unsaved changes!”
    • “Can Close” mechanics
  • Tabbed MDI layouts
    • How to know whether to activate a hidden screen or create a new one
    • Switching between tabs
    • Closing tabs, Close All, Close all but this
  • Web-style navigation / Wizard workflow
    • Remembering history and being able to go back or forward
    • Validating page transitions and disallowing navigation based on validation
  • “Dashboard” layout.  I don’t have much more here than a placeholder for “go learn about how people do dashboard layouts.”  This does seem to be what Prism is built for though
  • Synchronizing Menu state when screens are activated or deactivated
    • Adding peripheral controls to the shell to support a screen.  I.e., when you activate a screen in the main content area it wants to put other controls in the explorer pane on the left or right.
    • Dynamic menus
    • “Plugging in” custom shortcuts
    • Enabling / disabling menus while a screen is running
  • Wiring with an IoC tool

 

Again, this is what *I* have thought about to include in the book.  I really want to know what you would want to see.  What is difficult for your team?  Got an interesting solution?  I’d love to hear about it or get more suggestions for other content.  Thank you in advance.

 

Patterns I’m Using

All these pattern names are preliminary – i.e., until I or someone else comes up with a better name

 

 

 

 

 

 

 

 

  • Application Shell
  • Application Controller
    • Screen Collection
    • Screen Conductor
    • Screen Factory
  • Screen Subject
  • Shell Service
  • Menu State
  • Registry

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Presentation Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://enceradeira.blogspot.com/ JJ

    We tried mvp first time and we found the following points about ‘screen activating’ difficult:
    - View First vs. Presenter first
    - How to synchronize presenters? e.g. view that opens a modal dialog. how does the modaldialog-presenter get the context of the view-presenter, which presenter loads data, which presenter saves data etc…when do they share a unitofwork? We really had problems on that until we started to classify our presenters in independend and dependend presenters and started to standardize the communication between them.

  • Geovanny Tejeda

    I’m very very interested; for some reason our team has always struggle (badly) when using one of those frameworks out there (like CAB) and I always have problems thinking in the terms exposed by those frameworks… we usually get by, but ALWAYS think it’d be best to really learn that stuff.

    After we have some parts of the app working these are actual problems we go through in most projects, granted:

    - Oh we need a splash screen that does X, where do we put this?
    - How to add more functionality in the future with the least possible changes to the existing functionality.
    - Sometimes we have a navigation to the left (like most webpages), how do we update this and where should we put it? in some sort of shared space?
    - We’d like to keep the application functional while connecting to other sources and doing some work, so, background worker, but wait, the application froze anyway when updating the UI, huh?…

    Now that i think about it, I’m even more interested in a good shell app book… so there you go :D

  • Mike Strobel

    Last year, my boss and I spent a couple weeks establishing some UI design patterns to use as guidance for our junior developers in China. At the individual screen level, we came up with a pattern that I call PMVP, or Presentation Model-View-Presenter. This is somewhat similar to the ViewModel pattern, except that the ViewModel tends to encapsulate both the presentation/data model and presentation logic. Our pattern breaks these responsibilities down into two entities–the presenter and the presentation model. The presentation model is shared between the view and the presenter, and it encapsulates the underlying data model, commands, and whatever UI-oriented data is necessary. It also exposes change notification events. The view (as in MVVM) usually binds directly to the PM. The view may encapsulate some display logic, but only what is required for that particular view implementation. The presenter encapsulates the display logic for the screen, and typically listens for changes to the PM and manipulates it further as necessary.

    Screens and their lifecycle are managed by another entity that we call a “Task Director”. The Task Director encapsulates the entire workflow of some user task (sometimes called a “scenario” or “use case”). It determines when a screen should be displayed, and which presenter/view combination is appropriate given the context. Presenters and views are often pluggable, allowing them to be swapped out depending on how the user initiates a task. For instance, a task might have a standard view and a “wizard” view, each using the same presentation model and presenter.

    At the top level, we have the application controller, which effectively owns the task directors.

  • http://www.iserializable.com Roy Osherove

    here’s a simpler problem, would love to see how you’d tackle it:
    http://weblogs.asp.net/rosherove/archive/2004/06/16/156933.aspx

  • http://johnpapa.net John Papa

    Hi Jeremy,

    Comments got long … so I decided to post it to my blog and link to here.

    http://johnpapa.net/silverlight/who-activates-displays-and-closes-screens/

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    Thanks John!

  • http://codebetter.com/members/gblock/default.aspx Glenn Block

    Looks good Jeremy. As far as modularity, I would suggest looking at it from a more granular level as in larger apps modules represent sub-systems. The facilities for how sub-systems get loaded, integrated and have their screens activated tends to be less trivial than simple screen management.

  • http://waf.codeplex.com jbe

    Hi Jeremy,

    Some feedback:

    1) View First vs. ViewModel First navigation: We use ViewModel First navigation so the Controller class which is responsible for the navigation doesn’t have to refer the View. Thus, it’s easier to unit test the navigation workflow.

    2) Starting screens – Connecting ViewModel to the View: We use an IoC container which connects them together. Sorry, its MEF and not StructureMap ;-) .

    3) Starting screens – How to activate a screen: Another question is who is responsible to activate a screen. In our case it’s the ApplicationController or a Use Case Controller. They are responsible to create a ViewModel (and so the IoC creates the associated View) and show them. Showing might be done by setting a View (e.g. public object BottomView { …) property of the ShellViewModel which is bound by a ContentPresenter inside the Shell.

    4) How menus and other screens can start a new screen: Still a controller is responsible for this. The controller might define a DelegateCommand that it sets into the ViewModel. So the controller is notified when the user clicks on a menu item that should show a new screen.

    5) Closing screens: This might be done like this: View notifies the ViewModel (method call); ViewModel notifies the controller (raising an event) that the screen wants to close. The controller decides what to do.

    6) Names: We use quite similar names: Shell; Application Controller, Use Case Controllers; Shell Service; Shell Commands (also responsible for Menu State)

    If you like to see a concrete example (showing of modal dialog, wizard workflow) with MVVM you might have a look at the WPF Application Framework (WAF) project:

    http://waf.codeplex.com/Wiki/View.aspx?title=Model-View-ViewModel%20Pattern

    Greetings
    jbe

  • http://TheRock TheRock

  • http://www.Adum.com Adum

    This is nice

  • Michael Reuss

    Hi Jeremy,
    I think I got a pretty good picture on how to activate Screens from your invaluable posts. (Big thank you, by the way!)
    I still struggle though when it comes to the static, ‘non tabbed’ elements of the ‘Mainscreen’. Are they members of the ApplicationShell and how does this go with presenter first? Or do you use holders for them as well and activate the corresponding screens in the bootstrapper, which on the other hand would make the IApplicationShell quite chatty?
    Any clarification on that would be greatly appreciated.

  • Naresh Goradara

    Hi,
    Good work, Is there any working project for Presentation Model-View-Presenter?