RadioGroup display multiline implementation steps

Radio buttons wrapped in radio group are characterized by radio selection and mutual exclusion, which are often used in projects.

If RadioButton implements multi line display, it will lose its original feature.

On the Internet, most of them are customized to deal with this kind of demand, so as to realize single selection and mutual exclusion.

This example is used for fewer buttons. You only need to modify the previous code slightly to achieve the effect of multi line display.

Introduce the original requirements

        rb.setOnCheckedChangeListener(new RadioGroup.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(RadioGroup group, int checkedId) {
                switch (checkedId) {
                    case R.id.btn1:
                    //Other operations
                        break;
                    case R.id.btn2:
                        //Other operations
                        break;
                    case R.id.btn3:
                    //Other operations
                        break;
                    case R.id.btn4:
                        //Other operations
                        break;
                    default:
                        break;
                }
            }
        });

The above is the single line writing method. It's very simple, because other things have systems to do instead. But if they are not the direct child of RadioButton, the above method will not receive the callback. Here we need to do some operations ourselves. The test found that although the setonchecked changelistener method of RadioButton has no callback, the onch method of RadioButton has no callback The eckedchanged method always has callbacks, so it is mutually exclusive in the method change. The following code:

 @Override
 public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
                switch (buttonView.getId()) {
                    case R.id.btn1:
                        btn1.setChecked(true);
                        btn2.setChecked(false);
                        btn3.setChecked(false);
                        btn4.setChecked(false);
                    //Other operations
                        break;
                    case R.id.btn2:
                        btn1.setChecked(false);
                        btn2.setChecked(true);
                        btn3.setChecked(false);
                        btn4.setChecked(false);
                        //Other operations
                        break;
                    case R.id.btn3:
                        btn1.setChecked(false);
                        btn2.setChecked(false);
                        btn3.setChecked(true);
                        btn4.setChecked(false);
                    //Other operations
                        break;
                    case R.id.btn4:
                        btn1.setChecked(false);
                        btn2.setChecked(false);
                        btn3.setChecked(false);
                        btn4.setChecked(true);
                        //Other operations
                        break;
                    default:
                        break;
                }
            }

The reason why the above code is adopted is that such changes are relatively small, and there is basically no change to the original logic, and the risk is also small.

Write at the end

The above kind of radio buttons are less suitable for the packages in the radio group. Too many radio buttons are not suitable. The code looks bloated when it is written.