JetPack - UI 이벤트 (작성중)

Devoloper URL

UI 이벤트

UI 이벤트는 UI 레이어에서 UI 또는 ViewModel로 처리해야 하는 작업입니다. 가장 일반적인 이벤트 유형은 사용자 이벤트입니다. 사용자는 화면 탭하기 또는 동작 생성과 같은 앱과의 상호작용을 통해 사용자 이벤트를 생성합니다. 그러면 UI에서 onClick() 리스너와 같은 콜백을 통해 이러한 이벤트를 사용합니다

핵심 용어:

• UI: 사용자 인터페이스를 처리하는 뷰 기반 또는 Compose 코드입니다.
• UI 이벤트: UI 레이어에서 처리해야 하는 작업입니다.
• 사용자 이벤트: 사용자가 앱과 상호작용할 때 생성하는 이벤트입니다.

ViewModel은 일반적으로 사용자의 비지니스 로직을 처리합니다.(예: 사용자가 데이터를 새로고침하는 경우) 사용자 이벤트에는 UI에서 직접 처리할수있는 UI 동작 로직이 있을 수도 있습니다. (예: 다른화면 이동, snackbar 표시)

• 비즈니스 로직은 결제 또는 사용자 환경설정 저장과 같은 상태 변경과 관련하여 필요한 조치를 말합니다. 도메인과 데이터 레이어는 일반적으로 이 로직을 처리합니다. 이 가이드에서는 아키텍처 구성요소 ViewModel 클래스가 비즈니스 로직을 처리하는 클래스의 추천 솔루션으로 사용됩니다.
• UI 동작 로직 또는 UI 로직은 탐색 로직 또는 사용자에게 메시지를 표시하는 방법과 같이 상태 변경사항을 표시하는 방법을 나타냅니다. 이 로직은 UI에서 처리합니다.

UI 이벤트 결정 트리

사용자 이벤트 처리

데이터에 영향이 없는 뷰가 보이고 안보이고처리는 UI에서 처리하고
데이터에 영향이 가는 갱신 기능은 ViewModel에서 처리한다.

class LatestNewsActivity : AppCompatActivity() {

    private lateinit var binding: ActivityLatestNewsBinding
    private val viewModel: LatestNewsViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        // The expand details event is processed by the UI that
        // modifies a View's internal state.
        binding.expandButton.setOnClickListener {
            binding.expandedSection.visibility = View.VISIBLE
        }

        // The refresh event is processed by the ViewModel that is in charge
        // of the business logic.
        binding.refreshButton.setOnClickListener {
            viewModel.refreshNews()
        }
    }
}

RecyclerView의 사용자 이벤트

RecyclerView 항목 또는 맞춤 VIew와 같이 UI 트리 아래쪽에서 작업되는 경우도 ViewModel을 통해 사용자 이벤트를 처리한다.

예를 들어 NewsActivity 의 모든 뉴스 항목에 북마크가 있다고 가정한다. RecyclerView Adapter의 북마크 버튼을 누를때 ViewModel의 addBookmark함수를 호출하지 않으며, ViewModel의 종속 항목이 필요한다. 대신 ViewModel은 이벤트 처리를 위한 구현이 포함된 NewsItemUiState라는 상태 객체를 노출한다.

data class NewsItemUiState(
    val title: String,
    val body: String,
    val bookmarked: Boolean = false,
    val publicationDate: String,
    val onBookmark: () -> Unit
)

class LatestNewsViewModel(
    private val formatDateUseCase: FormatDateUseCase,
    private val repository: NewsRepository
)
    val newsListUiItems = repository.latestNews.map { news ->
        NewsItemUiState(
            title = news.title,
            body = news.body,
            bookmarked = news.bookmarked,
            publicationDate = formatDateUseCase(news.publicationDate),
            // Business logic is passed as a lambda function that the
            // UI calls on click events.
            onBookmark = {
                repository.addBookmark(news.id)
            }
        )
    }
}

