Android applications should always be neatly organized with a clear folder structure that makes your code easy to read. In addition, proper naming conventions for code and classes are important to ensure your code is clean and maintainable.
Be sure to check out the Ribot Code and Style Guidelines for a more extensive breakdown of suggested style and naming guidelines.
The following naming and casing conventions are important for your Java code:
||All variables should be camel case||Read More|
||All constants should be all uppercase||Read More|
||All methods should be camel case||Read More|
||All parameter names should be camel case||Read More|
See this naming guide for more details.
Android classes should be named with a particular convention that makes their purpose clear in the name. For example all activities should end with
Activity as in
MoviesActivity. The following are the most important naming conventions:
Use your best judgement for other types of files. The goal is for any Android-specific classes to be identifiable by the suffix.
There are several best practices for organizing your app's package structure.
The way to do this is to group things together by their category. Each component goes to the corresponding package:
com.example.myapp.activities- Contains all activities
com.example.myapp.adapters- Contains all custom adapters
com.example.myapp.models- Contains all our data models
com.example.myapp.network- Contains all networking code
com.example.myapp.fragments- Contains all fragments
com.example.myapp.utils- Contains all helpers supporting code.
com.example.myapp.interfaces- Contains all interfaces
Keeping these folders in each app means that code is logically organized and scanning the code is a pleasant experience. You can see a slight variation on this structure as suggested by Futurice on their best-practices repo.
com.example.myapp.service.*- Is a subpackage for all background related service packages/classes
com.example.myapp.ui.*- Is a subpackage for all UI-related packages/classes
com.example.myapp.ui.mainscreen- Contains classes related to some app's Main Screen
com.example.myapp.ui.detailsscreen- Contains classes related to some app's Item Details Screen
This feature allows you to place
DetailsItemModel in one package, which provides comfortable navigation when you're working on "item details" feature.
DetailsItemModel classes and/or their properties can be made package-private, and thus not exposed outside of the package. Within the package you may access their properties directly without generating tons of boilerplate "setter" methods.
This can make object creation really simple and intuitive, while objects remain immutable outside the package.
Resources should be split up into the following key files and folders:
||This is where we put our XML layout files.|
||This is where we put our AppBar menu actions.|
||This is where we put images and XML drawables.|
||This is where we put color definitions.|
||This is where we put dimension values.|
||This is where we put strings.|
||This is where we put style values.|
See the full list of resources here and note the following:
res/values/colors.xmland reference the colors in layouts with
res/values/dimens.xmland reference these in layouts with
Be sure to start properly organizing your resources early on in the development of an application. Be sure to check out the Ribot Code and Style Guidelines for a more extensive breakdown of suggested style and naming guidelines.
Often there are questions about organizing not just the source files but also better organizing the application resources. In a modern app, there are often hundreds of different layout files, drawables, styles, etc and by default these are all grouped together in a flat list within a single subdirectory (i.e
In order to further organize or group your various resources, the best way is to install the third-party folding-plugin for Android Studio to create virtual folders
Refer to stackoverflow post for a discussion of the other options.
It is up to you to decide which of the aforementioned approaches suits your project best.
However, in general Java programming, packaging apps by feature is considered preferable and makes a lot of sense.