Skip to content

API 요청에 따른 동적 탭 변화

HyeonSeongKang edited this page Aug 29, 2023 · 3 revisions

안녕하세요. 안드로이드 팀의 강현성 입니다.

이번 프로젝트에서 API 요청에 따른 동적 탭 변화를 구현했는데 어떻게 구현했는지에 대해서 공유하려 합니다.

문제 사항

"내 차 만들기"는 사용자가 다양한 부품을 선택하여 개인화된 차량을 구성하는 서비스입니다. 현재는 7개의 부품에 대해서만 개발하도록 고정되어 있지만 만약 부품이 추가되거나 제거되는 요구사항이 추가 된다면, (추가될 경우) 해당 부품에 대한 프래그먼트와 상태 관리를 위한 뷰모델을 매번 추가해야 합니다. (삭제될 경우) 해당 부품에 대한 프래그먼트와 상태 관리를 위한 뷰모델을 해당 차량을 선택했을 시 빼야합니다. 이러한 문제를 해결하기 위해 동적으로 차량 부품에 대한 정보를 관리해야 합니다.

해결 방법

해당 문제를 해결하기 위해 다음과 같은 Car 데이터 클래스를 설계했습니다.

data class Car(
    val name: String,
    val type: String,
    val mainOptions: List<Map<String, List<OptionInfo>>> = emptyList(),
    val subOptions: List<Map<String, List<OptionInfo>>> = emptyList()
)

위 Car 데이터 클래스는 차량의 이름과, 타입(SUV, 전기차 etc..), 차량에 대한 필수 메인 옵션, 사용자가 선택할 수 있는 선택 옵션을 포함하고 있습니다. 이와 같이 클래스를 설계 했을 경우 장점은 동적으로 각 차량에 대한 부품을 관리할 수 있다는 것 입니다. 예를 들어 "파워 트레인", "구동 방식", "바디 타입", "외장 색상", "내장 색상", "휠 선택"과 같은 필수 옵션이 있다면 mainOptions의 key값으로 해당 부품에 대한 이름을 넣어주고 value로 해당 부품에 대한 옵션 정보를 입력합니다. ex) Key: "파워 트레인", Value: "디젤 2.2", "가솔린" 이 데이터 클래스 구조를 통해 API 응답에 따라 mainOptions의 각 키를 사용하여 동적으로 탭을 생성하며, 해당 키에 해당하는 값(옵션 정보)을 사용하여 화면에 내용을 동적으로 표시할 수 있습니다.

새로운 문제

만약 각 부품별로 클래스를 만들고 관리했다면 각 하나의 프래그먼트에서 해당 부품의 로직을 처리하면 되지만 지금과 같은 경우 하나의 프래그먼트에서 여러개의 부품의 로직을 처리해야 합니다. 이로 인해 다음과 같은 문제가 발생했습니다.

  • 뷰모델의 크기 증가: 하나의 뷰모델이 다양한 부품의 로직을 모두 처리하게 되므로, 뷰모델의 크기와 복잡도가 증가했습니다.

  • 유지 보수의 어려움: 뷰모델이 커짐에 따라 코드의 가독성과 관리가 어려워지게 됩니다. 특정 부품에 대한 로직 수정이 필요할 때, 전체 뷰모델을 찾아봐야 하는 문제가 발생 했습니다.

위 새로운 문제를 해결하기 위해 다시 한 번 고민을 했고, 클린 아키텍처의 필요성을 느꼈습니다.

새로운 문제를 해결 하기 위한 클린 아키텍처 공부

위와 같은 문제를 해결하기 위해 클린 아키텍처 기반의 MVVM 공부를 시작했습니다. 특히, 도메인 레이어의 도입을 통해 뷰모델의 부담을 줄이는 것을 목표로 두었습니다. 만약 도메인 레이어를 도입한다면 다음과 같은 이점이 있을 것 입니다.

  • 도메인 레이어의 역할: 비즈니스 로직 처리를 담당하여, 뷰모델이 UI와 관련된 로직에만 집중할 수 있게 합니다.

  • 로직의 재사용성 향상: 도메인 레이어를 통해 정의된 비즈니스 로직은 다른 뷰모델에서도 재사용될 수 있습니다.

  • 테스트 용이성: 비즈니스 로직이 도메인 레이어로 분리되면, 해당 로직에 대한 단위 테스트를 수행하기가 더 쉬워집니다.

느낀점

"내 차 만들기" 프로젝트를 통해 API의 응답에 따라 동적으로 탭을 생성하도록 고민하고 구현해 봤습니다. 그러나 이런 데이터 클래스 설계와 하나의 라이브데이터로 상태를 관리하다보니 뷰모델의 복잡도 증가라는 새로운 문제점을 알게 되었습니당. 초기 설계 시에는 고려하지 못한 이 문제로 인해, 뷰모델에서의 로직 처리가 복잡해지며, 유지 보수 및 확장성에 어려움을 겪게 되었습니다. 뷰모델이 커지는 문제를 해결하기 위한 방법으로 클린 아키텍처의 필요성을 느끼게 되었습니다. 이를 통해 비즈니스 로직을 도메인 레이어에 위임함으로써, 뷰모델의 복잡도를 줄이고 코드의 품질을 향상시킬 수 있음을 깨달았습니다.

이번 프로젝트는 단순한 기능 구현뿐만 아니라, 좋은 아키텍쳐의 중요성과 그 기반에서의 설계 방법에 대해 깊이 있게 고민해 볼 수 있는 기회였습니다. 특히, 클린 아키텍처의 중요성을 체감하였으며, 이를 기반으로 한 아키텍쳐 학습을 다음 스텝으로 계획하고 있습니다.

Clone this wiki locally