Why Not Use Always Android:Configchanges="Keyboardhidden|Orientation"

Why not use always android:configChanges=keyboardHidden|orientation?

Quick Background

By default, when certain key configuration changes happen on Android (a common example is an orientation change), Android fully restarts the running Activity to help it adjust to such changes.

When you define android:configChanges="keyboardHidden|orientation" in your AndroidManifest, you are telling Android: "Please don't do the default reset when the keyboard is pulled out, or the phone is rotated; I want to handle this myself. Yes, I know what I'm doing"

Is this a good thing? We shall soon see...

No worries?

One of the pros you start with is that there is:

no need to worry about your activity been rotated

In many cases, people mistakenly believe that when they have an error that is being generated by an orientation change ("rotation"), they can simply fix it by putting in android:configChanges="keyboardHidden|orientation".

However, android:configChanges="keyboardHidden|orientation" is nothing more than a bandaid. In truth, there are many ways a configuration change can be triggered. For example, if the user selects a new language (i.e. the locale has changed), your activity will be restarted in the same way it does by an orientation change. If you want you can view a list of all the different types of config changes.

Edit: More importantly, though, as hackbod points out in the comments, your activity will also be restarted when your app is in the background and Android decides to free up some memory by killing it. When the user comes back to your app, Android will attempt to restart the activity in the same way it does if there was some other configuration change. If you can't handle that - the user will not be happy...

In other words, using android:configChanges="keyboardHidden|orientation" is not a solution for your "worries." The right way is to code your activities so that they are happy with any restart Android throws at them. This is a good practice that will help you down the road, so get used to it.

So when should I use it?

As you mentioned there is a distinct advantage. Overwriting the default configuration change for a rotation by handling it yourself will speed things up. However, this speed does come with a price of convenience.

To put it simply, if you use the same layout for both portrait and landscape you're in good shape by doing the overwrite. Instead of a full-blown reload of the activity, the views will simply shift around to fill the remaining space.

However, if for some reason you use a different layout when the device is in landscape, the fact that Android reloads your Activity is good because it will then load up the correct layout. [If you use the override on such an Activity, and want to do some magical re-layout at runtime... well, good luck - it's far from simple]

Quick Summary

By all means, if android:configChanges="keyboardHidden|orientation" is right for you, then use it. But PLEASE be sure to test what happens when something changes, because an orientation change is not the only way a full Activity restart can be triggered.

why using android:configChanges is a bad practice

Well, you need to remember that an Activity can be restarted for multiple reasons.

For example, one of these reasons is when your app is in the background and the OS decides to kill it (with your Activity, of course) to reclaim memory.

When you return to your app, the OS will try to recreate your Activity as you left it, but will fail to do so, because you decided not to bother with it, just used android:configChanges in your Manifest.

If you make sure your app can recover properly from a restart, android:configChanges might not be necessary at all. Because of this, the need to use android:configChanges might indicate some flaw in your app, that may worth to take a look at.

It's not bad practice to use android:configChanges, but it pretty easily can be, if you don't understand exactly what you're doing.

In AndroidManifest: Expecting android:screenOrientation=unspecified

In your manifest tag (just under xmlns:android="http://schemas.android.com/apk/res/android"), put

xmlns:tools="http://schemas.android.com/tools"

Then inside the application tag, put

tools:ignore="LockedOrientationActivity"

setting screenOrientation to portrait doesn't work

You can do it something like below.

After rootView in your java add this line

 getActivity().setRequestedOrientation (ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);  // programmatically

For example:

View rootView = inflater.inflate(R.layout.activityxml, container, false);       
getActivity().setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);

And also in your manifest change it:

android:configChanges="orientation|keyboardHidden"

as

android:configChanges="keyboardHidden"

<activity
android:name="com.test.activity"
android:label="@string/app_name"
android:screenOrientation="portrait"
android:configChanges="keyboardHidden" >

How can I make my android tablet app to look the same when it runs on phone in landscape mdoe

I think you need to use 2 flags, not just one.

