[android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 wrote: > Hi, > > I was just trying to extend the AbsSpinner Class, to create my own > custom widget. But the problem is that some of the member variables > have a a default scope, so I can't access them just by extending the > class (they can only be access directly by classes in the same > package). Some are ok as they have getters and setters , but there is > the odd member variable that doesn't , so i simply can't access them > because my new custom widget in not in the same package. An example of > such a member variable is mSelectedPosition in AdapterView. > > Would it not be better if these vars were to have a protected scope > rather than the default scope, it would then be easier to extend these > classes to make custom widgets outside of the package of these > classes. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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) {
super.onLayout(changed, l, t, r, b);
/*
* Remember that we are in layout to prevent more layout
request from
* being generated.
*/
mInLayout = true;
layout(0, false);
mInLayout = false;
}
I want to create a similar class to Gallery, but because my classes
are not in the same package i cannot access mInLayout. even though I
extend AbsSpinner and hence AdapterView,
so should mInLayout be protected? If it was i could then access it
and write a similar custom class to Gallery..
On Nov 30, 9:01 pm, Taf wrote:
> Hi,
>
> I was just trying to extend the AbsSpinner Class, to create my own
> custom widget. But the problem is that some of the member variables
> have a a default scope, so I can't access them just by extending the
> class (they can only be access directly by classes in the same
> package). Some are ok as they have getters and setters , but there is
> the odd member variable that doesn't , so i simply can't access them
> because my new custom widget in not in the same package. An example of
> such a member variable is mSelectedPosition in AdapterView.
>
> Would it not be better if these vars were to have a protected scope
> rather than the default scope, it would then be easier to extend these
> classes to make custom widgets outside of the package of these
> classes.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 wanted to. It seems to me that hiding the
member vars in something like AdapterView doesn't give many advantages
and just makes it harder to reuse existing code. Well anyhow, that's
how it looks from over here.. :)
On Nov 30, 9:52 pm, Dianne Hackborn wrote:
> 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 wrote:
> > 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) {
> > super.onLayout(changed, l, t, r, b);
>
> > /*
> > * Remember that we are in layout to prevent more layout
> > request from
> > * being generated.
> > */
> > mInLayout = true;
> > layout(0, false);
> > mInLayout = false;
> > }
>
> > I want to create a similar class to Gallery, but because my classes
> > are not in the same package i cannot access mInLayout. even though I
> > extend AbsSpinner and hence AdapterView,
>
> > so should mInLayout be protected? If it was i could then access it
> > and write a similar custom class to Gallery..
>
> > On Nov 30, 9:01 pm, Taf wrote:
> > > Hi,
>
> > > I was just trying to extend the AbsSpinner Class, to create my own
> > > custom widget. But the problem is that some of the member variables
> > > have a a default scope, so I can't access them just by extending the
> > > class (they can only be access directly by classes in the same
> > > package). Some are ok as they have getters and setters , but there is
> > > the odd member variable that doesn't , so i simply can't access them
> > > because my new custom widget in not in the same package. An example of
> > > such a member variable is mSelectedPosition in AdapterView.
>
> > > Would it not be better if these vars were to have a protected scope
> > > rather than the default scope, it would then be easier to extend these
> > > classes to make custom widgets outside of the package of these
> > > classes.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com > cr...@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 RadioButton(actually
CompoundButton) and override onDraw..
but mButtonResource is private so MyRadioButton can't get access to
it.
I think this discourages people from making custom widgets.
On Dec 1, 8:47 am, Dianne Hackborn wrote:
> 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 wrote:
> > 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 wanted to. It seems to me that hiding the
> > member vars in something like AdapterView doesn't give many advantages
> > and just makes it harder to reuse existing code. Well anyhow, that's
> > how it looks from over here.. :)
>
> > On Nov 30, 9:52 pm, Dianne Hackborn wrote:
> > > 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 wrote:
> > > > 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) {
> > > > super.onLayout(changed, l, t, r, b);
>
> > > > /*
> > > > * Remember that we are in layout to prevent more layout
> > > > request from
> > > > * being generated.
> > > > */
> > > > mInLayout = true;
> > > > layout(0, false);
> > > > mInLayout = false;
> > > > }
>
> > > > I want to create a similar class to Gallery, but because my classes
> > > > are not in the same package i cannot access mInLayout. even though I
> > > > extend AbsSpinner and hence AdapterView,
>
> > > > so should mInLayout be protected? If it was i could then access it
> > > > and write a similar custom class to Gallery..
>
> > > > On Nov 30, 9:01 pm, Taf wrote:
> > > > > Hi,
>
> > > > > I was just trying to extend the AbsSpinner Class, to create my own
> > > > > custom widget. But the problem is that some of the member variables
> > > > > have a a default scope, so I can't access them just by extending the
> > > > > class (they can only be access directly by classes in the same
> > > > > package). Some are ok as they have getters and setters , but there is
> > > > > the odd member variable that doesn't , so i simply can't access them
> > > > > because my new custom widget in not in the same package. An example
> > of
> > > > > such a member variable is mSelectedPosition in AdapterView.
>
> > > > > Would it not be better if these vars were to have a protected scope
> > > > > rather than the default scope, it would then be easier to extend
> > these
> > > > > classes to make custom widgets outside of the package of these
> > > > > classes.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Android Developers" group.
> > > > To post to this group, send email to
> > android-developers@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > android-developers+unsubscr...@googlegroups.com > cr...@googlegroups.com>
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/android-developers?hl=en
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer
> > > hack...@android.com
>
> > > Note: please don't send private questions to me, as I don't have time to
> > > provide private support, and so won't reply to such e-mails. All such
> > > questions should be posted on public forums, where I and others can see
> > and
> > > answer them.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All suc
[android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 wrote:
> 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 feature request. There will be no direct access to member variables
> for apps to hack around the current implementation of the framework. (And
> directly modifying mButtonResource is a perfect example of why it would be a
> huge problem to allow this -- what if other member variables in the future
> need to be set to match this? If you directly modify this, you could
> completely break on a future version of the platform where the framework
> doesn't have an opportunity to update its internal state appropriately.)
>
>
>
> On Mon, Nov 30, 2009 at 8:39 PM, NoraBora wrote:
> > 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 RadioButton(actually
> > CompoundButton) and override onDraw..
>
> > but mButtonResource is private so MyRadioButton can't get access to
> > it.
>
> > I think this discourages people from making custom widgets.
>
> > On Dec 1, 8:47 am, Dianne Hackborn wrote:
> > > 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 wrote:
> > > > 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 wanted to. It seems to me that hiding the
> > > > member vars in something like AdapterView doesn't give many advantages
> > > > and just makes it harder to reuse existing code. Well anyhow, that's
> > > > how it looks from over here.. :)
>
> > > > On Nov 30, 9:52 pm, Dianne Hackborn wrote:
> > > > > 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 wrote:
> > > > > > 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) {
> > > > > > super.onLayout(changed, l, t, r, b);
>
> > > > > > /*
> > > > > > * Remember that we are in layout to prevent more layout
> > > > > > request from
> > > > > > * being generated.
> > > > > > */
> > > > > > mInLayout = true;
> > > > > > layout(0, false);
> > > > > > mInLayout = false;
> > > > > > }
>
> > > > > > I want to create a similar class to Gallery, but because my classes
> > > > > > are not in the same package i cannot access mInLayout. even though
> > I
> > > > > > extend AbsSpinner and hence AdapterView,
>
> > > > > > so should mInLayout be protected? If it was i could then access it
> > > > > > and write a similar custom class to Gallery..
>
> > > > > > On Nov 30, 9:01 pm, Taf wrote:
> > > > > > > Hi,
>
> > > > > > > I was just trying to extend the AbsSpinner Class, to create my
> > own
> > > > > > > custom widget. But the problem is that some of the member
> > variables
> > > > > > > have a a default scope, so I can't access them just by extending
> > the
> > > > > > > class (they can only be access directly by classes in the same
> > > > > > > package). Some are ok as they have getters and setters , but
> > there is
> > > > > > > the odd member variable that doesn't , so i simply can't access
> > them
> > > > > > > because my new custom widget in not in the same package. An
> > example
> > > > of
> > > > > > > such a member variable is mSelectedPosition in AdapterView.
>
> > > > > > > Would it not be better if these vars were to have a protected
> > scope
> > > > > > > rather than the default scope, it would then be easier to extend
> > > > these
> > > > > > > classes to make custom widgets outside of the package of these
> > > > > > > classes.
>
> > > > > > --
> > > > > > You receive
[android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 extend to create out own custom classes. I just
thougth it would be nice to extend AdapterView instead of ViewGroup,
but it looks like the framework is not designed to do this so I'll
just have to extend ViewGroup instead.
On Dec 1, 7:19 am, NoraBora wrote:
> 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 wrote:
>
> > 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 feature request. There will be no direct access to member variables
> > for apps to hack around the current implementation of the framework. (And
> > directly modifying mButtonResource is a perfect example of why it would be a
> > huge problem to allow this -- what if other member variables in the future
> > need to be set to match this? If you directly modify this, you could
> > completely break on a future version of the platform where the framework
> > doesn't have an opportunity to update its internal state appropriately.)
>
> > On Mon, Nov 30, 2009 at 8:39 PM, NoraBora wrote:
> > > 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 RadioButton(actually
> > > CompoundButton) and override onDraw..
>
> > > but mButtonResource is private so MyRadioButton can't get access to
> > > it.
>
> > > I think this discourages people from making custom widgets.
>
> > > On Dec 1, 8:47 am, Dianne Hackborn wrote:
> > > > 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 wrote:
> > > > > 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 wanted to. It seems to me that hiding the
> > > > > member vars in something like AdapterView doesn't give many advantages
> > > > > and just makes it harder to reuse existing code. Well anyhow, that's
> > > > > how it looks from over here.. :)
>
> > > > > On Nov 30, 9:52 pm, Dianne Hackborn wrote:
> > > > > > 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 wrote:
> > > > > > > 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) {
> > > > > > > super.onLayout(changed, l, t, r, b);
>
> > > > > > > /*
> > > > > > > * Remember that we are in layout to prevent more layout
> > > > > > > request from
> > > > > > > * being generated.
> > > > > > > */
> > > > > > > mInLayout = true;
> > > > > > > layout(0, false);
> > > > > > > mInLayout = false;
> > > > > > > }
>
> > > > > > > I want to create a similar class to Gallery, but because my
> > > > > > > classes
> > > > > > > are not in the same package i cannot access mInLayout. even though
> > > I
> > > > > > > extend AbsSpinner and hence AdapterView,
>
> > > > > > > so should mInLayout be protected? If it was i could then access
> > > > > > > it
> > > > > > > and write a similar custom class to Gallery..
>
> > > > > > > On Nov 30, 9:01 pm, Taf wrote:
> > > > > > > > Hi,
>
> > > > > > > > I was just trying to extend the AbsSpinner Class, to create my
> > > own
> > > > > > > > custom widget. But the problem is that some of the member
> > > variables
> > > > > > > > have a a default scope, so I can't access them just by exten
Re: [android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 wrote:
> 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) {
>super.onLayout(changed, l, t, r, b);
>
>/*
> * Remember that we are in layout to prevent more layout
> request from
> * being generated.
> */
>mInLayout = true;
>layout(0, false);
>mInLayout = false;
>}
>
> I want to create a similar class to Gallery, but because my classes
> are not in the same package i cannot access mInLayout. even though I
> extend AbsSpinner and hence AdapterView,
>
> so should mInLayout be protected? If it was i could then access it
> and write a similar custom class to Gallery..
>
> On Nov 30, 9:01 pm, Taf wrote:
> > Hi,
> >
> > I was just trying to extend the AbsSpinner Class, to create my own
> > custom widget. But the problem is that some of the member variables
> > have a a default scope, so I can't access them just by extending the
> > class (they can only be access directly by classes in the same
> > package). Some are ok as they have getters and setters , but there is
> > the odd member variable that doesn't , so i simply can't access them
> > because my new custom widget in not in the same package. An example of
> > such a member variable is mSelectedPosition in AdapterView.
> >
> > Would it not be better if these vars were to have a protected scope
> > rather than the default scope, it would then be easier to extend these
> > classes to make custom widgets outside of the package of these
> > classes.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
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 wrote:
> 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 wanted to. It seems to me that hiding the
> member vars in something like AdapterView doesn't give many advantages
> and just makes it harder to reuse existing code. Well anyhow, that's
> how it looks from over here.. :)
>
> On Nov 30, 9:52 pm, Dianne Hackborn wrote:
> > 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 wrote:
> > > 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) {
> > >super.onLayout(changed, l, t, r, b);
> >
> > >/*
> > > * Remember that we are in layout to prevent more layout
> > > request from
> > > * being generated.
> > > */
> > >mInLayout = true;
> > >layout(0, false);
> > >mInLayout = false;
> > >}
> >
> > > I want to create a similar class to Gallery, but because my classes
> > > are not in the same package i cannot access mInLayout. even though I
> > > extend AbsSpinner and hence AdapterView,
> >
> > > so should mInLayout be protected? If it was i could then access it
> > > and write a similar custom class to Gallery..
> >
> > > On Nov 30, 9:01 pm, Taf wrote:
> > > > Hi,
> >
> > > > I was just trying to extend the AbsSpinner Class, to create my own
> > > > custom widget. But the problem is that some of the member variables
> > > > have a a default scope, so I can't access them just by extending the
> > > > class (they can only be access directly by classes in the same
> > > > package). Some are ok as they have getters and setters , but there is
> > > > the odd member variable that doesn't , so i simply can't access them
> > > > because my new custom widget in not in the same package. An example
> of
> > > > such a member variable is mSelectedPosition in AdapterView.
> >
> > > > Would it not be better if these vars were to have a protected scope
> > > > rather than the default scope, it would then be easier to extend
> these
> > > > classes to make custom widgets outside of the package of these
> > > > classes.
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Android Developers" group.
> > > To post to this group, send email to
> android-developers@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > android-developers+unsubscr...@googlegroups.com cr...@googlegroups.com>
> > > For more options, visit this group at
> > >http://groups.google.com/group/android-developers?hl=en
> >
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com
> >
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support, and so won't reply to such e-mails. All such
> > questions should be posted on public forums, where I and others can see
> and
> > answer them.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: scope of member variables in ViewGroup , AdapterView, AbsSpinner etc..
>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 feature request. There will be no direct access to member variables
for apps to hack around the current implementation of the framework. (And
directly modifying mButtonResource is a perfect example of why it would be a
huge problem to allow this -- what if other member variables in the future
need to be set to match this? If you directly modify this, you could
completely break on a future version of the platform where the framework
doesn't have an opportunity to update its internal state appropriately.)
On Mon, Nov 30, 2009 at 8:39 PM, NoraBora wrote:
> 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 RadioButton(actually
> CompoundButton) and override onDraw..
>
> but mButtonResource is private so MyRadioButton can't get access to
> it.
>
> I think this discourages people from making custom widgets.
>
> On Dec 1, 8:47 am, Dianne Hackborn wrote:
> > 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 wrote:
> > > 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 wanted to. It seems to me that hiding the
> > > member vars in something like AdapterView doesn't give many advantages
> > > and just makes it harder to reuse existing code. Well anyhow, that's
> > > how it looks from over here.. :)
> >
> > > On Nov 30, 9:52 pm, Dianne Hackborn wrote:
> > > > 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 wrote:
> > > > > 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) {
> > > > >super.onLayout(changed, l, t, r, b);
> >
> > > > >/*
> > > > > * Remember that we are in layout to prevent more layout
> > > > > request from
> > > > > * being generated.
> > > > > */
> > > > >mInLayout = true;
> > > > >layout(0, false);
> > > > >mInLayout = false;
> > > > >}
> >
> > > > > I want to create a similar class to Gallery, but because my classes
> > > > > are not in the same package i cannot access mInLayout. even though
> I
> > > > > extend AbsSpinner and hence AdapterView,
> >
> > > > > so should mInLayout be protected? If it was i could then access it
> > > > > and write a similar custom class to Gallery..
> >
> > > > > On Nov 30, 9:01 pm, Taf wrote:
> > > > > > Hi,
> >
> > > > > > I was just trying to extend the AbsSpinner Class, to create my
> own
> > > > > > custom widget. But the problem is that some of the member
> variables
> > > > > > have a a default scope, so I can't access them just by extending
> the
> > > > > > class (they can only be access directly by classes in the same
> > > > > > package). Some are ok as they have getters and setters , but
> there is
> > > > > > the odd member variable that doesn't , so i simply can't access
> them
> > > > > > because my new custom widget in not in the same package. An
> example
> > > of
> > > > > > such a member variable is mSelectedPosition in AdapterView.
> >
> > > > > > Would it not be better if these vars were to have a protected
> scope
> > > > > > rather than the default scope, it would then be easier to extend
> > > these
> > > > > > classes to make custom widgets outside of the package of these
> > > > > > classes.
> >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "Android Developers" group.
> > > > > To post to this group, send email to
> > > android-developers@googlegroups.com
> > > > > To unsubscribe from this group, send email to
> > > > > android-developers+unsubscr...@googlegroups.com
>
> > > > cr...@googlegroups.com>
> > > > > F
