Hi team,
Let me respond to Harry's post by explaining how EventBoss could work
given our architecture and where the MVC (Model/View/Controller)
design pattern fits in.
Actually, our architecture is agnostic about MVC; it doesn't know
whether or not the MVC design pattern is used within the application
or not.
Here's how the core/UI module might function within our apps overall
architecture. (I say 'might' because all this happens within the
core/UI module whose internal architecture is not specified.)
1. App starts.
2. Creates an object to implement the data model. (This object is an
instance of a class that's part of the core package; it's not an
Android thingy.)
3. Retrieves data from the eventsource and adds to data model.
4. Retrieves data from the datastore and adds to the data model.
5. Creates the object to implement the view.
6. Tells the view about the model. (passes a reference to the data
model (or adapter, see below) to the view
7. Tells the view to display.
8. .....user does what users do.....
9. When app closes, persist any changes to the datastore.
An adapter may or may not be needed depended on how well the data
model and view can play together on their own. If the view wants to
call "getCount()" on the data model and the data model has such a
method, everything is fine. If the data model has a method named
"getSize()" that returns the count, then you need an adapter that
knows about the data model. The adapter would have a method something
like 'int getCount() { return myDataModel.getSize(); }. Now instead
of passing the data model directly to the view (#6 above),
you pass the data model to an adapter instance and pass that to the
view; now the view and data model can play together because the
adapter is acting as an 'interpreter' between the different 'dialects'
of data model and view.
You don't need an adapter for an active model. What is needed is to
register the view (in some manner) with the data model so the data
model can notify the view when the data is changed. I believe the
Observer design patter is called for here.
Here's a nit to pick from the sequence of events you mention:
(2) The CONTROLLER responds by sending a message to the MODEL,
e.g. "change stored data".
(3) Simultaneously, the CONTROLLER notifies the VIEW that the
"stored data has changed"
the use of 'simultaneously', suggests the possibility of a race
condition wherein the view could ask the model for the changed data
before the model has changed the data.
Hope this helps,
jim
------------------------------------------------------------------------
Date: Fri, 29 Oct 2010 15:27:58 -0700
From: harry_henriques@xxxxxxxxxxx
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)
To: tssg-tech@xxxxxxxxxxxxx
Hello team,
We probably should use the "Passive Model" that is explained below.
I think that our architecture would look like this:
BTW, I realize that our application isn't a strict HTTP
request/response model
Passive Model
With a passive model, the objects used in the model are completely
unaware of being used in the MVC triad. The controller notifies the
view when it executes an operation on the model that will require the
view to be updated. The passive model is commonly used in web MVC.
The strict request/response cycle of HTTP does not require the
immediacy of an active model. The view is always completely
re-rendered on every cycle, regardless of changes. This may be
especially true in PHP where no state is retained between requests.
________________
| |
| DataStore |
| MODEL |
|persist data |
|---------------|
| Data Buffer |------|
--------^-------- |
find | store |
__data__|_data____ |
| | |
| RSS Parser | |
| CONTROLLER | |retrieve data
| | |
----------^------- |
update| | issue |
view | | requests |
------V----------- |
| | |
| User Interface |<-----
| VIEW |
| |
------------------
If I understand the passive MVC design pattern, the following
operations occur in sequence:
(1) A widget in the VIEW is activated. It sends a message to the
CONTROLLER, e.g. "get RSS feed"
(2) The CONTROLLER responds by sending a message to the MODEL, e.g.
"change stored data".
(3) Simultaneously, the CONTROLLER notifies the VIEW that the "stored
data has changed"
(4) The VIEW responds by retrieving data from the MODEL and populating
the presentation layer.
The MODEL doesn't know anything about the VIEW. The MODEL exposes
methods that allow the CONTROLLER to store data from the RSS Parser,
and exposes methods that allow the VIEW to retrieve data from it. The
MODEL is completely PASSIVE in this architecture; it is completely
uncoupled from the CONTROLLER and the VIEW.
Let me know if we agree if this is actually the MVC pattern that we
are talking about. I don't think we need a ADAPTER unless we are
forced to implement an ACTIVE MODEL.
Best regards,
Harry Henriques
<...snip...>
=
