On Mon, Jun 15, 2009 at 4:28 PM, Matt <[email protected]> wrote:
> #3 And apparently here is a version of what they _actually_ do: > > View.onMeasure: "Measure the size of this View. Also, compute a size > and position for all of its children." > View.onLayout: "Call layout() on each of the children with the size/ > position information that has ALREADY BEEN CALCULATED." This is an implementation detail. ViewGroup defines the sequence in which the method are called and their semantics, but different layout managers may implement them in different ways. > OK, here's my problem with this onMeasure/onLayout design, and maybe > I'm mistaken somehow. If #3 is the real scenario, then WHY IS THERE > AN ONLAYOUT METHOD THAT DERIVED CLASSES SHOULD OVERRIDE in the first > place? The hierarchy will go through one or more onMeasure() calls down the views to do the measurement, and then onLayout() will be called for placement once the measurement is done. They are separate methods because they are separate parts of the overall layout traversal. It is understood that content means children. As is my continued > point, if it really is the case, then it should be stated in the > onMeasure() javadoc that onMeasure() is the appropriate place to > compute the values that will be used by onLayout(), OR update onLayout > () to say that the values were already computed and should not be > computed in onLayout(). The way this is done -within- the layout manager is an implementation detail of that layout manager. A layout manager may compute its child placement in onMeasure() if it needs this to actually measure itself, in which case it will want to re-use this in onLayout() to avoid having to recompute it all over again. But other layout managers may not need to do this, and just do simple measurement in onMeasure() with the actual placement happening in onLayout(). (I think LinearLayout works this way.) > Agreed, that was in reponse to Romain's response about being able to > calculate the values at any point. And although you CAN calculate the > values anywhere, the framework itself should follow a certain pattern. > If your View calculates its size ahead of time, or in different spots, > then what happens when it gets subclassed? Layout managers are not really intended to be subclassed in order to change their layout algorithm. It sounds like this is the thing that is missing from the docs. For the most part the ViewGroup documentation is intentionally vague, because it is not trying to define implementation details but simply flow through the view hierarchy. -- 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 -~----------~----~----~----~------~----~------~--~---
