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?
Posted
Mon, Sep 7 2009 11:33 AM
by
Jeremy D. Miller