LiveData 알아보기

# LiveData?

LiveData는 Lifecycle을 인지할 수 있는 Observable 클래스다. 이때 lifecycle은 앱 컴포넌트의 수명주기를 말한다. 
사용을 위해서는 lifecycle dependency를 추가해야한다.

implementation("androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version")

class MyViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name
    
    fun setName(newName: String) {
        _name.value = newName
    }

    fun setNameWithSetValue(newName: String) {
        _name.setValue(newName)
    }

    fun setNameWithPostValue(newName: String) {
        _name.postValue(newName)
    }
}

_name은 name의 backing property로 내부에서는 Mutable하고, 외부에서는 읽기만 가능하도록 만드는 방법이다. 이렇게 사용하는 이유는 크게 두 가지로 나눠 볼 수 있을 것 같다.

1. 캡슐화
2. 단방향 데이터 flow

내부에서는 수정가능한 데이터지만 외부에서는 읽기만 가능하기 때문에 데이터 무결성을 보장할 수 있고, layer를 나눠서 사용하고 있다면 UI 레이어에서 데이터 수정을 못하기 때문에 아키텍처적인 관점으로 적합하다.
ViewModel 안에서 _name 수정하고, 그 외에서 name으로 접근할 수 있는데, 값을 업데이트 하는 방식은 세가지가 있다. 그냥 value에 넣는 법, setValue, postValue다.
 

# _name.value = newName

livedata는 property를 갖고있는데, 이렇게 값을 업데이트하는 건 직접 프로퍼티에 접근하는 방식이다. Observer가 즉시 변경을 알 수 있다. 메인스레드(UI 스레드), 백그라운드 스레드 상관없이 접근할 수 있는 방식이라 예외가 발생할 수도 있는 방식이다.(thread safe 하지 않다는 의미) setValue랑 동일하다
 

# _name.setValue(newName)

메인 스레드에서만 사용할 수 있는 방식이다. 따라서 thread safe하고, Observer에게 변경을 즉시 알린다.(내부에 있는 onChanged 메서드를 호출하는 방식) 백그라운드 스레드에서 setValue를 호출하게 되면, 예외(CalledFromWrongThreadException)가 발생한다. 
 

# _name.postValue(newName)

postValue도 thread safe한 값 업데이트 방식인데, 메인 스레드, 백그라운드 스레드 상관없이 안전한 호출 방식이다. 새 데이터를 메인 스레드의 다음 체크 포인트에 설정하고, Observer에게 알린다. setValue랑 차이점은 실제 값 설정 타이밍이 다르다는 것이다.
안드로이드에서 메인 스레드는 단일 스레드이고, 메시지 큐에 들어와있는 메시지들을 순차적으로 처리한다. 이때 메시지 큐에 새로운 메시지가 들어오면 이 메시지를 처리하기 위한 체크포인트가 발생하게 된다.
setValue는 메인스레드에서 처리되기때문에 값을 즉시 설정해서 업데이트 하기 때문에 메시지 큐에 데이터를 대기시키지 않는데, postValue는 메인스레드의 메시지 큐에 메시지(새로들어온 값에 대한)를 추가해서 메시지 큐 확인 시점에 Observer에게 업데이트를 알린다.
 
예를 들어보면, 대표적인 백그라운드 작업으로 DB작업이나, 네트워크 요청이 있다. 이런 작업은 메인스레드에서 실행하면 작업 수행중에 메인스레드의 업데이트가 멈추게 되므로 시스템이 에러를 뱉는다. 그래서 백그라운드에서 작업을 수행해야하는데 이걸 setValue로 하면 작업이 안끝났을 때 메인스레드에 접근해서 null값을 처리하게 될 수 있다.
DB를 섞어서 구성해본 코드블럭이다.

class MyViewModel : ViewModel() {
    private val _isLoading = MutableLiveData<Boolean>()
    val isLoading: LiveData<Boolean> = _isLoading

    fun loadData() {
        viewModelScope.launch {
            _isLoading.setValue(true) // 메인 스레드에서 setValue 사용
        	withContext(Dispatchers.IO){
            	val loadedData = loadFromDatabase() // 백그라운드 작업
            	_data.postValue(loadedData) // 백그라운드 스레드에서 postValue 사용
            }            
            _isLoading.postValue(false) // 메인 스레드에서 postValue 사용
        }
    }
}

