Android application architecture - what is the suggested model? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

In the same way a web or desktop app might have three or n tiers - UI, Business, Data for example - what is the suggested structure for an Android application? How do you group classes together, what layers do you have etc?

I'm just starting Android dev (an internet-based app that must respond to incoming notifications) and have no 开发者_运维百科real feel for the structure I'm aiming at. Suggestions appreciated.

IMHO, Android "wants to" follow a MVC pattern, but view & controller are generally really coupled in activities.

It makes unit test harder and it's hard to obey to the Single Responsibility Principle.

I found a really nice Android architecture presented here, there could be an idea. Everything is loosely coupled, so much easier to test and edit.

Obviously, I'm sure there are a lot of others possibilities (like the MVP pattern (Model View Presenter) - and here are answers talking about MVP in Android), but you should still take a look on it.

I've been working on Android for 9 months now from a server-side background where full unit testing and layered architectures are common and work well.

Through lots of trial and error and I would strongly suggest using the Model View Presenter pattern, not Model View Controller.

A huge issue I've found is that Activities/Fragments have a lifecycle which is outside your control and can lead to unexpected issues.

For example, our main android app wants to be used in landscape mode on tablets. We do this in OnCreateView() or OnCreate().

On a Nexus 7, the default view is portrait so what happens is that it starts the activity in portrait mode, our code then says go to landscape and android ultimately creates the activity class 3 times!

We've hooked up network requests to onCreate and they end up happening 3 times in this case.

Sure, we can add logic to look for duplicate calls but, in my opinion, it would be better, architecturally to try and divide the UI from the business logic.

My recommendation would be to use the factory pattern to create presenters from the activity but make sure the factory only ever returns the same instance. The presenter can then contain logic to do network request, look for duplicates and return cached results and general business logic.

When results from network calls return, either post to a bus such as Otto which the activity (register for the event on onResume() and deregister during onPause()) has registered to, or make sure the callback interface implemented by the activity has been updated to the last activity in the presenter.

This way, code in the presenter downwards is unit testable and not reliant on flaky UI layer testing.

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 should not 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 oppinion 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 your anyway following a MVC pattern.

MVP is the latest architecute most people are following Here is the small documentation As Uncle Bob's clean architecture says, “Architecture is About Intent, not Frameworks”

Watch this video it's just mindblowing good.

Here is a dedicated project for Android Architecture blueprints with well documented source codes. All of them are based on the MVP pattern with several twists. Also check the comparison of the various solutions based on lines-of-code, testability, cost of learning, their support for increasing data complexity. It depends on the particularly developed app and the context (time to market, developers, future plans, etc.) which blueprint fits best.