Organizing android app’s source files
Many beginner programmers may not realize what the point of this is, a guide on how to organize your project’s files ! Well I have had an experience working in team to develop desktop and web applications before, and on each time we divided team tasks, we did it depending on app’s features. So, I can tell you that organizing packages by feature (or modules) is way much better than making different developers look around the entire project each time they need to. This is one good reason for why you should consider this as a beginner developer, and organizing by modules is an example for one of the several package structures you can use to organize your android app.
Android package structure
There are several approches for organizing your app’s packages.
- Component level package structure
You create packages for the different components in your app ( such as Activity,Fragment,BroadcastReceiver…). For example, if your base package is com.demo, then the sub packages are as follows: com.demo.activities | com.demo.adapters | com.demo.models | com.demo.network | com.demo.fragments | com.demo.utils … The problem with this approach occurs when someone else also starts working on the same project, it is very unclear to find a module as a single package and so they have to run around all the packages, classes and verify their usage across the source code which is really hectic and difficult to maintain. Chances of errors increase and so the delivery time. So if you are following this approach, you might be in trouble in future if not in present.
- Module level package structure
Alternatively, we can package-by-feature rather than layers. This approach uses packages to reflect the feature set. In this case, the package names correspond to important, high-level aspects of the problem domain. For example, a drug prescription application might have these packages: com.demo.doctor | com.demo.patient | com.demo.prescription | com.demo.drug | com.demo.webmaster | com.demo.utils …This can make object creation really simple and intuitive, while objects remain immutable outside the package.
- Framework level package structure
If a developer follows the MVC framework then he will likely organize his packages as follows : com.demo.model | com.demo.view | com.demo.controller. The app’s package structure depends on which design pattern the developer is using. This approach is good to follow, but there is a slight problem similar what was disscussed on the first approach: the maintenance will be difficult if working on a team with newbie developpers.
In general Java programming, packaging apps by feature is considered preferable and makes alot of sense. Or, you can mix the last two approches if you are proceeding for a design pattern (in each module, package your classes depending on the design pattern you’re using).
In an android 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 (
res/layout). The best way to further organize or group your various resources, is to install the third-party folding-plugin for Android Studio to create virtual folders, because there is no support for nested folders under the layout folder in android.
Other solution can be using gradle’s ability to merge multiple resource folders, it is discussed in this stackoverflow post.
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. The following are the most important naming conventions:
- Activity : DoctorActivity
- List Adapter : PrescriptionsAdapter
- Database helper : MedicineDbHelper
- Network client: MedecineClient
- Fragment: DrugsFragment
- Service: DrugsService
Just the thought of creating an android project and throwing files and resources all together without structuring them right, is harmfull ! So please, try to train yourself, as a beginner, to conceive your project’s structure, and why not conceive your app or your ui before jumping to the development.