[android-developers] Re: Layout bugs
What's the rationale for hard-coding stack sizes at 8k? That's pretty small, even for Java apps that don't allocate things on the stack. Windows will actually grow the stack for you when you exceed the limits, up to the point at which you run out of memory. This really isn't a Views-heirarchy specific issue is it. Theoretically any app that is close to the 8k limit can be broken by having some additional recursion in a platform library. Growing the stack automatically appears to be the only robust, general solution. BTW I hope one day we have escape analysis/stack allocation in Dalvik. That'd probably go a long way towards taking the pressure off the GC system and making it easier to write smoothly performing games. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
On Sat, Apr 25, 2009 at 9:57 AM, Al Sutton wrote: > > Dianne has already pointed out that even the guys at Google consider it a > less than optimal, lets hope a 1.6 or whatever brings some improvements. To be clear, the main improvement I expect is a very clear delineation of the maximum stack depth, that will be consistently reported to developers and enforced in the SDK, which the framework will guarantee to support. View hierarchies of the depth we are talking about are just too inefficient to manage on G1 class of hardware; it is something people should just be avoiding. I do think we should look at what we can do in the platform about the situation where an activity is embedded inside of another activity to reduce the amount of nesting the system imposes there, but I don't know how much can/will be done. -- 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
I started coding on a 1Kb ZX-81 (http://en.wikipedia.org/wiki/Sinclair_ZX81), but that doesn't mean I'd expect to see the same problems and limitations on "modern" hardware, and I do see the stack depth limitations as tweaky. Dianne has already pointed out that even the guys at Google consider it a less than optimal, lets hope a 1.6 or whatever brings some improvements. Al. P.S. If 16Kb RAM makes you a greybeard I'd better start getting ready to draw my pension :). --- * 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 Mark Murphy Sent: 25 April 2009 14:05 To: android-developers@googlegroups.com Subject: [android-developers] Re: Layout bugs jarkman wrote: > Mark - I've spent a lot of time developing for a lot of mobile > platforms. It's true that they all have their quirks, and they all > need a bit of tweakiness, but this stack business seems to me to be > more than ordinarily tweaky. *shrugs* It all depends on what you're used to. I'm a graybeard. I had been programming various machines and languages for a decade-plus before I got my hands on anything with the G1's specs. When you cut your teeth on developing in 16KB of RAM total, dealing with the Android stack depth issue isn't terribly "tweaky". > Now it's more awkward. Reworking existing layouts, using more > laborious techniques when making new ones, building a UI to economise > on views instead of to serve the user, having to measure the deepest > possible nesting in an environment where views can be built at runtime > - none of this is helpful. > > I expect we are stuck with the teeny stack for 1.5. I'm sure the > Android engineers haven't gone this way for trivial reasons, and I'm > sure they won't change it just because I have a moan about it. But, > I'd like to be clear that this is not just an 'excuse for a bit of > optimisation' - it's a real (even if unavoidable) step backwards. Don't get me wrong -- I'm just trying to help explain and assist with an unpleasant situation. In an ideal world, view depth would not be an issue, because Android would either use less stack per view layer or would have, say, double the stack space. Of course, in an ideal world, my G1 would have as much horsepower as my quad-core desktop, battery life longer than my Prius, and would have Natalie Portman in my speed-dial. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
jarkman wrote: > Mark - I've spent a lot of time developing for a lot of mobile > platforms. It's true that they all have their quirks, and they all > need a bit of tweakiness, but this stack business seems to me to be > more than ordinarily tweaky. *shrugs* It all depends on what you're used to. I'm a graybeard. I had been programming various machines and languages for a decade-plus before I got my hands on anything with the G1's specs. When you cut your teeth on developing in 16KB of RAM total, dealing with the Android stack depth issue isn't terribly "tweaky". > Now it's more awkward. Reworking existing layouts, using more > laborious techniques when making new ones, building a UI to economise > on views instead of to serve the user, having to measure the deepest > possible nesting in an environment where views can be built at runtime > - none of this is helpful. > > I expect we are stuck with the teeny stack for 1.5. I'm sure the > Android engineers haven't gone this way for trivial reasons, and I'm > sure they won't change it just because I have a moan about it. But, > I'd like to be clear that this is not just an 'excuse for a bit of > optimisation' - it's a real (even if unavoidable) step backwards. Don't get me wrong -- I'm just trying to help explain and assist with an unpleasant situation. In an ideal world, view depth would not be an issue, because Android would either use less stack per view layer or would have, say, double the stack space. Of course, in an ideal world, my G1 would have as much horsepower as my quad-core desktop, battery life longer than my Prius, and would have Natalie Portman in my speed-dial. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
Jeff - I believe you are posting that from the future, when all the Android devices in the world have 1.5 running on them... :-) R. On Apr 24, 7:11 pm, Jeff Sharkey wrote: > > FastScrollView > > ListView > > You can now specify android:fastScrollEnabled="true" on the ListView > instead of wrapping in a FastScrollView. ;) > > -- > Jeff Sharkey > jshar...@android.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
Mark - I've spent a lot of time developing for a lot of mobile platforms. It's true that they all have their quirks, and they all need a bit of tweakiness, but this stack business seems to me to be more than ordinarily tweaky. The Android layout scheme has been a strange thing to work with. It's powerful, but it is complicated, and it's not been easy to get the results we need from it. It is definitely one of the awkward bits of Android development. Now it's more awkward. Reworking existing layouts, using more laborious techniques when making new ones, building a UI to economise on views instead of to serve the user, having to measure the deepest possible nesting in an environment where views can be built at runtime - none of this is helpful. I expect we are stuck with the teeny stack for 1.5. I'm sure the Android engineers haven't gone this way for trivial reasons, and I'm sure they won't change it just because I have a moan about it. But, I'd like to be clear that this is not just an 'excuse for a bit of optimisation' - it's a real (even if unavoidable) step backwards. R. On Apr 24, 7:00 pm, Mark Murphy wrote: > jarkman wrote: > > Scratching about looking for ways to use less stack, > > and to avoid complicated view structures, doesn't feel very 2009. > > Well, bear in mind, you are far closer to doing embedded systems > development than desktop or server development when you write for mobile > devices. These sorts of hiccups and optimizations are par for the course > when working on embedded systems, as I understand it. > > My hope is that we can collectively work out a set of design guidelines > to help avoid stack issues, while we await more stack space, or more > efficient use of existing stack space, or something. > > Cases in point: Romain Guy wrote a couple of blog posts earlier this > year about using RelativeLayout instead of nested LinearLayouts and > using to eliminate redundant layouts needed solely to satisfy > XML requirements. I link to them in a blog post I wrote up on this topic > earlier today: > > http://androidguys.com/?p=4688 > > At the time he wrote those posts, my reaction was "meh", because I > didn't see the value. Now, of course, the value is much more obvious and > immediate. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android App Developer Books:http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
> FastScrollView > ListView You can now specify android:fastScrollEnabled="true" on the ListView instead of wrapping in a FastScrollView. ;) -- Jeff Sharkey jshar...@android.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
jarkman wrote: > Scratching about looking for ways to use less stack, > and to avoid complicated view structures, doesn't feel very 2009. Well, bear in mind, you are far closer to doing embedded systems development than desktop or server development when you write for mobile devices. These sorts of hiccups and optimizations are par for the course when working on embedded systems, as I understand it. My hope is that we can collectively work out a set of design guidelines to help avoid stack issues, while we await more stack space, or more efficient use of existing stack space, or something. Cases in point: Romain Guy wrote a couple of blog posts earlier this year about using RelativeLayout instead of nested LinearLayouts and using to eliminate redundant layouts needed solely to satisfy XML requirements. I link to them in a blog post I wrote up on this topic earlier today: http://androidguys.com/?p=4688 At the time he wrote those posts, my reaction was "meh", because I didn't see the value. Now, of course, the value is much more obvious and immediate. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
Thanks for the suggestion (and yes, your guess is spot-on - we'll try rearranging it next time we have the covers off). But I don't think that changes the point - this app is not insanely badly-written as it stands, and it is already tripping over the stack- depth problem. Scratching about looking for ways to use less stack, and to avoid complicated view structures, doesn't feel very 2009. Nor does it feel like a good use of our time. R, On Apr 24, 4:21 pm, Mark Murphy wrote: > jarkman wrote: > > Well, it didn't seem insane on 1.1, and it ran happily enough. Let me > > break it down for you, and see if it makes any more sense. > > > From the top, in HierarchyViewer, reading down the deepest path, we > > go: > > > PhoneWindow$DecorView > > LinearLayout > > FrameLayout > > TabHost > > LinearLayout (comes with the TabHost) > > FrameLayout (comes with the TabHost) > > PhoneWindow$DecorView > > FrameLayout (for this tab) > > LinearLayout > > FrameLayout (also holds a loading-progress gizmo) > > FastScrollView > > ListView > > RelativeLayout (for the list item) > > OurPhotoView > > ImageView > > My guess from this list is that are using the embed-an-activity-in-a-tab > stuff, which is why you get the second PhoneWindow$DecorView and, > possibly, the subsequent FrameLayout. > > If my guess is correct, you could alter your application to not use > activities in this fashion and save 1-2 levels in your view hierarchy. > Populate your tabs via Views (possibly using the factory pattern for a > faster initial open) instead of activities. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Warescription: Three Android Books, Plus Updates, $35/Year --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
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: android-developers@googlegroups.com [mailto:android-develop...@googlegroups.com] On Behalf Of Romain Guy Sent: 24 April 2009 13:52 To: android-developers@googlegroups.com 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: 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. Th
[android-developers] Re: Layout bugs
jarkman wrote: > Well, it didn't seem insane on 1.1, and it ran happily enough. Let me > break it down for you, and see if it makes any more sense. > > From the top, in HierarchyViewer, reading down the deepest path, we > go: > > PhoneWindow$DecorView > LinearLayout > FrameLayout > TabHost > LinearLayout (comes with the TabHost) > FrameLayout (comes with the TabHost) > PhoneWindow$DecorView > FrameLayout (for this tab) > LinearLayout > FrameLayout (also holds a loading-progress gizmo) > FastScrollView > ListView > RelativeLayout (for the list item) > OurPhotoView > ImageView My guess from this list is that are using the embed-an-activity-in-a-tab stuff, which is why you get the second PhoneWindow$DecorView and, possibly, the subsequent FrameLayout. If my guess is correct, you could alter your application to not use activities in this fashion and save 1-2 levels in your view hierarchy. Populate your tabs via Views (possibly using the factory pattern for a faster initial open) instead of activities. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, $35/Year --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
Well, it didn't seem insane on 1.1, and it ran happily enough. Let me break it down for you, and see if it makes any more sense. >From the top, in HierarchyViewer, reading down the deepest path, we go: PhoneWindow$DecorView LinearLayout FrameLayout TabHost LinearLayout (comes with the TabHost) FrameLayout (comes with the TabHost) PhoneWindow$DecorView FrameLayout (for this tab) LinearLayout FrameLayout (also holds a loading-progress gizmo) FastScrollView ListView RelativeLayout (for the list item) OurPhotoView ImageView So, the total depth is the sum of several constructs that each use a few nested views - the TabHost needs a few, the fancy list needs a few, the photo view needs a few, and all of a sudden we are at 15. We used to use more, because the nesting of LinearLayouts worked very well as a way of collecting up a number of items that were often invisible, but that took us over the new stack size limit. Do you see how we got here ? Richard On Apr 24, 1:13 pm, Romain Guy wrote: > 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 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 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 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. > > >> -- > >>
[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. > 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. 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.) > 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 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 Diann
[android-developers] Re: Layout bugs
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 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
[android-developers] Re: Layout bugs
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 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 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 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 >> 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 -~--~~~~--~~--~--~---
[android-developers] Re: Layout bugs
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 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 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 > 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[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 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 wrote: >> >> Having read >> >> http://android-developers.blogspot.com/2009/04/future-proofing-your-apps.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. >>
[android-developers] Re: Layout bugs
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 wrote: Having read http://android-developers.blogspot.com/2009/04/future-proofing-your-apps.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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[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 wrote: > > Having read > > http://android-developers.blogspot.com/2009/04/future-proofing-your-apps.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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
