Skip to content

Android:Manifest

상태바, 타이틀바 제거

AndroidManifest.xml의 해당 액티비티에 android:theme="@android:style/Theme.Black.NoTitleBar.Fullscreen" 를 추가해 주면 된다.

내가 정의한 테마(Theme)에서는 아래와 같이 추가하면 된다. 

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

Java Code에서 설정하는 방법은 아래와 같다. 

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

타이틀바만 제거

AndroidManifest.xml의 해당 액티비티에 android:theme="@android:style/Theme.Black.NoTitleBar" 를 추가해 주면 된다.

내가 정의한 테마(Theme)에서는 아래와 같이 추가하면 된다. 

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

Java Code에서 설정하는 방법은 아래와 같다. 

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

android:windowSoftInputMode

Activity의 메인 윈도우에 어떻게 on-screen soft keyboard가 동작할것인지에 대한 방법을 기술한다. 이 설정은 두가지에 대해 영향을 준다.

  1. Soft keyboard의 상태: Activity가 사용자의 포커스를 받을때 보여질지 숨겨질지 조정.
  2. Activity 메인윈도우 조정: Soft keyboard의 크기를 줄이거나 Soft keyboard에 의해 덮어씌워질 때 윈도우 크기 조정.

아래 나열한 값들 중, 하나이상을 나열할 수 있으며 "state.."값하나와 "adjust.."값 하나 씩 사용할 수 있다. 각 그룹에 여러개의 값을 지정하는것은 정의되어 있지 않으며 각 값은 |로 분리하여 나열할 수 있다.

  • stateUnspecified: hidden 또는 visible을 지정하지 않음. 시스템이 알아서 선택하거나 theme의 값을 참조한다.
  • stateUnchanged: activity가 foreground로 올때 마지막 상태(visible, hidden)를 유지하고 있는다.
  • stateHidden: activity 실행중에 hidden이다. (that is, when the user affirmatively navigates forward to the activity, rather than backs into it because of leaving another activity.)
  • stateAlwaysHidden: activity가 focus를 가지고 있으면 무조건 softkeyboard는 hidden으로 함.
  • stateVisible: 일반적인 모드로 동작
  • stateAlwaysVisible: activity 실행중에 visible이다. (that is, when the user affirmatively navigates forward to the activity, rather than backs into it because of leaving another activity.)
  • adjustUnspecified : resize나 pan하지 않는다. 메인윈도우의 디폴트셋팅이다. 시스템은 자동으로 하나의 모드를 선택하는데 자신의 콘텐츠를 스크롤할 수 있는 layout view를 윈도우가 가지고 있는지에 따라 결정된다. 만일 그런 view라면 윈도우는 resize되어 더 작은 영역에서 모든 윈도우의 콘텐츠가 스크롤되어 표시될수 있어야 한다.
  • adjustResize : Activity의 메인윈도우가 softkeyboard에 따라 항상 resize된다.
  • adjustPan : Activity의 메인윈도우가 resize되지 않고 pan된다. 따라서 keyboard에 의해 현재 포커스가 가려지지 않아서 사용자는 항상 타이핑결과를 볼수가 있다. resizing옵션보다 권장되지 않는데 사용자는 윈도우상에 보이지 않는 부분을 보기 위해 softkeyboard를 닫아야 하기 때문이다.

adjustResize와 adjustPan의 차이점

화면의 하단에 EditText가 하나 있다고 가정후 두 옵션의 차이점은 아래와 같다.

  1. adjustResize: 메인윈도우 사이즈가 줄어든다, 하지만 EditText는 보이지 않는다. 스크롤이 지원되면 스크롤하여 볼수는 있다.
  2. adjustPan: 메인윈도우 사이즈가 줄어들지 전체적으로 않고 EditText가 보이도록 위로 올라간다. EditText는 보이나 다른 UI가 보이지 않는다.

Orientation

안드로이드(Android)의 화면 방향이 자동(Auto)으로 전환되지 않고, 한 방향으로 고정시키기 위한 방법에 대하여 설명한다.

AndroidManifest.xml의 activity속성중 screenOrientation을 다음과 같이 지정해준다.

화면을 세로방향으로 유지: 

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

화면을 가로방향으로 유지: 

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

런타임 설정(로테이션, orientation) 변환 라이프사이클

단말에서는 화면 orientation 변환, 키보드 변환, 언어 설정 변환 등과 같이 몇몇 설정들은 런타임 중에 실시간으로 변환하는 경우들이 있다. 이러한 경우에 안드로이드는 현재 Activity를 다시 시작하게 된다. 따라서 이전의 라이프사이클에서 공부했다시피 Activity의 onDestroy를 호출하고 다시 onCreate를 호출하게 되는 과정을 거치게 된다. 이렇게 다시 시작하는 것은 Activity를 다시 시작함으로써 바뀐 설정에 대한 resource들을 쉽게 다시 설정하도록 도와주기 위한 것이다.

