To me whenever someone on a project says "We didn't have time for ....." when discussing something that increases chances of an app crashing in *any* way that indicates the project has been rushed along.
Personally I don't believe an OS should crash when a developer writes code that doesn't fit in with OS design decisions. Error messages and exceptions are the way to handle code that exhausts resources such as the stack, crashing out doesn't give the app a chance to handle things gracefully or give the developer much to work with in terms of finding the problem. Given that the stack size can be changed on different platforms (or even between compilations for the same target) by altering kDefaultStackSize in vm/Thread.h in the davlik project in the repo, doesn't this introduce a problem where an app which works on one platform may just crash out on another where the stack size is different? Al. --- * Written an Android App? - List it at http://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. -----Original Message----- From: android-developers@googlegroups.com [mailto:android-develop...@googlegroups.com] On Behalf Of Romain Guy Sent: 24 April 2009 13:06 To: android-developers@googlegroups.com Subject: [android-developers] Re: Layout bugs Cupcake is not rushed in any way and every change we made was made after careful consideration. The problem that Dan warns about should not affect the vast majority of apps. In my experience, to trigger it, you need to have a hierarchy of views that's about 14 levels deep. And even in 1.0 and 1.1, such a deep hierarchy could blow up depending on the code path taken or how the app is using the views. And for what it's worth I DID made some changes to avoid this problem to occur in some existing Market applications. The "fix" goes against optimizing the framework but we gave priority to backward compatibility with existing apps. As Dianne said, applications that have enough views to trigger that crash would run into other issues anyway and we feel it's a good way to force developers who run into these issues to fix their applications. Inflating, laying out and drawing that many Views is just too slow. On Fri, Apr 24, 2009 at 3:15 AM, Al Sutton <a...@funkyandroid.com> wrote: > Dianne, > > Thanks for the explanation, it does leave me concerned that we're yet > again seeing an android version rushed out the door and as a result of > this we're now being told of problems even before consumers have it on their devices. > > Not upgrading to cupcake isn't an realistic option. The average > consumer is going to do the update and therefore to serve them > effectively and test applications properly I'll have to do the upgrade as well. > > Al. > > --- > > * Written an Android App? - List it at http://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. > > > ________________________________ > From: android-developers@googlegroups.com > [mailto:android-develop...@googlegroups.com] On Behalf Of Dianne > Hackborn > Sent: 24 April 2009 09:23 > To: android-developers@googlegroups.com > Subject: [android-developers] Re: Layout bugs > > 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 <a...@funkyandroid.com> wrote: >> >> Having read >> >> http://android-developers.blogspot.com/2009/04/future-proofing-your-a >> pps.htm >> 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 at http://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 > hack...@android.com > > 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 romain...@android.com 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 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 -~----------~----~----~----~------~----~------~--~---
