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

From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Date: Sat, 30 Oct 2010 18:09:03 -0700 (PDT)
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 Activitywill 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 Activitywill 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
>
>
>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...>
Follow-Ups:
- [tssg-tech] Re: research on Adapters (what, why, when and how)
  - From: Julie Carwellos
- [tssg-tech] Re: research on Adapters (what, why, when and how)
  - From: Julie Carwellos
References:
- [tssg-tech] Re: research on Adapters (what, why, when and how)
  - From: Julie Carwellos
[tssg-tech] Re: research on Adapters (what, why, when and how)

Other related posts:
