앱 처음 화면에서 Login시 AccessToken과 Refresh Token을 서버에서 받아옴

⇒ 1. Access Token과 Refresh Token을 DataStore에 저장한다.

⇒ 2. 모든 요청에 Access Token을 Header에 Authorization: Bearer ${access_token} 형식으로 달아준다.

⇒ 3. 모든 요청을 보낼 때, 401 응답이 오면

⇒ 3.1 message가 "Refresh token expired. Please log in again.” 라면 Refresh Token이 만료된 것 ⇒ 로그인 화면으로 돌아간다.

⇒ 3.2 그게 아니라면 Access Token이 만료된 것 ⇒ Refresh Token을 이용해 Access Token을 다시 받아오게 한 후, 원래의 요청을 다시 보낸다.

DataStore Preference

DataStore Preferenc란

• 키-값 형태로 객체를 저장할 수 있는 데이터 저장소
  • 만약 더 복잡한 객체 형태를 저장해야될 경우 Room을 사용하는게 좋음.
  • Datastore는 소규모 단순 데이터 셋에 적합함.
• 코루틴, Flow, Rx 지원.
• 트랜잭션 방식으로 데이터 저장.

Preferences DataStore 및 Proto DataStore

• Preferences DataStore

  • 키를 사용하여 데이터에 저장/액세스
    • ⇒ 유형 안전성을 제공x
  • 사전 정의된 스키마가 필요하지 않음

• Proto DataStore

  • 맞춤 데이터 유형의 객체를 통해 데이터를 저장
    • ⇒ 유형 안전성 제공
  • 프로토컬 버퍼를 통해 스키마를 사전 정의해야함
    • 프로토컬 버퍼 : 구글의 데이터 직렬화 알고리즘

⇒ Token을 저장하기 위해서는 Preference DataStore가 조금 더 적합

DataStore Preference vs SharedPreference

공식문서에서는 SharedPreference 대신 DataStore Preference를 사용하기를 권장하고 있다. 그 이유가 뭘까

1. SharedPreference는 비동기 처리를 지원해주지 않는다.

   • 비동기 작업을 제대로 처리해줘야지만 오류를 해결할 수 있다.
   • 데이터 작업은 보통 데이터가 변경되면 비동기로 처리가 되어야하는 로직이 많아서 이는 큰 이점

   DataStore는 코루틴, Flow, Rx를 통해 비동기 처리가 가능하다!

2. SharedPreference는 strong consistency가 보장되는 api가 없어 다중 스레드 환경에서 다른 결과값이 생길 수 있다.

   DataStore는 strong consistency가 보장된다.

   • Consistency : 트랜잭션이 완료되면 일관된 데이터를 유지해야한다. (데이터베이스의 일관성)

3. SharedPreference는 Type safety가 보장되지 않는다.

   • 일일이 데이터 형변환이 필요했음

4. DataStore는 Runtime exception에서 안전하다.

   • Runtime exception에서 안전하다는 건 예외 상황이 발생했을 때, 프로그램이 예외를 처리하거나, 적절한 에러메세지를 나타내주고, 예외 상황에서도 예상대로 작동한다는 것!