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

From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Date: Sun, 31 Oct 2010 09:13:22 -0700 (PDT)
Hi Julie,

Since I'm not going to be participating in [TSSG] for a month, I will abstain 
from providing direction for the group.  We have asked Jim Cant to provide this 
direction.  


I would like to suggest a change to the diagram that I submitted to the group.  
Instead of
a "Data Buffer", we could substitute an "Adapter".  The event list objects 
encapsulated
in the Adapter would effectively be in a buffer.  

The RSS Parser would save data to the Adapter.  The DataStore would save data 
to 
the Adapter in response to a "Find" operation. And the UI would retrieve data 
from the Adapter for display purposes.  The Data in the Adapter could be 
persisted to the SQL-lite database.

Actually, I think this is too much work for the MVC design pattern.  The MVC 
pattern only
needs to be a part of the design.  There can be external code blocks for 
processing the data, e.g. "find" and "get RSS feed" and "storing data".

Regards,
Harry


________________
|               |
| DataStore     |
| MODEL         |
|persist data   |
|---------------|      
|  Adapter      |------|
--------^--------      |
  find  | store        |
__data__|_data____     |
|                |     |
|  RSS Parser    |     |
|  CONTROLLER    |     |retrieve data
|                |     |
----------^-------     |
update|   | issue       |
view  |   | requests   |
------V-----------     |
|                |     |
| User Interface |<-----
|     VIEW       |
|                |
------------------

 
---------------
http://www.linkedin.com/in/harryhenriques

 




________________________________
From: Julie Carwellos <jcarwellos@xxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Sent: Sun, October 31, 2010 7:55:54 AM
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)



In reply to: 
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."

What's the plan, in our architecture, to replace Adapters? How is it simple? 
What can be simpler than Adapters? I'm really curious, since Android says 
Adapters are required, how we could improve on them, and yet still keep it 
simple - simpler than Adapters, since any change should improve on their 
architecture. If  its not an improvement, then I can't see any reason to change 
it, as we're not working around an issue or problem that Android doesn't have a 
solution for.

-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, 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 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...> 
>
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:
