[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 07:32:23 -0700 (PDT)

Julie says:

"... the Android guidelines and SDK components use strategies such as using  
interfaces to hide the implementation of software components in order to build  
modular, maintainable, reusable software ... To me, it appears the current 
EventBoss architecture adds unnecessary  layers and complexity, which most 
probably will have an negative impact  on performance and maintenance ... Also, 
the UI/controller is not supposed to manipulate data ... The last thing the UI 
should do is manipulate a list of  events. Adapters are designed to do that."

Harry says:

I don't believe that Adapters are designed to manipulate data.  I believe that 
they are designed to transform raw data so that it is compatible with the 
requirements of the widgets in the UI.

Jim says:

"Julie says, 'Android guidelines ... use strategies such as interfaces to hide 
implementation ...'.  Then Julie says, '... we need a strong argument to do 
things differently'.  "If the [Android]  guidelines use the strategies that our 
current design uses, then I  don't see that we are doing anything differently."

Harry says:

Good design in Java and in Android Java suggest that we "design to interfaces". 
 
Encapsulation, hiding implementation details within a class, exposing the 
minimum required number of public methods, low coupling, and high cohesion are 
all good design practices.  There isn't any difference between Java and Java 
Android in these issues.  Our current architecture doesn't suggest that we 
should abolish these practices.

Julie says, "The UI should not manipulate the list of events."  I agree.  I'm 
not sure whether the list should be manipulated in the Model or in the 
Controller.  I think that it belongs in the Controller if we use MVC, but I'm 
not sure.  By manipulating, I mean searching, parsing, capturing, and 
deleting...not transforming.  Transforming should happen in the Data Model.

Julie says, "the current EventBoss architecture adds unnecessary  layers and 
complexity."  This seems to be an unsupported comment, and an alternate 
approach 
is not suggested.  I don't know if I am missing a piece of this on-going 
conversation.

I hope this helped to clarify our conversation.

Regards,
Harry





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

 




________________________________
From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Sent: Sat, October 30, 2010 9:43:41 AM
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)


Maybe Julie can provide a code example of an Adapter being used in an Android 
environment?

Thanks,
Harry

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

 




________________________________
From: Jim Cant  <cant_jim@xxxxxxxxxxx>
To: tssg tech <tssg-tech@xxxxxxxxxxxxx>
Sent: Sat, October 30, 2010 9:31:28 AM
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)

 You say "Android guidelines...DO "use strategies....".  Then you say "... we 
need a strong argument to do things DIFFERENTLY".  But if the guidelines DO use 
the strategies etc. that our current design uses, it doesn't see that we're 
doing anything differently.

I still don't see where the conflict is between what you are advocating and 
what 
we have now.  Perhaps you could point out what it is included in our design 
that 
you have issue with or what is missing that you'd like to add.

Cheers,

jim

________________________________
Date: Fri, 29 Oct 2010 13:53:48 -0700
From: jcarwellos@xxxxxxxxx
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)
To: tssg-tech@xxxxxxxxxxxxx


Jim, the Android guidelines and SDK components DO "use strategies such as using 
 
interfaces to hide the implementation of software components  to build  
modular, 
maintainable, reusable software."

I believe we need a strong argument to do things DIFFERENTLY. Why reinvent the 
wheel (unless theirs is square)? And so far I can see no clear reason to go 
against their recommendations, or invent our own way of doing things. If their 
architecture works, why change it? I would have to have a clear explanation of 
why their recommendations will not work and how this architecture that has been 
set up will solve a problem or enhance performance, maintainability, 
extensibility, etc. To me, it appears the current EventBoss architecture adds 
unnecessary layers and complexity, which most probably will have an negative 
impact on performance and maintenance.

Also, the UI/controller is not supposed to manipulate data - it just makes 
calls 
on the data model to get/change/put/delete information. This would occur with 
Adapters, that wrap the data models. The last thing the UI should do is 
manipulate a list of  events. Adapters are designed to do that.

This in combination with "I want to learn Android, not Java" has my vote 
decided.

-julie

________________________________
Julie (Dingee) Carwellos
Web and IT Project Analyst, User Experience and Interaction Designer
LinkedIn- http://www.linkedin.com/in/jdingeecarwellos

--- On Fri, 10/29/10, Jim Cant <cant_jim@xxxxxxxxxxx> wrote:


>From: Jim Cant <cant_jim@xxxxxxxxxxx>
>Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)
>To: "tssg tech" <tssg-tech@xxxxxxxxxxxxx>
>Date: Friday, October 29, 2010, 8:53 AM
>
>
> Julie's research makes the case for using 'Adaptors' in implementing a 
>ModelViewControler model in Android apps; it focuses on Android.
>
>I see nothing in it that says one shouldn't use strategies such as using 
>interfaces to hide the implementation of software components  to build 
>modular, 
>maintainable, reusable software.  I don't see where it argues against our 
>current design for EventBoss.
>
>jim
>
>________________________________
Date: Wed, 27 Oct 2010 17:33:31 -0700
>From: jcarwellos@xxxxxxxxx
>Subject: [tssg-tech] research on Adapters (what, why, when and how)
>To: tssg-tech@xxxxxxxxxxxxx
>CC: kieu.hua@xxxxxxxxx
>
>
>I'm attaching a Word document that has the results of my research around the 
>net 
>on Adapters - what are they, why and when to use them, how to implement them 
>and 
>use multiple adapters. I was surprised (but should not have been) that they 
>are 
>actually an implementation of the Mediator pattern. They are also required for 
>AdapterViews (such as ListView and GridView). When you do a 'setAdapter()' on 
>the view to change the adapter, the data in the list is automatically 
>invalidated, and the list refreshes itself.
>
>The attached contains the details, links and additional information.
>
>Julie
>
> 
________________________________
Julie (Dingee) Carwellos
>Web and IT Project Analyst, User Experience and Interaction Designer
>LinkedIn - http://www.linkedin.com/in/jdingeecarwellos
>
>
>

Other related posts:

  1. Home
  2. tssg-tech
  3. Archive
  4. 10-2010