Tips to keep your Android app project organized

The importance of an organized code structure

It's all about readability. Big projects can be difficult to organize due to the amount of classes, resource files and libraries used. Having an organized code structure involves separating classes into different packages according to their purpose and having proper names for your resource files.

This post should be useful if you develop Android apps using either AndroidStudio or IntelliJ.

Package name for your Android app project

Quick note, when you're just creating a new project you will be asked to choose the package name for your project. As the Android documentation states, the correct way to name your project is com.company.appname, this follows the normal Java package naming conventions.

File types

Some of the file types that we work with in an Android includes classes (ClassName.java or .kt) and resource files (activity_main.xml) such as drawables, layouts, values, etc.

Classes and resource files are separated by AndroidStudio (or IntelliJ) by default. You can find classes in app/java/com.company.myapp/ and resource files in app/res. However, as I mentioned before, big projects can have a lot of classes with different purposes, and a lot of layout resource files. Keeping them orginized its important to have a mantainable project.

Classes

Organization and naming tips

There are a lot of classes, with different purposes, that you can have on a project. Surely you'll have Activities, Fragments, Models for your objects, Adapters, and depending on your app's reach, Network requests, Services, Wrappers (which I call Response), etc.

As for the class names, I like to follow this guide and end the name with the name of the component (Activity, Fragment, etc.).

Android Studio lets you create packages after app/java/com.company.myapp/ so you can use them to keep classes separated according to it's purpose. This will help you and your coworkers navigate through your project. To crate a package just right-click on the package name -> New -> Package.

• Activities: Contains yout project Activity classes. An Activity name example can be LoginActivity.

• Fragments: Contains your project Fragment classes. A Fragment name example can be UserRegisterFragment

• Adapters: Contains Adapter classes for your ListViews (or RecyclerViews). Adapters should be reused as much as possible to prevent repeating code. (DRY :) ) An Adapter name example can be SongsAdapter.

• Network calls: This depends on your preference I personally name this package as HttpRequest and contains the classes associated with Retrofit2 to perform REST calls, as well as the API interface where I define the endpoints. Class names can vary, in my case, I usually have the RetrofitServer.java, MyAppAPI.java and APIUtils.java classes.

• Models: The Model package is usually used to store the classes to map objects from a network request, or simply to create objects in other classes. Since it looks weird to initialize an object as 'HouseModel house = new HouseModel()' I take out the component name from it and keep it just as House.

• Wrappers or Response: This package contains classes that serve as wrappers when performing network calls, and usually contains only one object pointing to a Model class. Same as with Adapters, try to reuse as much of these as you can. I usually name this classes with the same name as the Model class it'll wrapp, but with 'Response' at the end, for example, HouseResponse.

• Utils: Any other classes that you cosnider that don't require their own package, from simple things as a class that creates some special margin you wanted for your TextViews to Services or Singleton classes to manage user sessions.

Here's a quick exampe of how my packages look.

Resource files

Types of resource files

Resource files can be found in the res folder. There are several packages that contains resource files, some of them are: drawables (for icons, images and backgrounds), fonts, layout (for our Activities and Fragments layouts), menu (for menus such as NavigationDrawers, BottomNavigationBar, etc.), values (may contain your string, colors, dimens, styles, among other resources.

I'm going to focus on the naming conventions for layout resource files. Unfortunately, you cannot create packages or folders to save layout files as we do with classes, all of the layouts are saved together in the layout folder. That's why it's important to pick the right naming convention.

Resource files naming tips

Something that's been useful for me is to name my layout resource files as: 'component_description'. For example, the layout for your LoginActivity would be named as activity_login. A UserRegisterFragment layout would be named fragment_user_register_activity. And same for adapters, dialog fragments, and even menu resource files (for example, for a BottomNavigatioMenu: bottom_nav_main_menu). This way you only have to look for the component and then for the description of your layout. Think of it as sorting them.

Here's an example:

Even though I didn't chose the best names for my layout files (still needs refactoring), I know where to look for a Fragment layout, for my DialogFragment ones, as well as Activities and Adapter.

Conclusion

That's it for this post! We've discussed the importance of keeping and organized project and how to do it with simple every-day practices. If there's some convention or practice that you think can be useful for code organization either for me or anyone reading this post, please share!

Twitter: https://twitter.com/MiguelDev_95

Some references

https://blog.smartlogic.io/2013-07-09-organizing-your-android-development-code-structure/

https://guides.codepath.com/android/Organizing-your-Source-Files

https://github.com/ribot/android-guidelines/blob/master/project_and_code_guidelines.md