On Sun, Oct 9, 2011 at 10:59 AM, Studio LFP <studio....@gmail.com> wrote: > 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
False. "Special consideration" may be required but they do not need to be stopped and restarted. http://stackoverflow.com/questions/3821423/background-task-progress-dialog-orientation-change-is-there-any-100-working/3821998#3821998 > 4. Special consideration for threading, but not quite as much as AsyncTasks False. If the thread has interaction with the UI, you need to deal with the thread the same way you deal with the AsyncTask. If the thread has no interaction with the UI, an equivalent AsyncTask would also not require any additional work. > 5. Special consideration needs to be taken for the things saved in the > bundle so you don't leak the previous context. False. There is nothing you can put in a Bundle that can leak a Context. This is by definition -- a Bundle has to be able to be passed across process boundaries, and a Context cannot be passed across process boundaries. Now, had you written "things returned by onRetainNonConfigurationInstance()", that *is* an issue. > With configChanges: > > 1. Layout may need to be changed on rotation > 2. Other unknown issues It's not just screen rotations and it's not just layouts. If the user changes their locale and comes back to your running app, that's a configuration change. If the user drops their device into a car dock, that's a configuration change. If the user removes the device from the car dock, that's a configuration change. And so on. You also forgot about your options menus and perhaps others. And, not only do you have to deal with this for each and every resource you are using today, but also for each and every resource you add in the future. And for each and every new configuration change that appears in the future (averaging one new one per Android release). > 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. Not necessarily. Many applications have strings beyond those wired into a layout resource, which if cached would need to be reloaded. Options menus are cached if the user opened the menu before. Drawables get cached. And so on. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.6 Available! -- 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
