NetworkViewModel 논의

[ki960213]

사전 지식

NetworkViewModel의 필요성을 알기 위해선 커디 앱의 공통적인 UI 규칙에 대해 알아야 합니다.
커디 앱은 모든 화면에서 아래의 규칙을 따라야 한다고 생각합니다.

1. 처음 화면에 들어갔을 때 데이터를 불러올 땐 항상 ProgressBar를 보여준다.

2. 금방 결과가 나올만한 요청을 할 땐 1초 후 ProgressBar를 보여준다. (대게 CUD 작업은 1초 후 ProgressBar를 보여주는 게 좋다고 생각합니다.)

3. 네트워크 요청을 해야 하는 화면의 상태는 크게 세 가지로 나뉜다.

   • ProgressBar를 보여주는 상태(만약 요청에 대한 결과가 발생하면 ProgressBar가 필수적으로 사라져야 한다.)
   • NetworkErrorView를 보여주는 상태
   • 위의 두 상태에 해당되지 않는 상태

4. 새로고침을 할 수 있는 방법은 두 가지이다.

   • SwipeRefreshLayout을 이용하여 새로고침
   • NetworkErrorView에서 재시도 버튼 클릭

   따라서 새로고침 시엔 로딩 상태로 변하면 안됩니다. SwipeRefreshLayout을 이용할 땐 SwipeRefreshLayout가 로딩 상태를 표현하고, NetworkErrorView를 이용할 땐 로딩 상태로 변하면 로딩 상태와 네트워크 에러 상태가 공존할 수 없기 때문에 네트워크 문제가 해결되지 않았을 때 재시도 버튼을 클릭하면 사용자는 NetworkErrorView가 깜빡이는 것을 보게 됩니다.

5. 만약 서버에서 불러온 데이터가 이미 화면에 그려진 상태라면 최대한 화면을 가리지 않도록 한다.

   • 이를 위해 CUD 작업 요청이나 새로고침 시엔 네트워크 요청 실패 하더라도 NetworkErrorView를 보여주지 않는다.

문제

위의 규칙을 지키기 위해서는 대부분의 뷰모델 클래스에 아래의 로직을 작성해야 합니다.

• (delay() 후) 로딩 상태로 변경
• 네트워크 에러 상태로 변경
• 아무것도 아닌 상태로 변경
• 알 수 없는 에러 이벤트 발생 알림
• 네트워크 에러에 의한 요청 실패 이벤트 발생 알림(해당 이벤트 사용 사례: 네트워크 에러에 의해 요청 실패 이벤트 발생 시 네트워크 연결을 확인하라는 스낵바 띄우기)
• 새로고침

순서 또한 동일합니다.

1. 로딩 상태로 바꾸기
2. 요청 결과를 처리
3. 화면 상태를 네트워크 에러 상태 혹은 아무것도 아닌 상태로 변경

위의 공통적인 요구사항을 만족하려면 공통적인 로직을 순서에 맞게 작성해야 합니다.
또한 간단하지 않기 때문에 실수할 가능성이 있습니다.
1초 뒤 로딩 바를 띄우게 하기 위해서는 로딩 상태로 변경하는 로직을 비동기로 실행해야 합니다. 이 로직은 성공 상태로 변하게 하는 명령어가 실행되기 전 취소되어야 합니다. 그렇지 않으면 성공 상태로 변경 후 로딩 상태로 변경하는 명령어가 수행되어 로딩 바가 사라지지 않을 수 있습니다.
CUD 요청 시 네트워크 에러에 의해 요청이 실패하더라도 네트워크 에러 화면을 보여주지 않아야 하지만 "네트워크 에러가 발생했으니 네트워크 에러 상태로 변경해야지"라고 착각할 수 있습니다.
새로고침을 했을 때 로딩 상태로 변하게 하면 안되지만 잊을 수 있습니다.

이러한 실수를 막기 위해 NetworkViewModel을 만들었습니다.

얻을 수 있는 이점

• 매 구현마다 순서를 지키려고 노력하지 않아도 됩니다. 단지 요청 종류에 따라 로딩 시, 성공 시, 실패 응답 받을 시, 네트워크 에러 시, 알 수 없는 에러 시 수행할 콜백 함수를 선언적으로 등록하면 됩니다.
• 코드가 간결해집니다.
• NetworkViewModel을 상속한 뷰모델은 화면에 공통적인 UI 상태와 UiEvent를 관리하지 않아도 됩니다. 그 화면과 관련 있는 것들만 관리할 수 있습니다.

아직 해결하지 못한 문제

• 만약 데이터 불러오기 요청을 비동기적으로 여러 개 호출해야 한다면 NetworkViewModel에서 제공하는 기능을 사용할 수 없습니다. 그래서 이전처럼 직접 구현해야 합니다.

코드 설명

소스 코드

abstract class NetworkViewModel : ViewModel() {

    protected val _screenUiState = NotNullMutableLiveData(ScreenUiState.NONE)
    val screenUiState: NotNullLiveData<ScreenUiState> = _screenUiState

    protected val _commonUiEvent = SingleLiveEvent<CommonUiEvent>()
    val commonUiEvent: LiveData<CommonUiEvent> = _commonUiEvent

    protected fun changeToLoadingState() {
        _screenUiState.value = ScreenUiState.LOADING
    }

    private fun changeToNetworkErrorState() {
        _screenUiState.value = ScreenUiState.NETWORK_ERROR
    }

    protected fun dispatchNetworkErrorEvent() {
        _commonUiEvent.value = CommonUiEvent.RequestFailByNetworkError
    }

    protected suspend fun delayLoading(timeMillis: Long = LOADING_DELAY) {
        delay(timeMillis)
        changeToLoadingState()
    }

    abstract fun refresh(): Job

    protected fun <T : Any> fetchData(
        fetchData: suspend () -> ApiResponse<T>,
        onSuccess: (T) -> Unit = {},
        onFailure: (code: Int, message: String?) -> Unit = { _, _ -> },
        onLoading: suspend () -> Unit = suspend { changeToLoadingState() },
        onNetworkError: () -> Unit = ::changeToNetworkErrorState,
    ): Job = viewModelScope.launch {
        val loadingJob = launch { onLoading() }
        when (val result = fetchData()) {
            is Failure -> onFailure(result.code, result.message)
            NetworkError -> {
                onNetworkError()
                return@launch
            }

            is Success -> onSuccess(result.data)
            is Unexpected ->
                _commonUiEvent.value = CommonUiEvent.Unexpected(result.error.toString())
        }
        loadingJob.cancel()
        _screenUiState.value = ScreenUiState.NONE
    }

    protected fun <T : Any> refreshData(
        refresh: suspend () -> ApiResponse<T>,
        onSuccess: (T) -> Unit = {},
        onFailure: (code: Int, message: String?) -> Unit = { _, _ -> },
    ): Job = viewModelScope.launch {
        when (val result = refresh()) {
            is Failure -> onFailure(result.code, result.message)
            NetworkError -> {
                dispatchNetworkErrorEvent()
                return@launch
            }

            is Success -> onSuccess(result.data)
            is Unexpected ->
                _commonUiEvent.value = CommonUiEvent.Unexpected(result.error.toString())
        }
        _screenUiState.value = ScreenUiState.NONE
    }

    protected fun <T : Any> command(
        command: suspend () -> ApiResponse<T>,
        onSuccess: (T) -> Unit = {},
        onFailure: (code: Int, message: String?) -> Unit = { _, _ -> },
        onLoading: suspend () -> Unit = suspend { delayLoading() },
    ): Job = viewModelScope.launch {
        val loadingJob = launch { onLoading() }
        when (val result = command()) {
            is Failure -> onFailure(result.code, result.message)
            NetworkError -> dispatchNetworkErrorEvent()
            is Success -> onSuccess(result.data)
            is Unexpected ->
                _commonUiEvent.value = CommonUiEvent.Unexpected(result.error.toString())
        }
        loadingJob.cancel()
        _screenUiState.value = ScreenUiState.NONE
    }

    protected fun <T : Any> commandAndRefresh(
        command: suspend () -> ApiResponse<T>,
        onSuccess: (T) -> Unit = {},
        onFailure: (code: Int, message: String?) -> Unit = { _, _ -> },
        onLoading: suspend () -> Unit = suspend { delayLoading() },
        refresh: () -> Job = { [email protected]() },
    ): Job = viewModelScope.launch {
        val loadingJob = launch { onLoading() }
        when (val result = command()) {
            is Failure -> onFailure(result.code, result.message)
            NetworkError -> dispatchNetworkErrorEvent()
            is Success -> {
                refresh().join()
                onSuccess(result.data)
            }

            is Unexpected ->
                _commonUiEvent.value = CommonUiEvent.Unexpected(result.error.toString())
        }
        loadingJob.cancel()
        _screenUiState.value = ScreenUiState.NONE
    }

    companion object {
        private const val LOADING_DELAY: Long = 1000
    }
}

enum class ScreenUiState {
    NONE, LOADING, NETWORK_ERROR
}

sealed interface CommonUiEvent {
    data class Unexpected(val errorMessage: String) : BaseUiEvent
    object RequestFailByNetworkError : BaseUiEvent
}

멤버 변수

NetworkViewModel을 상속한 뷰모델이 공통적인 화면 상태와 이벤트를 관리할 수 있도록 관련 멤버 변수와 메서드의 공개 범위를 protected로 선언했습니다.

• screenUiState: 로딩 상태, 네트워크 에러 상태, 아무것도 아닌 상태
• baseUiEvent: 알 수 없는 에러 발생 이벤트, 네트워크 에러에 의한 요청 실패 이벤트

메서드

fetchData

데이터를 불러오는 요청을 할 때 사용하기에 좋습니다. 매개 변수는 아래와 같습니다.

• fetchData: suspend () -> ApiResponse<T> 타입입니다. 데이터 요청 콜백 함수를 넣어야 합니다.
• onSuccess: (T) -> Unit = {} 타입입니다. 성공 응답을 받으면 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 성공 시 아무 일도 하지 않습니다.
• onFailure: (code: Int, message: String?) -> Unit = { _, _ -> } 타입입니다. 실패 응답을 받으면 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 아무 일도 하지 않습니다.
• onLoading: suspend () -> Unit = suspend { changeToLoadingState() } 타입입니다. 로딩 시 수행될 콜백 함수입니다. fetchData를 호출하기 전 수행됩니다. 만약 인자를 넣지 않는다면 화면의 상태를 로딩 상태로 변경합니다. 불러올 데이터의 성격에 따라 로딩 시 수행할 로직을 다르게 할 수 있습니다. 예를 들어 빠르게 불러올 수 있는 데이터라면 로딩 바를 1초 뒤에 보이도록 할 수 있습니다.
• onNetworkError: () -> Unit = ::changeToNetworkErrorState 타입입니다. 네트워크 에러 발생 시 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 화면의 상태를 네트워크 에러 상태로 변경합니다. 만약 이 메서드 수행 시 이미 화면에 그려진 데이터가 있다면 네트워크 에러에 의한 요청 실패 이벤트 발생을 알리는 콜백 함수를 넣는 것이 좋습니다.

refreshData

refresh() 메서드 구현하기 위해 사용할 수 있습니다. 매개 변수는 아래와 같습니다.

• refresh: suspend () -> ApiResponse<T> 타입입니다. 새로고침 요청 콜백 함수를 넣어야 합니다.
• onSuccess: (T) -> Unit = {} 타입입니다. 새로고침 성공 시 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 성공 시 아무 일도 하지 않습니다.
• onFailure: (code: Int, message: String?) -> Unit = { _, _ -> } 타입입니다. 실패 응답을 받으면 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 아무 일도 하지 않습니다.

로딩 시엔 무조건 아무 일도 하지 않도록 했습니다.
네트워크 에러 시엔 무조건 네트워크 에러에 의한 요청 실패 이벤트를 알리도록 했습니다.

