An Android subcontracting strategy recommendation

The importance of subcontracting

In the framework of an app, people tend to focus on the latest technology, but ignore the point, that is subcontracting. Many people may not have a set of subcontracting principles to create packages or put code into any package with the feeling or even the freedom to do so.

Although it will not eventually affect the app functionality, this problem is actually very serious. The impact of a bad subcontracting strategy will continue throughout the app development iteration cycle, mainly in the following points:

1. Code confusion, functional module bounds Blur
2. Difficult to read and maintain, especially for newcomers
3. Functional expansion and reuse difficulties
4. High coupling ratio between packages

Based on personal years of experience in app development and project practice, it is recommended that an Android subcontracting strategy, although not optimal, is basically suitable for the vast majority of Android application development.

A counter-example analysis of subcontracting strategy

First look at a "counter example" (quoted, so the sub-person taps). Have seen a number of third-party projects or open source projects, their subcontracting strategy is this:

1. Put all the activity in the application into a package, such as Com.example.activities
2. Put all the fragment in the application into another package, such as Com.example.fragments
3. ......

It is believed that a considerable part of the developer is such subcontracting, to analyze its advantages and disadvantages.

What are the advantages? Perhaps the classification is particularly clear, such as all the activity is together, but think carefully, so what is the point?

The disadvantages are very obvious:

1. When you see such an app subcontracting structure, you probably don't know what the app has, where it's applied.
2. Code confusion, mixed together, no clear module boundaries
3. Poor readability, when you look for a feature page, you may need to cross multiple packages to find
4. Modifying maintenance is more cumbersome and does not even know if a class is being used in another package
5. ......

Subcontracting Principles

Subcontracting does not have an official principle and is therefore free, but complete freedom equals no freedom.

First, the personal recommended subcontracting principle: sub-package according to the function module.

This is a bit abstract, we refine into an app example, assuming that an app has the following features:

Basic support Features

1. Network requests
2. Image processing
3. Database
4. ......

Business functions

1. News-related function modules
2. Film-related function modules
3. Music-related function modules
4. ......

For the example app above, we subcontract according to the function module:

1. the network function-related code to a package, such as Com.example.network, as to the specific use of okhttp or volley or their own packaging httpurlconnection does not matter. The
2. applies the associated function code, such as picture loading, scaling, caching, to a package, such as com.example.image, regardless of which picture frame is used.
3. The code for a SQLite database-related operation is grouped into a package, such as com.example.db.
4. the relevant business code for the News function module is grouped into a package, such as com.example.news, and all activity and fragment related to the news feature are placed in the package.
5. the relevant business code for the movie function module is grouped into a package, such as Com.example.movie, and all activity and fragment related to the movie function are placed in the package.
6. the relevant business code for the music function module is grouped into a package, such as Com.example.music, and all activity and fragment related to the music function are placed in the package.
7. for adapter, the generic adapter that are encapsulated, Can be attributed to the com.example.adapter, such as just an activity of their own use of adapter, can also be placed in the Business module package, where all adapter are recommended to put in a separate package, because we find the code, often from the functional module angle of entry, according to the principle of functional subcontracting, can be quickly Find activity in the corresponding package, find activity, its use of adapter, entity can also be quickly found, so do not have to put in the package of the function module.
8. for custom controls, you can uniformly classify a package, such as Com.example.widget.
9. for some base classes, such as baseactivity and basefragment, can be placed in a package called com.example.base.
10. for the data object entity, can be unified into the com.example.entity, not into the package of the specific function module, the reason is mentioned in the 7th, another entity may be reused, inherited and so on.
11. for business-independent public methods and tool classes, you can put them in com.example.util.
12. ...

Based on the subcontracting strategy described above, the hierarchy of an app in Android studio is as follows:

Java|---com|---Example|---base| |---Baseactivity.java| |---Basefragment.java| |---Xxx.java||---Network| |---Httpclient.java| |---Xxx.java||---image| |---Imagemanager.java| |---Xxx.java||---db| |---Dbmanager.java| |---Xxx.java||---News| |---Newsactivity.java| |---Newsfragment.java| |---Xxx.java||---Movie| |---Movieactivity.java| |---Moviefragment.java| |---Xxx.java||---Music| | |---musicactivity.java | |---musicfragment.java | |---xxx.java | |---entity | |---movie.java | |---news.java | |---xxx.java | |---adapter | |---absadapter.java | |---movieadapter.java | |---widget | |---circleimageview.java | |---xxx.java | |---util |---toastutil.java |---xxx.java          

1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• Ten
• one
• 2
• (
• )
• +
• +
• /
• 0
• +
• all
• +
• +
• +
• -
• 29
• +
• +
• all
• +
• +
• PNS
• up
i>39
• 48
• all
• /
• /
• /
• /li>
• -

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48
• 49
• 50
• 51

Advantages

The following are the key benefits of using the subcontracting strategy described above:

1. Get a general idea of the app's functionality from a subcontracting structure
2. Highly modular, readability and maintainability greatly improved
3. Functional module navigation is clear, easy to find the relevant function code, even if the new person can quickly find the corresponding code
4. Reduced coupling between package and package, adding or removing function modules becomes simple
5. When you modify your code, you generally only have a feature, and you generally don't have to worry about features that affect other packages.
6. More abstract, modular, easy to extend and reuse, especially for basic function modules
7. From the point of view of code access permissions, the in-package invoke permission overrides the inter-package call, and security increases

Summarize

Subcontracting itself is an open question, there is no fixed or optimal solution, the above recommended strategy is only some basic principles, specific details can be based on the actual situation of the app, welcome to explore.

An Android subcontracting strategy recommendation