이렇게하면 RecyclerView 어댑터가 NewsItemUiState 객체 목록과 같이 필요한 데이터만 사용할 수 있다. 어댑터가 전체ViewModel에 억세스 할 수 없으므로 VIewModel에 의해 노출된 기능을 악용할 가능성이 낮다. Activity클래스에서만 ViewModel을 사용하도록 허용하는 경우 책임이 분리된다.

• 경고: ViewModel을 RecyclerView 어댑터에 전달하면 이를 ViewModel 클래스와 긴밀하게 결합하게 되므로 좋지 않습니다.
• 참고: 또 다른 일반적인 패턴은 RecyclerView 어댑터가 사용자 작업을 위한 Callback 인터페이스를 갖는 것입니다. 이 경우 활동이나 프래그먼트가 바인딩을 처리하고 콜백 인터페이스에서 직접 ViewModel 함수를 호출할 수 있습니다.

사용자 이벤트 함수의 이름 지정 규칙

ViewModel 함수는 처리하는 작업에 따라 동사를 포함해 이름이 지정됩니다(예: addBookmark(id) 또는 logIn(username, password)).

ViewModel 이벤트 처리

ViewModel에서 발생하는 Ui 작업은 항상 UI 상태 업데이트로 이뤄진다. -> 데이터 단방향 흐름 원칙에 의해 구성 변경후 이벤트를 재현할 수 있으며 UI 작업이 손실되지 않는다.

로그인후 홈 화면으로 이동하는 경우 코드
(corutine를 수명주기와 함께 사용하는 방법 추후 공부 예정)

data class LoginUiState(
    val isLoading: Boolean = false,
    val errorMessage: String? = null,
    val isUserLoggedIn: Boolean = false
)

class LoginViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(LoginUiState())
    val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()
    /* ... */
}

class LoginActivity : AppCompatActivity() {
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { uiState ->
                    if (uiState.isUserLoggedIn) {
                        // Navigate to the Home screen.
                    }
                    ...
                }
            }
        }
    }
}

이벤트를 소비하면 상태 업데이트가 트리거될 수 있음

UI에서 특정 ViewModel 이벤트를 소비하면 다른 UI 상태가 업데이트될 수 있습니다.
예) 화면에 임시 메시지를 표시하여 사용자에게 무언가 발생했음을 알리는 경우 (데이터 상태에 따라 메시지가 표시되고 닫히기 때문에 ViewModel을 통해서 모델링한다.

// Models the UI state for the Latest news screen.
data class LatestNewsUiState(
    val news: List<News> = emptyList(),
    val isLoading: Boolean = false,
    val userMessage: String? = null
)

비즈니스 로직이 사용자에게 임시 메시지를 새로 표시해야 하는 경우 ViewModel은 다음과 같이 UI 상태를 업데이트합니다.

class LatestNewsViewModel(/* ... */) : ViewModel() {

    private val _uiState = MutableStateFlow(LatestNewsUiState(isLoading = true))
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    fun refreshNews() {
        viewModelScope.launch {
            // If there isn't internet connection, show a new message on the screen.
            if (!internetConnection()) {
                _uiState.update { currentUiState ->
                    currentUiState.copy(userMessage = "No Internet connection")
                }
                return@launch
            }

            // Do something else.
        }
    }

    fun userMessageShown() {
        _uiState.update { currentUiState ->
            currentUiState.copy(userMessage = null)
        }
    }
}

tip: viewModelScope: ViewModel이 destroy 될 때 자식 코루틴을 자동으로 취소하는 기능을 제공한다.

ViewModel은 UI가 화면에 메시지를 표시하는 방식을 알 필요가 없습니다. 표시해야 하는 사용자 메시지가 있다는 사실만 알면 됩니다. 임시 메시지가 표시되면 UI가 ViewModel에 이를 알려야 하며 그러면 userMessage 속성을 삭제하기 위해 또 다른 UI 상태 업데이트가 발생합니다.

class LatestNewsActivity : AppCompatActivity() {
    private val viewModel: LatestNewsViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { uiState ->
                    uiState.userMessage?.let {
                        // TODO: Show Snackbar with userMessage.

                        // Once the message is displayed and
                        // dismissed, notify the ViewModel.
                        viewModel.userMessageShown()
                    }
                    ...
                }
            }
        }
    }
}

