Just to clarify my position here, i don't think that private member
vars in general should be available to any class, that's a bad idea, I
was talking specifically about classes such as AdapterView (whose vars
have a default scope) that extend ViewGroup and View, which we seem to
be encouraged to
My mistake, there is a getter for mSelectedPosition, still think it
would be nice if the scope was protected for this and others , it
could then be accessed directly by custom classes that extend base
classes such as AbsSpinner, as the Gallery class does..
On Nov 30, 9:01 pm, Taf
OK a better example would be:
boolean mInLayout = false;
in AdapterView, this has no get or set function so it can only be
accessed by classes in the same package such as Gallery with it's
onLayout function:
protected void onLayout(boolean changed, int l, int t, int r, int
b) {
Member variables are implementation details. Exposing them for applications
to whack away on them as they want would make it much more difficult to
maintain the platform.
On Mon, Nov 30, 2009 at 1:41 PM, Taf neild...@gmail.com wrote:
OK a better example would be:
boolean mInLayout = false;
I'm not sure how 'hiding' the member vars in something like
AdapterView makes it easier to maintain the platform. AdapterView just
extends ViewGroup, so it would be straight forward for me to implement
a copy of AdapterView just by extending ViewGroup, and then i could
whack away at anything i
It does, because it means the application can change it at any time, without
the framework knowing this has happened. Direct access to member variables
is bad bad bad for maintenance.
On Mon, Nov 30, 2009 at 2:50 PM, Taf neild...@gmail.com wrote:
I'm not sure how 'hiding' the member vars in
I agree that Direct access to member variable is very bad.
but how about protected?
If all the variables are protected, people can extend and make their
widget much more easily.
For example I wanted to change the image alignment of RadioButton,
so I tried to make MyRadioButton extends
From this perspective, protected is EXACTLY the same as public. Third party
apps can directly whack the value of the variable, at any time, without the
framework having any opportunity to do anything about it.
If there is a feature you need that isn't available in the public APIs, then
file a
You are absolutely right. protected is same as public in that case.
I thought only the Android SDK user.
Thank you for correcting me quick answer.
On Dec 1, 2:57 pm, Dianne Hackborn hack...@android.com wrote:
From this perspective, protected is EXACTLY the same as public. Third party
apps
9 matches
Mail list logo
