[tssg-tech] Re: Android mediators

  • From: Jim Cant <cant_jim@xxxxxxxxxxx>
  • To: tssg tech <tssg-tech@xxxxxxxxxxxxx>
  • Date: Fri, 15 Oct 2010 14:26:11 -0400

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
      
    
  
  

                                          

Other related posts: