“Screen Activator” Pattern

This is kind of a call for help.  One of the patterns I’m talking about in my book is what I call the “Screen Activator.”  First off, what I’m calling the Screen Activator is a role within an application that is responsible for bootstrapping, activating, deactivating, and generally controlling the lifecycle of a single logical screen within the application.  In StoryTeller my “Screen Activator” interface is this:

    public interface IScreen

    {

        // What’s the actual UI control to display?

        object View { get; }

        string Title { get; }

 

 

        // Sets up the ancillary screen elements like menus and

        // extra controls in the explorer pane

        void Activate(IScreenObjectRegistry screenObjects);

 

        // Implements the traditional “I can’t close because

        // “you have unsaved changes” functionality

        bool CanClose();

 

        // Sometime soon there will also be a Dispose() method

        // for tearing down and deactivating the pieces of the

        // screen.  For now, I’m just letting the memory leak…

    }

I clearly see this pattern reemerging over 5-6 years of my projects and in other people’s work as well – only there’s one little problem with the pattern.  Almost everybody I explain the pattern to hates the pattern name.  They clearly recognize the pattern itself, but the naming doesn’t work.  Nobody has come up with another name that I like either (“Screen Lifecycle Manager” captures the essence, but anything code-related terminology with the word “Manager” in it is automatically vague and useless), so I want to widen the net and get some input from you, dear reader.  I still like “Screen Activator,” but the immediate feedback is “but it also deactivates the screen!”

The other suggestions are:

  • Screen Custodian
  • Screen Activator
  • Screen Lifecycle

Lastly, I don’t see “Screen Activator” as a specific implementation pattern so much as it is a role and responsibility within the bigger presentation infrastructure.  Let’s back up and talk about what I’m labeling the “Screen Activation Lifecycle.”  Think of an application like Visual Studio.Net itself that displays and hides or destroys dozens of different screens in a single user session.  These screens behave differently, show different user controls inside the main tab area, change the active selections of the menus, toolbars, and even stuff new things into the other panes of the application shell (like when you open a XAML file and the “Toolbox” control shows up somewhere).  Oh, and because we don’t hate our users (seriously, we don’t, they ultimately pay our bills), we want to warn them whenever something in the user interface tries to close a screen that has some sort of unresolved issue.  I certainly appreciate that Visual Studio warns me when I’m trying to close a code file with unsaved changes and I definitely like that Visual Studio quietly saves any outstanding changes from all open screens anytime I’m compiling the code when I’m running a unit test.  There’s a lot of responsibilities in that whole mess, and the Screen Activator role is an awfully important part of the equation.

In a much earlier post, I talked a little bit about the main players in the Screen Activation Lifecycle, but hadn’t pulled out the activator pattern yet. 

 

