“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:

publicinterfaceIScreen

{

// 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.

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.

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.

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.

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.

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.