🔍 학습계기
Jetpack Compose를 이용한 클론 코딩 프로젝트를 위해 학습을 하는 도 중 아래와 같은 의문이 생겼다.
xml방식의 경우에는 화면 이동을 위해서 startActivity같은 걸이용해서 전환을 하기에 새로운 화면이 필요하다면 모든 경우 액티비티를 만들고 그에 맞는 xml을 디자인해왔는데..
컴포즈는 꼭 액티비티를 사용하지 않고도 메인 액티비티에서 @Composable을 부르고 네비게이션으로 다음 Compose화면으로 넘어가면 굳이 액티비티를 구성하지 않아도 정상적으로 작동이 되었다.
아래 그림처럼

🤔 Activity하나로 모든 화면을 구현해도 될까?
이 고민에 대해 상당히 오래 생각을 해보았다.
액티비티는 결국 안드로이드 라이프 사이클과 관련이 되어 있는데 하나의 액티비티로 모든 화면을 구현하는 경우에는 라이프사이클과 관련된? 문제가 발생하지 않을까 하는 생각이 들었다.
Compose UI관련 구매한 강의에서는 강사님께서 말씀해주신 말로는
Activity 전환 시에 자연스럽게 다음 화면으로 넘어가는 효과도 디자이너분이 요청하셨을 때 액티비티 한개로는 부자연스러운 느낌이 들었던 경험이 있다.
ViewModel이 비대해질 가능성이 있다.
일반적인 방법으로 액티비티를 전환이 가능하다.
Intent를 사용하여 다른 액티비티로 이동할 수 있으며, 기존의 startActivity()나 startActivityForResult()와 같은 메서드를 사용하여 화면을 전환이 가능!
하나의 액티비티에서 여러 화면에 대한 상태와 로직을 모두 다루기 때문에 해당 뷰모델은 다양한 화면 전환 시나리오와 관련된 코드를 포함하게 된다.
이로 인해 뷰모델의 크기가 커지고 유지 보수가 어려워질 수 있으며 또한 코드의 가독성과 재사용성이 저하될 가능성이 존재한다.
이러한 상황을 방지하기 위해서는 각각의 화면에 대한 상태와 로직을 별도의 뷰모델로 분리하여 관리하는 것이 좋음!
-> 이렇게 하면 각 화면에 대한 코드가 더욱 모듈화되고 관리하기 쉬워지며, 각 화면이 독립적으로 테스트될 수 있다.