viewModelScope가 메인스레드에 묶여있기 때문에 withContext로 백그라운드 작업을 처리해야된다.
withContext는 현재 실행중이던 코루틴을 suspend시키고 dispatcher를 바꿔서 처리한다. 그게 끝나야 마지막 줄에 있는 _isLoading값이 false로 바뀐다.

public val ViewModel.viewModelScope: CoroutineScope
    get() {
        val scope: CoroutineScope? = this.getTag(JOB_KEY)
        if (scope != null) {
            return scope
        }
        return setTagIfAbsent(
            JOB_KEY,
            CloseableCoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
        )
    }

withContext로 처리하지않으면 아래와 같은 예외 메시지를 보게 될 것이다.

java.lang.IllegalStateException: Cannot access database on the main thread since it may potentially lock the UI for a long period of time.

이걸 뷰에서 받을 때는 아래처럼 하면 된다.

viewModel.name.observe(this@MyActivity){ name->
	// name을 받아서 처리할 코드
}

이때 this@MyActivity가 하는 일은 lifecycle을 name이 알게 하는 것이다. MyActivity의 수명주기 안에서, name에 대한 LiveData값이 업데이트 되면, 람다로 지정해둔 Observer를 실행하는 코드로 앞에서 setValue, postValue, name.value = "" 가 일어나면 여기서 observe해서 람다 함수를 처리하게 된다. MyActivity가 여기서 observe할 라이프사이클의 주인이다. 이 컴포넌트가 STARTED(onStart와 onPause 사이), RESUMED(onResume이 불린상태) 상태일 때만 observer(여기서는 람다함수)에 값을 전달한다. DESTROYED일때는 당연히 observer에게 값을 넘기지 않는다. onPause가 불려있는 상태도 활성상태가 아니기 때문에 observer에게 접근하지않는다.
 
이런 방식은 컴포넌트가 활성화된 상태에서만 값에 접근할 수 있기 때문에 불필요한 업데이트나, 메모리 누수를 예방할 수 있다. Fragment라면 viewLifecycleOwner를 lifecycleOwner로 지정해주면 된다. 활성상태가 아니면 메모리에서 내려간다. lifecycleOwner가 없는 observer를 observeForever - removeObserver로 사용할 수 있는데, 이러면 수동으로 제거해주기 전까지 항상 활성상태이기 때문에 관리에 주의해야된다.
 
대다수의 경우 onCreate(컴포넌트), onViewCreated(Fragment라면)에서 observer를 설정해주는게 좋다.

# 왜 쓸까?

이 부분은 공식문서에 적혀있는 걸 그대로 가져왔다. 글에서 얘기 안한부분만 내용을 남겨놨으니 필요하면 링크를 통해 확인하자

• UI와 데이터 상태의 일치 보장
  • LiveData는 기본 데이터가 변경될 때 Observer객체에 알린다(이번 글에서는 람다로 정의했다). 이렇게 하면 앱 데이터가 변경될 때마다 Observer가 대신 UI를 업데이트하므로 개발자가 업데이트할 필요가 없다.
• 메모리 누수 없음
• 중지된 활동으로 인한 비정상 종료 없음
• 수명 주기를 더 이상 수동으로 처리하지 않음
• 최신 데이터 유지
  • 수명 주기가 비활성화(onPause)되면 다시 활성화(onResume)될 때 최신 데이터를 수신한다. 예를 들어 백그라운드에 있었던 활동은 포그라운드로 돌아온 직후 최신 데이터를 받는다.
• 적절한 구성 변경
  • 기기 회전과 같은 구성 변경으로 인해 활동 또는 프래그먼트가 다시 생성되면 사용 가능한 최신 데이터를 즉시 받게 된다.
• 리소스 공유
  • 앱에서 시스템 서비스를 공유할 수 있도록 싱글톤 패턴을 사용하는 LiveData객체를 확장하여 시스템 서비스를 래핑할 수 있다. LiveData객체가 시스템 서비스에 한 번 연결되면 리소스가 필요한 모든 Observer가 해당 객체를 볼 수 있게된다. 
    
    

LivaData확장하기

LiveData 개요  |  Android 개발자  |  Android Developers

 

Why does viewModelScope.launch run on the main thread by default

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^