[tssg-tech] Re: research on Adapters (what, why, when and how)

From: Julie Carwellos <jcarwellos@xxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Date: Sun, 31 Oct 2010 04:23:05 -0700 (PDT)
Exactly - it isn't that complicated. Adapters are simple, they just wrap the 
model.

I understood you to ask for code examples - not to build the thing. That link 
has code examples.

Another place to look would be in svn, EventBOSSUI, the EventList.java module. 
It has both the onCreate setting up the adapter, and the Adapter itself.

Julie (Dingee) Carwellos
Web and IT Project Analyst, User Experience and Interaction Designer
LinkedIn - http://www.linkedin.com/in/jdingeecarwellos

--- On Sat, 10/30/10, Harry Henriques <harry_henriques@xxxxxxxxxxx> wrote:

From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)
To: tssg-tech@xxxxxxxxxxxxx
Date: Saturday, October 30, 2010, 9:09 PM

Hi Julie,

http://developer.android.com/resources/tutorials/notepad/notepad-ex1.html is a 
developer
exercise.  I would have to implement all the steps in the exercise to see the 
result.  Can you post the code for this example (that you have completed) in an 
email?  I don't have the time or interest in implementing this simple 
application.



android.widget


Class ListView
java.lang.Object
  android.view.View
      android.view.ViewGroup
          android.widget.AdapterView<ListAdapter>
              android.widget.AbsListView
                  android.widget.ListView

Yes, you are correct ListView is an AdapterView.

As I wrote to Bea, 'binding the data to the view' is a semantic construction 
concocted by
Android developers.  Regardless, the adapter still wraps the data and 
customizes the
behavior of the data model so that it is useful for the view.  Providing a 
reference 
(pointer) form the view to the adapter is ultimately the same thing as 'binding 
the data
to the view.' Call it what you like.

Julie says:"The EventList Activity will need  (it's faster to cap, though) an 
Adapter for the events in the database and one for the events in the RSS feed."

Harry
 says:

"Not necessarily.  It depends on our architecture.  I think that the EventList 
Activity
should get all of its data from the MODEL."

Let's try to keep this simple.  It really isn't that complicated.

Best regards,
Harry
  
---------------
http://www.linkedin.com/in/harryhenriques
 

From: Julie Carwellos
 <jcarwellos@xxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Sent: Sat, October 30, 2010 7:19:04 PM
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)


http://developer.android.com/resources/tutorials/notepad/notepad-ex1.html is a 
tutorial using ListView and Adaptor (in this case, database). The code is clean 
and simple.

ListView is an AdapterView.

Quote from Google Android documentation: "The AdapterView is a ViewGroup 
subclass whose child Views are determined by an Adapter
 that 
binds to data of some type. AdapterView is useful whenever you need to 
display stored data (as opposed to resource strings or drawables) in 
your layout."

The call setAdapter() does that binding. See 
http://developer.android.com/guide/topics/ui/binding.html

Quote from Google Android documentation: "An Adapter object acts as a bridge 
between an AdapterView and the
 underlying data for that view. The Adapter provides access to the data items.
 The Adapter is also responsible for making a View for
 each item in the data set."

The EventList Activity will need  (it's faster to cap, though) an Adapter for 
the events in the database and one for the events in the RSS feed. 

-julie

Julie (Dingee) Carwellos
Web and IT Project Analyst, User Experience and Interaction Designer
LinkedIn - http://www.linkedin.com/in/jdingeecarwellos

--- On Sat, 10/30/10, Harry Henriques <harry_henriques@xxxxxxxxxxx> wrote:

From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
Subject: [tssg-tech] Re: research on
 Adapters (what, why, when and how)
To: tssg-tech@xxxxxxxxxxxxx
Date: Saturday, October 30, 2010, 4:54 PM

See comments below in blue.

Regards,
Harry
 
---------------
http://www.linkedin.com/in/harryhenriques
 

From: Jim Cant <cant_jim@xxxxxxxxxxx>
To: tssg tech <tssg-tech@xxxxxxxxxxxxx>
Sent: Sat, October 30, 2010 10:48:23 AM
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)






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.

If our architecture is agnostic relative to the MVC design pattern, then there 
shouldn't be a problem with implementing the MVC design pattern without 
significantly altering our architecture.  The MVC design pattern describes the 
partitioning of the components in the application and the interrelationships / 
communications between the components.  Our current architecture is defined by 
the Packages in the Project, but it may just be agnostic to all design 
patterns.  In keeping with our present Package layout strategy, there would be 
(3) new
 Packages:  MODEL, VIEW, & CONTROLLER.  The advantage of this construction is 
that the MVC design patterns defines how the different Packages are related to 
each other.

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.

The issue with the core/UI module is that there isn't a clear partition of 
application responsibilities, but  many disparate activities are all under the 
control of this core module.  The UI should be unconcerned with retrieving or 
storing data.  We should probably refresh the UI every time the data model 
changes. 

I suggest that we have an adapter that wraps a data buffer.  The data buffer 
could be filled from the data model in response to a "find" operation or in 
response to a "get RSS feed" operation.  The UI should get a reference to the 
adapter that wraps the data buffer.  The data buffer would be persisted to the 
database on a periodic basis. The data buffer would be part of the
 data model.

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.

I should have said 'synchronously' instead of 'simultaneously'.


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


 

#yiv1507540530 #yiv1507540530yiv833565385 
.yiv1507540530yiv833565385ExternalClass DIV
{}

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...>
References:
- [tssg-tech] Re: research on Adapters (what, why, when and how)
  - From: Harry Henriques
[tssg-tech] Re: research on Adapters (what, why, when and how)

Other related posts:
