기술스택
UI, 비즈니스 로직이 모두 Activity나 Fragement에 작성될 경우 코드의 가독성이 떨어지고, 코드간의 연관성이 밀접해져 수정이 어려워집니다.
관심사를 분리를 통해 코드의 가독성을 높이고, 유지보수를 쉽게 하여 개발의 효율을 높이고자 아키텍처 패턴을 적용했습니다.
- View, ViewModel, Model(Repository)을 분리해 뷰와 모델간의 의존성을 줄여줍니다.
- View가 ViewModel의 Data를 관찰하고 있으므로 UI 업데이트가 간편합니다.
- ViewModel이 데이터를 가지고 있으므로 Memory Leak 발생 가능성 배제할 수 있습니다.
- 모듈간의 의존성을 분리해 유지보수가 용이합니다.
MVP는 Presenter가 View와 1대1로 동작하기 때문에 View와 Presenter의 의존성이 강해지는 문제가 발생하고 이에 따라 Presenter의 로직이 커질 수 있습니다.
따라서, 관심사를 충분히 분리할 수 있고 화면회전 등의 동작으로 View가 다시 생성되어도 ViewModel을 통해 데이터를 유지할 수 있는 MVVM 방식을 적용하기로 결정했습니다.
- 국내에서 가장 점유율이 높고, 제공하는 데이터가 가장 많다.
- 많은 사람들에게 친숙한 디자인이다.
- 최대 월 1억건까지 무료이며, 다른 지도 API보다 이용 한도가 높다.
사용자 정보, 약속 정보, 위치 정보를 저장할 수 있는 데이터베이스가 필요했습니다. 이 역할을 Firebase로 해결할 수 있었고, 데이터를 가져올 때 쿼리를 통해 원하는 데이터만 필터링해 올 수 있어 필터링 과정을 따로 처리해 주지 않아도 되는 장점이 있어 사용하게 되었습니다.
Firebase의 데이터베이스로 Firebase Realtime, Cloud Firestore가 있었고, 이 둘 중 어떤 것을 사용해야 할지 고민하는 과정이 있었습니다.
Realtime Database
- 데이터를 하나의 큰 JSON 덩어리로 저장한다.
- 하나의 쿼리에는 필터링/정렬 하나만 가능하다.
- 데이터를 반환할 때 그 이하의 모든 깊이의 데이터도 함께 반환된다.
- 용량, 대역폭에 따라 과금이 발생한다.
Cloud Firestore
- 문서와 컬렉션으로 저장한다.
- 하나의 쿼리에 정렬과 필터링 모두 가능하다. (복합적인 쿼리 가능)
- 데이터를 반환할 때 불필요한 하위 데이터까지 반환하지 않는다.
- 용량, 문서의 CRUD 연산 횟수에 따라 과금이 발생한다.
둘 다 비슷한 기능을 제공하는 느낌을 받았고, 팀원들과 처음 의논을 했을 때는 많은 기능을 가지고 있는 Cloud Firestore를 선택하는 것보다는 프로젝트의 규모가 작은 만큼 Realtime Database을 선택하여 사용하지 않을 기능의 낭비를 줄이자는 의견이었습니다.
하지만, 기능을 추가하다 보니 점점 데이터들의 구조와 관계가 복잡해지고 쿼리 부분에서 어려움을 겪게 되었습니다.
두 개 이상의 쿼리를 사용하여 필터링을 해야 하는 상황이 생겼고, 팀원들과 다시 상의를 나눈 후에 Cloud Firestore로 변경하는 것으로 결정하고, Cloud Firestore를 사용하여 프로젝트를 완성하게 되었습니다.
- 지정된 시간에 작업을 수행해야 한다.
- 앱의 실행 여부와 상관없이 작업이 수행되어야 한다. 위 두 조건을 AlarmManager로 해결할 수 있었기에 사용하게 되었습니다.
SharedPreferences를 사용하다가 Preferences Datastore로 변경했다.
- PreferencesDatastoresms Flow를 지원한다.
- 내부에서 Dispatchers.IO로 돌아가기 때문에 UI thread에서 호출하는것이 안전하다.