[Android] Custom View 상태 저장 + 커스텀 캘린더뷰 제작 기록

https://www.charlezz.com/?p=29013 

Android에서 View의 생명주기 | 찰스의 안드로이드

위 블로그의 상태 저장과 복구 예시 코드를 잘 활용했다. 찰스님 감사합니다👍

 

---

커스텀뷰로 달력을 만들었다. 디자인 가이드를 적용하고 앱 성능을 위해서는 커스텀뷰로 구현하는 것이 적합하다는 것을 인정할 수 밖에 없었다.

달력에서 초기화로 선택되거나(오늘 날짜가 선택됨), 사용자가 선택한 날짜는 강조되어 표시되는 (당연한) UI이다.

커스텀뷰 달력이 노출되는 화면에서 다음 depth 화면으로 진입하는 시나리오들이 있는데, Jetpack Navigation을 이용해 Fragment들로 화면을 이동하기로 했다. 이 달력이 있는 화면이 서비스의 메인 화면이고, 이 서비스를 Activity 하나에서 관리하는 것이 적합할 것이라고 판단했다. (그래야 하는데🤔 depth들을 Activity로 호출하는 방법과 Navigation을 두고 정말 많이 고민했다.)

문제는 커스텀뷰가 있는 Fragment(A 라 부르겠다.)에서 다른 Fragment 화면(B라 부르겠다.)으로 갔다가 돌아오면 커스텀뷰의 상태가 초기화된다는 것이었다. 

A에서 B로 화면이 노출되면 A의 뷰는 destroyed 됐다. B에서 A로 돌아오면 A의 뷰는 다시 created 되어 커스텀뷰도 다시 초기화되어 그려졌다.

 

https://developer.android.com/codelabs/kotlin-android-training-lifecycles-logging?index=..%2F..android-kotlin-fundamentals#0

https://developer.android.com/guide/fragments/lifecycle

 

 

여기서 또 고민.

- B 화면으로 넘어가기 전에 A의 캘린더뷰에 선택된 날짜 상태값을 저장하는 것은 누구의 역할인 것인가.

A와 한 쌍으로 동작하는 ViewModel이 진행해야 하는 것인가, 이 캘린더뷰가 해야하는 것인가.

 

1) 처음 선택. 캘린더뷰가 날짜 관리에 책임이 있다고 생각해 커스텀뷰의 상태 저장을 시도했다.

캘린더뷰(부모뷰) 아래 날짜 일별 뷰(자식 뷰)에 일일이 id를 붙여주고...(6 x 7개의 날짜 뷰에 각기 다른 id를 붙여줘야 한다는 것을 처음 깨달았을 때 정말 피곤했다.)

BaseSavedState를 상속받아 이 커스텀뷰에 맞게 State 클래스를 만들어주고

onSaveInstanceState()와 onRestoreInstanceState()를 오버라이드해서 잘! 정말 잘 동작했다. 성공.

 

(뷰의 생명주기는 찰스님의 블로그에서 확인하기로.)

 

2) 문제 발생

①A(get api 호출. 월별 데이터 조회 및 노출 + 사용자가 날짜 선택.)-> ②B(일별 post api 호출) -> ③ A로 다시 돌아와서 data 갱신(get api 호출) 하게되면서, 타이밍 이슈가 발생했다.

③에서 data 갱신으로 인한 뷰 갱신과 커스텀뷰의 상태 복구 타이밍이 섞여서, 캘린더뷰는 ①에서의 날짜가 선택되어 잘 나타나나 해당 날짜의 정보가 제대로 노출되지 않았다. 

 

3) 결국엔 A의 선택된 날짜 관리는 ViewModel만 하기로 결정했다.

커스텀 캘린더 뷰의 초기화 시, ViewModel에서 선택한 날짜를 받아 캘린더에 표시하기로 했고, 커스텀 뷰의 상태 저장/복구 코드는 다 주석처리😂

최상단 화면이 A에서 B로 넘어가며 A의 뷰는 destroyed 되고, B에서 A로 돌아와 A가 다시 뷰를 그릴 때, ViewModel에서 저장된 날짜를 가져다가 커스텀 뷰를 그려주니, 원하는 대로 정상동작한다.

 

https://developer.android.com/topic/libraries/architecture/viewmodel

 

---

이 과정 내내 느낀 것은, lifecycle을 아는 것이 정말 중요하다는 것이다.