Android project package structure

Question

I am wondering, how to create flexible package structure for an Android application, such that it'll be easy to extend and manage. My first idea is to put each application component in separate package, such as:

spk.myapp.main.(all classes used in Main activity) spk.myapp.processor.(all classes used by Processor provider)

...and so on. However, the aspect I don't like is, that the class and package naming convention may quickly became inconsistent with other fully qualified names, such as provider authorities (in this case I would rather name these spk.myapp.processor than spk.myapp.processor.processor as the class package path would suggest).

I've done some research, but most pages explain the initial project directory structure, rather than suggest one for bigger projects.

My problem might sound silly, but I like to have order in my projects from the beginning, such that further managing and expanding them doesn't involve unnecessary refactorings or cleanups. Also, I do not have much experience in Java and I wish to learn good habits from the beginning.

Does one have a good and reliable project package structure and naming conventions for Android projects?

Answer 1

Wikipedia has useful notes on Java packages. Packages are mainly useful for two reasons:

1. A package provides a unique namespace for the types it contains.
2. Classes in the same package can access each other's package-access members.

The first point means that you can group items by logical functionality. Activities could reside under an activity package, and your services under a service package.

The second point is quite important and often overlooked. Package access allows you to do some clever things. For example, you can have a 'builder' class which can build and populate models which have package access properties, without adding lots of setter methods or using public properties. This can make object creation really simple and intuitive, while objects remain immutable outside the package.

A really good example of this principle can be found in Romain Guy's Shelves app. The BookStore class can create Book objects and modify their members, without exposing these fields to other classes (in other packages).