I have been doing some research for custom components. The long thread of the research is at
http://satyakomatineni.com/item/4148 Reading the internet I have got bits and pieces about requestLayout() and invalidate(). I think I kind of know what they are. However the difference between requestLayout() and forceLayout() is hazy, especially the "force" part. Here is what I think is the difference: (Hope this will add to larger corpus out there) It is easier to tell what forceLayout() is first. It is like a "touch" command in build environments. Usually when a file doesn't change the build dependencies will ignore it. So you force that file to be compiled by "touch"ing and thereby updating its time stamp. Just like "touch" it will not invoke any build commands by itself (Unless your build environment is too sophisticated to kick off right away.) When a build is requested just don't ignore this file. So when you forceLayout() a view you are marking that view (only that) a candidate for measuring. If a view is not marked then its onMeasure() will not be called. You can see this in the measure() method of the view. This measure() method checks to see if this view is marked for layout. The behavior of requestLayout() is (only) slightly different. a requestlayout touches the current view just like forceLayout() but also walks up the chain touching every parent of this view until it reaches ViewRoot. ViewRoot overrides this method and schedules a layout pass. Because it is just a schedule to run it doesnt start the layout pass right away. It will wait for the main thread to complete its chores and attend the message queue. Still, explain to me when I use forceLayout!! I understand the requestLayout because I end up scheduling a pass. What am I doing with forceLayout? Obviously if you are calling a requestLayout on a view there is no point in calling forceLayout on that view. What is "force" anyway? Recall, that a "force" is like a "touch" for build!! So you are "forcing" the file to compile. When a view gets its requestLayout called, all its siblings are untouched. They don't have this flag up. Or if the view that is touched is a viewgroup (like when you delete a view or add a view) the viewgroup doesn't need to calculate the sizes of the its children because their sizes haven't changed. No point in calling their onMeasure. But if for some reason if the view group decides that these children needs to be measured, it will call forceLayout on each of them followed by measure() which now correctly calls onmeasure(). It won't call requestLayout on children because no need to trigger another pass when i am in the middle of the current pass. (Don't interrupt me while I am interrupting kind of deal). That begs the question then what happens the very first time?? who touched all views to begin with. I reason that (I haven't verified this yet) the views start out with this flag being set!! Let me see I will check in a minute and report again. That's what I thought. But thats not what happens. When a view is added to a view group, the view group makes sure the view is marked for measurement and calls a request layout on itself. Importantly, when do you call each? Developers typically have more occasions to call requestLayout. For example when you respond to a mouse click on a view to increase its size, you do that and then you say "requestLayout" on that view. For whatever reason if that doesn't do anything you are inclined to call "forceLayout" as the name is quite leading. Based on what I know that is like yelling twice. if the first yell is a no-op, second yell will get the same response. However for some reason, on the account of your target view changing, if you believe the size of your sibling view will get impacted, then call its forceLayout. Of course you call the siblings requestLayout as well but that adds a few more cycles to the CPU but knowing what you are doing a simpler "forceLayout" would do. It is also possibly common in complex layouts that are derived from view groups where a change to a single sibling may need a measurement of its siblings, so you want to explicitly decide if they need to remeasure again or not. Hope this adds to what is out there http://twitter.com/SatyaKomatineni http://satyakomatineni.com http://androidbook.com http://satyakomatineni.com/android/training -- 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