메시지가 일시적이더라도 UI 상태는 모든 시점에 화면에 표시되는 내용을 충실하게 표현합니다. 사용자 메시지는 표시되거나 표시되지 않습니다.

탐색 이벤트

이벤트 소비로 상태 업데이트 트리거 가능 섹션에서는 UI 상태를 사용하여 화면에 사용자 메시지를 표시하는 방법을 자세히 설명합니다. 탐색 이벤트는 Android 앱의 일반적인 이벤트 유형이기도 합니다.

• UI에서 이벤트가 트리거 되는 경우

class LoginActivity : AppCompatActivity() {

    private lateinit var binding: ActivityLoginBinding
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        binding.helpButton.setOnClickListener {
            navController.navigate(...) // Open help screen
        }
    }
}

• 탐색 전에 데이터 입력에 비즈니스 로직 확인이 필요하면 ViewModel은 UI에 상태를 노출해야 합니다. UI는 상태 변경에 반응하고 적절하게 이동합니다. ViewModel 이벤트 처리 섹션에서는 이 사용 사례를 다룹니다. 다음은 비슷한 코드입니다.

class LoginActivity : AppCompatActivity() {
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { uiState ->
                    if (uiState.isUserLoggedIn) {
                        // Navigate to the Home screen.
                    }
                    ...
                }
            }
        }
    }
}

대상이 백 스택에 유지된 경우 탐색 이벤트

코드 이해가 안됨.

기타 사용 사례

UI 상태 업데이트로 UI 이벤트 사용 사례를 해결할 수 없다고 생각되면 앱의 데이터 흐름 방식을 다시 고려해야 할 수도 있습니다. 다음 원칙을 고려하세요.

• 각 클래스에서 각자의 역할만을 수행해야 합니다.
  UI는 탐색 호출, 클릭 이벤트, 권한 요청 가져오기와 같은 화면별 동작 로직을 담당합니다. ViewModel은 비즈니스 로직을 포함하며 계층 구조의 하위 레이어에서 얻은 결과를 UI 상태로 변환합니다.
• 이벤트가 발생하는 위치를 생각해 보세요.
  이 가이드의 시작 부분에 있는 결정 트리를 따르고 각 클래스가 담당하는 역할을 처리하게 합니다. 예를 들어 이벤트가 UI에서 발생하고 그 결과 탐색 이벤트가 발생하면 이 이벤트는 UI에서 처리되어야 합니다. 일부 로직이 ViewModel에 위임될 수 있지만, 이벤트 처리는 ViewModel에 완전히 위임될 수 없습니다.
• 소비자가 여러 명이고 이벤트가 여러 번 소비될 것이 우려된다면 앱 아키텍처를 다시 고려해야 할 수도 있습니다.
  동시 실행 소비자가 여럿인 경우 정확히 한 번 제공되는 계약을 보장하기가 매우 어려워지므로 복잡성과 미묘한 동작의 양이 폭발적으로 증가합니다. 이 문제가 발생하면 UI 트리의 위쪽으로 문제를 푸시해 보세요. 계층 구조의 상위로 범위가 지정된 다른 항목이 필요할 수 있습니다.
• 상태를 소비해야 하는 경우를 생각해 보세요.
  어떤 상황에서는 앱이 백그라운드에 있다면 계속 소비하지 않는 것이 좋을 수 있습니다(예: Toast 표시). 이 경우 UI가 포그라운드에 있을 때 상태를 소비하는 것이 좋습니다.