Android에서 View 레이어는 무엇을 담당해야 하나요?

최근에 우수한 "Guide to app architecture"이 출시되었습니다. 이것은 Android 앱 개발 분야에 입문하는 모든 사람을 위한 멋진 리소스입니다. 새 Android 앱을 만들 때 염두에 두어야 하는 많은 중요한 아키텍처 결정을 요약합니다. 당신의 경험 수준이 무엇이든, 빠른 읽기는 확실히 당신의 시간을 가질 가치가 있습니다.

물론 소프트웨어 아키텍처와 관련하여 작업을 수행하는 진정한 단일 범용 방법은 없습니다. 그리고 레이어 사이의 "경계"는 설명하려고 아무리 노력해도 주관적입니다.

"Types of logic "섹션에서 "UI 비즈니스 로직"은 다음과 같이 정의됩니다.

UI behavior logic or UI logic is _ how _ to display state changes on the screen. Examples include obtaining the right text to show on the screen using Android Resources, navigating to a particular screen when the user clicks a button, or displaying a user message on the screen using a toast or a snackbar.

그리고 이것이 제가 저자와 동의하지 않는 부분입니다.

전통적으로 UI 테스트는 Android 세계에서 매우 어렵고 깨지기 쉽습니다. 따라서 우리는 앱의 UI가 아닌 요소에 대한 상당히 강력한 커버리지와 전체 앱을 종단 간 테스트하기 위한 몇 가지 통합 테스트를 갖게 됩니다. Android 앱을 빌드할 때 보기 외부로 최대한 많은 논리를 이동하는 것이 목표여야 합니다.

제 생각에는 표시할 올바른 문자열을 얻거나 다른 화면으로 이동하는 것이 보기 계층의 책임이 되어서는 안 됩니다. 이는 비즈니스 로직 계층(예: 널리 사용되는 MVVM 접근 방식을 따르는 경우 모델 보기)에서 처리되어야 합니다. 보기 계층에 배치하면 테스트하고 추론하기가 더 어려워집니다. 그리고 이것은 테스트되지 않은(또는 테스트되지 않은) 상태로 두기에는 너무 중요한 책임입니다.

그러나 ViewModel(또는 다른 비즈니스 로직 계층)에서 Android 시스템에 대한 종속성을 격리하는 개념으로 어떤 일이 발생하는지 질문할 수 있습니다. 뷰 모델은 가능하면 Android에 대해 아무것도 몰라야 하며 이것이 올바른 접근 방식입니다. 이것이 추상화가 작용하는 곳입니다. 이 격리 지침을 얼마나 강력하게 따르고 싶은지에 따라 Android 시스템의 많은 부분을 테스트에서 쉽게 조롱/대체할 수 있는 자체 클래스로 래핑하여 추상화할 수 있습니다.

예를 들어 보기 레이어에 표시할 일부 문자열을 어셈블하려면 AndroidResource 객체에 액세스해야 합니다. 저는 시스템 리소스에 액세스할 수 있고 단위 테스트에서 쉽게 조롱할 수 있는 SystemController를 만드는 경향이 있습니다. 따라서 문자열을 수집하고 조립하는 책임은 View Model에 있습니다. 보기는 표시해야 하는 것을 정확히 가져옵니다. View 레이어에는 "표시 방법"논리가 저장되지 않고 "표시 위치"논리가 저장됩니다.

@Singleton
class SystemController @Inject constructor(
    @ApplicationContext private val context: Context
) {

    fun getString(@StringRes stringResId: Int): String = context.getString(stringResId)
}

물론 이것은 View Model이 리소스 ID에 대해 알고 있다는 단점이 있지만 저는 이것으로 괜찮습니다. Android 시스템과의 완전한 격리를 주장하는 경우 한 단계 더 나아가 이러한 리소스 ID를 추상화할 수 있습니다(더 장황하지만 실행 가능).

이 접근 방식에 동의하지 않더라도 이런 종류의 폭언이 유용한 생각거리가 되었기를 바랍니다. :)

즐거운 코딩하세요!