Thank you everyone for the great insight on this issue. I tried the simple -down and dirty workaround by adding android:configChanges="orientation|keyboardHidden" to the activity tag in the manifest. This did in fact work as the data persisted after rotation.
However, as many have pointed out, this is not really a viable, long term solution, and a better fix would be to store the data either using shared preferences, a database, a file, or the onSaved instance method. Unfortunately, I cannot seem to get any of these to work! Can anyone provide a code sample with a very simple example -perhaps just one textview element that can keep its data using one of the above methods? Thanks in advance On Oct 9, 11:24 am, Mark Murphy <mmur...@commonsware.com> wrote: > 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-d... > > > 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/commonsguyhttp://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
