views:

235

answers:

2

In the same way a web or desktop app might have 3 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 Androi 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.

+1  A: 

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 don't should 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.

Pentium10
A: 

In addition to the points that Pentium10 raised:

The SQL database should only be called from an class that extends ContentProvider and all other classes should use that ContentProvider.

Christian
For what reason? Also, the abstract methods provided by the ContentProvider class are so generic that they're almost useless.. the ContentProvider is one class I don't yet see the point of.
MalcomTucker