Tips to keep your Android app project organized
Tags: practices, android, beginners, learning
Published: 2019-01-14 17:52:02

---
title: Tips to keep your Android app project organized
published: true
description: Keeping an orginized project structure is important to keep it readable and easy to maintain.
tags: practices, android, beginner, learning
---

##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](https://developer.android.com/studio/build/application-id) 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](https://github.com/ribot/android-guidelines/blob/master/project_and_code_guidelines.md) 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.

![packages](https://thepracticaldev.s3.amazonaws.com/i/04hn3ylsxx0aunirap0l.png)

##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:

![layouts](https://thepracticaldev.s3.amazonaws.com/i/hr4s4ttuk8ytqb997yy3.png)

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