Better UI update routine

[[174789]]

This is a lesson I learned while writing Windows desktop programs.

Sometimes, we need to create a business-compliant View, or UI object. For example, each item in the friend list of an instant messaging software must have three data items: avatar, name, and brief description. Then, our View object must have three corresponding methods to set these three properties, and then when the View is displayed, it will display our required data.

At the very beginning, I wrote like this honestly.

 // The following is a pseudo-code, not rigorous
 class UserItemView extends View {
 ImageView mAvatar;
 TextView mName;
 TextView mDesc; 
     
 public void setAvatar(Bitmap avatarImage) {
        mAvatar.setImage(avatarImage);
 } 
     
 public void setName(String name ) {
        mName.setText( name );
 } 
     
 public void setDesc(String desc ) {
        mDesc.setText( desc );
 }
 }

At the beginning, this is OK, it looks very safe, and there is no problem. If a user's data changes, just update the data.

Okay, now here comes the problem. The problem with writing like this is that when the states/data depend on each other and affect the display of the UI, problems will arise and the code will be messy.

We now propose a requirement that if the description (desc) is empty, the avatar will be displayed, and if it is not empty, the avatar will not be displayed.

The requirement is indeed strange, but similar situations will definitely be encountered in actual work.

Well, first of all, let's change the code as a matter of course.

 class UserItemView extends View {
 ImageView mAvatar;
 TextView mName;
 TextView mDesc; 
     
 String mDescData; 
     
 public void setAvatar(Bitmap avatarImage) {
        mAvatar.setImage(avatarImage);
 } 
     
 public void setName(String name ) {
        mName.setText( name );
 } 
     
 public void setDesc(String desc ) {
 mDescData = desc ;
        if (mDescData == null || mDescData .equals( "" )) {
            mAvatar.setVisible( true );
 } else {
            mAvatar.setVisible( false );
 }
        mDesc.setText(mDescData);
 }
 }

You see, now the description setting method has to take care of the avatar display, which is disgusting. If there are more data items and states, more UI controls, and there are many dependencies between them, if you write it this way, the logic in each of your methods will become disgusting and complicated. Even setting the state of a certain UI needs to depend on other data items. You have no choice but to pass in irrelevant data as parameters, and it will become like this.

 // !!! Explosion!!! Why should the avatar pay attention to other data!!!
 public void setAvatar(Bitmap avatarImage, String desc ) {
    mAvatar.setImage(avatarImage);
    if ( desc == null || desc .equals( "" )) {
        mAvatar.setVisible( true );
 } else {
        mAvatar.setVisible( false );
 }
 }

At that time, my UI had become very disgusting. Under such circumstances, I finally realized that the update of UI objects cannot be done on the spot. The update of UI objects should be done in a unified way. The setXXXX methods that will change the UI display only do two things. One is to set the data to the member properties of this object, and the other is to call a unified method to update the UI.

In fact, a standard design has always been in front of me, but I didn't realize and truly understand it until that moment. That is the View in Android. Each subclass of View in Android has a lot of set methods. For example, TextView has setText, setTextColor, etc. It is that each set method actually makes a data change to this object and then ignores it. When the system calls the OnDraw method, the UI is updated uniformly in the OnDraw method.

The next step is simple. Our code becomes like this:

 class UserItemView extends View {
 ImageView mAvatar;
 TextView mName;
 TextView mDesc; 
     
 String mNameData;
 String mDescData;
 Bitmap mAvatarData; 
     
 public void updateView() {
        mAvatar.setImage(mAvatarData);
        if (mDescData== null || mDescData.equals( "" )) {
            mAvatar.setVisible( true );
 } else {
            mAvatar.setVisible( false );
 } 
         
        mDesc.setText(mDescData); 
         
        mName.setText(mNameData);
 } 
     
 public void setAvatar(Bitmap avatarImage) {
        mAvatarData = avatarImage;
 updateView();
 } 
     
 public void setName(String name ) {
 mNameData = name ;
 updateView();
 } 
     
 public void setDesc(String desc ) {
 mDescData = desc ;
 updateView();
 }
 }

Notice that an updateView method is added, which is used to update the data to the UI. In this way, other set methods only store data, and the updateView method updates the UI according to the current data status, so the set method is clean and tidy. No matter how complex the display logic is, you don't have to worry about it, just do it in updateView.

I have been maintaining an Activity that has about 15+ Views, 20-30 data and states. These data and states mysteriously affect the display of these views. I was young and ignorant at the time, so I just updated the UI status immediately after the data changed (the next line). There are the following locations:

• Click Event
• System callback
• Network request callback
• Timer, handler

With so many places updating data and changing the UI, it's a pain to maintain.

Later, after I realized the above technique, I refactored it and had a super large updateView method in it, and then updated each View.

Here is another little trick, that is, if you have 10,000 views and 10,000 states, do you write by state or by view? This means: think like a normal person, for example, if your page has two modes, most people will write

 if (mode == A) {
 viewA.xxxxxx
 viewB.xxxxxx
 ...
 } else if (mode == B) {
 viewA.xxxxxx
 viewB.xxxxxx
 ...
 }

There is a problem with writing like this, young man, do you think you only have two states? Do you think each UI object only depends on one state? Can it be so elegantly distributed in if and else? You are wrong. Requirements are very disgusting and completely illogical.

If you write it this way, when you have a lot of states, it is difficult to arrange where to update the view, and if a new state is added, it will affect it. In order not to affect the previous logic, you often add another line at the end, which is difficult to maintain.

How to do it? The easiest way is to write by View. If you have 10,000 Views, then deal with them one by one. How does the first View affect you? Write them all out, whether it's if-else or anything else. Anyway, the first few lines of code should deal with View1 first.

Then write the logic of View2 and View3 again. The only disadvantage is that you have to repeat your judgment. It seems cumbersome. View1 and View2 may have the same display logic. You really want to write them in one if-else, but I suggest you not to do so. For the best flexibility, please write them separately.

When you perform maintenance in the future, if there is a problem with a View, you only need to find that one and don't need to worry about anything else.