command

CUD 요청 시 사용할 수 있습니다. 매개 변수는 아래와 같습니다.

• command: suspend () -> ApiResponse<T> 타입입니다. CUD 작업을 요청하는 콜백 함수를 넣어야 합니다.
• onSuccess: (T) -> Unit = {} 타입입니다. CUD 작업 성공 시 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 성공 시 아무 일도 하지 않습니다.
• onFailure: (code: Int, message: String?) -> Unit = { _, _ -> } 타입입니다. 실패 응답을 받으면 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 아무 일도 하지 않습니다.
• onLoading: suspend () -> Unit = suspend { delayLoading() } 타입입니다. 로딩 시 수행될 콜백 함수입니다. command를 호출하기 전 수행됩니다. 만약 인자를 넣지 않는다면 화면의 상태를 1초 뒤 로딩 상태로 변경합니다. 불러올 데이터의 성격에 따라 로딩 시 수행할 로직을 다르게 할 수 있게 하기 위해 존재합니다. 예를 들어 오래 걸릴 만한 요청이라면 로딩 바를 즉시 보이도록 할 수 있습니다.

네트워크 에러 시엔 무조건 네트워크 에러에 의한 요청 실패 이벤트를 알리도록 했습니다.

commandAndRefresh

CUD 요청 후 새로고침하여 화면을 갱신할 때 사용할 수 있습니다. 매개 변수는 아래와 같습니다.

• command: suspend () -> ApiResponse<T> 타입입니다. CUD 작업을 요청하는 콜백 함수를 넣어야 합니다.
• refresh: () -> Job = this::refresh 타입입니다. CUD 작업이 성공하면 실행됩니다. 새로고침 및 결과 처리하는 콜백 함수를 넣어야 합니다.
• onSuccess: (T) -> Unit = {} 타입입니다. CUD 작업 성공 후 refresh 매개 변수 혹은 NetworkViewModel의 refresh() 메서드를 호출하고 결과가 성공이면 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 성공 시 아무 일도 하지 않습니다.
• onFailure: (code: Int, message: String?) -> Unit = { _, _ -> } 타입입니다. 실패 응답을 받으면 수행될 콜백 함수입니다. 만약 인자를 넣지 않는다면 아무 일도 하지 않습니다.
• onLoading: suspend () -> Unit = suspend { delayLoading() } 타입입니다. 로딩 시 수행될 콜백 함수입니다. command를 호출하기 전 수행됩니다. 만약 인자를 넣지 않는다면 화면의 상태를 1초 뒤 로딩 상태로 변경합니다. 불러올 데이터의 성격에 따라 로딩 시 수행할 로직을 다르게 할 수 있게 하기 위해 존재합니다. 예를 들어 오래 걸릴 만한 요청이라면 로딩 바를 즉시 보이도록 할 수 있습니다.

네트워크 에러 시엔 무조건 네트워크 에러에 의한 요청 실패 이벤트를 알리도록 했습니다.

---

혹시 제가 위에서 제시한 UI 규칙에 대해 아쉬운 점이 있다면 알려주세요.
그리고 NetworkViewModel에 대해 더 나은 의견이 있다면 알려주세요.

---

BaseViewModel을 NetworkViewModel로 변경했습니다.

[tmdgh1592]

금방 결과가 나올만한 요청을 할 땐 1초 후 ProgressBar를 보여준다. (대게 CUD 작업은 1초 후 ProgressBar를 보여주는 게 좋다고 생각합니다.)

금방 결과가 나온다면 ProgressBar를 안 보여주는 것이 낫지 않을까요?
또한 다음과 같은 상황에 문제점이 있습니다.

1. Remote에서 데이터를 로딩한다. (1.2초 소요 예정)
2. 1초 후 ProgressBar를 보여준다.
   => ProgressBar가 0.2초동안 깜빡 거리는 상황이 발생합니다.

[ki960213]

