I’m developing a java application to visualize time series. I need (at least) three linked views, meaning that interaction with one of them updates the others.
The views are:
-
A list represents the available and currently selected time series. The selected time series are used as input for subsequent computations. Changing the selection should update the other views.
-
A line chart displays the available and selected time series. Time series should be selectable from here by clicking on them.
-
A bar chart shows aggregated data on time series. When zooming in to a period of time, the line chart should zoom in to the same period (and vice versa).
How to implement this nicely, from a software engineering point of view? I.e. I’d like to write reusable and clear, maintainable code. So I thought of the MVC pattern.
At first I liked the idea of having the three view components observing my model
class and to refresh views upon being notified. But then, it didn’t feel right to store view related data in the model. Storing e.g. the time series selection or plot zoom level in the model makes implications about the view which I wouldn’t want in a reusable model.
On the other hand, having the controllers observe each other results in a lot of dependencies. When adding another view, I’d have to register all other views as observer of the new view and vice versa, passing around many references and introducing dependencies. Maybe another “model” storing only view-related data would be the solution?
The ‘active time series’ and the ‘zoom level’ have slightly different consequences and have therefor different considerations where they can best be handled.
For the ‘active time series’, this can best be recorded in the model. The reason is that, if there is a component that could make modifications to a time series, then it is better if the model already knows which one is being operated on rather than having to pass it to the model each time you need to access the data. That also allows for a (future) optimization that the inactive time series are discarded from memory.
The zoom level is a UI concept that should ideally not be known to the model. One solution is to have a single controller that handles zoom events and that controller updates all the view with the change in zoom level (it is then up to the view what it does with the information).
Another option is to introduce a special “zoom model” that handles the zoom updates.
A completely different way to look at the zoom level is to regard it similar to showing a paginated set of results (with a variable page size). Sometimes, pagination is pushed to the model to provide an optimization opportunity for not keeping the entire model in memory.