Set them in the setting, keep that stored in a variable in the view, and use that value in onMeasure or wherever else you need it. That way the view can initialize it with a reasonable value in its constructor (or from the layout attributes) and the activity can override it.
If a change in the value means that you must do a re-layout, then in the setting when it changes you should call invalidateLayout(). Likewise if it just needs a redraw, call invalidate(). On Wed, Apr 6, 2011 at 8:39 AM, Emanuel Moecklin <[email protected]>wrote: > There's one issue I still haven't solved to my satisfaction. > As the layouting of views isn't tied to the activity's lifecycle > there's no way to predict when onMeasure, onLayout are called (from an > Activities point of view). > If the parameters are needed in the onMeasure, onLayout methods then > setting them in setter methods might be too late. > The only solution to that problem I found so far is to invalidate the > view whenever one of the setters is called. > > Anyone got a better idea? > > Cheers > Emanuel Moecklin > > On Apr 6, 9:25 am, Dianne Hackborn <[email protected]> wrote: > > The standard pattern in Android is for a view to have APIs for setting > its > > attributes, which the activity calls when it wants. This pattern occurs > all > > *over* the place -- see the innumerable sample code that does > findViewById() > > in Activity.onCreate() to retrieve and set up views. This is how you > attach > > callbacks, set adapters in list view, set text in text views, and on and > on > > and on. > > > > (And as has also been suggested to parse XML attributes for values to > come > > from the layout and/or theme.) > > > > It is a better pattern than what you are wanting to do because you can > then > > actual use the view in multiple activities. > > > > But, you know, if you *want* to do the approach you are taking, then have > at > > it. There is no need to argue with people recommending the normal > approach. > > It's your code. Write it how you want. I don't think you are going to > get > > people to recommend you do what you want, though. > > > > > > > > > > > > > > > > > > > > On Wed, Apr 6, 2011 at 2:59 AM, Mike Bear <[email protected]> > wrote: > > > In my scenario, MyView will be only used in MyActivity. > > > In addition, it's also the simplest way. > > > > > Thanks for your help > > > > > On Wed, Apr 6, 2011 at 5:51 PM, Kostya Vasilyev <[email protected] > >wrote: > > > > >> Ah. > > > > >> Well, you could have a setSomething method in the view, and push the > value > > >> from the activity's onCreate - as already suggested by Kumar. > > > > >> If MyView is only intended to be used by MyActivity, then your > original > > >> code seems fine (getting the context, casting to MyActivity and > getting the > > >> value). It's not "pretty", and it's not "pure", but why mess with > something > > >> that works? > > > > >> -- Kostya > > > > >> 06.04.2011 13:47, Mike Bear пишет: > > > > >> The scenario is like the following: > > > > >>> 1. MyView is one of the component in MyActivity. > > >>> 2. MyActivity is created from other activity, with an intent > containing > > >>> all the information for the activity, including the parameter for > MyView. > > >>> 3. We shall pass the parameter to the constructor of MyView, for the > > >>> construction of it. > > > > >>> I thought of other ways, like use the shared preference, it seems > also > > >>> work. But not a good way. > > > > >> -- > > >> Kostya Vasilyev --http://kmansoft.wordpress.com > > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "Android Developers" group. > > >> To post to this group, send email to > [email protected] > > >> To unsubscribe from this group, send email to > > >> [email protected] > > >> For more options, visit this group at > > >>http://groups.google.com/group/android-developers?hl=en > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
