이번 글에서는 LifecycleScope를 소개해본다. 다만 제목 그대로 간단히 알아보려 하는데 이전 글에서 알아본 ViewModelScope와 비슷하기 때문이다. LifecycleScope의 lifecycle 알아보기생명주기는 생각보다 심플하다. Lifecycle owner가 살아있는 동안 해당 스코프도 살아있게 된다. 상황에 따라 Activity, Fragment 등이 될 수 있다. 해당 owner가 destroy될 때 LifecycleScope에서 실행된 모든 코루틴은 cancel된다. 가장 대표적인 destroy 상황은 화면 회전에 의한 Activity destroy이다. 이렇게 되면 특정 작업을 수행하다가도 cancel되어버리는 상황이 발생하기에이런 경우, ViewModelScope를 사용하는..
이번에는 드디어 이전 예제들에서 사용해왔던 viewModelScope에 대해 알아보도록 하자. ViewModelScope LifecycleviewModelScope는 ViewModel의 lifecycle과 연관되어 있다. 다르게 말하면 viewModelScope에서 시작된 코루틴은 ViewModel이 살아있는 경우 계속 실행된다. 당연히 ViewModel onCleared 메소드가 호출되는 시점에viewModelScope에서 시작된 코루틴은 모두 cancel된다. ViewModelScope 구현 살펴보기이 스코프는 ViewModel이 clear될 때 자동으로 cancel된다는위의 lifecycle 설명에서 말했던 부분이 보인다. Dispatcher 확인하기MainCoroutineDispatcher.imm..
이번 글에서는 구조적 동시성(Structured Concurrency)의 특징을 정리해본다. 1. 모든 코루틴은 제한된 수명이 있는 위치에서 시작되어야 한다.가장 대표적인 예로 Activity가 될 수 있다. RxJava에서는 특정 시점에서 disposable을 모아 처리해야 하는데컴파일러는 개발자가 처리하는 코드를 작성하지 않아도 경고하지 않는다. 이렇게 clear 혹은 cancel의 과정이 없다면OOM(Out Of Memory) 에러 혹은 앱 크래시가 발생할 수 있을 것이다. 반면에 코루틴을 사용할 때 예시로 사용했던 코드를 보면 viewModelScope가 있다. 이 스코프는 ViewModel 수명에 엮여있다. 따라서 ViewModel이 수명에 따라 clear될 때,viewModelScope에서 실..
저번 글에서 예고했던 대로 메인 스레드에서 했던 무거운 작업을 이제 다른 스레드에서 작업시켜보자.(이전 글 확인하기) 이전 동작 이해하기아까 첨부한 링크에서의 이전 글을 보면우리는 viewModelScope를 사용해 CPU 연산이 무거운 작업을 메인 스레드에서 실행했다. 그렇게 수초간 메인 스레드가 blocking되었고, 다른 UI는 반응할 수 없었다. 그리고 우리가 실행했던 viewModelScope의 Context를 확인하는 방법이 하나 있다.fun performCalculationOnMain(factorial: Int) { viewModelScope.launch { println("Coroutine Context: $coroutineContext") var result = BigInt..
이번에는 CoroutineContext는 대체 무엇인지 알아보자. 그리고 간단히 CoroutineScope 구조까지 살펴보도록 하겠다. viewModelScope로 찾아보기viewModelScope는 CoroutineScope라는 인터페이스를 상속받아 만들어진 녀석이다. 그리고 CoroutineScope 인터페이스를 확인해보자.보다시피 CoroutineContext를 가지고 있는 걸 볼 수 있다. 그리고 다시 한 번 CoroutineContext가 무엇인지 들어가보자.문서 최상단을 읽어보면 CoroutineContext는 여러 Context Element를 포함하고 있다는 사실을 알 수 있다. 여기서 가장 중요한 Element에는 바로 Dispatcher, Job, ExceptionHandler, Nam..
오늘은 코루틴을 메인 스레드에서 실행해보고 그 결과에 대해 생각해보는 시간을 가져보았다. 어떤 작업을 시킬까이번에는 단순한 연산을 시킬 예정이다. 아주 많이 팩토리얼(Factorial) 계산을 시켜보겠다. 코드를 보자.fun calculateFactorial(number: Int): BigInteger { var factorial = BigInteger.ONE for (i in 1 .. number) { factorial = factorial.multiply(BigInteger.valueOf(i.toLong())) } return factorial}여기서 BigInteger를 사용했는데 간단히 말하면Integer형으로 계산할 때 오버플로우가 날만한 범위까지도 계산이 가능한 클래스이..
이번 글에서는 저번 Coroutine retry 로직을 구현했던 것을 고차함수로 추출해내는 작업을 해볼 예정이다. Step1. 초안 작성하기fun retry(numberOfRetries: Int, block: () -> Unit) { repeat(numberOfRetries) { try { block() } catch (e: Exception) { e.printStackTrace() } } block()}초안을 작성해보면 위와 같은 코드가 된다. 얼핏 보기엔 문제가 없을 것 같지만, 파라미터 전달될 함수 리턴 타입을 알 수 없기에 Unit 하나로 제한해버리면 안된다. 이럴 때 생각나는 녀석이 하나 있는데 바로 제네릭(Generic)이..
