Note that basically everything you do for dealing with a configuration change is *exactly* the same thing you need to do to correctly handle your app being killed in the background if the user has (temporarily) left its UI. Thus making sure you deal correctly with a config change is a really good way to test that you are also able to correctly restore if your process needs to be restarted.
If you have transient data that shouldn't be restored (such as a running thread), just use Activity.onRetainNonConfigurationInstance(): http://developer.android.com/reference/android/app/Activity.html#onRetainNonConfigurationInstance() (Or as the current document recommends, the more convenient new Fragment APIs.) On Sat, Jul 16, 2011 at 9:17 PM, Brad <bradfull...@gmail.com> wrote: > Dianne, thanks for the response - you're probably right, I should just > bite the bullet. > > I'd like to vent a little though about what a hassle it is to deal > with orientation changes. It must be the #1 source of bugs in the > apps that I've come across (including my own apps). iOS does a lot > of things wrong, but it makes orientation changes so much easier than > Android. I still haven't found a way to preserve the state of an > activity that launches another dialog style activity that gets an > orientation change - I end up shoving everything in the db or passing > the state data to the dialog class. I'm no guru so I'm probably > doing something wrong there, but I wish to God that we could go back > in time and come up with a better way to deal with orientation changes > that didn't involve killing and reconstructing the entire activity! > > Ok, done w/the vent. Having said all that I still enjoy programming > for Android more than Apple even though I sell a lot more apps on the > App Store vs the Market :-) > > Brad > > On Jul 16, 8:53 pm, Dianne Hackborn <hack...@android.com> wrote: > > Those are two different orientations. > > > > The Configuration constants: > http://developer.android.com/reference/android/content/res/Configurat... > > > > The constants for set/getRequestedOrientation(): > http://developer.android.com/reference/android/content/pm/ActivityInf... > > > > Beyond that, I would strongly recommend not doing what you are trying to > do. > > This would result in a UI flow that is very counter to what the user > > expects -- that either an app is going to run in a particular > orientation, > > or allow them to rotate their screen as they would elsewhere. Ending up > > locked into whatever orientation they happened to launch the app in is > just > > not how things should work. > > > > Besides which, there are all kinds of edge cases you'll never get right > -- > > for example what happens if they press home to leave your app, rotate > their > > device, and then task switch back to your app? Or as another poster > > mention, if you lock the screen into portrait like this and they flip the > > lid on their keyboard the orientation won't change to landscape, which is > > not what they are going to want. > > > > You really, really just need to code your activity correctly to be able > to > > destroy and re-create the activity. > > > > > > > > > > > > > > > > > > > > On Sat, Jul 16, 2011 at 3:41 PM, Brad <bradfull...@gmail.com> wrote: > > > Hi, > > > > > I'm trying to lock my activity to the current orientation to prevent > > > an orientation change from restarting my activity while I'm waiting > > > for a http response. > > > > > So I'm trying to use this: > > > > > setRequestedOrientation(getResources().getConfiguration().orientation); > > > > > And it works fine for portrait (orientation == 1), but when the device > > > is in landscape it's getting a value of 2 which == > > > > > ActivityInfo.SCREEN_ORIENTATION_USER > > > > > And this doesn't lock the screen. > > > > > Does anyone have any idea why I'm getting this instead of LANDSCAPE? > > > Any suggestions for a better way to lock the current orientation? > > > > > Thanks! > > > > > -- > > > 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 > > > > -- > > 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 > -- 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
