getOrientation() has never returned orientation, it returns rotation. So it is being renamed to getRotation(). This is *much* less confusing. In fact you were confused -- you thought it returned orientation, when it does not.
If you want the current orientation, Resources.getConfiguration().orientation has that. Surface.setOrientation() is actually not available to applications (it is an accident it is in the SDK, but apps don't have permission to use it, so there is nothing they can actually do with it), so not really relevant here. The solution for that one is probably just to remove it from the SDK since apps can't use it anyway. This was done to better clarify the differences between orientations and screen rotations, which a lot of people have been confused about, and has resulted in a lot of incorrect use of sensors and such. It's worth noting that both Display.getOrientation() and Surface.setOrientation() work with the constants Surface.ROTATION_0, Surface.ROTATION_90, Surface.ROTATION_180, etc. Those APIs intrinsically have a naming conflict. On Sun, Oct 31, 2010 at 10:44 AM, tenacious <[email protected]> wrote: > I'm not sure what the motivation was to deprecate > Display#getOrientation() in SDK 8 is, since I haven't had a chance to > read the changeset description. The decision made the API a little > less humanistic. I propose it be brought back in SDK 9 for these > reasons: > 1) The community has two+ years of discovery and documentation around > Display#getOrientation. > 2) There's no clear reason why applications which don't distinguish > between a 90/270 degree rotation should have to implement extra work > for forwards/backwards compatibility. > 3) The system already decides which side is "top" whether the rotation > is 90 or 270 degrees. > 4) android.view.Surface has no setRotation(...) method, it uses > setOrientation(...). Thus, if Display#getOrientation() was to be > deprecated, the same should have happened to Surface#getOrientation > for architectural symmetry. > 5) Using Display#getOrientation() will always be desired by some > applications, whereas Display#getRotation() will always be desired by > others. > > The frustrating factor here is that on top of the confusion caused by > the SDK having different classes/methods to get runtime orientation > versus configured orientation, this deprecation is poorly motivated. > > Yours Truly, > Free > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
