Re-planning the Android project structure

We need to re-plan the directory structure of the Android project in two steps:

Step one: Set up the Androidlib class library to transfer business-independent logic to Androidlib.

What business-agnostic logic should be included in the Androidlib? Should include at least five of the majority.

The explanations for these sections are as follows:

The activity package stores the activity base classes that are not related to the business. The activity base class is divided into two layers, shown in 1-3.

The base class baseactivity in Androidlib encapsulates the business-independent common logic, and the Appbaseactivity base class in the master project encapsulates the business-related common logic.

NET package is stored in the network underlying package. The package here is asynctask.

The cache package contains cached data and images related to processing.

A custom control is stored in the UI package.

The Utils package stores various common methods that are not business-agnostic, such as the encapsulation of sharedpreferences.

Step two: Classify the classes in the main project into categories, and place them in various packages.

Activity: We continue to split according to the module, dividing the activity of different modules into different packages.

Adapter: All adapters are put together.

Entity: Put all the entities together.

Db:sqllite-related logic encapsulation.

Engine: Put all the business-related classes together.

UI: Place custom controls in this package.

Utils: Put all the common methods here.

Interfaces: The real interface, named with I as the beginning.

Listener: Listener-based interface, named with on as the beginning.

These divisions are mainly for the following two purposes:

1) Each file has only a single class, not nested classes, such as nesting adapter, Entity in activity.

2) You can quickly locate a specific page after the activity has been categorized by the module split. In addition, by dividing the developer into modules, each developer is responsible for only his own package, and the development boundary is clear.

I have been asked, the activity according to the module split, why adapter, entity do not do the corresponding split it? The question is in fact negotiable. I do not split the reason is that when looking at the code, must first find the page from the activity to look at, and not from the adapter, so the activity of the class is enough. In addition, the logic of adapter is much the same, if the developers are strict adherence to the Android encoding, then the method and implementation in the code is basically the same. This is different from the activity, each activity has a very complex business logic, so activity is the most important.

Entity is also like this, entity should only attribute, otherwise it is not called entity. Just when there are hundreds of entity, you need to consider dividing it by module.

Since there should be only attributes in the entity and there should be no business logic, then if it does, we will transfer it to the engine under some class in the package, which is also the meaning of the engine package.

Re-planning the Android project structure