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 #yiv833565385 .yiv833565385ExternalClass 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...>