Android, Flash, Flex, and PHP

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