cristobal baray
kids iPhone apps
s100+ pages

Last edited - March / 99
-- Hear and forget; see and remember; do and understand...

the model-view-controller (MVC) design pattern

introadvantagesexample appmodelscontrollersheretodosrefs

the heartbeat view

The views in this app are very simple. The basic view (source - again, most of the AWT related code was created with Visual Cafe) has a constructor that takes a model and registers for updates from it. The update method uses the current heart beat count (in the data object passed to the update method) as the new value for the display label. For this application, I decided that the view needs to know the heart beat count from the model in case it joins the application late. When a view is created, the heart could have been beating for a while already. In more substantial applications, this information might be essential, even though it isn't in this application. Just to illustrate potential problem, I made it an issue in this toy application. Similarly, the number of heartbeats that the view has received can be kept locally (by the view), in cases where that information is important.

The applet (source) is a view as well. Its update method doesn't rely on the heart beat count, because it just plays a sound for each heart beat. It is pretty straightforward.

Implementation Note

In the applet case, there was some data sent that wasn't used (the heartbeat number was ignored), which some could consider wasteful. In fact, if the model provided an accessor method for the view to use for obtaining the current heart beat, then there would be no need for the current heart beat to be sent as data in the model's notifyObservers method. Instead, a null value could be sent during the update. Then, if a view needed the current heart beat, it could access it directly from the model, which is always passed to the updatemethod.

But this model doesn't have any accessors like that. It could - and it's easy to argue that having views get their data directly from the model is a better design:

  • it allows views to obtain from the model specific information for that particular view. Only the necessary information is transferred.
  • no data bundling/carrying objects need to be created. Eliminating a middle-man between models and views
  • no extra overhead of object creation during observer updates.
  • as the model grows, views are all that need to be updated - again, no middle-man classes need to be maintained as well.
But passing data update objects has advantages too:
  • no concurrency problems - if the model runs in a higher priority thread, the view might miss some data points if it has to access the model directly for its data. This can be a serious problem.
  • data abstraction - I use the same text based view with all of my applications...the text based view doesn't need to know what data is important to a particular model, as the update data object defines that (and how to print it...).
  • easier to distribute the model and view on different machines if they pass messages/data objects to each other, instead of making application specific calls upon each other. With message passing, all the models and views will have a common interface (allowing the same proxies to be re-used). in distributed applications, getting each data point (concurrency problem) becomes more complicated, as one has to deal with a variety of network conditions.

It really depends on how complicated your application is going to be and whether or not you want to distribute it. Personally, I prefer the data update object approach. I'm not too concerned with efficiency right now - machines and JVM implementations will get faster and I'm satisfied with letting those engineers/developers concentrate on improving my run-time performance. Distributing my applications also helps trim my run-times as well and the data update object approach lends itself nicely to being distributed. But I tend to use the data update object method mainly because it helps me focus on what information about the model is important. I'm forced to do that when designing the data update objects.

Again, it's the design process that MVC has helped tune for me. I'm asking better questions about the objects in my application, their functions, and what information they should have access to and provide. Since I find it is still an evolving process in my own head, it is probably something you probably should play around with too, in order to find out what you like and don't like. I've even got some suggestions on how to play around...

introadvantagesexample appmodelscontrollersheretodosrefs