Handling orientation changes in the Android UI framework

William Francis provides Android developers with an overview of four common ways to manage orientation changes on the UI in applications.

One aspect of Android development that can be daunting to newcomers is how to deal with orientation changes. The Android operating system restarts the current activity any time the device gets rotated, and in several other cases. The framework engineers at Google had good reasons for designing the activity lifecycle in this manner, but this knowledge doesn't make handling the transition from portrait to landscape and back any less frustrating for budding Android developers.

There are two items a developer has to account for during an orientation change: maintaining state and reloading resources. It's the latter I'm going to address in this post, and if it garners enough interest, I may write about maintaining state at some point down the road. Let's consider the four most common ways of handling orientation changes on the UI and then look at some code.

1: Do nothing

If this sounds like a bad idea to you, then it probably is. However, there are some very simplistic interfaces where not worrying about the rotation (in terms of UI only) is a valid approach. The images in Figure A illustrate the most common issue when developers do nothing on a screen rotation -- part of the UI is lost.

Figure A

fig. 1

Click the images to enlarge.

2: Suppress it

It's possible to suppress the orientation change and force your app to always operate in portrait or landscape mode. This only stops your UI from rotating -- it does not stop the activity from restarting. It's a very common mistake for new developers to think that by suppressing orientation changes they don't have to deal with maintaining state. Whether orientation changes occur, applications still must deal with activity restart because of things like incoming calls, pressing the home key, etc. That said, if you are certain suppressing the orientation change is the right way to go for you, it's simply a matter of adding a property to the manifest file for each activity affected. See Figure B.

<activity android:name=".SuppressIt" android:screenOrientation="portrait" />

Figure B

fig. 2

Click the images to enlarge.

3: Use a scroll view

While not the right choice for every type of UI, scroll views work well for things like application preferences. The secret to using a scroll view is in understanding that you must wrap all of your UI elements within a single layout tag, such as a linearLayout. Scroll views can only deal with a single parent layout. See Figure C.

<?xml version="1.0" encoding="utf-8"?>
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
  <!-- Add your UI elements inside the inner most linear layout -->
Figure C

fig. 3

Click the images to enlarge.

4: Load an alternate layout

In my experience, loading a new layout file is often the best approach. While it's not intuitive since the resource folders you need aren't created by the new project wizard, you can have two versions of every layout. The trick is creating a new directory under your /res folder titled: layout-land. Any xml files found in the layout-land folder will be used when the activity restarts and determines the phone to be in landscape orientation. See Figure D.

Figure D

fig. 4

Click the images to enlarge.

I've created a demo program that allows you to see each of these approaches. It can be downloaded here. Until next time, happy coding!