> 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.
I understand completely, thank you. > 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. Also understood, thank you. This separateness is necessary to implement WRAP_CONTENT and FILL_PARENT. > 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.) Also understood completely, thank you. However, I believe that this part of our conversation is the key detail that should probably be documented. Layout management, in my experience, is one of the most frustrating "frameworks" to implement in any language or environment, because although you can generally follow examples to mimic what you want, as soon as you start trying to get something even slightly different from the standard examples you'll find yourself grasping for the details of how exactly a layout manager works (and why it's not working the way you want it to!). I know now exactly how the Linear and Relative Layouts work internally, such as how they work in the slightly different way that you have mentioned with onMeasure and onLayout. I think it would be very useful to note your previous paragraph in the documentation, especially as a reference to those who would try to subclass the layout managers without knowing these internal details (instead of reading our long thread :) > 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. I said in a previous post that I thought the onMeasure/onLayout is a bad design if onLayout is an unnecessary step for subclasses to implement. We've clarified that it isn't an unnecessary step, but implemented differently in various layouts, so I certainly don't think the design is bad. However, like I said above, I argue that if ViewGroup is rightly vague on how to implement it, the actual implementations shouldn't be vague in their documentation. And after all this work in this thread, I would volunteer to write the extra two paragraphs if I could! Hopefully anyone Googling will find this, with all of our mention of RelativeLayout, LinearLayout, ViewGroup, onMeasure, and onLayout. And thank you for all of your helpful clarifications! - Matt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