Well dear readers, what do you think?  Do you see this pattern in your own work?  What do you think it should be called? 

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.
  • Anand Kumar B

    How about “View Manager” or “View Controller”

  • AndreaF

    ScreenPad (in analogy with the area where rockets take off)

  • http://nileshgule.blogspot.com Nilesh

    How about ScreenPresenter as its main responsibility lies in presenting the required screen to the user?

  • http://www.adverseconditionals.com Harry M

    The Puppet Master

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

    @Mario,

    It does, but I think I’ve settled on “Custodian” instead of Activator after some consultation behind the scenes. The Activate and Deactivate methods would both be called by a Screen Conductor as it switches screens. There is value in having it be the same class as it has to hold state many times between activate and deactivate.

  • http://www.mariopareja.com Mario Pareja

    Jeremy,

    You emphasize that “Screen Activator” is a role, and if simple enough, you often see the role being placed directly on the presenter. Perhaps you are having difficulty in naming this role because it is not explicit enough. Why not have “Screen Activator” and “Screen Deactivator” roles? This does not imply that they live in different classes. The CanClose and Dispose methods seem semantically cohesive and would likely be called by the same (or related) function. The Activate method, on the other hand, would probably be used in a different context.

    Does that make sense?

  • http://ggreig.livejournal.com/ Gavin Greig

    @ Alex Simkin

    Maybe the credibility of the term depends a bit on where you’re coming from. In Scotland (where I am) janitor is the commonly used term, so caretaker doesn’t have any social associations, and sounds pretty positive – oh, so this is a class that takes care of a screen? Cool!

    However, if you’re somewhere that prefers the term caretaker over janitor for the real-world job, then maybe caretaker doesn’t work so well for you. Janitor sounds a bit odd to me for a class, although I mentioned it to make the point about Janus and door-keeping.

  • ibrahim

    ScreenDirector

  • sam de la garza

    Canvas Mayordomo
    or
    Screen Juggler

  • Alex Simkin

    Caretaker and janitor? Why not ‘screen maid’ like in ‘French Maid’? Takes care about almost everything.

  • http://ggreig.livejournal.com/ Gavin Greig

    +1 for ScreenCaretaker. I commented to this effect yesterday, but for some reason it doesn’t seem to have appeared.

    I came to it independently of Rob’s thesaurus bash, after thinking about your roadie analogy. A caretaker (or janitor, the term preferred in some places) is responsible for maintenance, setting up for any special events and, most fundamentally, opening the door at the start of the day and locking up at the end. (The term janitor comes from Janus, the Roman god of gates, doorways, beginnings and endings.) That seems a pretty good match for what you’re describing.

  • Gagan Rajpal

    Two more, ScreenMaster or ScreenHost.

  • Gagan Rajpal

    How about “ScreenAnchor”, with anchor as in anchorman

  • http://twitter.com/vitaminjeff vitaminjeff

    @robeisenberg Awesome thesaurus usage!

    How about “Screen Sage”.

    sage – n – someone venerated for the possession of wisdom, judgment, and experience.

    Your pattern enforces “wise, judicious, or prudent” actions towards the screen; e.g., “bool CanClose();”.

  • http://codebetter.com/members/laribee/default.aspx Dave Laribee

    Jeremy, why not just “Screen?” It is the screen from the developer’s perspective after all.

  • http://jiltedcitizen.com Nick Portelli

    Why screen? Just director or dispatcher.

  • Alex Simkin

    Screen Lifecycle Management Helper
    (SLiM)

  • pattonjp

    how about Screen Steward

  • pattonjp

    how about Screen Steward

  • pattonjp

    how about Screen Steward

  • Blindeblanke

    ScreenDictator, also known as “The Dic”…

  • http://igorbrejc.net Igor Brejc

    Why not just stay with IScreen?

    BTW I’m very interested in IScreenObjectRegistry… Can you give an example of what this interface is supposed to look like?

  • Bu

    WindowManager

  • http://www.neverindoubtnet.blogspot.com/ Ward Bell

    +1 for Director. “You, screen there, enter from the left. You … off the set. Hey, you’re already on … keep going. Are you ready to go on? Can you leave now? You’re fired! Can somebody get me a screen that knows how to act?”

  • http://thedwalker.blogspot.com Thedric Walker

    I like Screen Dispatcher. Then I looked at Rob’s list and thought how about you keep the name in a way and go with Screen Catalyst. I mean I growing up in the 80′s still have an aversion to activator(brr, Jheri curls).

  • http://activeengine.wordpress.com David Robbins

    ScreenDispatcher – At muni’s like the police or fire department, the dispatcher receives the call and in turn alerts the appropriate parties, coordinates other parties and services from other departments, routes messages, and re-calls the force if someone else has responded or if it is a false alarm.

  • http://realfiction.net Frank Quednau

    Um, but your interface is called Screen? So what’s wrong with screen?

  • Steve Py

    Generally this is part of the functionality that I assign to Presenters. Though I can sort of see how the responsibility for view management might fall outside of the presenter. (I.e. where views are provided to the presenters and managed externally.)

    Currently I am building presenters where the views are provided by an IoC container. The presenter manages when the view is shown/hidden & composed, but the construction & decomposition falls to the container.

    So I’d probably suggest something along the same lines for a name since your looking to manage elements of the view composition externally:

    View Container or Screen Container.

  • http://blogger.forgottenskies.com Steve

    I like the Presentation Shell as well.

  • http://www.borber.com/ Borek

    Although “manager” in itself isn’t very descriptive (and “screen manager” would be quite a bad name), I find “screen lifecycle manager” pretty descriptive, probably more than most of the other proposed names. At first, I also liked “screen supervisor” but when I think about it, the word “supervisor” isn’t any better than “manager”, just less commonly used.

  • http://www.52m.be Cohen

    I would add +1 for Screen Marshaller
    and propose:

    screen mediator

    screen container (analogue to IOC/DI container)? (although the name doesn’t say that much)

  • Karl

    ScreenMarshaller

  • http://blog.codiceplastico.com Emanuele Delbono

    I used a similar patter in my application. I called it “Screen Advisor”.

  • Bill Barry

    I would call it Screen Director I think.

    It isn’t really managing the life cycle of the screen because it doesn’t actually initialize or dispose the screen itself. It also is not activating the screen. It is instead putting the screen in context with the application.

  • http://www.bluespire.com Rob Eisenberg

    ScreenCatalyst
    ScreenSupervisor
    ScreenGovernor
    ScreenOperator
    ScreenMarshal
    ScreenCurator
    ScreenWarden
    ScreenOverseer
    ScreenGuardian
    ScreenParent
    ScreenShepherd
    ScreenCaretaker
    ScreenDriver
    ScreenForeman

    (and yes, I did use a Thesaurus…)

  • http://phatboyg.lostechies.com/ Chris Patterson

    The last system I built where this was a concern, we sort of looked at the roles used in the production of a hollywood film to associate names with the roles. I’ll admin, we took it way too far, but some of the things stuck.

    On the screen, we had actors. The actors had scripts. The scripts were given to the actors by the teleprompter.

    But the role in charge of the screen lifecycle, the coordination of the actors on the screen, was in fact, the Director. The director was in charge from the time the screen when active (Action), to the time when the screen was gone (Cut). Everything leading up to that was a support cast (producers, grips, wardrobe) role and everything after was cleanup (such as the custodian, which if you recall junior high, was the guy that you blamed for stealing your bag from your locker).

    So I like Screen Director, it makes sense to me. And it is much shorter to type than:

    ScreenLifecycleManagerInCharge

  • Mike Levy

    I like Simon’s Screen Coordinator if the implementation will be a single instance that affects multiple screens.

    Where do you see this component within the architecture?

  • Simon

    Screen Orchestrator
    Screen Coordinator

  • Haider Abdullah

    Screen Composer

    Screen Conductor

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

    @Dennis,

    That’s not quite the role I’m going for here. If you think of the screen real estate as the stage and the View, Presenters, and ViewModel’s as the rock band, the Screen Activator is more like the roadie that gets there first, sets up the stage, then tears down the stage after the rock band is finished.

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

    @SimplyGed,

    The role I’m talking about here is distinct from the Controller in MVC or the Presenter in an MVP architecture — even if it ends up on the Presenter class.

    I say “screen” because that’s generally how my teams and the product managers describe it, even if we really just mean something that lives inside a tab item within the greater application shell.

    Are you really doing Smalltalk style MVC in a stateful client? Why? I didn’t think anybody did that anymore.

  • http://moleseyhill.com Mat Roberts
  • SimplyGed

    I have something similar in a framework I’ve written.
    It is called

    View Controller

    My naming is biased because I used the MVC pattern within the framework, but I don’t understand why you are fixated with the word Screen? You’re not managing/directing/supervising the whole of the screen, just a view of the data, within an application.

  • Daniel Fernandes

    Screens Dependencies Manager
    Screens Controller

    Notice I said Screens and not Screen.

  • http://www.dennisdoomen.net Dennis Doomen

    Presentation Shell since it acts as a shell that holds the current view, passes events from end-users back to the view and typically manages the entire realastate

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

    @Thedric & @Matt,

    Thanks for the response

    “Observer” is out because the activator is in charge rather than being a passive watcher. I’m iffy on Monitor for the same reason.

    I like Supervisor. Director is a maybe.

  • Matt Hall

    Screen Observer
    Screen Monitor
    Screen Director
    Screen Supervisor

  • http://thedwalker.blogspot.com Thedric Walker

    Listening to the VAN meeting from 8/5 I thought of two suggestions: Screen Monitor and Screen Director.