Efficient Android Studio Project Structure

Organized Workspace

Android project structure has pretty strict rules, especially the resources folders, but here are few simple tips that could make your life easier and your development process more efficient.

Note: In all the examples below I use classic Android MVC approach, so anyone can get it. However, the same principles work with MVVM or other architecture approach as well.

In resource folder you are not able to have subfolders, you can’t use Uppercase letters and need to follow python-style underscore_convention to name your files. Sometimes it takes a lot to find and reuse the old resource like drawable/selector or just to check for duplicated resources when working in a team. What you can do in this case — use the advantages of your IDE environment, rather Android Studio or IntelliJ Idea, to decrease time you spend on resources organization.

1. Use Resource Files Naming Pattern

JetBrains’ products like IntelliJ Idea, Android Studio, WebStorm and others have a great indexation and search tools. But to get the most of it - you should do some work on your side. You need to specify the naming pattern for your files to increase efficiency of your search.

To do that you should think about keywords or scope where these resources are used. For example, you can define pattern like: {parent/activity}_[element(s)]_{name}_{state} , it will give you this look:

Resources Files Example Naming Pattern

It can be a little hard to read sometimes (usually when there are many similar-purpose files), but that gives you a great advantage when you search for things:

Searching Using Idea Environment

So you don’t really need to memorize exact resource file names, but just know a few facts about it: button on login screen in normal state. You can think about other name patterns that will make your search more efficient, somebody likes to add img or image to diff selectors from image files and so on.

2. Keep Activity- or Fragment- related source files in the same folder

Sometimes it can save you a lot of time when you search for particular place in order to make a quick change or fix some bug. For example you are looking for some Adapter used in specific Activity, and instead of digging into pile of other adapters used in projects — you can simply find it under the same folder as your Activity:

Example of Source Files Organization

3. Declare subclasses and interfaces in master class when possible

Instead of creating a pile of files - sometimes it’s wise to define subclasses and interfaces inside the master class, especially when they needed only to define a communication interface with other classes or represent some specific data structure, eg. Callbacks, Data containers you passing in/out your class interface or use in class implementation.

Example of subclasses and interfaces

As you see here we can define private StatisticsContainer class that is only used in our class logic, and public StatisticsCallback that is used only to support external communications for our class. Instead of defining each class and interface in it’s own file — we put it together because of the same context, to keep our project structure light and readable.

4. Listeners and other Anonymous classes

It is good to be flexible, because your application can evolve and requirements can change. One day your login form that consists of 3 independent elements: 1 Button and 2 EditTexts — can become custom View with completely different interface.

So it can be very important for you to be able to adopt quickly. To achieve that I usually define anonymous classes as properties in my Activity or Fragment :

Inline Anonymous Classes as Property

In this case you can easily comment out or remove implementation of specific listener or replace it with something else, instead of removing listener from class‘ declaration (implement interfaces section), then search for universal function you use for all same-type listeners and remove it from there.

5. “Choose wisely” where to use Vector/Xml Drawables

Efficiency of it can be and should be questionable.

First there are unquestionable advantages of using Vector images and Xml drawables over multi-source drawables:

• Only 1 file to work with, instead mdpi/ hdpi/ xhdpi/ and so on
• Ability to make changes (stroke color, background, etc.)

At first I was trying to use vectors and xmls everywhere where is possible. But I quickly noticed that sometimes I spend too much time to work with it rather then use multi-source drawables. So if you look closer you can question these advantages based on your situation:

1. One Resource File to Work With.

Most of modern Designers software supports multiple files export (Sketch, Photoshop in “Design Space” Preview Mode and others), so you can generate all the versions in one click with the right file names.

You can also import multiple source images faster using Android Drawable Importer Plugin for Android Studio (https://plugins.jetbrains.com/plugin/7658-android-drawable-importer);

And the last but not least — you can easily rename your multi-source drawables using Idea’s tools (Refactor -> Rename);

2. Ability to make changes

I noticed that sometimes it’s much easier to make some changes (gradient, colors, shape) in source file using original software, eg. Sketch or Photoshop, and re-generate and re-import files into Android Studio . Rather than spend time modifying it in xml and debugging it.

So as you see, not always vector images or xml drawables increase your effectiveness.

Thanks for reading! I hope you find it useful or at least it gives you some fresh ideas. Tried to keep it short, but if you want some more particular examples and/or have suggestions — Please let me know in comments below!