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.

Shamefaced

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.

Pumphrey

I just released something for my Android Binding project, that helps decouple the Activity and View. code.google.com/p/android-binding – Yolandoyolane

I'm assuming you use Class Models, as opposed to Subclasses of Application, for Models which you just need to instantiate in the Activity, use, and destroy? As in, Models which stay "local" to the Activity, there's no point in using a Subclass of Application, is there? I guess a Subclass of Application would be good if you need to share general things across many Activities. In my apps, my data is very specific like an invoice, or a payment, so I have an Activity (Payments.java, Invoices.java) which deal with each specific type and therefore I don't need global Models. – Embarrass

Models consist of several different types of objects. POJO objects that model your program like Invoice or Payment are apart of the model, but they aren't subclasses of Application. Payment as a subclass of Application doesn't pass the IS-A relationship test. Payment is NOT an application. However, your Application is made up of payments and invoices so it's reasonable that Application might contain instances of Invoice or Payments. It might only create them from service calls, but it could also cache them... – Pumphrey

Classes that talk to services also live in the Application because all Activites could use the service to do network communication. Things like Invoice might be used on multiple Activites because you have invoices you have sent to clients, and invoices you received from service providers. Those might be two separate views, and they share use of Invoice instances. Your service calls use objects like Payments, Invoice, etc as parameters to methods and they'll return these model objects. Typically, objects in the model are POJOs, but they don't have to DTOs or VOs always. – Pumphrey

The idea of a model being "local" to an activity is a by product of your UI design. Should that change through adding features or evolving your design you can very easily wind up needing to share data between views. So tying your data models like Payment and Invoice to an Activity is not a flexible way of designing things because it locks you into that UI design. So how do you separate these things out so you can more easily modify the UI without rewriting a lot of plumbing? Using proper separation between model, controller and view which is what using an subclass of Application helps you do. – Pumphrey

Adding this so people won't go crazy subclassing Application, FROM ANDROID DOCS: "There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton." - developer.android.com/reference/android/app/Application.html – Kristoferkristoffer

I find Singletons a worse solution in every platform. Your program is NOT modular when you use singletons. And that existed since well forever which is way before Android was even an idea. Previously they were known as global variables and they are the same thing. Who knows what the developer was thinking saying they are "more modular". That person would have to explain themselves very carefully to clarify that. The good news is that with frameworks like Roboguice or Dagger you don't have to subclass Application to build the container for your app anymore. – Pumphrey

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.

Skelly

hmm...it is more code behind concept than mvc...becuase you have xml definitions of layouts(xml files), and you have 'code behind' code that work with these layouts..it is more tightly coupled than mvc, where views(xml layouts in this case) know nothing about controllers(code behind code here).. – Aruabea

The most problem in our Android project is the coupled. One class seems do everything for one module. I need a principle to decoupled it, just like MVC. – Shamefaced

I don't see any Data binding capability in Android so it's hard to understand why you said ...are an implementation of a model-view-viewmodel pattern - There is totally nothing MVVMic when working with Android. Even MVC is hard to implement. – Fenugreek

Answer 3

Android development is primarily GUI development, which like Swing/AWT in Java consists of lots of anonymous inner classes reacting to GUI events. Its one of the things that has really kept me away from doing a lot with Swing....but I have an Android phone, so I'm going to grit my teeth and just get over it, as many an Apple fanboy has said about the antenna problems. ;)

Afroasiatic

Answer 4

Android makes the typical decision of making the Controller and the View a single class. This encourages putting too much in the same place. An Activity corresponds to a screen, each View to a region of a screen (sometimes the whole screen), each Controller to the user gestures from that region of the screen, and Models are just Models, sometimes backed by services from Environment or some other crazy little set of utility functions. I use the Activity to coordinate one or more MVC trios. This helps deal with Android's choice to just throw everything in the same place.

I can test the vast majority of an Android app without running the simulator. Big win.

Billyebilobate

Answer 5

Sorry for my English.

Android has a very good modularity (Activities, Fragments, Views, Services, etc.). So there is no need in MVC.

Of course there is the separation of taking input (Activities, Fragments), logic, view (xml or java) and data (databases, files, preferences). But this is not MVC. You shouldn't try to use MVC, it will only complicate your architecture.

Rather than keeping something in global scope, Android motivates you to keep objects as deep as possible in their scopes (class members, local variables), and pass objects to/from activities, or to fragments, using Intents/Bundles. This is also because of memory limitation.

The system may destroy your activity if the foreground activity requires more resources so the system must shut down background processes to recover memory.

So it's not safe to store not-constant (mutable) objects as global (static) objects. Usually you use static for immutable constants.

In simple terms, you separate your application into screens (Activities). Then each screen - into fragments (Fragments). To perform a sequence of actions on the screen you can also separate them using Fragments (example).

So you have very small blocks in your application, each of which you can easily test and reuse.

Landfall

Answer 6

My impression is that android programming model has lots of similarity with MS WPF. XML layout definitions, code that is always bound to one of these definitions... So, if you are asking about design patterns because you want to improve your current or in development android projects, maybe you should look at WPF practices and patterns for improved architecture, like MVVM.

Check out these links:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

there is small project that is already trying similar thing:

http://code.google.com/p/android-binding/

cheers

Aruabea