[TellingMe/Android] 텔링미 안드로이드 개발 🔥3차 스프린트🔥

이번 3차 스프린트 기간에는 Compose 기반의 UI 구성에서 벗어나 카카오 소셜로그인과 관련된 API 연동 및 로그인 관련 비즈니스 로직을 작성하는 작업을 했습니다.

 

카카오에서 제공하는 로그인 API만 연결하면 마치 앱의 로그인 과정이 모두 끝난 것 같은(?) 것처럼 보이지만 전혀 그렇지 않습니다.

클라이언트에서 시도한 카카오 로그인이 정상임이 확인되면 이제부터 많은 부분들을 신경 써줘야 합니다.

프로젝트마다 로그인 로직이 조금씩 다를 수 있겠지만 저희는 카카오에서 발급해 준 사용자 고유의 인가코드를 서버로 전달해 자체적인 AccessToken/RefreshToken을 발급받아 사용자를 관리하고 있습니다. 그리고 최초 로그인인지 아닌지를 구분해 최초 로그인 이후로는 당연히 자동 로그인이 되어야 하고, 이때 로컬 DB에 읽고 쓰는 과정도 필요합니다. 발급받은 AccessToken/RefreshToken의 만료 여부도 계속 체크하면서 적절하게 갱신해줘야 하구요.

 

위의 과정을 위해서 Http → Https 네트워크 통신 방법, Retrofit을 사용한 API 응답을 커스텀하기 위해서 CallAdapter 정의, 로컬 DB에 접근하기 위해 DataStore 설정, 다른 계층에서 특정 객체에 편리하게 접근할 수 있도록 Hilt 설정 및 DI 주입, 매 API 요청마다 Token의 만료 여부를 확인하기 위해 OkHttp의 Interceptor 체이닝 등 많은 공부를 했습니다.

(필요한 라이브러리와 API 설정만 해도 많은데 설정하면서 발생하는 이슈들도 굉장히 많았습니다... 후..)

 

Compose UI와 API를 연결하면서 알게 된 점은 컴포즈는 상태에 따라 UI가 존재하기 때문에 상태 관리가 매우 중요합니다.

이 점을 이번 스프린트를 진행하면서 몸소 깨닫게 되었는데 상태 관리를 어떻게 하면 편리하고 효율적으로 할 수 있을까 찾아보던 중 Compose에서 지향하는 MVI 패턴을 알게 되었습니다. 

• Model: MVP 또는 MVVM 모델의 정의와는 다른 UI에 반영될 상태를 의미합니다.
  또한, MVI에서 Model은 데이터의 흐름이 단방향으로 이루어지기 위해 불변성을 보장해야 합니다.
• View: UI 그 자체다. View, Activity, Fragment, Compose 등이 될 수 있다.
• Intent: 사용자가 취하는 액션 및 이벤트를 의미합니다.

즉, 사용자의 액션(이벤트)이 새로운 Intent로 변경되고, 해당 Intent로부터 새로운 Model을 만들어 View를 갱신하는 흐름을 보여줍니다.

상태 관리에 대해 고민을 하던 중 MVI 패턴을 알게 되니 어떤 방식으로 상태 관리를 하려고 하는지, MVI가 왜 필요한지가 더 와닿게 된 것 같네요.

 

MVI에 더해 BaseViewModel에서 여러 메소드와 상태를 의미하는 State, Event, Effect를 추상화하고, 필요한 ViewModel에서 BaseViewModel을 상속받아 사용하는 형태로 구성하다 보니 이번 스프린트에서는 프로젝트의 구조, 아키텍쳐에 대해 공부했던 시간이 많았네요..

다음 스프린트에서는 기존에 작성된 비즈니스 로직을 MVI에 맞게 수정하는 작업과 소셜로그인 기능에 MVI를 처음부터 끝까지 적용하면서 연습하고, 프로젝트 전체에 MVI 패턴을 따라갈 수 있도록 구조를 갖춰두는 작업을 할 것 같습니다. 그리고 현재는 Compose에서 화면을 전환하는 Navigation 컴포넌트가 아주 기본적인 작동만 가능하게끔 만들어져 있어 NavGraph(?)로 분할해 관리할 수 있는 방법에 대해 공부해야 할 것 같아요.

 

개인적으로 MVI 패턴을 익숙하지 않은 Compose 환경에서 State, Event, Effect 같은 낯선 용어와 함께 쓰여 좀 더 어렵게 느껴졌던 것 같습니다. 거기에 BaseViewModel, CallAdapter 등 기존에 있는 여러 컴포넌트들을 커스텀해서 적용하려니 러닝커브가 굉장히 높게 느껴졌습니다.

현재는 많은 고민과 다른 팀에서는 어떻게 하고 있는지 염탐하고 참고하면서 조금은 익숙해지고 있는 것 같습니다!!

---

📝 3차 스프린트 리뷰

고민 1. Http 통신에 문제가 있는 것 같다. Https 통신을 어떻게 하지..?

- 안드로이드는 현재 공식적으로 http 통신을 허용하고 있지 않지만 Manifest에 usesCleartextTraffic 속성을 true로 설정해주는 것만으로도 우회해서 http 접근이 가능하기 때문에 그동안 우회해서 접근하는 방식으로 개발했습니다.

그치만 이번에는 위 방법이 통하지 않아 근본적으로 SSL 인증서를 통해 https 네트워크 통신을 할 수 있도록 설정했습니다.

자세한 내용은 아래 포스팅에서 확인할 수 있습니다. ↓

[Android/Kotlin] Retrofit을 이용한 https통신에서 SSL 인증서 오류 해결방법

고민 2. 상태 관리에 대한 고민

- 위에서 언급한 대로 상태 관리에 대한 고민을 정말 많이 했습니다.

그리고 Compose에서 MVI 패턴을 적용하는 방법에 대해 알 수 있었고, 진행하고 있는 프로젝트에 설계부터 적용까지 직접 해보기 위해 레퍼런스를 정말 많이 참고해 나름 잘(?) 적용할 수 있었던 것 같아요.

현재는 소셜로그인 기능에만 적용해 봤지만 앞으로 작업하게 될 기능에도 비슷한 방식으로 적용할 수 있을 것 같아 큰 산은 넘은 것 같습니다.

 

고민 3. Retrofit의 반환 타입을 커스텀하기

- Retrofit을 통한 네트워크 통신의 응답으로 Response나 Call 객체가 아닌 제 입맛대로 커스텀 된 ApiResult 클래스를 만들어 해당 타입을 return하도록 설정했습니다.

레퍼런스가 많아 구현하는 데에 크게 어렵지는 않았지만 스웨거 API 문서와 response의 status를 통일하는 부분에서 조금 까다로웠고, resopnses.errorBody()가 null인 상황을 처리하는 방법에 조금 어려움이 있었던 것 같습니다.