Home>Network programming tutorial>Java tutorial

A brief discussion on the file structure and standardized deployment suggestions of projects in Android development

Author：Eve Cole Update Time：2025-05-22 19:16:01

1. A few words

  • Using Gradle and its recommended project framework
  • Put sensitive data such as passwords into gradle.properties
  • Don't write the Http client yourself, use the Volley or OkHttp library
  • Use Jackson library to parse JSON data
  • Avoid Guava and do not use too many libraries for Dalvik 65K methods limit
  • Use Fragment to draw UI interface
  • Activity is mainly used to manage Fragments
  • Layout file XML is also code, organize them well
  • In the layout file, use styles to avoid duplicate properties
  • Use multiple style files instead of one huge style file
  • Keep your color.xml short and DRY, define the color disk
  • Also keep dimens.xml DRY, define common constants
  • Don't create a layout that is too deep
  • Avoid client processing of WebView and pay attention to memory leaks
  • Use Robolectric for unit testing and Robotium for connection (UI) testing
  • Genymotion for emulators
  • Be sure to use ProGuard or DexGuard

2. Details
Android SDK
 Place your Android SDK in your home directory or other places that are not related to the app. Some IDEs will associate the SDK when installing and place the SDK in the same directory of the IDE. When you need to upgrade (reinstall) the IDE or replace the IDE, you will find something bad. In addition, if your IDE is running under a user account instead of root, do not place the SDK in the system-level directory, otherwise sudo permission is required when using it.

Build System
 The default choice is Gradle. Ant has many restrictions and is too large. With Gradle, you can do it easily:
- Compile different flavours or application variants
-Create simple classes -Script tasks
-Manage and download dependencies
-Custom keystores
-etc
The Gradle plug-in for Android is also designated by Google as the new standard compilation system, and Google continues to upgrade it.

Project structure
 There are two popular options: the old Ant & Eclipse ADT project structure; the new Gradle & Android Studio project structure. You should choose the latter. If your project uses an old structure, replace it.
Old structure

 old-structure ├─ assets├─ libs├─ res├─ src│ └─ com/futurice/project ├─ AndroidManifest.xml├─ build.gradle├─ project.properties└─ proguard-rules.pro

New structure

 new-structure ├─ library-foobar├─ app│ ├─ libs│ ├─ src│ ├─ androidTest│ │ │ └─ java│ │ │ └─ com/futurice/project│ │ └─ main│ ├─ java│ │ └─ main│ ├─ java│ │ └─ com/futurice/project│ │ ├─ res│ │ └─ AndroidManifest.xml│ ├─ build.gradle│ └─ proguard-rules.pro├─ build.gradle└─ settings.gradle

The main difference between the new structure is the splitting of the 'source code set' (main, androidTest), which is the concept from Gradle.
Using the highest level "app" is helpful to distinguish your app from other library projects referenced by your app (such as library-foobar). Then settings.gradle keeps the application's index to these libraries, and app/build.gradle can point to these libraries.

Gradle configuration
 General architecture please follow Google's guide on Gradle for Android;
Small tasks (scripts), you can use Gradle to create small tasks instead of Shell, Python, or Perl, etc. For details, please refer to Gradle's documentation;
password. In your application build.gradle you need to define signingConfigs for publishing compilation. The details are as follows:
Don't write like the following, it will appear in your version control system:

 signingConfigs { release { storeFile file("myapp.keystore") storePassword"password123" keyAlias"thekey" keyPassword"password789" }}

Instead, you should create a gradle.properties file that will not be added to the version control system.

 KEYSTORE_PASSWORD=password123KEY_PASSWORD=password789

