Question

I’ve been coding for my Android phone lately, and i’ve been wondering… is this Intent class supposed to outline a new programming style?

I’ve been suspecting the API design discourages MVC: Intents are the main way to interact with all user-related objects (Activities, Services, Other apps…).

Is my train of thought right? Should is stick to “contaminating” Activities with business logic?

I have been reading the android developers site and no particular coding style is encouraged though.

Answer 1

I took a lot of the following ideas I took from this OReilly book. This is just whats worked best for me.

As far as architecture goes, its helped me to think of Android’s UI as a Page Controller pattern – I found it to be similar to .Net Web Forms actually. So yes, it does fit with MVC (at least the Page Controller flavor of it). An Activity is your controller, you typically store your view in XML, and you can build out your Model however you like.

You see a lot of web-ish ideas in Android. Intents are a lot like HTTP, or more generally REST. Intents have a ‘noun’ that says what they are concerned with (can be explicit class declaration ie: go to a specific Activity, or can be more implicit using Intent Filters), the Action is a lot like an HTTP verb (Get, Post, etc), a Bundle is a lot like a list of query string parameters or payload…etc.

And similar to a web page, you want an Activity to be able to take care of itself. What I mean is, you don’t want to pass around some big serialized object from activity to activity, its a lot cleaner/resilient/reliable to just pass the id of the a given record to the next Activity and let that activity grab the record with that id from the db (ContentProvider, some other persistent source…). Activities are also meant to be loosely coupled, and you’re supposed to be able to navigate to one from various paths, it also makes them more re-usable. Thus, allowing the callers of an Activity to simply provide a recordId is a lot easier then the Activity expecting its consumer to have provided a large serialized object.

Bottom line – no, you don’t need to contaminate Activities with Business Logic, tuck that stuff away in an application layer, or a gateway or something like that. As for persistence, the ContentProvider interface is pretty well designed – I like it alot. It also continues the Android RESTful theme, accessing content via URLs and verbs (query, delete, update, insert).