Java Question ViewWrapper wrapped my brain

[corwin42]

I have a library with following methods:

public void ReplaceEditText(BA ba, EditTextWrapper View) {
...
}

public void ReplaceCheckBox(BA ba, CheckBoxWrapper View) {
...
}

Calling this in B4A with MyLib.ReplaceEditText(EditText1) for example works well.

Now I want to simplify the usage and provide just a ReplaceView() method that calls the other methods depending on the type of view in the parameter.

I tried the following method:

    public void ReplaceView(BA ba, Object View) {

        if (android.os.Build.VERSION.SDK_INT >= 21) {
            Common.Log("No View replacement needed for Lollipop or above");
        } else {
            if (View instanceof EditTextWrapper) {
                Common.Log("Replace an EditText View");
                ReplaceEditText(ba, (EditTextWrapper) View);
            } else {
                Common.Log("Replacing of " + View.getClass().toString()
                        + " not supported!");
            }
        }
    }

But this does not work because now if I call MyLib.ReplaceView(EditText1) the parameter is of type android.view.EditText and not EditTextWrapper as I expected. I tried with different parameter types like ViewWrapper. But then I get a ClassCastException when I try to cast the parameter to the correct type for ReplaceEditText().

So what I don't understand is why is the EditText1 object of type android.view.EditText if I declare the parameter as Object and of type anywheresoftware.b4a.objects.EditTextWrapper if I declare the parameter as EditTextWrapper. Is this done by the Java compiler? Is there any solution for my problem? I need the wrapper object as the parameter.

 

[Erel]

Just look for the native type instead of the wrapper. The wrapper is removed automatically when the target type is different.

if (View instanceof EditText) {
...
}

 

[corwin42]

Ok, thanks for the answer.

Since I want to replace the "wrapped" object in the wrapper (and therefore I need the wrapper object) there seems to be no other possibility than writing multiple methods. One for each object type. Ok, currently there are only three needed.