금방 결과가 나올만한 요청이라도 네트워크 상태에 따라 결과가 오랫동안 안 나올 수 있습니다.
만약 결과가 오랫동안 나오지 않는데 ProgressBar가 보여지지 않는다면 사용자는 지루할 거라고 생각합니다.
따라서 1초 후에 ProgressBar를 보여주는 로직이 필요하다고 생각합니다.

[tmdgh1592]

그럼 제가 작성한 상황은 어떻게 해결하려고 하셨나요?

[ki960213]

네트워크 요청 시간을 예상할 수 없기 때문에 위에 제시한 상황은 어쩔 수 없다고 생각합니다.

[tmdgh1592]

네트워크 요청을 해야 하는 화면의 상태는 크게 세 가지로 나뉜다.

• 위의 두 상태에 해당되지 않는 상태

위의 두 상태에 해당되지 않는다는 것은 정상적으로 로딩을 마친 상태를 의미하나요?

[ki960213]

정확히는 화면의 상태를 의미합니다. ProgressBar와 NetworkErrorView를 보여주지 않는 화면의 상태를 말합니다.
프로필 한 줄 소개 변경 요청 같은 금방 결과가 나올만한 요청을 하면 로딩중임에도 ProgressBar를 곧바로 보여주지 않습니다.

[tmdgh1592]

• 네트워크 에러 상태로 변경
• 네트워크 에러에 의한 요청 실패 이벤트 발생 알림(해당 이벤트 사용 사례: 네트워크 에러에 의해 요청 실패 이벤트 발생 시 네트워크 연결을 확인하라는 스낵바 띄우기)

둘 다 네트워크 에러인데 어떤 점이 다른 건가요?
전자는 UiState, 후자는 Event를 의미하는 건가요?

[ki960213]

네, 맞습니다. 둘 다 화면과 관련한 것들을 변경하는 것입니다.
네트워크 에러에 의해 서버로부터 결과를 받을 수 없다면 저희 앱은 NetworkErrorView를 보여주거나, 스낵바를 보여주고 있습니다.
따라서 저희 앱에서 NetworkErrorView를 보여주는 것을 "화면을 네트워크 에러 상태로 변경한다" 라고 말할 수 있습니다.
또한 저희 앱에서 CUD 작업이 네트워크 에러에 의해 요청 실패했을 때, 스낵바를 띄우므로 "액티비티는 네트워크 에러에 의한 요청 실패 이벤트 알림을 받으면 스낵바를 보여준다" 라고 말할 수 있습니다.

[tmdgh1592]

fetchData()에 궁금한 점이 있습니다.

• Unexpected에 대한 콜백만 전달받지 않는 이유가 있나요?
• 저는 당연히 networkError, loading상태로 바꿔주는 상황을 BaseViewModel이 알아서 수행해줄 것이라고 생각했는데, 코드를 보면 아무것도 지정하지 않아야 수행이 되는군요. 개인적으로 에러, 로딩 상태로 변경해주는 것은 기본적으로 수행이 되고, 콜백으로 전달받은 함수를 추가로 호출하는 것이 자연스러울 것이라고 생각됩니다.

[ki960213]

Unexpected는 화면과 요청의 성격마다 처리 방법이 달라지지 않기 때문입니다.

기본적으로 수행되고 콜백 함수를 추가적으로 호출하게 한다면 로딩 시 BaseViewModel을 상속받은 뷰모델은 무조건 로딩 상태로 변경해야 합니다.
따라서 onLoading 매개 변수에 콜백 함수를 할당하면 로딩 시 수행할 로직을 "추가"하는 것보다 "변경"하는 것이 낫다고 생각합니다.

[tmdgh1592]

말씀하신 것처럼 내용대로라면 일부 메서드를 private이 아닌 protected로 변경해주셔야 할 것 같습니다.

[ki960213]

좋습니다!

[tmdgh1592]

개인적으로 fetchData()에서 Success가 최상단에 있는 것이 좋아 보입니다.

[ki960213]

