기술 선택

Firebase

Firebase realtime database vs firestore

	Realtime Database	Firestore
저장 방식	하나의 큰 JSON 트리	document의 컬렉션
캐싱	실시간 SDK로컬 데이터 스토리지 지원	실시간 SDK로컬 데이터 스토리지 지원
동기화	동기화 지원	Cloud Functions를 사용해 추가 구현 필요
쿼리	정렬 or 필터링 가능 데이터 반환 시 하위 depth도 함께 반환 인덱스가 필요하지 않음	정렬 and 필터링 가능 특정 컬렉션 또는 컬렉션 그룹의 문서만 반환 기본적으로 인덱싱 되어있음

Firestore

• 1대n 관계가 많아 realtime database를 사용하면 depth가 깊어져 쿼리의 성능이 떨어진다.
• 컬렉션 단위로 정규화에 유리하다.
• 실시간으로 동기화를 지원할 필요가 없다.

Firebase 통신 방법(Rest API)

• Firebase에서 제공하는 SDK를 사용하지 않고 Rest API를 사용한 통신 방식을 구성하기로 결정
• 간단히 사용할 수 있는 SDK를 사용하기 보다는 통신 방식을 직접 구현 하면서 학습
• SDK를 사용하지 않아서 얻을 수 있는 이점(빌드속도, 앱 용량)
• Firebase에서 다른 API 기반 서버로 바뀌었을 때 변경 용이성
• SDK에서 지원해 주는 캐싱, 동기화 등의 기능을 직접 구현해보는 경험

Room

Local database가 필요한 이유

• 오프라인 사용성을 지원
• 공유된 루틴들에 대한 로컬 캐싱을 구현 (SDK에서 제공되는 기능을 사용하지 않고 API를 사용할 통신을 직접 구현할 것이기 때문)
• 실시간으로 서버와 계속하여 통신하는 것이 아니라 유저의 필요에 따라 동기화 기능을 제공

Paging

Paging이 필요한 이유

모든 데이터를 서버에서 한꺼번에 가져올 경우

• (클라이언트) 서버 요청량 문제, 대기 시간 문제 - 서버에서 전체 데이터를 한번에 가져오려 할 경우 통신량이 많아지고, 데이터를 화면에 표시하기까지 너무 많은 시간이 걸릴 수 있다.
• (클라이언트) 불필요하게 많은 데이터를 캐싱 - 당장 보여지지도 않을 데이터를 너무 많이 캐싱하게 된다.
• (서버) 다수의 사용자에게 방대한 데이터를 모두 보내야 하므로 과부하가 올 수 있다.

Service

WorkManager vs Service

우리 앱의 특징

• 사용자가 시작한 즉시 확인할 수 있어야 한다.
• 사용자가 종료를 결정하기 때문에 얼마나 길게 수행될 지 모른다.
• 알림을 계속 업데이트 해야한다.
• 도즈모드인 상태에서도 타이머가 동작해야 한다.

Sevice의 생명주기 관리

• 서비스 내부에 운동 기록을 위한 타이머 로직과 타이머 시간을 저장하기 위해 DB에 저장하는 로직이 존재한다.
• 이런 코루틴 로직들의 처리를 서비스의 생명주기와 맞춰 서비스 종료 시에 코루틴 Job도 취소되게 하기 위해 LifecycleService를 사용하였다.