Android Application Archtecture

Question

I have a lot of .Net development behind me, and most of my applications were layered in UI, Service, BL and DAL .. and Database layers. Each layer was often it's own project, all referencing each other to have a flow of data running through the solution.

I am brand new to Java and Android. What it seems is that we develop one output file, and therefore, one project. Would I simply use different folders for each layer? Maybe a ServiceLayer folder, with the classes inside that, and then a BusinessLayer folder with the business classes within there?

What's the usual structure to keep code clean and maintainable? I am not doing this for professional reasons (yet). It's purely to learn.

Edit: The application is just going to be a simple application that allows the user to enter data daily about something (Simple UI, with maybe a few drop down loookups getting 'reference data' from a database), and allowing the user to select something, enter some details, and store to the inbuilt SQLite database.

Once that's working, I'd like to syncronise data to an online database (I will write a webservice hosted on a .Net hosted system (GoDaddy, for now)) which will store latest data, and provide a web front end to provide easier data entry if the user has access to a Laptop or PC). So, some sort of web service that refreshes my app, and also sends updates to the server.

Answer 1

First, it depends on what application are you doing.

you should do a textual or schematic description on how a user will work with application. Fix down every possible scenario. Put down examples that will be used later for tests.

Decide what belongs to the functionality and what - to the changeable configuration. Extract functionalities and data entities from scenarios.

From scenarios make decision what your app will be. Is it service, activity, widget , even a content provider or a complex system, including some different components. TEst your decision against scenarios.

In the case of the complex system, distribute functionalities and data entities among application components. Make a list of components and what they are (activities or smth else).

Make the list of UI components with description what they do (not HOW yet) These will be widgets and activities or fragments or layouts later.

Make draft layouts for UI components. Make simple passes from one to another. Look at the UI. Return to scenarios and play all of them them with your draft UI. All UI components and classes put into one hierarchy of packages or package.

Make a list of data entities. Decide what will be in what. Plan them as collections or tables in DB or different DBs. Make them as classes, put them into another hierarchy of packages or another package. Here also put DB helpers - classes that talk with DB by SQL.

Make a testing classes for fillling UI and data entities with test data and launching them.

Adapters needn't be public, for they are used in their parent GroupView only. So, no files for adapters usually.

Do not put all globals into special static classes - it is a bad practice. You are mixing so the code and the configuration.

Configuration data put into recources. If some of them are complex, use XML sources and parser(s). Make readers of resource data into global variables. Not all of them will be static! They could belong to the main Activity instance, for example.

Do not use unconfigurable constants in the code! May be, your name only :-). Every other constant becomes non-constant sometimes.

Always do so:write something - connect something to a bulk - add test(s) for this new thing - test this new one - test the bulk - repeat. Small steps only!