- 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
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.
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
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:
But passing data update objects has advantages too:
- 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
- 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.
- 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