This file will be automatically imported by gradle, so you can use it in build.gradle like this:

 signingConfigs { release { try{ storeFile file("myapp.keystore") storePasswordKEYSTORE_PASSWORD keyAlias"thekey" keyPasswordKEY_PASSWORD } catch(ex) { thrownewInvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.") } }}

(If using Maven, please refer to the original document)

Library
 Jackson is a Java library that can convert objects and JSON data into each other. Gson is also a similarly good choice. However, we think Jsckson is better because it supports multiple ways to handle JSON: streaming, memory tree model and drive JSON-POJO data binding. But remember, Jackson is bigger than GSON, so you should consider it as you please, if you want to avoid 65k methods limit, it is best to use GSON. Other options: Json-smart and Boon JSON
Network, cache and pictures. Use Volley or Retrofit. Volley can also be used to load and cache images. If you choose Retrofit, you can use Picasso to load and cache images. Then use OkHttp to perform a valid HTTP request. These three types: Retrofit, Picasso and OkHttp all come from the same company, so they complement each other. OkHttp can be used to connect to Volley.
RxJava is a responsive programming library, in other words, handles asynchronous events. (For details, please refer to the original document)
Retrolambda is a Java library that helps you use Lambda expressions on Android or other platforms before JDK8. (For details, please refer to the original document)
Finally, remember the dex method limitations and don't use too many libraries. (Android applications, when packaged into dex files, have a maximum limit: 65535 reference methods [1][2][3]. If you exceed the limit, a serious error will occur. Therefore, don't use just too many libraries, use the dex-method-counts tool to decide which classes to use to keep within the limit, especially avoid using the Guava library, because it contains more than 13k methods)
Activities and Fragments
 Fragments should be the default option for your Android deployment UI interface. Fragments can be reused in your application. We recommend using Fragments instead of activities to draw interfaces based on the following points:

  • The solution is multi-view layout. The main reason why Fragments was introduced was to expand mobile applications to platform computers, so that you can display A and B views on your tablet, while only A or B can be displayed on your phone. If your program is implemented using Fragment in the beginning, then your program can be easier to apply to multiple devices.
  • Screen-to-screen communication. Android's API does not provide a suitable way to pass complex data (such as Java objects) between activities. However, using Fragment, you can use Activity to become a channel for communication between its children Fragments. Even if this is much better than Activity-to-Activity communication, I still recommend that you adopt the Event Bus architecture, such as using Otto or greenrobot EventBus as a simpler solution. If you don't want to take additional libraries, then RxJava can also be used to implement an EventBus.
  • Fragment can be used not only to layout the UI. You can add a Fragment without a UI interface as the backend servicer of the Activity. You can even create a Fragment to implement the Fragment switching logic instead of letting the Activity handle the Fragment switching logic.
  • Even ActionBar can be managed in the Fragment. You can choose a Fragment without a UI interface to specifically manage the ActionBar, or you can choose each currently visible Fragment to handle the ActionBar of the parent Activity by itself. Refer to here.
  • Then, we also do not recommend over-use of nested Fragments, which may cause matryoshka vulnerabilities.
  • From an architectural point of view, your application should have a top-level activity that will contain most business-related fragments. You can also create some other supportive Activities as long as their communication with the main Activity is kept simple -- similar to Intent.setData() or Intent.setAction().

Java package structure

The Java structure in Android applications is close to the MVC structure (Model-View-Controller). In Android, Fragment and Activity are actually controller classes. From another perspective, they are part of user interaction, that is, they belong to the View View class.
Therefore, it is difficult for us to strictly distinguish whether a Fragment (or Activity) is a controller or a view. So from the perspective of Java packages, we'd better put Fragments in their own fragments packages, and then the Activity is in the most advanced package (follow the suggestions put above). Of course, if you want to have 2 or more activities, then you create an activities package.
In this way, the entire structure looks like a typical MVC structure. A Models package contains POJOs, which is used to convert Json data obtained by the API interface, and a views package contains Views, notifications, action bar views, widgets, etc. Adapters is an intermediate layer that is located between data and views. However, they usually need to output the View view through getView(), so you can place adapters in the subpackage location of the views package.
Some application-level controller classes that belong only to the Android system should be placed in the managers package. Various data processing classes, such as DateUtils, can be placed in the utils package. Classes that interact with the background server should be placed in the network package.
In short, the overall architecture from interacting with the server to interacting with the user can be designed as follows:

 com.futurice.project ├─ network ├─ models ├─ managers ├─ utils ├─ fragments ├─ views ├─ adapters ├─ actionbar ├─ widgets ├─ notifications

Resource file naming
 Follow the prefix convention, similar to type_foo_bar.xml, such as: fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.

Organize layout files
 If you don't know how to normalize a layout XML file, you can refer to the following conventions:

  • One property per line, indented by 4 spaces;
  • android:id is always the first one;
  • android:layout_** attribute should be placed on top;
  • The style attribute is placed at the end;
  • End flag/> To occupy an exclusive line, it helps to sort or add properties;
  • Don't write hard codes, such as android:text. For Android Studio, you can consider using the Designtime attributes method.
 <?xml version="1.0" encoding="utf-8"?><LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" android:layout_height="match_parent" android:orientation="vertical"> <TextView android:id="@+id/name" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_alignParentRight="true" android:text="@string/name" style="@style/FancyText" /> <include layout="@layout/reusable_part" /></LinearLayout>
Related Articles