저는 when문을 작성할 때 Add remaining branches로 작성한 코드를 바꾸지 않아서 ApiResponse 객체를 when문에 넣으면 항상 Failure, NetworkError, Success, Unexpected 순으로 작성됩니다.
그리고 when 문으로 sealed class나 enum class를 처리하는 데 순서는 상관 없으니 IDE가 만들어준 코드를 그대로 사용해도 괜찮다고 생각합니다.
사실 이건 스타일 차이이기 때문에 이러한 코드 리뷰는 지양하는 것이 좋다고 생각합니다. 이전 코드 리뷰를 생각해보면 저도 이러한 점은 반성할 부분이 있는 것 같네요 😓
참고한 글

[tmdgh1592]

보통 성공 케이스 다음에 실패 케이스를 나열하는 경우가 많아서 제안했습니다.
개인 프로젝트를 할 때에는 개인 스타일대로 해도 상관없겠지만 팀 프로젝트인만큼 여러 사람들의 스타일을 고려해보는 것이 어떤가 싶은 마음에 리뷰했습니다.
이전에 스캇도 성공 케이스를 위에 두는 것이 어떤가 라는 의견이 있어서 3명의 의견을 모아보고자 했습니다~

[ki960213]

생각해보니 Success 시 수행할 로직이 보통 가장 길고 복잡해서 그 코드를 자주 볼 것 같네요. 그러면 앞으로 Success만 가장 위에 두도록 할까요?

[tmdgh1592]

람다 인자에 기본으로 실행할 함수를 설정하지 않고 nullable하게 설정한 이유가 있나요?
괄호도 많고 elvis도 많이 생기다보니 가독성이 낮아지는 것 같아요.

[ki960213]

생각해보니 기본으로 빈 람다를 넣으면 되겠군요. 좋은 아이디어 감사합니다 👍

[tmdgh1592]

command, commandAndRefresh가 CUD를 의미하는 함수명이라고 느껴지지 않습니다 🥲

[ki960213]

cqrs 패턴이나 cqs 패턴을 검색해보면 CUD 작업을 command라는 이름으로 사용하고 있습니다.
많이 알려진 패턴이라고 생각해서 command라는 이름을 사용했습니다.

[tmdgh1592]

백엔드 관련인가요?
저는 아예 처음 들어봤습니다ㅠ

[ki960213]

cqs 패턴은 모든 프로그래밍에 적용할 수 있는 디자인 패턴입니다. :)

[tmdgh1592]

onRequestFailByNetworkError() 함수명도 changeToNetworkErrorState() 처럼 실제로 수행하는 역할과 동일하게 이름을 지어보면 좋을 것 같아요.
ex) changeToNetworkErrorEvent()

[ki960213]

좋은 아이디어네요. 네트워크 에러에 의한 요청 실패 이벤트를 발생시키는 것이므로 dispatchRequestFailEventByNetwork()라는 이름이 더 낫겠군요. 더 짧게 dispatchNetworkErrorEvent()라고 해도 충분히 이해가 가능할까요?

[tmdgh1592]

dispatch가 어떤 의미를 가지고 있나요?

[ki960213]

이벤트를 보낸다는 뜻입니다.

[tmdgh1592]

refresh() 메서드 구현하기 위해 사용할 수 있습니다. 매개 변수는 아래와 같습니다.

이런 이유라면 abstract fun refresh()와 fun refreshData(...) 둘 중 하나만 사용하는 것이 낫지 않을까요?
사용자 입장에서 XxxViewModel에 refresh와 refreshData가 모두 있으면 헷갈릴 것 같습니다.

[ki960213]

refreshData는 fetchData, command처럼 BaseViewModel을 상속한 클래스 내부에서 사용하기 위한 메서드입니다.
반면 refresh는 외부에서 사용하기 위한 메서드입니다.
BaseViewModel을 올바르게 사용하기 위해서는 저희 앱의 UX 규칙을 이해해야 한다고 생각합니다.

• 처음 데이터 불러올 때
• 이미 데이터를 불러왔는데 다시 불러올 때
• 서버에 CUD 작업을 요청할 때
• 서버에 CUD 작업을 요청하고 다시 데이터를 불러올 때

