5. 공통 모듈 내 로직
Android와 iOS가 공통으로 사용하는 shared 모듈에는 어떤 로직들이 작성되어야 할까?
제일 먼저 떠올릴 수 있는 것은 데이터 레이어 영역이다.
애플리케이션의 비즈니스 로직에서 처리하기 위한 데이터는 어딘가에 존재하기 마련이고, 이는 동일한 URI로 표현되고 있을 가능성이 매우 높기 떄문이다.
예를 들어 원격에 있는 데이터를 API 호출을 통해 받아오거나, 로컬내 데이터베이스에 있는 데이터를 조회해서 꺼내오는 작업은
플랫폼에 상관없이 공통적으로 일어나는 동작이라고 볼 수 있기 때문이다.
5.1. KMM에서의 데이터 획득
KMM에서는 API 호출을 ktor 로, 내부 데이터는 SQL Delight 를 통해 구현할 수 있다.
간단하게 표로 나타내보면 아래와 같다.
| 구분 | Android | iOS | KMM |
|---|---|---|---|
| Http Api 호출 | OkHttp / Retrofit | URLSession / Alamofire | Ktor |
| DB SQL | SQLite / Room | SQLite / CoreData | SQL Delight |
즉 KMM에서는 Ktor와 SQL Delight을 이용해 kotlin으로 데이터 획득을 위한 코드를 작성하는 공통 라이브러리가 이미 지원되고 있기때문에
양쪽 플랫폼에 대해 하나의 코드로 커버할 수 있다.
5.2. domain-layer만 공통화 대상인가?
KMP를 살펴보면서 한 가지 의문이 들었다.
shared 모듈에 data / damain / presenter를 전부 다 배치하는 것이 옳은 걸까?
아니면
옳진 안더라도 어느정도는 유용할까?
유용하다면 얼만큼 유용할까?
솔직히 확신을 얻기가 힘들었다.
개인적으로 shared 모듈에 허용할 수 있는 범주는 data / domain / 의존적이지않은 플랫폼 api 까지라는 생각이 계속 들었기 댸문이다.
만약 ViewModel을 shared에 배치한다면 Android 까지는 당연히 잘 동작하겠지만 iOS에서의 suspend나 flow를 어떻게 접근할까?
단순히 생산성이 좋다라는 측면 하나만 두고 공통 로직으로 다 작성하는 것이 맞을까?
KMP가 익숙치않아서이기도 하겠지만, 오히려 생산성이 더 안좋아지는 느낌이 들었다.
즉, 공통화가 가능한 것과 공통화가 권장되는 영역의 경계가 모호해서 딱 부러지는 맛이 없다.
억지로 하나의 공통코드로 커버하는 방법도 생각해보니 추상화를 위한 추상화가 될 것 같고,
추상화의 수준이 높아지면 결국 이해도는 떨어지는 것이 아닌가?
결국 최대한 유연하고 느슨한 인터페이스로 생각을 정리하긴 했다.
다만 단일 방안을 찾아낸 사례들을 듣고 있어서, 언젠간 딱 부러지지않을까? 하는 기대를 가지고 있다.
