In the previous post I gave a short overview over the players that are involved in the so called Screen Activation Lifecycle. Today I would like to take a closer look at, guess what, the Screen.
For me personally, the design ‘around’ a Screen is one of the crutial elements for success in developing a composite UI layer. Why do I think so?
Mostly because it’s one of the central points which connects the UI infrastructure with all the rest of the application, the actual application code. It’s THE INTERFACE that fills you’re framework / infrastructure with life. If you fail here you probably feel the result throughout the complete application. Day to day work happens around that interface and since the UI seems to be one of those places in an application that is very volatile and changes a lot, a Screen design with principles like DRY and OCP in mind will make your life as an application developer much easier.
So what are the basic responsibilities of a Screen?
- First of all it provides content. While a composite UI’s shell provides the hull of the application, the Screen provides the UI to fulfill a business requirement. I think it’s comparable to the relationship between an Asp.Net Masterpage and the aspx pages displayed in its content placeholder (Disclaimer: I’m no Asp.net expert so feel free to correct).
- Controlling Screen Activation. Since the UI infrastructure can’t possibly now what has to happen when a Screen is activated, it delegates the responsibility to the Screen itself. A practical example of the Tell-Don’t-Ask-principle. Interaction with the Command infrastructure mostly happens here.
- Controlling Screen Deactivation / Closing. I’ve seen this in several applications now. A Screen with changed data can only be left / closed when a) changes have been persisted or b) the user votes to discard the changes. Like in point 2. the UI infrastructure can’t possibly know when that’s the case, so it’s delegated.
With those 3 points in mind, let’s take a look at the Screen interface in StoryTeller.
1 2 3 4 5 6 7
Pretty straight forward, isn’t it?. Next question, who is
actually implementing the interface? And the answer is surprisingly: It
depends! This interface can be implemented for instance by
Supervising Controller - style Presenters. It can be implemented by
ViewModels in Model-View-View-Model implementations. It can even be
implemented by UserControls (though StoryTeller uses this only for very
simplistic screens). It’s a very pragmatic solution giving a lot of
choice to an application developer on how to interact with the UI
I think that’s a good choice. We, as a community, shouldn’t be dogmatic about MVVM vs. MVP, or the whole No-Code-Behind-debate. Consistency is import but, sticking to a pattern not suited for a particular screen (for instance using Passive View for a screen with a lot of fields) can hurt much more than the (pattern) consistency would justify. Mh, that was a little bit off-topic, wasn’t it?
Most of the Screens in StoryTeller are classical Model View Presenter implementations getting their view injected in the constructor.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
The structural aspect of the screens isn’t
that interesting to me. Standard MVP stuff. The activation however (in
particular the usage of
IScreenObjectRegistry) looks really interesting.
Take a look for yourself:
1 2 3 4 5 6 7
IScreenObjectRegistry will be inspected in a future post. The next post
though, will take a closer look at the
ScreenCollection. So, if you’re
eager to learn more about the diamonds and jewels Jeremy has created in
StoryTellers trunk (like I am) rejoin me for the next post when it’s
time to go diving again …