Hower there is bunch of patterns addressing presentation layer issues, implementing clean presentation layer in Java desktop application is tricky task. Main problem for me is a lot of mess inside. I'd like to present my approach to take control of presentation layer, which is combination of existing ideas such:
Supervising Controller, Passive View,
Presentation Model,
Publish-Subscribe,
Observer.
This will be an approach, not a pattern. The reason is a pattern is something widely used and this will be just set of tips. So you won't be able to apply it by just repetition some steps, but by interpretation the approach in the current context and
SOLID analysis. But if you are not familiar with patterns listed above and presentation layer issues of desktop application, try
Mediator pattern or SmartUI approach first. You will have some mess in the code but still under control.
So, if you want to take a look on risky implementation of a presentation layer, check out
this example. As far I remember some folks call this SmartUI anti-pattern.
Well, the UI is really smart in the example. It contains child UI components, implements listeners and does both UI and business processing. This GUI is simple but continuing this approach leads to code which is hard to understand, hard to test, hard to develop.
The idea
Let's list challenges for the desktop applications with visual presentation layer:
- communication between controls
- managing application state - there are three types of it: screen state, session state and record state
- type conversion between view and rest of the application
- handling user events
- keeping GUI responsive - typically with threads
- testability - Humble Dialog aka MVP is a solution
Take look on the figure.
In the typical application all controls are grouped by their business purpose and UX rules. Let's treat the controls arrangement as being not so important for the application architect. What is important that we have many groups of controls, each group has its business purpose and groups need to communicate with others. Let's call these groups components.
However components might be visually arranged in a hierarchy (depends on UX designer), from the source code side they are totally equivalent. Component to communicate with other component use an event bus. When an event comes to a component it updates its state (what mostly means a user view is changed) according to the subscribed event.
Using event bus gives all benefits of the
Publish-Subscribe pattern. You may use topics or even two or more event buses for really complex GUIs.
This was an idea. Now let's take a look how a component is designed inside.
Structure of a component
Five parts works together as a component.
| part | responsibility | out of responsibility |
Form | * is coupled with a particular GUI technology
* builds itself
* has private helper methods to working with embedded controls
* calculates a control arrangement | * business processing
* calling calling services
* validation
event publishing |
FormEventHandler | * implements all technology-specific event listeners
* might be decomposed into specialized handlers e.g. DragAndDropHandler | * subscribing events other than technology-specific
* business processing
* calling calling services
* validation
* event publishing |
View | * exposes methods for getting and Form state (see Nice Move with ValueSetter)
* typically is implemented by Form classes | * event publishing
* event subscribing |
ViewObserver | * notifies that something happened on a Form
* typically is implemented by the Presenter class | * event subscribing |
Presenter | * calls business services
* publishes events addressed other components
* subscribes on events from other components | * business processing (except of very rarely cases) |
So how you see, a component talks to other components via event bus, but asynchronous communication inside the component is implemented via
Observer Patterns. There is nothing wrong with using event bus inside the component also. But in my opinion the solution with event bus outside- and Observer inside- is more clear and easier to test.
and how it works?
Here you have a diagram how a user request is processed by a component.
and also how components talk to others:
ViewModel - what is for?
The problem is how to deal with screen state (keeping
Form as stupid as possible), especially when you work with the remote backend and you need to synchronize the client with the server.
Possible solution to this is introducing a session state which is in-memory copy of screen state.
Presentation Model pattern do that. The pattern
represent the state and behavior of the presentation independently of the GUI controls used in the user interface. It is possible to find
Presentation Model structure in this approach. These are:
View interface and
Presenter.viewModel property.
However implementing
Presentation Model is not the goal, I have borrowed
viewModel part from the pattern. Why?
In regular MVP pattern
View exposes methods to set and get state of
Form controls. It's something like that:
public class DetailsPresenter implements DetailsViewObserver {
private DetailsView view;
public void handleRequest() {
String name = view.getName();
String name = view.getTitle();
Date dayOfBirth = toDate( view.getDayOfBirth());
//call services
view.setTitle( newTitle );
//...
}
}
This approach causes lots of
set/get methods in the
View interface. Because the fact that some controls states are needed to business processing the Presenter handler methods are full
set/get/add invocations.
An alternative to this is full-featured
Data Binding. When something changes on the screen it is automatically reflected to the
viewModel and vice versa. Really magic
Data Binding means lots of listeners, controllers and events going there and back again.
So, what instead? Map? Well, map might be a bag for everything, but idea is good. I use the apache-commons
DynaBean as
viewModel implementation.
ViewObserver exposes the method to notify about changes of screen state.
public class DetailsPresenter implements DetailsViewObserver {
private DynaBean viewModel;
private DetailsView view;
public void buildViewModel() {
viewModel = new LazyDynaBean();
viewModel.set("name", "Jack");
viewModel.set("title", "Dr.");
viewModel.set( "dayOfBirth", new Date());
}
public void handleRequest() {
String name = viewModel.get("name");
String name = viewModel.get("title);
Date dayOfBirth = viewModel.get("dayOfBirth");
//call services
view.updateControl( "title", viewModel.get( newTitle) );
//or updateAllControls()
}
@Override
public void propertyChanged(String property, Object value) {
viewModel.set(property, value);
}
}
public class DetailsFormListener implements DocumentListener {
private DetailsViewObserver viewObserver;
public void changedUpdate(DocumentEvent e) {
viewObserver.propertyChanged("title", e.getDocument().getText());
}
//...
}
Implementation details
You may fetch examples from
my Github profile.
pl.bnsit.architecture package
This is basic template of the approach.
pl.bnsit.flights package
This is an example with coule windows, validation and so on. But I followed the typical llayered architecture.
pl.bnsit.onepieceflow package
There I went a step ahead. I tried to write simple Kanban board. But I started thinking iin a component-like way. I asked myself
What are independent components on this GUI? and answered:
a card, lane containing set of cards and board containing set of lanes. Then I realized that the independency might be considered through all application layers, not only inside the presentation layer.
Continuing this way of thinking we come the architecture with small, well-defined components anchored in the business domain, which are working together to do a business task.
Type conversion
Notice that some type conversion must be done between
viewModel and
Form. I did this with TypeConverter interface:
public interface TypeConverter {
String toString( Object anObject );
Object fromString( String str);
Class type();
}
Conversion is done when the control state is updated:
public class AddingCustomerForm extends JFrame implements AddingCustomerView {
private Map converters;
public void updateComponent(String id, Object value) {
Object convertedValue = convert(value);
JComponent component = components.get(id);
ValueSetter.get(component.getClass()).set(component, converterValue);
}
private Object convert(Object value) {
Object converterValue = value;
if( converters.containsKey(value.getClass()) ) {
TypeConverter converter = converters.get(value.getClass());
converterValue = converter.toString(value);
}
return converterValue;
}
and back, when Listener notifies via
ViewObserver that control state was changed.
