I'm compiling a list of things that need to happen in both cases. So far it looks like a lot bigger challenge to not use the android:configChanges than to use it.
I've read the optimization post plenty of times and do understand it, but I'd like to get the big picture for the usages of both to be able to decide which is better in certain cases. Here's a few of the issues I'm trying to find good solutions to when *not*using configChanges: 1. Window states are not saved. ListView scroll locations, ExpandedListView drop-downs and scroll locations, ScrollView locations, etc. 2. OpenGL VBOs and textures loaded into memory get destroyed and have to be reprocessed and copied back into memory along with the GLSurfaceView state information 3. Special consideration now has to be taken with AsyncTasks since they are linked to the UI and need to be stopped, location of processing saved and restarted 4. Special consideration for threading, but not quite as much as AsyncTasks 5. Special consideration needs to be taken for the things saved in the bundle so you don't leak the previous context. This could get tricky because I'm sure a lot of people pass a context to objects or blend data and view objects *With* configChanges: 1. Layout may need to be changed on rotation 2. Other unknown issues With the resources being automatically swapped out by Android, a simple refresh on screen elements would pick up a new language if you needed to support that. That also includes any images that might be swapped over, but as I have to refresh the state of my windows even when it isn't rotated, this is already written in the base application anyways. To me it's also wrong to forget about the general case, i.e. other config > changes and the out of memory killer (and maybe more cases I can't think of > right now). > This part did catch my eye and it is what I was wondering. Is there something that the configChanges does to cause internal issues because it is bugged? All of the configuration changes are fairly straight forward and documented, but if there is some issue internally, would be nice to know. In an effort for this discussion not to go to waste, I'm trying to get the full picture compiled together on what has to happen on both so that I can get a post on my site or somewhere to help others. I know we all see this question fly by on this group (and on other help areas) all the time, so I figure a post of the compiled pros and cons of each would be helpful. Anyone that would like to toss in additional information about the things you have to deal with on either occasion (using configChanges or not), please do so and I will compile it for us for future reference. Steven Studio LFP http://www.studio-lfp.com On Sunday, October 9, 2011 4:47:03 AM UTC-5, Kostya Vasilyev wrote: > > > 09.10.2011 2:41, Studio LFP пишет: > > *TreKing, Kostya, Romain Guy,* > > I do understand what you guys are saying, so I am listening, but it seems > to be a contradiction since it seems most of the internal applications use > it, including quite a few that Google themselves send with the devices. > Maybe they aren't, but based on the speed of the rotate and the way the > screen looks, I'm pretty sure they are. > > [snip] > > > That's where those methods pointed out by TreKing come into play, as an > optimization. > > And here is a blog post written by Romain Guy that covers this in more > detail: > > > http://android-developers.blogspot.com/2009/02/faster-screen-orientation-change.html > > Those are optimizations for the common cases. > > The manifest attribute is fine, too, as long as 1) one understands that > it's also an optimization 2) the code can handle the general case, where > the activity gets recreated and 3) the layout is the same for all > orientations. > > > It seems like there are so many times where this is useful and being used, > yet people seem to be trying to tell people that it is "wrong", "incorrect", > "you are a horrible person and coder for using this". > > > To me, it's wrong to mix up the concepts of "here is how you fix this > problem" and "this is an optimization you can make". > > To me it's also wrong to forget about the general case, i.e. other config > changes and the out of memory killer (and maybe more cases I can't think of > right now). > > YMMV. > > > Steven > Studio LFP > http://www.studio-lfp.com > > > On Saturday, October 8, 2011 4:34:14 PM UTC-5, Romain Guy (Google) wrote: >> >> *TreKing,* >>> >>> If you choose to ignore a well documented feature given to us by the >>> Android team, that's your prerogative. As for the rest of us, we'll decide >>> when we prefer to use one feature over another. >>> >> >> He makes a good point. "Solving" this issue by requesting to handle >> orientation changes yourself just masks the problem (unless you request to >> handle *all* configuration changes in which case you make more work for >> yourself.) Handling orientation changes yourself also has a lot of side >> effects (if you want to have a different layout in landscape and portrait >> you now need to deal with it manually.) >> >> -- >> Romain Guy >> Android framework engineer >> rom...@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-d...@googlegroups.com > To unsubscribe from this group, send email to > android-develop...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > > > -- > Kostya Vasilyev > > -- 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
