Responses inline. 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: [email protected] [mailto:[email protected]] On Behalf Of Romain Guy Sent: 24 April 2009 13:52 To: [email protected] Subject: [android-developers] Re: Layout bugs > By "crash" here we mean that you get a StackOverflowException, just like with any regular Java application. There is nothing special about this. Thanks for the clarification. To me a crash is when a program suddenly stops executing (i.e. running stopped by a crash), if it's throwing a SOE then that’s good to know. > > 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. > ANY code change that we do increases chances of an app crashing. (And by crashing I mean altering its behavior or throwing an exception, > etc.) Like I said, all changes we make are carefully considered and this one was NOT deemed critical. We are releasing a preview SDK *and* articles > to help you fix that kind of bug if you run into it but it doesn't mean it is going to happen to your app or even any app. Crashing isn't about altering behaviour, crashing is about a program becoming ceasing to respond (see http://en.wikipedia.org/wiki/Crash_(computing)). I know the Google dictionary is a little different to the one every else uses (with Beta having a vary loose definition in it), so when someone says Crash you'll have to expect some of us to be using the more widely accepted definition. If every change made increased the chances of crashing then you could draw the conclusion that after a number of changes you would have code that ever app crashed all of the time, which I hope isn't the goal. Btw, All the support work to help to test for this is much appreciated. > Whatever you might think we take compatibility VERY seriously. We also monitor Market applications closely to ensure we don't break them when it's > > not justified (we caught many bugs we introduced during the Cupcake development by looking at Market applications.) It's good to know you're doing compatibility testing and, in all seriousness, it's a great leap forward in the QA stakes. > 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: [email protected] > [mailto:[email protected]] On Behalf Of Romain Guy > Sent: 24 April 2009 13:06 > To: [email protected] > 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 <[email protected]> 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: [email protected] >> [mailto:[email protected]] On Behalf Of Dianne >> Hackborn >> Sent: 24 April 2009 09:23 >> To: [email protected] >> 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 <[email protected]> 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 >> [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 > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
