A custom control has nothing to do with this kind of issue. Actually, custom controls are a good way to avoid that issue, and optimize layouts in general. Around 15 levels deep of layouts is just insanely complex for a cell phone screen.
On Fri, Apr 24, 2009 at 5:08 AM, jarkman <[email protected]> wrote: > > I'm not sure it's realistic to describe this as a simple optimisation > issue. > > We've just gone through an exercise to fix these crashes in one of our > apps. We've managed it, but only at the expense of uglification of the > code. > > We're working with a custom list on a tab. Looking at the hierarchy > viewer, we are 12 deep in the tree by the time we get to our ListView. > We now have three levels under that - a RelativeLayout for our list > item, various simple views, and one custom control with a child view. > > That just fits, and doesn't crash in 1.5. Previously, we laid out the > list item with a 2-deep tree of linear layouts, which was a lot more > convenient in our code. > > As far as I can see, if we had built any more custom controls or used > a more complex layout, we'd be quite knackered at this point, which > makes this restriction seem like a real step backwards. > > Richard > > > On Apr 24, 9:23 am, Dianne Hackborn <[email protected]> wrote: >> We didn't have time for Cupcake, but we definitely want to have some very >> well-defined limits in a future release. There is no nice error because >> what actually is happening is the app is running out of stack space -- some >> optimizations and new features in the view hierarchy caused certain >> functions to use a little more stack, which can result in apps that were >> skirting the edge of the stack to go over the limit. >> >> We apologize, and definitely aren't happy about this; we had some some >> additional optimization of the code to reduce stack usage at the very last >> minute but found a little later that it still wasn't enough. >> >> Anyway, if this makes cupcake not a good as 1.1 to you, well okay, I guess >> don't run cupcake or something. >> >> (Btw, in practice, an application with a deep hierarchy like this is also >> going to have noticeable performance issues because of the work required to >> manage it, so this can be considered a nice opportunity to do a bit of good >> optimization.) >> >> >> >> On Fri, Apr 24, 2009 at 12:52 AM, Al Sutton <[email protected]> wrote: >> >> > Having read >> >> >http://android-developers.blogspot.com/2009/04/future-proofing-your-a... >> > l I noted this little section; >> >> > "Due to changes in the View rendering infrastructure, unreasonably deep >> > (more than 10 or so) or broad (more than 30 total) View hierarchies in >> > layouts are now likely to cause crashes. This was always a risk for >> > excessively complex layouts, but you can think of Android 1.5 as being >> > better than 1.1 at exposing this problem..." >> >> > Will the SDK warn us when we're reaching the limit for crashes? >> >> > And more to the point why does it crash and not return some form of >> > meaningful error to the app? With an error code or thrown exception >> > developers could create various levels of layout complexity and step down >> > the layout complexity level until they find one the device will support. >> >> > Al. >> >> > P.S. No matter what the post says I see this as a regression in >> > functionality and I definitely do not see it as "Android 1.5 as being >> > better >> > than 1.1" in any way. >> >> > --- >> >> > * Written an Android App? - List it athttp://andappstore.com/* >> >> > ====== >> > Funky Android Limited is registered in England & Wales with the >> > company number 6741909. The registered head office is Kemp House, >> > 152-160 City Road, London, EC1V 2NX, UK. >> >> > The views expressed in this email are those of the author and not >> > necessarily those of Funky Android Limited, it's associates, or it's >> > subsidiaries. >> >> -- >> 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. > > > -- Romain Guy Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. 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 -~----------~----~----~----~------~----~------~--~---
