Lesson 2. Project Structure, Organization and Architecture

This lesson will show you how an Android project structure should be organized taking in account a classic Android MVC approach. Please take in mind that most of the principles listed here will and should work with other approaches such as MVMVM.

1. Guide to App Architecture

Unlike most desktop applications, Android apps have a much more complex structure which typically involves different Activities, Fragments, Services and Broadcast Listeners working together and relying on each other to deliver the best experience possible. Moreover, keep in mind that these app components might even belong to different apps and deliver different behaviors depending on the context. Now, think about handling the UI and views while managing the lifecycle of these components, it can become a total mess if done wrong.

In this section, we'll show you a recommended app Architecture that uses native App Components by working through a use-case:

Think about building an UI that shows an user profile. The user profile will be fetched from a private Backend using an API. Normally, a developer would create two different files:

1. UserProfileActivity.java -> UI controller and view model holder.
2. user_profile_activity.xml -> UI definition.

This means that all the information in the profile will be held by the Activity, an Android component that can get garbage-collected if the OS needs some space for others, and which's state will be destroyed and re-created with, for example, phone screen rotation. To solve this, Android now offers developers a ViewModel pattern. With a ViewModel, you could then add a new file to persist the information, and your project would look like this:

1. UserProfileActivity.java -> UI controller and view model holder.
2. UserProfileViewModel.java -> Class that prepares data for the UI.
3. user_profile_activity.xml -> UI definition.

With this architecture you can make sure that the lifecycle of your activities will not play against your data. Even if the phone is rotated, the ViewModel will keep the data and your UI controller will be able to restore it on the interface.

If you want to learn more about this architecture, visit: https://developer.android.com/topic/libraries/architecture/guide.html#common_problems_faced_by_app_developers

2. Project Structure and Organization

1. Search-oriented naming conventions

Android Studio 3.0 is a product from JetBrains with amazingly fast and convenient searching tools, but you've got to do some work on your own to take full advantage of it. Think of the naming you implement as a fast method for searching files among your project, DEFINE PATTERNS:

In the Resources folder you can't use camelCase, therefore a good naming pattern may be the follow:

{activity}_[element]_{name}_{state} i.e. login_button_bg_disabled.xml

2. Use packages to group Activity or Fragment-related files

When you are in front of a big and complicated project, having all your Activity and Fragment-related files in one folder will help you do quick changes to an specific module, fix a bug or make a change without affecting the whole project or spending hours trying to understand it. Some key files you'll probably end up placing together are the Activity or Fragment main class, the adapters for any list you may implement on it and why not, an static class with important tools or methods.

3. Define anonymous classes as properties in your Activities

Making changes to your app's interface may come with the need of changing of the code behind it. Think for example in the listeners you implement on an activity's button. In the future, you may need to change its position o remap its functionality to another component, if you declared that listener as an anonymous property, the change will be easy and painless.

4. Split large style files into smaller files

Having a single style.xml file may be the choice of many developers while working on Android Studio, but think about how difficult it may get to have all your styles configurations in one same file. Android lets you create new .xml files inside the same /values folder and place different styles inside. For example, instead of having all your activities styles inside one style.xml file, you can create style_home.xml, style_login.xml and style_registration.xml.

5. String naming convention

Name your strings in such a way that it resemble namespaces:

Bad

<string name="network_error">Network error</string>
<string name="call_failed">Call failed</string>
<string name="map_failed">Map loading failed</string>

Good

<string name="error_message_network">Network error</string>
<string name="error_message_call">Call failed</string>
<string name="error_message_map">Map loading failed</string>