Analysis of Android code quality management

Template method - base class encapsulation

Activity and fragment should be the most commonly used components of Android. Simple encapsulation of them is also very helpful to improve the simplicity of the code.

BaseActivity ：

BaseFragment :

The code is relatively simple. The template design mode is used. A method only does one thing. For initialization, only initialization is done, and for setting listening, only listening is set. No matter how many activities \ fragments can unify the coding style, it looks clearer and not messy.

Fragment simple management

Let's take a look at the creation and management of standard fragments

Copy this method every time you create a fragment. The code is redundant and not conducive to maintenance and update.

Let's encapsulate it

Calling code:

The above encapsulation uses the knowledge of generics, factories, singletons and so on. You only need to initialize the object once in the activity to manage the fragment in one line of code. You can pass in the class of the corresponding fragment on which page you want to display.

Simple universal adapter

Listview is the most commonly used component of Android. Optimizing litsview is essential.

The most painful thing about using listview is to write the getview () method of baseadapter, which is written over and over again. Most of the code is repetitive and redundant, but you have to write it again. Let's extract redundant code and encapsulate it.

Calling code:

The notes are very clear, so I won't say more.

Custom combination control, layout modularization

There must be a lot of layout redundancy in normal project development, such as the setting and navigation in the red box in the figure below.

As like as two peas, the ID files are distributed to the layout of the files.

The worst thing is not this, and all the logic is written in the activity \ fragment, which makes the activity \ fragment particularly huge and really realizes a lump of X code.

I think we should extract the common layout into an XML, and then use a groupview to deal with these logic and businesses, so as to reduce the burden of activity \ fragment.

The code will not be pasted. Go to the source code demo to check the paramswitchview. This view is an item in Figure 1, which encapsulates the layout and the logic of the required remote control keys to switch data left and right.

Interface oriented programming

Interface oriented programming means that the interaction between all classes or modules in an object-oriented system is completed by interfaces.

The reference of the parent class points to the subclass object and points to different subclass objects, resulting in different behaviors:

Parent a = new child a;

Many children's boots often change business in project development, such as customized system applications, and the underlying interfaces may be different on different models of TV \ mobile phones. At this time, these underlying interfaces are separately encapsulated in a class for management. When the platform changes, only the implementation needs to be changed.

Define unified management methods for interface classes

Implementation class 1

If the current business requirement is Huawei's customized system, you only need to call Huawei's subclasses

If the business requirements are transformed into Xiaomi, you only need to create a class for implementation

Implementation class 2

In the calling code, you only need to change huaweimanager to xiaomimanager to adapt to other models.

Here is just to instill a coding thinking. There are many emergencies in actual development, which may not be applicable to all.

Before coding, you must take a little time to simply conceive and organize the code, and don't write what you think.

Pay attention to the encapsulation of tools

In our normal development, we often use many methods that do not need to be written in the logic layer. We can extract them separately and put them in separate classes for separate management.

For example: toast, sharepreference, acquisition time, system version, network, MD5, etc....

These things can be encapsulated and managed separately, reduce the code of the logic layer, and can also be called by other logic layers.

bad habit

Some people like to define a tool class like tools, which stores all the tools and methods.

1. The network, toast, status, time, etc. are all managed by one class. The consequence is that it is inconvenient to maintain and update in the later stage, and the code looks chaotic.

2. Build some common methods directly in the logical layer, and copy them directly in other places.

Or there are other similar methods without encapsulation, which directly copy the code that used to modify only one other line in other places.

good habit

1. Create a variety of tools to store these methods separately. Toast only stores toast related, and network only stores network related, so as to avoid being mixed together. It also conforms to one of the design principles: single principle.

2. Similar methods are extracted independently, and the parameter flag flag is used to distinguish application scenarios.

Some common tool classes are collected in the source code and shared with you.

MVP layered architecture

I wrote an article about it last year. You can have a look. It can make the code unusually clear.

https://www.oudahe.com/p/27279/

There are many ways to improve the code. I can't think about it all at once. I'll continue to update and share what I think of later.