개요
AAC에는 LifecycleOwner와 LifecycleObserver가 포함되어있습니다. 이들은 광범위하게 사용될 수 있으나 이번 포스팅에서는 가장 기초적인 개념과 활용을 알아봅니다. 향후 발전된 예제는 따로 다뤄보죠.
쨌든 공식문서의 설명은 딱딱하고 잘 와닿지 않아 좀 더 쉬운 예제로 입문용으로 풀어볼까 생각하게 되었습니다(..절 위해 =.=)
LifecycleOwner
라이프사이클 오너는 말그대로 라이프사이클을 소유하고 있는 옵져버패턴의 서브젝트입니다. 이때 라이프사이클을 소유한다라는 뜻은 정확하게는 라이프사이클옵져버(LifecycleObserver)를 소유한다는 것입니다.
이는 직접 구상하여 구축할 수 있습니다만 그것으로는 크게 의미가 없습니다. 왜냐면 짜피 커스텀으로 구현할 거라면 굳이 LifecycleOwner가 아니라도 나만의 서브젝트를 만들면 그만이기 때문입니다.
진짜 의미가 있는 건 android.support.v7.app.AppCompatActivity(지원액티비티)와 android.support.v4.app.Fragment(지원프래그먼트)가 이걸 내장하고 있다는 사실입니다.
실제 AAC가 1.0으로 정식릴리즈 된 후에 호환성 지원 유틸리티의 프래그먼트 선언은 다음과 같이 변경되었습니다.
public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner {
...
}
public class SupportActivity extends Activity implements LifecycleOwner {
...
}
위 코드처럼 LifecycleOwner를 구상하여 주요 생명주기 메소드에서 각 상태를 dispatch해줍니다. 따라서 큰 노력 없이 액티비티나 프래그먼트에서 생명주기의 변화를 옵져버로 수신할 수 있게 되었습니다.
LifecycleObserver
실제 액티비티나 프래그먼트의 생명주기를 수신하는 옵져버를 이용하면 액티비티나 프래그먼트측의 코드를 건드리지 않고 추가적인 작업을 수행할 수 있습니다.
모든 프래그먼트에 공통되게 적용할 작업 등을 정의할 수도 있고, 관심사에 따라 코드를 옵져버가 처리할 부분과 프래그먼트 본체가 처리할 부분으로 분리하여 관리할 수도 있습니다.
예를 들어 간단하게 생명주기 진입시 로그를 기록한다고 해보면, 기존에는 전부 직접 액티비티에 기술해야 했습니다. 하지만 지금은 다음과 같은 옵져버를 미리 만들어두면 됩니다.
class Logger implements LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
public void onCreate(){
Log.i("base", "onCreate");
}
}
이러면 이 옵져버는 오너측의 onCreate를 통보받아 실행되므로 액티비티에서는 다음과 같이 등록하면 됩니다.
public class MainActivity extends AppCompatActivity{
{
getLifecycle().addObserver(new Logger());
}
@Override
protected void onCreate(Bundle savedInstanceState){
...
}
}
감지할 수 있는 이벤트
이벤트에 등록된 enum은 다음과 같습니다.
ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_ANY
실제 위의 이벤트는 아래 그림처럼 매칭됩니다.
프래그먼트와 매칭하는 조건을 그림으로는 알기 어렵습니다.
- ON_CREATE – onCreate와 onCreateView 사이에 호출됩니다. onCreateView 직전이라고 생각하시면 됩니다.
- ON_DESTROY – onDestroyView와 onDestroy 사이에 호출됩니다. onDestroyView 다음이라고 생각하시면 됩니다.
결론
라이프사이클을 사용하면 외부에서 손쉽게 프래그먼트와 액티비티의 생명주기에 추가적인 코드를 삽입할 수 있어 굉장히 편리합니다.
예를 들어 모든 UI에 공통적인 요소를 추가한다던가, 이미 등록된 추적코드를 생명주기에 따라 활성화, 비활성화 한다던가 하는 식으로요.
UI에 공통적인 내용을 분리하여 더욱 유지보수가 쉬운 코드로 이전하거나 더 나아가 어떤 UI에서도 쓸 수 있는 공통 유틸리티같은 걸 만들어서 재활용할 수도 있겠다 싶습니다.
recent comment