On Friday, September 9, 2011 4:48:51 PM UTC-4, Ted Hopp wrote: > > I keep running into a sizing and layout problem for custom views and I'm > wondering if anyone can suggest a "best practices" approach. The problem is > as follows. Imagine a custom view where the height required for the content > depends on the width of the view (similar to a multi-line TextView). > (Obviously, this only applies if the height isn't fixed by the layout > parameters.) The catch is that for a given width, it's rather expensive to > compute the content height in these custom views. In particular, it's too > expensive to be computed on the UI thread, so at some point a worker thread > needs to be fired up to compute the layout and when it is finished, the UI > needs to be updated. > > The question is, how should this be designed? I've thought of several > strategies. They all assume that whenever the height is calculated, the > corresponding width is recorded. > From the docs, it's clear that onMeasure might be called several times > during the course of a single layout. It's less clear (but seems likely) > that onSizeChanged might also be called several times. So I'm thinking that > putting the logic in onDraw might be the better strategy. But that seems > contrary to the spirit of custom view sizing, so I have an admittedly > irrational bias against it. > > Other people must have faced this same problem. Are there approaches I've > missed? Is there a best approach? >
(shortened above) Hi Ted, I have experienced the need to know the height/width of the view for the sizing of many components which I draw on the screen that are all relative to the view size. I have found in my experience that using onSizeChanged is what seems to be the best approach. It can be called several times (possibly even initially with 0,0 as values, unless I am mistaken), and each time it is called I update some variables which I then use to size/scale/place components. Previously I had used onMeasure, but this did not seem to work as well or as cleanly. Hopefully others can weigh in as I'm curious what others have done in this regard. This is all done outside of onDraw, though, as you do not want onDraw to do anything unnecessary or intensive. The number of times onDraw is going to be called far exceed that of onMeasure or onSizeChanged, so keep that in mind - remember that it can be called many times per second, so that anything calculation wise or creation wise that can be cached, should be. If you have elements which may involve intense calculations to scale and compose, then using a separate thread is desirable instead of doing it on the main thread. You can perhaps take the strategy of always using values you have "published" and cached in your onDraw call, meanwhile calculating new values in a separate thread, and then publishing them when ready (with some synchronization/locking here - kind of a double buffering/swap effect). Carefully profiling any approach will be key for performance. Adam -- 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
