Java – can I use refactoring to swap the type of another variable?

Android Studio provides powerful refactoring, such as renaming I can use it to change the names of variables, fields and parameters, but I can't seem to find a way to rename types For example:

LinearLayout layout = (LinearLayout) v.findViewById(....);
// ........
// A bunch of code using `layout` many times

How to quickly refactor LinearLayout into relativelayout and apply it to the rest of the code? Can I do the same thing?

Solution

Short answer

The function you are looking for is type migration!

You can perform type migration by right clicking the type of variable or field and selecting refactor – > type migration. Alternatively, you can use these keyboard shortcuts:

>On MAC: shift ⌘ F6 on Windows: shift Ctrl F6

Just select the type to be migrated and click refactor to start Android studio!

Long and more detailed answers

You seem to have misunderstood what rename actually did

Rename allows you to literally rename an element So you can change its name with variables, parameters, methods or classes For example, if you have a class named Foo and you want to change its name to bar, you can easily do so using rename

However, you cannot rename LinearLayout because it is a framework class and cannot be modified This shouldn't be a problem at all, because you don't actually want to rename LinearLayout, do you? What you really want to do is change the type from LinearLayout to relativelayout There is also a very useful refactoring feature that can do this, called type migration

You can perform type migration by right clicking any variable of the type you want to exchange with other types and selecting refactor – > After typing the migration, a dialog box will pop up. You can enter the type to be migrated. In your case, it is relativelayout Then just click refactor and Android studio can start working There may be an additional pop-up window that notifies you of all content in your code that cannot be migrated automatically Just scan the conflict list and manually ignore and repair these conflicts

The following is an example of type migration at work I started with this Code:

private LinearLayout mLayout;

private void doStuff(ViewGroup container) {
    LinearLayout layout = (LinearLayout) container.findViewById(0);

    layout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            ...
        }
    });

    mLayout = layout;
    fooTheBar(layout);   
}

private void fooTheBar(LinearLayout layout) {
    ...
}

Now I have performed type migration to relativelayout. On the local variable layout in dostuff() The results are as follows:

private RelativeLayout mLayout;

private void doStuff(ViewGroup container) {
    // Here is the only conflict which Could not be refactored automatically.
    // I had to change the cast to RelativeLayout manually.
    RelativeLayout layout = (LinearLayout) container.findViewById(R.id.linearLayout);

    layout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            ...
        }
    });

    mLayout = layout;
    fooTheBar(layout);
}

private void fooTheBar(RelativeLayout layout) {
    ...
}

As you can see, type migration works well The field type of foothebar() and even the type of parameters are changed to relativelayout There is only one conflict Android studio cannot automatically change the projection type at the top of dostuff() I have to fix it manually As I mentioned earlier, I was warned of this conflict when performing refactoring

Of course, you can ask yourself why it can automatically change the types of fields and parameters, but can not change the types of a conversion, but if you consider it, it actually makes great sense:

Part of the code for automatic migration is (LinearLayout) container findViewById(R.id.linearLayout). Of course, this method can use r.id LinearLayout finds a view This view may be defined in the layout XML or may be dynamically added to the container at run time, but in any case, it is not reconfigurable automatically without the risk of interrupting the function Only developers can decide what to do, which is why you are warned