반응형
멀티 모듈 구조로 프로젝트를 구성하면서 가장 화가났던건
A feature -> B, C, D feature 모듈간 이동을 위해 A모듈에서 이동하는 모든 경로를
app모듈에서 함수 형식으로 graph함수에 전달해주는 일이었다.
feature모듈은 서로 독립적이기 때문에 navigator를 사용해서 직접적인 이동이 불가능하기 때문이다.
fun EntryProviderScope<NavKey>.aNavGraph(
navigator: Navigator,
navigateToB: () -> Unit,
navigateToC: () -> Unit,
navigateToD: () -> Unit
...
) {
...
}
이런 경우에 위처럼 2~3개 정도면 별로 상관 없겠지만
경로가 많아질수록 선언부, 호출부 모두 꼴보기 싫은 상태가 된다.
실제로 현업 프로젝트에서 10개 이상의 경로가 추가된 경우가 있었다.
이런 상황을 어떻게 해야하나 고민을 가지고 있었는데, NIA앱에서 각 feature가 api/impl 모듈을 각각 가지고 있는걸 발견했다.
이 구조는 api는 외부 공개가 가능하고, impl에서 실제 구현은 숨기면서 독립성을 지키는 구조이기 때문에 내가 원하는 구현에 딱 맞는 구조라고 생각했다.
이후 전체 feature모듈에 대해 리팩토링을 진행해서
api에는 NavKey와 navigator 확장 함수로 백스텍에 추가하도록 하고,
impl의 graph에선 navigator만 파라미터로 받아서 위 함수를 호출하기만 하면 되는 간단한 구조로 리팩토링 되었다.
fun Navigator.navigateToB() = navigate(BNAvKey)
fun Navigator.navigateToC() = navigate(CNAvKey)
fun Navigator.navigateToD() = navigate(DNAvKey)
@Serializable data object BNavKey: NavKey
@Serializable data object CNavKey: NavKey
@Serializable data object DNavKey: NavKey
fun EntryProviderScope<NavKey>.aNavGraph(
navigator: Navigator
) {
navigator.navigateToB()
...
}
반응형
'안드로이드 > 리팩토링' 카테고리의 다른 글
| [안드로이드] Linear Calendar에서 offset 검색 최적화 (0) | 2025.12.23 |
|---|