Android Developer

Los Angeles Freelance Developer

Android Developer header image 2

Android Architecture: Part 9, Conclusion

December 29th, 2011 · 23 Comments · Android, OOP

In the previous 8 articles we discussed in-depth all parts to setting up a well-architected Android project. This post will mostly be some of my general thoughts about our project Tap Counter,  MVC in Android and what’s next for this blog.

Tap Counter:
Sources
I’m pretty happy with the  way the series turned out and Tap Counter served well as a discussion piece. We got to address a lot of interesting topics like the under-appreciated package structures, MVC, DAOs, and State Patterns and what those look like in Android. This is pretty much the fundamentals for any data-driven project. If you can do these several things, creating apps become cake.  The only topic I wished I had covered in this series was working with webservices like REST and sending data back and forth from our app. Tap Counter isn’t a good fit to demonstrate this, but I have hopes to talk about it in the future. Perhaps the next post or two will cover this topic. Anyway, the app has been launched to the market so get it and play around with it to see what we’ve talked about in action. Feel free to modify the code and if you make an extension of it, be sure to leave a comment here so we can check out what you’ve done.

Layout Files Aren’t Views:
While discussing MVC in Android with people, lots of developer seem to think that the res/layout/{some_file}.xml are Views. These are not MVC Views. Because you can “view” or see them they are views, yes, but perhaps a better word for them would be components. For example, think of calling  TextView a TextComponent instead. Views in MVC bind data and other great things. They do more than just have a presence on the screen. The items in res/layout/ are simply that: they are layout files, used as a convenience to layout components. This wrong notion that the layout files are Views is very prevalent even on Stack Overflow seen here. With the correct idea, one user writes:

if you’re trying to imply that a static xml file is the view and an activity is a presenter/controller then you’re missing the part of MVC/MVP pattern actually decouples the view and presenter. You cannot instantiate an activity without talking to your layout/view. Really what you want to do is use composition and embed the activity/layout into a view class and the have all the application/presentation logic decoupled out into their respective classes.

MVC in Android is tough. In fact, it kind of sucks. Android wasn’t built for it. From that same post, another user writes:

Android is terrible at MVC. Android’s API philosophy is template/inheritance over composition; which makes it bad for testing too. That being said, there are ways to get MVC out of android, but it is not intuitive.

This statement is completely accurate. To do anything on Android, each screen must extend one of my many types of Activity classes. With no interface, the Activity concept provides a multitude of hooks and convenience methods and is based around the Template Design Pattern. Urgh, so where does that leave us with MVC in Android? Is all hope lost? Absolutely not. Go back and reread parts 1-8 if you think so. MVC in Android just isn’t very intuitive and even comes with a set of other challenges that standard application architecture doesn’t have to deal with.

The Activity:
What’s the role the activity should take? Well….really it doesn’t matter. Just be consistent with it and don’t have it handle multiple responsibilities. In Tap Counter, the Activity is the View, but as I mentioned before, I’ve played around with making Activities function as the Controller and composing my Views instead of having the Activity serve as the View and composing the Controller. I’m liking this approach better and it will probably be the approach I take in the future. The only downside I’ve come across so far is it’s easier to have my Views extends Activity than my Controllers because I’d like to make abstractions with common logic.

What’s Next:
I still want to write about handling data over the wire and Commands in Android. I’ll continue writing articles in the Android Architecture series, but I’ll also be throwing in some other post here and there as I come up with things. I think the next post may deal with styling Android in the appropriate way. If you have a topic you’d like covered, leave a comment.

Cheers!
whizzle :)

 

Tags: ·····