이렇게 다시 시작을 할 때에 Activity에서 가지고 있었던 정보들을 잘 보존해야 하는데 이전에 공부했던 onSaveInstanceState를 호출하게 해서 정보를 저장하고, 다시 onCreate나 onRestoreInstanceState에서 저장했던 정보를 다시 불러오도록 하는 것이다.

이렇게 앱이 다시 시작되는 것을 테스트하기 위해서는 앱으로 다양한 작업들을 하면서 이것저것 화면 로테이션 등과 같은 환경 설정의 변화를 줘보면서 테스트를 하면 좋을 것이다. 위의 라이프사이클 이벤트들을 잘 구현하고 있다면 Activity는 데이터를 잘 잘 보존하고 있을 것이다. 하지만, 이런 변화가 즉각적인 변화를 요구하고 있다면, 때로는 방대한 데이터를 저장하고 복원하는 것에 대한 자원 소모가 심각하여 UX를 갑소 시킬지도 모른다. 그럴 때에는 2가지 방법으로 해결할 수 있다.

  • Object를 보관하여 새롭게 시작하는 Activity에 넘겨주는 방법
  • 시스템이 환경 설정을 바꾸고 Activity를 다시 시작하는 것을 방지하고 직접 처리하는 방법

Object를 보관하여 새롭게 시작하는 Activity에 넘겨주는 방법

만약에 Activity를 시작할 때 방대한 데이터를 복원해야하고, 네트워크 연결도 복원하고, 어떠한 복잡한 처리과정이 필요로 한다면, 환경 변화로 Activity를 다시 시작하는 것은 매우 소모적인 일일 것이다. onSaveInstanceState() 함수에서 저장하는 Bundle은 커다란 데이터를 저장하기 위한 용이 아니라 특히 비트맵 이미지 등과 같은 데이터를 넘겨주기 곤란한 경우가 있다. 게다가 Object로 넘겨주는 경우 serialize 단계를 거쳐서 넘겨주고 다시 deserialize 단계를 거치는 처리과정이 필요하기 때문에 많은 메모리를 요구하게 되고, 환경 설정의 변화를 더디게 할 수 있을 것이다. 그럴 때에는 데이터를 저장한 Object를 보존함으로써 그러한 재시작에 대한 자원 소모를 최소화할 수 있는 것이다.

이것은 두 단계에서 일어나게 된다.

  1. onRetainNonConfigurationInstance() 함수를 오버라이드해서 보존하고 싶은 object를 저장
  2. Activity가 시작될 때 getLastNonConfigurationInstance()에서 이전에 보존한 object 복원

안드로이드 시스템에서 Activity를 환경 설정의 변화로 인해 재시작을 한다면, 중간에 onRetainNonConfigurationInstance()를 onStop()과 onDestroy() 사이에서 호출을 하게 되고, 이 onRetainNonConfigurationInstance() 함수에서는 기존의 정보와 상태들을 복원시키기 편한 아무 Object를 리턴해서 복원을 하면 되는 것이다.

가장 많이 사용될 수 있는 시나리오는 바로 인터넷에서 앱으로 많은 양의 데이터를 받았을 때, 사용자가 화면을 돌려서 재시작을 해야한다면, 이럴때 인터넷에서 받은 데이터를 다시 받기보다는 onRetainNonConfigureInstance() 함수를 통해 데이터를 저장하고 환경설정이 바뀐 뒤에 다시 시작될 때, getLastNonConfigurationInstance()를 통해 복원시키면 되는 것이다.

시스템의 환경이 바뀌는 것을 직접 다루기

만약에 개발하고 있는 앱이 리소스를 업데이트할 필요가 없고, Activity가 재시작할 때의 퍼포먼스 문제가 있다고 한다면, Activity가 재시작하는 것을 막고, 직접 Activity에서 환경의 변화를 어떻게 적용시킬것인가 설정하면 된다.

만약에 직접 환경 설정을 다루게 된다면 다른 새로운 리소스를 이용하는 것은 매우 복잡할 것이다. 왜냐하면 일반적으로 시스템에서 자동적으로 모든 것을 적용해주면서 재시작하기 때문이다. 따라서 이 방법은 재시작을 피해야할 때 사용해야할 마지막 수단으로 대부분의 앱에서는 추천되지 않는 방법이다.

만약 환경 설정이 바뀌는 것을 직접 제어하고 싶다면, manifest 파일에 android:configChanges속성을 추가해서 제어를 하고 싶은 해당하는 환경 설정을 인자로 추가해주면 된다.

See also

Favorite site

References

  1. Android_app_develop_basic-orientation_life_cycle.pdf ↩