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 > > >