Android- Development of multi-state loading layouts -Tips

In this article, I will share some practical Tips on multi-state layouts based on my own project development practices.

Personal homepage goodong

Blog address: loading_layout_practice

What is a multi-state Layout

For most apps, there is a requirement for multi-state loading views in the project, as shown in the figure below.

Corresponding to the development, we usually develop a corresponding custom layout to display different prompt view according to the different state of the page.

In the project, most of us will write this layout framework in the early stage of development, and then other people can directly use their own development process. As follows:

<name.gudong.MJMultipleStatusLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <ListView
        android:id="@+id/lv_activity_center"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />

</name.gudong.MJMultipleStatusLayout>
Copy the code

This article does not discuss how to implement such a custom loading layout. There are too many such layouts on Github. Here we mainly think and summarize what should be paid attention to when developing such a custom layout in practical development.

But for the sake of convenience, here is a simple description of the scheme used. (This custom Layout is called MultipleStatusLayout for convenience.)

Implementation scheme

When implementing MultipleStatusLayout, you choose to inherit a ViewGroup as its parent class, and then default to the first internal View as a ContentView. According to the different loading state, in the MultipleStatusLayout through dynamic addView to control the corresponding layout loading display, can also be lazy loading of different layout through ViewStub, and then provide different methods. Convenient external call, control layout display in different states.

Well, simply say that is the case, the principle is very simple, there is no technical difficulty to achieve, for the general developer as long as the beginning to understand the specific product logic and implementation ideas, I believe that it does not take much time to complete this MultipleStatusLayout. An implementation of this approach can be seen in an open source project.

Tips

Considering that MultipleStatusLayout will be applied in many pages of the project after the completion of development, and many times as the top parent of the page exists, so the development process must pay attention to its performance and stability, otherwise once problems occur, Throughout the project, pages applied to the MultipleStatusLayout will have problems.

Here are some development tips from a performance perspective, maintainability, stability, and more.

Choose the parent container that makes the most sense

FrameLayout, RelativeLayout, LinearLayout are all parent classes of MultipleStatusLayout. You know that a Layout with a RelativeLayout needs to measure twice, so for a layout that will be used on many pages in the future, pass this scheme first.

Just a few more words about RelativeLayout, even though it executes twice its measure on an internal layout, it’s not a performance problem with RelativeLayout, Otherwise, the AndroidStudio activity generation template would not use a RelativeLayout as the default root layout (prior to AndroidStudio3.0). Google’s use of RelativeLayout as the template’s default layout container should have taken into account another advantage of RelativeLayout: using RelativeLayout can effectively reduce the depth of layout nesting. If you’ve ever done layout optimization, you know that layout performance gets worse the deeper you go. The official performance optimization recommendation is to have a layout that is wide and shallow, not narrow and deep, so it makes sense to default to a RelativeLayout root layout.

But because most of the views displayed in MultipleStatusLayout need to be centered, using a RelativeLayout is relatively easy to control, which is probably why many people choose a RelativeLayout parent class. You can make a tradeoff here.

About LinearLayout and FrameLayout, if you follow the implementation scheme mentioned in the previous section, you can actually use both. However, considering the application scenario of this kind of Layout, it is recommended to choose FrameLayout.

Because MultipleStatusLayout will be used as the parent of the page in most cases, the content of the page may change. Then the LinearLayout will be particularly limited. For example, if a page needs to display a FloatActionButton or other view on top of MultipleStatusLayout, using FrameLayout is much easier and more flexible.

Select the best way to load the View

How do I control the views that correspond to these multistates? For general cases, there are at least two types of View, one is loading style View, one is abnormal state layout View, of course, there may be more specific cases.

Different styles correspond to a different layout. For simplicity, we can write all the corresponding layouts in one layout at a time, and then we can display different views according to different states through control hiding and display. This is the most direct idea.

However, if you take a step further, this approach is highly undesirable. Because most of the time, MultipleStatusLayout as a parent container only cares about its own ContentView, and the exception page and the load page may not even have a chance to appear, but doing so now means that the page has no exception or load logic, You will always have the corresponding layout code in your layout. This will waste extra time in drawing the interface.

Moreover, this Layout will be used in many pages of the project later, so the Layout time problem here will become serious when magnified.

A better way to do this is to dynamically load the layout only when loading or showError is called for the first time. The ViewStub works the same way.

Load the layout only when the corresponding method is called.

Resource name

This is a common problem when developing a common Api. As MultipleStatusLayout may define some color resources or background resources, it is recommended that all resources start with a fixed beginning. This prevents the resources from having the same name as those in the main version. This can lead to some weird UI problems or compilation problems. For example, the background of the button you can define as msl_btn_normal instead of btn_normal, and the color of the text you can define as msl_text_white instead of text_white. This can effectively avoid some resource conflicts.

For more information on how to develop a third-party library, see Skyline’s best practices for developing third-party libraries

Provide a friendly way to call methods

Since it is for everyone to use, you should pay more attention to the method name, preferably see the meaning of the name, so that everyone will be more comfortable when calling.

There should also be restraint when providing apis externally. Do not provide too many methods out of a sudden, no matter whether useful or not, all of a sudden to provide external, this will cause an invisible burden on the subsequent maintenance, because the more common methods provided, you have to maintain these methods.

The best rule of thumb is to provide what you use, not design in advance.

In addition, as the project iterates, there may be more arguments to provide methods, such as the previous method to display error pages

void showErrorView(Stirng error) 
Copy the code

Later, to add custom ICONS or click event responses, you need to extend the method parameters, which can become too much to handle. In this case, it is recommended to use Build mode design, as shown in the following example:

showErrorView(StatusViewConfig config) 
Copy the code

It can be called this way when called

showErrorView(new StatusViewConfig.StatusViewBuild(getContext())
                .icon(icon)
                .message(message)
                .subMessage(subMessage)
                .layoutMode(mLayoutMode)
                .withActionText(actionText, clickListener)
                .build())
Copy the code

Good documentation

When you’re done, it’s a good idea to write a simple usage document while it’s hot, so that people can use your library directly against the documentation, not worry about the code implementation, call the Api directly to fulfill their business needs, and save themselves from having to tell others how to use it face to face.

Some time ago, I saw a question on V website. It said that what kind of document management tool does your company use? One of the answers was succinct, interesting, four-word word.

In fact, for any project is, have time to write some documents, comb their own ideas at the same time convenient to others, why not.

other

This Layout will be updated as the project iterations, so you should know from the beginning that it will be updated in subsequent iterations, so you should pay attention to extensibility when designing your code.

In addition, there are many related open source solutions. It is suggested to refer to some good solutions at the beginning, and then develop and maintain a set of frameworks for your own projects based on the actual needs of your own projects. Because multi-state loading prompt framework is mostly strongly related to product design, it does not have general versatility.

Here are some of the multi-state loading open source solutions I have collected for easy comparison.

Open source solutions

StatefulLayout

progress-activity

StateLayout

MultipleStatusView

conclusion

The Layout of the same function may be implemented in different business scenarios in different ways, so no matter which implementation method is good or bad, as long as it is suitable. But the development of this kind of Layout to follow the basic criteria, and to pay attention to the point should be mostly the same, I hope this article can give you some inspiration to help.

Pay attention to my

• Weibo – Gu Dong da Xia
• Zhihu – Goo dong
• Lot – splash