http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/
Android Architecture: Part 1, Intro
November 24th, 2011 · 11 Comments · Android, OOP
As an Actionscript developer and having worked on numerous data-driven applications, I’ve had an Object Oriented mindset for many years now. When I first started learning Android I want to know some of the common approaches people were taking to their applications. I had questions like “What approach are people using to send data back and forth using web services?” and “What does an MVC look like in Android?” and “How are people persisting their data locally?” and “What are some of the common patterns in Android to achieve common tasks?”
Sleuth:
I began investigating what MVC looked like in Android. After spending a lot of time reading community forums like Stack Overflow and Android blogs, I frequently saw the term “View-Controller” when talking about implementing an MVC pattern. Summarizing, people were saying the Activity should function both as both the View and Controller. This idea didn’t sit with me too well. The idea of a View-Controller violates the Single Responsibility Principle. Let’s not start mixing and matching the responsibilities.
I began investigating what MVC looked like in Android. After spending a lot of time reading community forums like Stack Overflow and Android blogs, I frequently saw the term “View-Controller” when talking about implementing an MVC pattern. Summarizing, people were saying the Activity should function both as both the View and Controller. This idea didn’t sit with me too well. The idea of a View-Controller violates the Single Responsibility Principle. Let’s not start mixing and matching the responsibilities.
I then went on to investigate how other developers were structuring their code for handling web services. So I downloaded a popular online dating app since I knew it would be heavily web-service driven, decompiled it using dex2jar (maybe I’ll make a blog post on this process sometime), and took a look at their source code. Their approach was to make all request go through a single class. For instance, XRequest.viewUser(142) and XRequest.sendMessage(142, “hello world”) and XRequest.blockUser(142, 138). You get the idea. Again, this approach didn’t sit well with me. Not only did this approach violate the Single Responsibility Principle it also violates the Open-Closed Principle. If a new API call was to be added, they would have to go back in XRequest class and modify the code. The class was not closed to modifications and was not open to extensibility.
The Results:
Through my reading and research, I didn’t feel like I’d saw a solid or common architectural approach on Android. This series of articles will walk through building a simple application from start to finish using practices I’ve found to be very beneficial and extensible. We will explore using a strict MVC in Android, use of the State Pattern, Data Access Objects for persisting data, and Commands for sending and receiving data using a web service. The series will cover how to implement these ideas in Android and not necessarily go in depth as to why or what benefits these patterns have. I’m going to assume you know already know the benefits of MVC and such. Additionally, the order I present the topics is not the order which I would code an application but the order I find makes most sense in disussion.
Through my reading and research, I didn’t feel like I’d saw a solid or common architectural approach on Android. This series of articles will walk through building a simple application from start to finish using practices I’ve found to be very beneficial and extensible. We will explore using a strict MVC in Android, use of the State Pattern, Data Access Objects for persisting data, and Commands for sending and receiving data using a web service. The series will cover how to implement these ideas in Android and not necessarily go in depth as to why or what benefits these patterns have. I’m going to assume you know already know the benefits of MVC and such. Additionally, the order I present the topics is not the order which I would code an application but the order I find makes most sense in disussion.
Our Project:
We will use an application I wrote called “Tap Counter” for the discussion. Go ahead and grab the sources, compile it and play around with it. It’s one of those tools gate attendants use to count how many people pass by. Here’s a couple screenshots because it’s much more fun reading about code when you get to see the results it produces.
Sources
We will use an application I wrote called “Tap Counter” for the discussion. Go ahead and grab the sources, compile it and play around with it. It’s one of those tools gate attendants use to count how many people pass by. Here’s a couple screenshots because it’s much more fun reading about code when you get to see the results it produces.
Sources
No comments:
Post a Comment