Skip to content
Search

Android:Manifest

lastmod 2018-08-17created 2014-01-0811 edits

Removing the status bar and title bar

Add android:theme="@android:style/Theme.Black.NoTitleBar.Fullscreen" to the activity in AndroidManifest.xml.

In a theme (Theme) you defined yourself, add the following. 

<item name="windowFullscreen">true</item>

To set it in Java Code: 

// Status Bar 없는 상태로 만들기. Theme 설정과 다른 것은 Fullscreen Flag를 주더라도 Title Bar는 남아있습니다. 
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);

Removing only the title bar

Add android:theme="@android:style/Theme.Black.NoTitleBar" to the activity in AndroidManifest.xml.

In a theme (Theme) you defined yourself, add the following. 

<item name="windowNoTitle">true</item>

To set it in Java Code: 

// Title Bar 없는 상태로 만들기
requestWindowFeature(Window.FEATURE_NO_TITLE);

android:windowSoftInputMode

Describes how the on-screen soft keyboard behaves with the Activity's main window. This setting affects two things.

  1. State of the Soft keyboard: controls whether it is shown or hidden when the Activity receives user focus.
  2. Adjustment of the Activity's main window: whether the window is resized smaller to make room for the Soft keyboard, or adjusted when it would be covered by the Soft keyboard.

You can list one or more of the values below, using one "state.." value and one "adjust.." value. Specifying multiple values from the same group is undefined, and values are separated with |.

  • stateUnspecified: Neither hidden nor visible is specified. The system chooses, or refers to the theme's value.
  • stateUnchanged: Keeps the last state (visible, hidden) when the activity comes to the foreground.
  • stateHidden: Hidden while the activity runs. (that is, when the user affirmatively navigates forward to the activity, rather than backs into it because of leaving another activity.)
  • stateAlwaysHidden: The softkeyboard is always hidden while the activity has focus.
  • stateVisible: Behaves in the normal mode
  • stateAlwaysVisible: Visible while the activity runs. (that is, when the user affirmatively navigates forward to the activity, rather than backs into it because of leaving another activity.)
  • adjustUnspecified : Does not resize or pan. This is the default setting for the main window. The system automatically chooses one of the modes depending on whether the window has a layout view that can scroll its content. If there is such a view, the window will be resized so that all of the window's content can be scrolled and shown in the smaller area.
  • adjustResize : The Activity's main window is always resized to accommodate the softkeyboard.
  • adjustPan : The Activity's main window is not resized but panned. As a result, the current focus is never obscured by the keyboard, so the user can always see what they are typing. This is less desirable than the resizing option, because the user has to close the softkeyboard to see the parts of the window that are not visible.

Difference between adjustResize and adjustPan

Assuming there is one EditText at the bottom of the screen, the difference between the two options is as follows.

  1. adjustResize: The main window size shrinks, but the EditText is not visible. If scrolling is supported, you can scroll to see it.
  2. adjustPan: The main window size does not shrink; instead, the whole window moves up so the EditText is visible. The EditText is visible but the rest of the UI is not.

Orientation

Describes how to lock the screen orientation of Android (Android) to one direction instead of having it rotate automatically (Auto).

Set screenOrientation among the activity attributes in AndroidManifest.xml as follows.

Keep the screen in portrait orientation: 

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

Keep the screen in landscape orientation: 

<activity android:name=".Powermeter"
android:label="@string/app_name"
android:screenOrientation="landscape">

Runtime configuration (rotation, orientation) change lifecycle

On a device, some configurations change in real time at runtime, such as screen orientation changes, keyboard changes, and language setting changes. In such cases, Android restarts the current Activity. So, as we studied in the earlier lifecycle, it goes through the process of calling the Activity's onDestroy and then calling onCreate again. This restart is meant to make it easy to reload the resources for the changed configuration by restarting the Activity.

When restarting like this, the information held by the Activity must be preserved properly: call onSaveInstanceState, which we studied earlier, to save the information, and then load the saved information again in onCreate or onRestoreInstanceState.

To test this app restart, it is a good idea to do various things with the app while changing the configuration, such as rotating the screen. If you have implemented the lifecycle events above properly, the Activity will preserve its data well. However, if such a change requires an immediate response, the resource cost of saving and restoring large amounts of data can sometimes be severe enough to degrade the UX. In that case, there are 2 ways to solve it.

  • Retaining an Object and passing it to the newly started Activity
  • Preventing the system from changing the configuration and restarting the Activity, and handling it yourself

Retaining an Object and passing it to the newly started Activity

If starting the Activity requires restoring a large amount of data, re-establishing network connections, or some other complex processing, restarting the Activity due to a configuration change would be very costly. The Bundle saved in the onSaveInstanceState() function is not intended for storing large data, and there are cases where data such as bitmap images is particularly hard to pass along. Moreover, passing it as an Object requires serializing and then deserializing it, which demands a lot of memory and can slow down the configuration change. In that case, you can minimize the resource cost of the restart by retaining the Object that holds the data.

This happens in two steps.

  1. Override the onRetainNonConfigurationInstance() function to save the object you want to retain
  2. When the Activity starts, restore the previously retained object with getLastNonConfigurationInstance()

If the Android system restarts an Activity due to a configuration change, it calls onRetainNonConfigurationInstance() between onStop() and onDestroy(), and in this onRetainNonConfigurationInstance() function you just return any Object that makes it easy to restore the existing information and state.

The most common scenario is when the app has received a large amount of data from the Internet and the user rotates the screen, forcing a restart. Rather than downloading the data from the Internet again, you save the data through the onRetainNonConfigureInstance() function and, when the app restarts after the configuration change, restore it through getLastNonConfigurationInstance().

Handling system configuration changes yourself

If the app you are developing does not need to update resources and has performance problems when the Activity restarts, you can prevent the Activity from restarting and specify yourself how the Activity applies configuration changes.

If you handle configuration changes yourself, using other new resources becomes very complicated, because normally the system applies everything automatically while restarting. So this method is a last resort to use when you must avoid a restart, and it is not recommended for most apps.

If you want to control configuration changes yourself, add the android:configChanges attribute to the manifest file, with the configurations you want to control as its value.

See also

Favorite site

References

  1. Android_app_develop_basic-orientation_life_cycle.pdf ↩

sitemap