what's design pattern principle in the Android development? [closed]

Question

I was a JaveEE developer. Recently I joined an Android development team. The structure of Android confused me. The MVC design pattern doesn't seem to suit for Android development. So what is the design pattern principle for Android development? I mean is there any hint about how to write a clean, easy reading and effective Android code.

Answer 1

Android's architecture annoyed me at first, but I beginning to see a method to their madness. It's poorly explained by the android documentation. My biggest gripe has always been that it's hard to have a centralized data model with objects that your Activities share just like a normal application. Android seemed to want me to be a nomad because I could only share primitives between my Activities. And dropping junk in a database is NOT a model because it contains no behavior. So as most people my business logic all ends up in my activity making it hard to share business logic in other activities.

I've come to find out I was missing some key puzzle pieces. Android is MVC. However, it's coupled to the View fairly heavily.

1. Activity == Controller
2. Model == Subclass of Application
3. Anything that subclasses View == View

Interestingly you can create a subclass of Application and declare this in your Manifest file, and Android will create a single instance of this object that lives the length of your application no matter what Activity is destroyed or created. That means you can build a centralized data model there that all Activities have access to.

The way I see this is something like a primitive Spring container that you can initialize objects and resolve dependencies between them. That way you can decouple the model portion of your application away from the Activity themselves. And just have the Activity make calls on the model, and hand callbacks to receive the results so it can update the UI.

The problems with Android is that it mixes controller and view pretty heavily. For example, subclasses like TabActivity, ListActivity imply a certain view being used. So swapping out a view is pretty involved. Also the Controller makes very specific assumptions about what the view is even if you use Activity. He contains direct references to UI objects like TextView, etc. And it registers for low level events like clicks, keyboard, etc.

It would be better if Activity could register for more high level events like "Login", "Update Account Balance", etc which the view would dispatch in response to a series of clicks, keyboard, touch events. That way the controller works at the level you might describe features instead of design features.

I think we'll reach this type of design eventually as we better understand come up with better tools and techniques. It seems like Android might have the extensibility to make this happen, but it's up to community to chart it.

Answer 2

The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.

To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.

You can find MVC in the followings:

• You define your user interface in various XML files by resolution/hardware etc.
• You define your resources in various XML files by locale etc.
• You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
• You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
• You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
• A lot of Utils have been already written for you. DatabaseUtils, Html,

There is no single MVC Pattern you could obey to. MVC just states more or less that you shouldn't mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.

But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my opinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.

If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then you're anyway following a MVC pattern.