First is

android:screenOrientation='landscape' 

Second is

android:configChanges="orientation"

First will tell android to run activity in landscape mode, where as second will tell android that do not change the orientation even when user rotates the phone. Basically with 2nd flag you are overriding orientation config changes.

Force portrait orientation mode

Don't apply the orientation to the application element, instead you should apply the attribute to the activity element, and you must also set configChanges as noted below.

Example:

<activity
android:screenOrientation="portrait"
android:configChanges="orientation|keyboardHidden">
</activity>

This is applied in the manifest file AndroidManifest.xml.

Tab Widget Issue when use android:configChanges=orientation|keyboardHidden in Grid View but working for other Tab

Oooohhh Finally i got the solution for above issue. It's was very difficult.

For maintain the state of orientation Landscape to portrait and vice-versa we generally adding android:configChanges="keyboardHidden|orientation" property tag under activity.

But here may be issue is Tab_Group_ Activity due to that i am not able to maintain state in GridView. Grid_File.java is Only single java file which was not handling the orientation rest of all other working perfectly.

Now if i remove android:configChanges="keyboardHidden|orientation" from TAB_SAMPLE.java then Its handling only Grid_File.java not others.

mean that was keeping same Layout XML in landscape also where i have two separate XML File.

Here is my solution:

I have add android:configChanges="keyboardHidden|orientation" in TAB_SAMPLE.java as well as
implement onConfigurationChanged(Configuration newConfig) and set Number of column of grid. like gridView.setNumColumns(6);

@Override
public void onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
// gridView.setSelection(index);
if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE)
{

// Log.e("On Config Change", "LANDSCAPE");
gridView.setNumColumns(6);

} else
{

// Log.e("On Config Change", "PORTRAIT");
gridView.setNumColumns(4);
}
}

Generally we are adding either android:configChanges="keyboardHidden|orientation" tag under activity or implementing onConfigurationChanged(Configuration newConfig) but here i have written both.

How can I disable landscape mode in Android?

Add android:screenOrientation="portrait" to the activity in the AndroidManifest.xml. For example:

<activity android:name=".SomeActivity"
android:label="@string/app_name"
android:screenOrientation="portrait" />

Since this has become a super-popular answer, I feel very guilty as forcing portrait is rarely the right solution to the problems it's frequently applied to.

The major caveats with forced portrait:

  • This does not absolve you of having to think about activity
    lifecycle events or properly saving/restoring state. There are plenty of
    things besides app rotation that can trigger an activity
    destruction/recreation, including unavoidable things like multitasking. There are no shortcuts; learn to use bundles and retainInstance fragments.
  • Keep in mind that unlike the fairly uniform iPhone experience, there are some devices where portrait is not the clearly popular orientation. When users are on devices with hardware keyboards or game pads a la the Nvidia Shield, on Chromebooks, on foldables, or on Samsung DeX, forcing portrait can make your app experience either limiting or a giant usability hassle. If your app doesn't have a strong UX argument that would lead to a negative experience for supporting other orientations, you should probably not force landscape. I'm talking about things like "this is a cash register app for one specific model of tablet always used in a fixed hardware dock."

So most apps should just let the phone sensors, software, and physical configuration make their own decision about how the user wants to interact with your app. A few cases you may still want to think about, though, if you're not happy with the default behavior of sensor orientation in your use case:

  • If your main concern is accidental orientation changes mid-activity that you think the device's sensors and software won't cope with well (for example, in a tilt-based game) consider supporting landscape and portrait, but using nosensor for the orientation. This forces landscape on most tablets and portrait on most phones, but I still wouldn't recommend this for most "normal" apps (some users just like to type in the landscape softkeyboard on their phones, and many tablet users read in portrait - and you should let them).
  • If you still need to force portrait for some reason, sensorPortrait may be better than portrait for Android 2.3 (Gingerbread) and later; this allows for upside-down portrait, which is quite common in tablet usage.


Related Topics



Leave a reply



Submit