Protected fields not visible to subclasses

2019-01-14 12:39发布

问题:

I'm writing a custom view that directly extends android.view.View. If I try to access fields mScrollX or mScrollY, I see an error that the field "cannot be resolved or is not a field." The source code for android.view.View has mScrollX, mScrollY, and similar variables declared protected. How is it that my direct subclass cannot access protected fields of its parent class? (Classes like ScrollView apparently can.)

P.S. I realize that I can call getScrollX(), but I want to update these fields; calling setScroll() has side effects that I don't want.

回答1:

It's because they are not part of the Android SDK.

Here is the source code for mScrollX:

/**
 * The offset, in pixels, by which the content of this view is scrolled
 * horizontally.
 * {@hide}
 */
@ViewDebug.ExportedProperty(category = "scrolling")
protected int mScrollX;

You will notice the @hide annotation. That means this is not part of the Android SDK. The part of the build process that creates the Android SDK will not include this data member in the stub edition of android.view.View that is in the android.jar file that you are compiling against.

The @hide annotation is used for things that for internal purposes needed to be public or protected but are not considered something SDK developers should be using.

Please find other solutions for whatever problem you are experiencing.



回答2:

It's very straight forward: notice the @hide annotation above these variables. It's an Android-specific annotation that hides the fields/methods from the public SDK. That's why you can't access them directly.

Romain Guy mentioned it in this post.



回答3:

You could try setting the fields with reflection:

import java.lang.reflect.Field;

// ...

try {
    Field scrollXField = View.class.getDeclaredField("mScrollX");
    scrollXField.setAccessible(true);
    scrollXField.set(this, myNewValue);
} catch (Exception ex) {
    // oops, android changed the implementation. sucks to be you.
}

Note, however, that you're relying on undocumented and unsupported behavior when you do this, and so you should be prepared for things to break on some devices or in future versions.