Don't think of our mediators as being part of a Model/View/Control implementation. Think of them as how a MVC implementation gets access to the 'M'. Here is the intent of the mediator design pattern: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Design Patterns Elements of Reusable Object-Oriented Software, Gamma, Erich et al, 1995, p 273. It may look like overkill in our application which deals with only one data format from tne source. However, I believe it's appropriate to our goal of learning good practices as we build the app. We of could chose to just mix things together more as described here. http://en.wikipedia.org/wiki/Spaghetti_codeDate: Fri, 15 Oct 2010 12:03:02 -0400 From: bwchaney@xxxxxxxx To: tssg-tech@xxxxxxxxxxxxx Subject: [tssg-tech] Re: Android mediators Message body Julie, I believe the articel you mention refers to a business or person mediator, not the 'Mediator' pattern as defined in the book 'Design Patterns' by Gamma et. al. While the pattern derives its name from the real-world analogy, it is a little more specific to software design. After consulting the Gamma book (which I have owned and meant to read for a decade :-) it seems a 'Mediator' pattern's function is to facilite two-way communication between components and centralizing control. It is suited, for example, to propagating change among dependent components, in our case, for example, coordinating different views, like updating them when state changes (like inactivating buttons, etc...) or if the user changes a preference that affects multiple parts of the system (not necessarily when teh data changes! see below) Also, it appears that Android Adapters are not really Mediators, but rather follow the 'Facade' or 'Adapter' (aptly named) patterns, which also de-couple components, but facilitates communication between them in one direction only. Jim, I still would like to understand the need and role of a 'Mediator' component as part of an MVC architecture, which already offers separation of concerns, if not necessarily loose coupling (which may or may not always be desirable). The following article describes MVC and also highlights the issue of 'is the Controller a Mediator?' http://www.phpwact.org/pattern/model_view_controller In the Android architecture, I see the Activity as the Controller, the View as the View, and the data source as the Model (rss or database in our case) The Android Adapter connects the View and the Model, but the Controller picks which adapter to use! As a clarification to an earlier post, there is no such thing as an Adapter to an Activity. The Activity controls and creates the Adapter, but the Adapter is a bridge between a View and a data source (Model). Android Adapters, by the way, also handle asynchronous updating of data! this could come in real handy. You can define listeners on an Adapter for when the data changes, and it automatically updates theView. Bea Julie Carwellos wrote: In trying to get a better "feel" for what Jim intended for the Mediator, I looked around for other Android mediators. Here's one: http://internet2go.net/news/ad-networks/networks-vs-mediators-one-sdk-rule-them-all Ads come in in various formats for mobile apps because they're from different suppliers, and this mediator makes life easier for the Activity. A single call into the mediator gets reorganized to present the ad in a way the Activity understands it and can send it to the display. Jim, is this what your intention was for the mediator - to make RSS and Database look the same to the Activity? And maybe for future suppliers of data for the view? e.g. Other Event feeds or even APIs. Thanks, Julie Julie (Dingee) Carwellos Web and IT Project Analyst, User Experience and Interaction Designer LinkedIn - http://www.linkedin.com/in/jdingeecarwellos