Fragment 재사용
MeetMeet 프로젝트를 진행하면서 UI가 똑같은 Layout이 3곳에서 사용되는 부분이 있다.
 |
 |
 |
|---|
팔로우 화면, 일정 초대 화면, 그룹 초대 화면 총 3곳에서 완전히 똑같은 Layout이 사용되었다.
처음에는 만들어둔 layout.xml 파일을 그대로 똑같은 곳에서 재사용하면 된다고 생각했었다.
하지만 개발을 진행하면서 어려움을 겪게 되었다.
전체를 포괄하는 부모 Fragment 안에 FragmentStateAdapter 를 사용하여 내부에 팔로잉, 팔로워 목록을 보여주는 자식 Fragment가 2개 존재한다.
부모 Fragment에서도 유저를 검색하여 취할 수 있는 Action이 있기 때문에 자식 Fragment에서 ViewModel을 만들 경우, 부모 Fragment의 ViewModel에서도, 자식 Fragment의 ViewModel에서도 비슷한 코드가 만들어 지는 문제가 발생했다.
또 xml에서 binding 하고 있는 ViewModel이 있는데, 팔로우, 일정 초대 , 그룹 초대 를 담당하는ViewModel을 모두 다르게 사용한다면, xml에서 binding하는데 문제가 생기기 때문에 xml을 재사용할 수 없는 문제가 발생하였다.
문제를 해결하기 위해서 생각했던 방법은 다음과 같다.
- xml을 재사용하지 않고, 각 Fragment 마다 ViewModel을 만들어 binding한다.
- 가장 간단하면서도 직관적인 방법이지만, 똑같은 코드가 너무 많아진다.
- 부모 Fragment와 자식 Fragment의 ViewModel에서는 결국 같은 Action의 코드가 작성된다.
- xml을 재사용하지 않고, 부모 Fragment에만 ViewModel을 만들어 자식 Fragment에서는 부모 Fragment의 ViewModel을 사용한다.
- 똑같은 xml코드가 중복된다는 문제는 해결되지 않는다.
-
팔로우,일정 초대,그룹 초대,의 로직이 비슷한 형태로 각 ViewModel에 작성된다.
- xml을 재사용하고, 각 Fragment 마다 ViewModel을 만들어 binding한다.
- 부모 Fragment와 자식 Fragment의 ViewModel에서는 결국 같은 Action의 코드가 작성되는 문제는 해결되지 않는다.
- 부모 Fragment와 자식 Fragment의 ViewModel 모두 방대해진다.
- xml을 재사용하고, 부모 Fragment에만 ViewModel을 만들어 자식 Fragment에서는 부모 Fragment의 ViewModel을 사용한다.
- 부모 Fragment의 ViewModel이 방대해진다.
4번째 방안을 선택하여 개발하기로 하였다.
1,2,3번째 방안과는 다르게 중복되는 코드를 최소화 할 수 있지만, 부모 Fragment의 ViewModel이 방대해진다는 단점은 감안하고 일단 개발을 진행하기로 하였다.
부모 Fragment는 argument로 actionType 과 id를 받도록 한다.
actionType은 FOLLOW EVENT GROUP 의 enum class로 받고, id는 일정id 혹은 그룹id 이며, action이 FOLLOW일 경우 defaultValue로 0을 받고 사용하지 않는다.
부모 Fragment의 ViewModel에서 ActionType 과 해당 user의 상태에 따라서 각각 다른 API를 호출하도록 분기 처리하였다.
-
팔로우
유저 검색(팔로우 상태 포함),팔로잉 목록 가져오기(팔로우 상태 포함),팔로워 목록 가져오기(팔로우 상태 포함),팔로우 기능,언팔로우 기능 -
일정 초대
유저 검색(일정 초대 상태 포함),팔로잉 목록 가져오기(일정 초대 상태 포함),팔로워 목록 가져오기(일정 초대 상태 포함),일정 초대
각각의 팔로우와 일정 초대 기능마다 호출하는 API의 종류가 모두 다르기 때문에 이 모든 로직이 전부 ViewModel에 들어있어서 ViewModel이 너무 방대해졌다.
ViewModel이 위와 같은 많은 API 호출에 대한 로직을 가지고 있기 때문에 이를 분리할 필요가 있다고 생각한다.
이를 해결 하기 위해서, Fragment에서 ViewModel을 생성할 때 actionType에 따라 다르게 ViewModel을 생성할 수 있도록 처리할 수 있을 것 같다.
각 ViewModel은 추상화를 통해서 상태에 따라 유저 검색(actionType 상태 포함), 팔로잉 목록 가져오기(actionType 상태 포함), 팔로워 목록 가져오기(actionType 상태 포함) 기능으로 분리하여 각각의 함수를 만들고 버튼 이벤트에 대해서는 Positive Action (팔로우 or 일정 초대) 와 Negative Action (언팔로우) 로 나누어 함수를 만들면 방대해진 ViewModel을 좀 더 효율적으로 분리하여 사용할 수 있지 않을까 생각한다.