📦 왜 DataStore 인가?

Jump to bottom

saeyoung Oh edited this page Dec 13, 2023 · 1 revision

SharedPreferences

비동기 API 지원 부족
- 값이 변경되었을 때 listener 를 통해서 콜백을 받을 수 있는 것 말고는 지원하지 않음.
호출된 스레드에서 바로 write 이 가능함.
- UI 스레드에서도 호출이 가능하기 때문에 UI 스레드 블로킹으로 인한 ANR 발생의 가능성이 존재함.
Runtime exception 에 취약
- exception 핸들링을 제공하지 않아, runtime에 에러가 발생하면 어플이 종료되는 문제.

DataStore

코루틴과 Flow 를 통한 비동기 API 를 지원하고, 일관된 트랜잭션 방식으로 데이터를 저장
Dispatcher.IO 에서의 작업이 보장되기 때문에 UI 스레드에서 호출되어도 안전하게 사용할 수 있음.
유형
- Preferences DataStore
  - key-value 형식으로 데이터 저장하며, 사전 정의된 스키마가 필요하지 않음.
  - 타입 안전성을 제공하지 않음.
- Proto DataStore
  - 프로토콜 버퍼를 사용하여 유형이 지정된 객체를 저장하며, 사전 정의된 스키마가 필요함.
  - 타입 안전성을 제공하며, Preferences DataStore 보다 복잡한 데이터 구조를 저장하기에 적합.

Room

기존 안드로이드에서 사용하던 SQLite 를 더 편리하게 사용할 수 있도록 구축된 ORM (Object Relational Mapping) 라이브러리
Entity (데이터베이스 테이블), DAO (테이블의 데이터에 접근할 수 있는 인터페이스를 정의한 클래스로 메서드를 제공함), Database (데이터베이스를 보유하고 있으며 기본 엑세스 포인트 역할을 함) 로 구성되어 있음.
관계형 데이터베이스에서 복잡한 데이터베이스 관계와 쿼리를 처리할 수 있음.

-> Preferences DataStore 를 선택한 이유

- 위에서 언급한 대로 SharedPreferences 은 갖은 문제가 있었기 때문에 선택하지 않음.
- 저장해야 할 데이터는 유저의 accessToken / refreshToken 이 전부.  복잡한 데이터 구조를 관리할 필요가 없었고, 
관계형 데이터베이스에 값을 저장하거나 쿼리 할 필요가 없었음.
- 이러한 이유로 Preferences DataStore 기술을 채택하여 accessToken / refreshToken 을 관리함.