현재 진행중인 프로젝트의 회원가입 플로우가 마음에 들지 않아 최근에 리패키징 겸 리팩토링을 했다.
회원가입 플로우는 소셜, 번호, 그리고 비밀번호 찾기 까지 포함되어 있었고, 각 플로우간 겹치는 화면들이 꽤 있었다.
하지만 각 플로우별로 사용되는 API가 달랐고, 그에 따라 Data Layer의 파일들이 달라질 수 밖에 없었다. (Repository, Source)
그리고 기존에는 ViewModel을 Activity당 하나만 할당해두고, 그 위의 Fragment들은 Activity의 ViewModel을 상속받아 사용했다.
이렇게 했더니, 같은 화면에서 여러개의 Activity의 ViewModel을 상속받고, 각 Activity의 ViewModel은 여러개의 Fragment의 로직들까지 포함되어 굉장히 코드가 길어지고, 가독성이 하락하는 이슈가 있었다.
그리고 화면간 전환들에도 소소한 이슈가 있었는데, A플로우에서 1번 화면에 진입할 때와 B플로우에서 동일한 화면에 진입할 때, 단순 tag 혹은 type으로만 분기처리를 해주기에는 코드를 작성하면서 햇갈리는점, 그리고 A플로우를 들렀다 B플로우로 가서 다시 1번 화면에 진입할 때 등,
이러한 분기처리 변수들을 Activity의 ViewModel로 관리하다보니, 기존 Activity의 생명주기가 끝나지 않고 새로운 Activity에서 해당 화면을 열었을 때 등 생각보다 훨씬 다양한 상황이 발생했고, 그러한 이슈들을 전부 트래킹하기엔 무리가 있다고 판단되었고
결국 패키지 구조를 갈아엎기에 들어섰다.
공통된 화면들을 따로 패키징하고, 그 외엔 플로우의 고유한 화면들만을 모아 패키지를 따로 모았다.
그리고 각 Fragment별로 ViewModel을 두어 해당 Fragment에서 종결나는 로직들 (다른 화면과의 정보 공유가 필요없는)을 담았다.
그리고, Activity의 ViewModel은 Fragment에서의 작업들을 총괄하여 최종적으로 호출해야하는, 혹은 Fragment간 공유가 가능해야 하는 변수들 (AAC ViewModel의 역할로) 을 담았다.
회원가입의 플로우로 예시를 들어보면
Activity -> 최종 회원가입 Request로직, 회원가입에 필요한 각 값들(이름, 번호 등등)을 담아두는 변수
Fragment -> 각 화면에서 필요한 Request (번호 인증 등) 및 유효성 로직
으로 구분되어 각 ViewModel이 훨씬 깔끔해졌다.
그리고 화면별 분기처리를 할 때도, 구분되는 동작 모두가 Fragment의 ViewModel에서 동작하므로
Fragment 생성시 받는 구분자만으로도 플로우별 분기처리를 확실하게 할 수 있어 훨씬 깔끔하게 동작했다.
'[개발] > [안드로이드_이슈 일기]' 카테고리의 다른 글
[Android] FCM 관련 팁 총 정리 (1) | 2023.08.12 |
---|---|
[Android] local.properties의 값 Manifest에서 사용하기 (2) | 2023.08.09 |
[Android] 멀티파트로 String 전송시 " 가 붙던 오류 트러블슈 (0) | 2023.07.30 |
[Android] Bitmap 이미지 용량 줄이기 (0) | 2023.07.25 |
[Android] 커스텀 달력 만들기 기록 - 01 (1) | 2023.07.14 |