This is particularly important if you have an application with many different screens, but all with the same activation/deactivation logic. If a particular screen has complex activation logic, it may be necessary to factor the ScreenActivator into its own class in order to reduce the complexity of the Screen. However, you should remember that these are two separate roles. In simple scenarios, the ScreenActivator is often the same class as the Screen. Each one of those screens has custom activation/deactivation logic that enables it to setup/teardown the application toolbars such that they provide the appropriate icons based on the active screen.
If you are editing a C# code file in one tab, then you switch to a tab containing an XML document, you will notice that the toolbar icons change.
For example, take the Visual Studio code editor window. This is what Jeremy calls the ScreenActivator. Often times a screen has a lifecycle associated with it which allows the screen to perform custom activation and deactivation logic. You probably have a pretty good intuitive sense about this. Some screen examples might be a modal dialog for application settings, a code editor window in Visual Studio or a page in a browser. The shell may display lots of widgets as well, but these are not part of any screen. The shell may display many different screens, some even at the same time. It’s independent from the application shell. You might think of it as a stateful unit of work existing within the presentation tier of an application. This is the simplest construct to understand. First, let’s talk about what these things are in general. That’s getting a little ahead of ourselves though.
In fact, depending on your architecture, a Screen could be a UserControl, Presenter or ViewModel. While these patterns are primarily used in CM by inheriting ViewModels from particular base classes, it’s important to think of them as roles rather than as View-Models. The terms Screen, Screen Conductor and Screen Collection have more recently been codified by Jeremy Miller during his work on the book “Presentation Patterns” for Addison Wesley. It’s particularly important if you want to leverage composition. Actions, Coroutines and Conventions tend to draw the most attention to Caliburn.Micro, but the Screens and Conductors piece is probably most important to understand if you want your UI to be engineered well.
0 kommentar(er)