23 responses so far ↓

  • 1 ben // Dec 29, 2011 at 5:01 pm

    hey josh, what do you mean by having your view compose your controller here? thanks!

  • 2 Chris // Dec 29, 2011 at 11:26 pm

    “I’ve played around with making Activities function as the Controller and composing my Views instead of having the Activity serve as the View and composing the Controller. I’m liking this approach better and it will probably be the approach I take in the future.”

    If you have some spare time, please make a bonus post where you do this.

  • 3 musselwhizzle // Dec 29, 2011 at 11:41 pm

    @Ben, The word compose here means creates or instantiates the View. It’s an Object Oriented term. Perhaps you’ve heard it more in the context of “Favor composition over inheritance.”

  • 4 musselwhizzle // Dec 29, 2011 at 11:52 pm

    @Chris, Looks like I’ll have too. I’ve had a couple of request for it now. Thanks for the comment. :)

  • 5 ben // Dec 30, 2011 at 3:17 pm

    this tutorial is insanely detailed, thanks for taking the time to do this! what are your views on delegation with Java? I’ve been looking at obj-c lately and found it extremely useful, but somehow in java it isn’t the same thing, or is it?

  • 6 musselwhizzle // Dec 30, 2011 at 3:26 pm

    @ben, you’re welcome. :)
    I’m historically an Actionscript developer now working in Android/Java. So I don’t have a background in Java or the C languages. However, I think appropriate delegation is a good thing (Singe Responsibility Principle). However, too much delegation can make code hard to work with. You end up tracking down something like “A delegates to B which delegates to C which delegates to D” and it becomes hard to debug and to find out what piece of code is actually responsible for what.

  • 7 empollica // Jan 6, 2012 at 7:05 am

    This is maybe one of the best tutorial I’ve ever read. Really good example for rookies programmers like me… I was programming following Mindtherobot’s tutorial but definitelly, this is a more complete tutorial XD

    Thank you so much and Im waiting for more tutorials!!! Greetings from Spain Josh!!

  • 8 musselwhizzle // Jan 6, 2012 at 1:10 pm

    @empollica. Thanks! And greets from Los Angeles. Yeah, MindTheRobot was a great blog. I was sad when I read the guy would no longer be posting to it. Take care.

  • 9 karni // Jan 26, 2012 at 6:05 pm

    Fantastic blog post. Thank you for taking time to write it down. Greetings from Poland!

  • 10 Robert Taylor // Feb 23, 2012 at 10:01 am

    Hey Josh, nice series.

    We’re working on an open source framework called RoboBinding at the moment which might be up your street. It allows you to declare one/two-way bindings directly in your layout xml, similar to how you might have done in your ActionScript/MXML days. It promotes the adoption of a Presentation/View Model approach, and out of the box you get fine-grained sychronization between views and properties on your presentation model.

    It’s fairly new, but I’d be interested to hear your thoughts (good or bad). There’s a write-up on my blog and an overview on the website.

    I might try a RoboBinding adaption of the TapCounter app – is it available on GitHub or only direct download?

    Cheers.

  • 11 musselwhizzle // Feb 23, 2012 at 1:09 pm

    Hi Robert, That’s wonderful! That will be the best addition to Android I’ve heard of yet. Yea, MXML is light years ahead of Android xml. This would be a great step in the right direction. The sources are at the top of the blog post. Search for “Sources” in the second paragraph. Cheers!

  • 12 nicie // Mar 24, 2012 at 10:30 am

    Thanks for a really interesting series!

    I found it while watching some youtube clips on android development. Seeing those videos it struck me that I missed the possibility to bind UI components to methods and properties of the model/controller which I could in ActionScript/MXML.

    Before finding your excellent blog I found a youtube video http://www.youtube.com/playlist?list=PL18D5B364CB92780F&feature=plcp on MVC for Android which implements this lab description http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf.

    I realize I haven’t grasped the concepts on your series fully yet, but my impression on the youtube video was that it was somewhat simpler than your design. Maybe because the model in the youtube video implements the java.util.Observable and maybe because there are somewhat fewer classes.

    Maybe you have seen the video? What would you say on the differences between the two approaches?

    By the way, I would really enjoy reading on your approach for consuming web services! I guess it would be somewhat similar to the dao pattern?

    Cheers!

  • 13 musselwhizzle // Mar 26, 2012 at 12:40 am

    Hi nicie, I haven’t seen that video but to answer your question about Java Observable, Observable does not have an interface. If you want something to be a java.util.Observable you are forced to subclass it. This is a terrible design (OOP rule: Favorite Composition over Inheritance), and for that reason I just make my own Observable which has an interface. My approach to webservices aren’t DOA, but typically a front controller to the application that’s responsible for handling a thread pool and making modifications to the data. My other sections are MVC where my Controller’s delegate to the front controller for “application level” stuff. I can’t remember where I found this definition for front controller, but here it is: A centralized point of contact for handling a request may be useful, for example, to control and log a user’s progress through the site. System services and view management logic are relatively sophisticated.

  • 14 O.J. Fidelino // Apr 6, 2012 at 11:24 am

    Josh,

    Kudos on an amazing article, I love how you’ve divided your topics, with each post having a clear flow of ideas. I’d been googling for MVC recommendations for android app development, and yours is the most practical I’ve seen so far.

    With the introduction of fragments in 3.0 and the availability of it for prior API’s through the support library, I’m looking at implementing Activities as Controllers and Fragments as Views.

  • 15 Michael Ritchie // May 19, 2012 at 5:37 pm

    I would be interested in seeing an article (or series) on how to expand your MVC idea when consuming web services. I know you stated in your comments that your “approach to webservices aren’t DOA, but typically a front controller to the application that’s responsible for handling a thread pool and making modifications to the data.”

    I am using your idea on a current project and I have to say its working well, really not a performance hit when compared with alternative approaches. I too come from a Flex background and was really looking for something like RobotLegs for Android.

    Anyways, thanks for sharing and contributing to the community!

    -Mr

  • 16 musselwhizzle // May 19, 2012 at 5:46 pm

    Hey Michael. Yup, I come from a Flex background too and my Android architecture is (now….) greatly influenced by Cairngorm/RobotLegs. I find that Flex MVC approaches work fantastic on Android. I’ll write a blog post on it someday. I’ve got a couple of ideas to blog about soon. Thanks for the comments. Cheers Josh.

  • 17 Michael Ritchie // May 21, 2012 at 3:56 pm

    Look forward to your next blog posts. Definitely a lot of Flex knowledge easily transfers over to Android. That is why I was happy to find your Architecture series. It’s very natural for me to use this with Android. Thanks!!

  • 18 Fei // Jun 12, 2012 at 3:44 pm

    Fabulous Post! Clear with inspiring contents. I have got a much better understanding of programming my phone. Thank you so much, Josh!

  • 19 Richard Williams // Jun 30, 2012 at 9:33 am

    I rarely comment much on posts, but this was absolutely superb to follow. I have used MVC 2 for ASP.Net and wondered how to go about it for the Android platform, which I am just starting to develop on. Finding these posts was great and they absolutely nailed it for me! Although I am wondering what/how you got the Activities to act as the controller instead? Would be superb if you could point me to a link or some source that you may have also come across or posted on this :-) Would be really interested in seeing this. Thanks again superb! :-)

  • 20 Rajesh Perul // Nov 9, 2012 at 1:50 am

    Gud Job…….You helped me .Thankyou very much,

  • 21 Valerie // Sep 30, 2013 at 7:17 pm

    Very helpful posts. Thank you :)

  • 22 brent // Dec 17, 2013 at 11:03 pm

    I am a android developer for 2 year and wondered about mvc. I spent several days studying those chapters and it helped a lot. thanks!

  • 23 Greg Palen // Jan 8, 2014 at 2:30 pm

    Josh,

    I’d love to see the “next step” in this – making the timer itself a Fragment and being able to have more than one in the View at a time. Even better, turn the timer itself into an icon that acts as a toggle (tap to start/stop the timer).

    Can you continue this series by walking us through how you’d encapsulate as such?

Leave a Comment