Dev. Oratorium : For Mobile, By Mobile

Coroutine 사용방법

1. Dispatcher(=작업 종류) 결정
2. ispatcher로 CoroutineScope 생성
3. 3. CoroutineScope의 launch/async에 실행할 코드 블록을 넘김

CoroutineScope

- 코루틴의 실행 범위, 코루틴 블록을 제어할 수 있는 단위

1. GlobalScope
   • CoroutineScope의 한 종류. 최초 접근시 만들어짐.
   • 앱이 동작하는 동안 별도의 생명 주기를 관리하지 않고 사용할 수 있음.
   • 이는 안드로이드 앱이 처음 시작부터 종료 할때까지 하나의 CoroutineContext 안에서 동작하도록 할 수 있음.
   • 다만, Job을 컨트롤하기에 접합하지 않음에 주의 해야함
2. Lifecycle-Aware Coroutine Scopes: 
   • Android Lifecycle용(KTX 종속)
     
     1.  ViewModelScope
        • androidx.lifecycle ViewModelKt .class public val ViewModel.viewModelScope: CoroutineScope CoroutineScope tied to this ViewModel. This scope will be canceled when ViewModel will be cleared, i.e ViewModel.onCleared is called This scope is bound to Dispatchers.Main.immediate
        • ViewModelScope는 앱의 각 ViewModel을 대상으로 정의됩니다. 이 범위에서 시작된 모든 코루틴은 ViewModel이 삭제되면 자동으로 취소됩니다. 코루틴은 ViewModel이 활성 상태인 경우에만 실행해야 할 작업이 있을 때 유용합니다. 예를 들어 레이아웃의 일부 데이터를 계산한다면 작업의 범위를 ViewModel로 지정하여 ViewModel을 삭제하면 리소스를 소모하지 않도록 작업이 자동으로 취소됩니다.
     2. LifecycleScope
        • LifecycleScope는 각 Lifecycle 객체에서 정의됩니다. 이 범위에서 시작된 코루틴은 Lifecycle이 끝날 때 취소됩니다. lifecycle.coroutineScope 또는 lifecycleOwner.lifecycleScope 속성을 통해 Lifecycle의 CoroutineScope에 액세스할 수 있습니다.

Reference

thdev.tech/kotlin/2019/04/05/Init-Coroutines/

developer.android.com/topic/libraries/architecture/coroutines#lifecyclescope

zion830.tistory.com/56

Kotlin의 Delegates 사용

1. Observable
   • 갱신 거부 불가능, 데이터를 넣어주는대로 갱신함
2. vetoable
   • 갱신 거부 가능
   • boolean을 반환: true-데이터 갱신/false-데이터 비갱신

Reference

medium.com/androiddevelopers/built-in-delegates-4811947e781f

medium.com/@yeongpal/kotlin-%EC%9D%98-delegate%EA%B8%B0%EB%8A%A5-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-b358211a756

Android Studio에서 corotine을 쓸때

Update

In the recent releases of Kotlin Coroutines, I notice if a method doesn't contain any coroutines code(like launch, async, etc), the compiler complains This inspection reports a suspend modifier as redundant if no other suspend functions are called inside. So I assume that suspend should be only used when it's a must.

Update2

An advice from Google

Reference

stackoverflow.com/questions/54554753/when-to-use-kotlin-suspend-keyword

1. 기존 legacy 프로젝트를 많이 유지보수 하는 관계로, 네트워크 클래스가 async task로 구현된걸 발견..

사실 절망에 빠져있는 상황인데...

Async Task를 대체할 방안은 찾아보니 대체로 두가지였다.

1) RxJava, RxKotlin 등 비동기처리를 Rx기반으로 변경

2) Kotlin의 Coroutine 이용

2. 그러나 현재 legacy 프로젝트는 전부 Java이고, 신규메뉴만 Kotlin도 아니고 핵심 네트워크 클래스를 Kotlin으로 변경하면 연결된 Java코드들에서도 무난하게 다 돌아가는지... 순전히 경험미숙으로 걱정 중

- 기존 레거시 프로젝트: Java기반, HttpUrlConnection+Async Task를 사용

- 토이 프로젝트: Kotlin 기반, Retrofit 사용 

찾아보니 Retrofit은 AsyncTask를 사용하지 않는 관계로, 굳이 해당 부분을 전부 수정할 필요는 없는 듯 하다.

"Retrofit의 장점은 속도, 편의성, 가독성이 있다. 가장 비교하기 좋은 Okhttp는 사용시 대개 Asynctask를 통해 비동기로 실행하게 되는데 Asynctask가 성능상 느리다는 이슈가 있었다. Retrofit에서는 Asynctask를 사용하지 않고 자체적인 비동기 실행과 스레드 관리를 통해 속도를 훨씬 빠르게 끌어올렸다. 약 3~10배 차이가 난다고 한다."

"앱-서버 통신을 Okhttp 라이브러리로 AsyncTask를 사용하여 구현했다고 할 수도 있다. 하지만 AsyncTask 로 서버와 통신을 구현하는 것은 어렵고 시간이 많이 들 뿐만 아니라(비동기 처리 코드를 개발자가 하나하나 작성), AsyncTask 자체가 안드로이드에서 deprecated 되었다. 그래서 이제 AsyncTask 를 사용하여 서버 통신을 구현하는 것은 좋은 생각이 아니다. 

그대신, retrofit 을 사용하는 것이 가독성도 좋고 훨씬 간편하고 쉽고, 빠르기 때문에 retrofit 을 사용한다."

==> 그렇다면 레거시 프로젝트는 네트워크 클래스 부분을 Retrofit으로 변경하고, 그 외에 AsyncTask를 사용하는 부분은 RxJava로 수정하면 급한 불은 끌 수 있지 않을까 싶다.

Reference

woovictory.github.io/2019/01/03/Android-What-is-retrofit/

salix97.tistory.com/204