위처럼 구분되는 요청마다 모든 화면에서 일관적인 UX를 구현하기 쉽도록 하기 위해 BaseViewModel을 만들었습니다.
위 지식을 알고 있다면 외부에서 사용할 수 있는 refresh와 내부에서만 사용할 수 있는 refreshData의 차이점을 잘 이해할 수 있지 않을까요?
더 나은 방법이 있다면 제시해주시면 감사하겠습니다.

[tmdgh1592]

private이 아닌 순간부터 하위 클래스에서 접근할 수가 있죠..
이미 두 메서드 모두 BaseViewModel 기준으로 외부에서 접근이 가능한 상황입니다.
(토마스가 말씀하시는 외부는 Activity라고 생각이 드네요.)

위에 작성해주신 의도대로라면 네이밍을 더 명확하게 할 필요가 있어 보입니다.
refresh나 refreshData나 결국 데이터를 새로고침한다. 라는 동일한 의미니까요 🙂

[ki960213]

refreshData는 fetchData, command처럼 BaseViewModel을 상속한 클래스 내부에서 사용하기 위한 메서드입니다.

네 맞습니다.

둘의 이름이 비슷해서 혼동할 수 있다는 점은 아쉬운 것 같습니다. 더 나은 이름을 제시해주시면 감사하겠습니다.
refresh는 데이터라는 말이 붙지 않기 때문에 refreshData보다 더 추상적인 것으로 생각할 수 있습니다.
ViewModel 외부에서 refresh를 호출하는 경우는 뷰모델이 관리하는 화면 전체를 새로고침할 때입니다.
반면 refreshData는 Data라는 말이 붙어 있기 때문에 특정 데이터를 다시 불러올 때 사용합니다. 그게 화면 전체이든 일부이든 말이죠.
이렇게 생각하면 refresh와 refreshData의 차이를 쉽게 기억할 수 있다고 생각합니다.

[tmdgh1592]

command() 는 딜레이 로딩을 사용하는 것이 이해가 되지만,
commandAndRefresh() 는 요청 후 새로고침하는 작업이라면 딜레이 로딩할 필요가 없지 않나요?

+) 코드를 보면서 느낀 건데, CUD는 READ보다 작업이 짧아서 delayLoading() 을 하는 건가요?

[ki960213]

사실 저는 CUD 작업은 사용자가 금방 끝날 것으로 예상한다고 생각하기 때문에 commandAndRefresh()도 딜레이 로딩을 사용하도록 구현했습니다.
사용자 입장에서 CUD 작업만 요청하든, CUD 작업이 끝나고 데이터를 다시 불러와서 화면에 그리든 1초 안에 끝난다면 차이를 느끼지 못하기 때문입니다.
반면 처음 화면에 들어가서 데이터를 불러오고 화면을 그리는 작업은 사용자가 시간이 조금 걸릴 거라고 예상할 거라고 생각해서 곧바로 로딩바를 보여주도록 했습니다.
쉽게 말해 사용자의 예상대로 작동하는 앱으로 보이기 위해 이처럼 설계했습니다.

[tmdgh1592]

말씀하신 내용대로라면 fetchData도 동일하지 않을까요?
오히려 CUD 작업 + fetch(= refresh) 작업에 시간이 더 오래 소요되니까요.

[ki960213]

실제 시간보단 사용자가 예상하는 시간을 기준으로 선택했습니다.
사용자는 처음 화면에 들어가서 데이터를 불러오는 시간이 일부 command 기능을 사용하는 것보다 더 오래 걸릴 거라고 예상하기 때문입니다.
command 후에 다시 데이터를 새로 불러오는 건 앱의 구현일 뿐이지, 사용자는 그렇게 느끼지 않도록 하는 게 좋다고 생각합니다.

[chws0508]

음 저는 현재로서는 직접 적용해보질 않아서 딱 감이 잡히질 않아서, 내일부터 실제로 적용해보면서, 부족한 부분이 있다면 조금씩 고쳐보는 것도 좋아보입니다.

[ki960213]

좋습니다!