android Flow 알아보기

Flow 이해하기

스트림은 입력장치나 서버로부터 들어오는 입력 데이터 흐름을 읽어들이면서 출력 장치나 동영상 플레이어로 데이터 흐름을 내보내는 역할을 하는 객체이다.

 

코틀린의 플로우는 단일 값만 반환하는 suspend 함수와 달리 여러 값을  순차적으로 내보낼 수 있는 유형이다.

예를 들어 Flow를 사용하여 데이터 베이스에서 실시간 업데이트를 수신할 수 있다.

 

Flow는 코루틴을 기반으로 빌드되어 비동기적으로 계산할 수 있는 데이터 스트림의 개념이다.  이 때 내보내는 값을 동일한 유형이어야한다. Flow<Int> 의 경우 정수 값을 내보내는 흐름을 말한다.

 

[kotlin flows in practice 내용 정리] 

 

 

 

이 때에는 그래서 호수까지 가는 시간을 낭비하고 다른 곳에서 물을 찾아야한다.

이러한 실패를 여러 번 겪은 후 일종의 인프라를 만드는 게 낫다고 생각했다.

 

 

 

그래서 다음에 호수로 걸어갈 때 파이프를 설치했다.

이제 물이 필요할 때 호수가 마르지 않았다면 꼭지를 열기만 하면 물이 나온다.

 

 

이렇게 파이프를 설치하면 ,여러 소스의 데이터인 즉 물줄기를 합칠 수 있다.

이제 판쵸는 호수가 말랐는지 확인할 필요가 없다.

 

 

 

 

 

안드로이드 앱에서는 간단한 경로를 통해 필요한 데이터를 요청할 수 있다.

예를 들어 뷰가 시작되면 ViewModel에 데이터를 요청하고 ViewModel이 data layer에 데이터를 요청한다. suspend 함수를 사용하면 이 과정을 쉽게 처리할 수 있다.

하지만 한동안 그렇게 하면 판쵸와 마찬가지로 인프라에 투자하는 게 낫다는 걸 깨닫게 된다.

 

 

 

관을 설치하고나면 데이터 소스 업데이트가 자동으로 뷰에까지 전달된다. 더이상 호수로 걸어갈 필요가 없다.

 

이런 패턴을 사용하는 시스템을 Reactive : 반응형이라고 부른다. 관찰하는 쪽이 관찰 대상의 변화에 자동으로 반응하기 때문이다.

그리고 데이터는 한 방향으로 흐르게 하는 것이 좋다. 오류 발생 가능성도 줄어들기 때문이다.

 

그럼 데이터 베 이스는 원격 데이터 소스에  각 항목을 로드하라고 지시한다.

 

새로운 데이터를 가져오는 동안 뷰에서 로딩 중인 스피너를 표시하게 된다.

즉, 안되는 건 아니지만 버그가 발생하기 운 방법이다.

 

더 좋은 방법은 데이터를 한 방향으로 흐르게 하고 수도관 역할을 하는 인프라를 구현해서 데이터 스트림을 결합하고 변환하는 것이 좋다.

 

무언가 바뀌어서 수정이 필요한 경우 예를 들어 사용자가 로그아웃하면 관을 다시 설치할 수 있다.

이런 결합과 변환을 실행하려면 도구가 필요하다 ! 

이를 위해서 오늘 세션에서는  Kotlin Flow를 사용할 것이다.

 

---

 

Kotlin Flow<T> 

Flow는 물이 아니므로 어떤 유형이든 가능하다.

예를 들어 사용자 데이터나 UI 상태도 될 수 있다. 

 

용어 정의

 

생산자는 데이터를 Flow에 입력하고 소비자는 Flow에서 데이터를 수집한다.

 

 

android에서는 데이터 소스나 리포지토리가 전형적인 앱 데이터 생산자이다.

최종적으로 화면에 데이터를 표시하는 ui가 소비자 역할을 한다.

 

Creating Flows : Flow를 생성하는 방법

먼저 호수로 걸어가야한다 .대부분의 경우 플로 직접 만들 필요없다. 라이브러리와 코루틴에 Flow가 이미 결합되어 있다.

 

개발자는 데이터 생성방법을 몰라도 파이프에 연결하기만 하면 된다.

 

 

Room을 예로 들어보자

List<Codelab> 타입의  Flow를 노출하여 데이터베이스 변경 사항을 알린다. Room 라이브러리가 생산자 역할을 맡아서 

업데이트가 있을 때마다 쿼리 내용을 전송한다.

 

플로를 직접 만들어야할 때 옵션

- 플로 빌더

userMessageDatatSource에서 수시로 앱에서 온 메시지를 확인하려고 한다고 생각해보자.

 

메시지 목록 유형의 플로로 사용자 메시지를 노출할 수 있다. 이 때 flow를 만드려면 flow 빌더를 사용해야한다. flow는 코루친 컨텍스트에서 실행되기 때문에 flow 빌더는 suspend 함수를 호출할 수 있다.

 

 

내부에서 while(true) 루프로 반복하게 하고, 먼저 messageApi를 통해 메시지를 가져온다.

가져온 메시지를 emit 함수를 통해 노출시킨다. 이를 통해 컬렉터가 아이템을 받을 때까지 코루틴을 중단시킬 수 있다.

 

마지막으로 일정 시간 코루틴을 중단한다.

위 flow는 동일한 코루틴에서 연산을 순차적으로 진행하며 관찰자가 사라지고 아이템 수집이 중단되면 멈추게 된다.

 

flow 빌더에 전달된 suspend 블록은 생산자 블록이라고도 한다.

Collecting Flows 

Android에서 생산자와 소비자 간의 계층은 그 이후에 계층 요구 사항에 맞게 데이터 스트림을 수정할 수 있다.

플로를 변환하려면 중간 연산자를 사용한다.

 

 

latestMessage 스트림이 플로의 시작점이라고 하면  map 연산자를 이용해  데이터 소스에서 받은 원본 메시지를  다른 타입(여기서는 MessageUiModel)으로 변경할 수 있다.

 

각 연산자는 기능에 따라 데이터를 전송하는 새 플로를 생성한다.

스트림을 필터링하여 중요한 알림이 포함된 해당 메시지를 flow를 가져올 수 있다.

 

그러면 스트림에서 발생하는 오류는 어떻게 처리할까?

 

catch 연산자는 업스트림 flow에서 항목을 처리하는동안 발생할만한 에러를 찾는다.

upstram flow는 프로듀서 블록에서 생성한 flow이고  현재 연산자 전에 이 블록을 호출한다.

 

현재 연산자 이후에서 발생하는 모든 것을 downstream flow라고 한다.

Collecting Flows

일반적으로 flow 수집은 UI 계층에서 일어난다. 화면에 데이터를 표시할 위치이기 때문이다

우리 예시에서는 목록에 최신 메시지를 표시할 것이다. 그래야 판쵸가 현재 상황을 알 수 있기 때문이다.

terminal 연산자를 사용해서 값을 수신하기 시작해야한다.

스트림의 모든 값을 전송 즉시 가져오려면 collect를 사용한다.

 

collect는 새로운 값이 생길 때마다 호출되는 함수를 매개변수로 받는다.

이건 suspend 함수이므로 코루틴 내에서 실행되어야한다.

 

terminal 함수를 flow에 적용하면 필요에 따라 flow가 생성되고 값을 전송하기 시작한다.

반면, intermediate 연산자는 일련의 연산자만 설정하며 항목을 flow로 전송했을 때 간격을 두고 연산자를 실행한다.

 

userMessage에서 collect를 호출할 때마다 새 flow가 생성된다.

생산자 블록은 정해진 간격에 따라 api에서 메시지를 새로고침하기 시작한다.

 

코루틴 용어에서 이런 플로를 clod flow라고 한다.

필요에 따라 생성되고 관찰되는 중에만 데이터를 전송하기 때문이다

 

Flows in Android UI

Android UI에서 최적으로 flow를 수집하는 방법을 알아보자. 고려해야할 점은 두가지가 있다.

첫 번째는 앱이 백그라운드에 있을 때 리소스를 낭비하지 않아야한다.

두 번째는 구성 변경과 관련이 있다.

 

MessagesActivity에서 화면에 메시지 목록을 표시하려 한다고 생각해보자. 

얼마나 오래 flow에서 collecting을 해야할까?

 

UI가 적절히 동작하고, 화면에 UI가 표시되지 않을 때는 flow에서 수집을 중단해야한다.

물로 비유를 들어보면, 판쵸가 이를 닦거나 낮잠을 잘 때는 수도꼭지를 잠가야한다. 판쵸는 물을 낭비하면 안된다.

UI도 마찬가지로 화면에 정보를 표시하지 않을 때는 flow에서 수집해서는 안된다. 

 

여기에는 여러 옵션이 있는데 모든 옵션이 UI 수명 주기를 인식한다. 수명 주기 코루틴별 api나 LiveData를 사용할 수 있다.

 

asLiveData flow 연산자는 flow를 LiveData로 변환해서 UI가 화면에 표시되는 동안에만 항목을 관찰한다.

뷰 모델 클래스에서도 이런 변환이 가능하다.

 

ui에서는 평소처럼 LiveData를 소비한다.

 

UI 계층에서 flow를 수집할 때 repeatOnLifeCycle을 사용하는 것이 좋다.

 

이는 Lifecycle.State를 매개변수로 받는 suspend 함수이다.

이 api는 수명주기를 인식하며 수명 주기가 해당 상태에 도달하면 블록을 전달할 새 코루틴이 자동으로 시작된다.

그러면 수명 주기가 그 상태 아래로 떨어지면 진행 중인 코루틴이 취소된다. 블록 안쪽은 코루틴 컨텍스트이므로 collect를 호출할 수 있다.

repeatOnLifecycle은 suspend 함수이므로 코루틴에서 호출해야한다. 

 

액티비티 안에 있으므로 lifecycleScope로 시작할 수 있다.

 

수명주기가 초기화되면 이 함수를 호출하는 것이 좋다. 예를 들어 이 액티비티는 onCreate에서 호출한다.

repeatOnLifeCycle의 자동화 동작은 UI 수명 주기를 자동으로 고려한다.

특히 repeatOnLifeCycle을 호출하는 코루틴은 수명주기가 파괴될 때까지 실행을 다시 시작하지 않는다.

 

여러 flow에서 수집해야할 경우 repeatOnLifecycle에서 launch를 사용하여 여러 코루틴을 생성해야한다.

 

flowWithLifeCycle연산자는 수집할 플로가 하나뿐일 때 repeatOnLifecycle 대신 사용할 수 있다.

이 api는 수명주기가 대상 상태에서 들어가고 나갈 때 항목을 전송하고 기본 생산자를 취소한다.

 

 

액티비티의 수명주기를 생성 시점부터 알아보자. 사용자가 홈버튼을 전달하면 백그라운드로 전송되고 액티비티에서 onStop 신호를 받고, onStart가 호출되었을 때 앱을 다시 연다.

repeatOnLifecycle을 호출하면 UI가 화면에 표시되는 동안 flow 전송을 처리하고 앱이 백그라운드로 이동하면 수집이 취소된다.

 

안드로이드 UI에서 다른 방식으로 flow를 수집할 수도 있다.

lifecycleScope에서 시작한 코루틴에서 바로 수집할 수도 있다. 이런 방법을 사용해도 되지만 이런 방식의 수지븡ㄴ 위험하다.

flow에서 수집하고 UI 요소를 업데이트한다. 앱이 백그라운드에 있어도 마찬가지

 

화면에 ui가 표시되지 않을 때는 우리도 플로에서 수집하면 안된다.

 

lifecycleScope.launch에서 직접 수집하는 경우 액티비티가 백그라운드에 있을 도 계속 플로 업데이트를 받는다. 이는 낭비이고 위험하다.

앱이 백그라운드일 대 대화상자를 표시하면 충돌이 일어난다.

 

 

이 문제를 해결하려면 onStart에서 수동으로 수집을 시작하고 onStop에서 수집을 중단해야한다. 그리고 repeatOnLifecycle을 사용하면 모든 상용구 코드가 제거된다.

 

launchWhenStarted를 사용하면 lifecycleScope.launch보다 낫다.

앱이 백그라운드에 있을 때 flow 수집을 중단하기 때문이다.  그러나 이 방법은 flow 생선자를 계속 활성화시켜서 화면에 표시되지 않을 항목으로 메모리를 채울 수 있는 백그라운드에서 항목을 전달할 수도 있다.

 

UI에서 플로 생산자의 구현 방법을 알 수 없으므로 repeatOnLifecycle이나 flowWithLifecycle을 안전하게 사용하는 것이 좋다. UI가 백그라운드에 있을 때 항목을 수집하기 않고 플로 생산자를 살려둔다.

 

이렇게 앱이 백그라운드에 있을 때 플로 수집을 최적화할 경우 앱에서 구성 변경할 때의 몇 가지 요령을 알아보자

 

플로를 뷰에 노출하면 수명 주기가 서로 다른 두 요소 사이에 데이터를 전달해야한다는 걸 고려해야한다. 모든 수명 주기가 해당하는 건 아니다. 액티비티의 프래그먼트의 수명주기는 까다로울 수 있다. 

 

 

기기가 회전되었거나 구성 변경을 수신하면 모든 액티비티를 다시 시작하지만 ViewModel은 그렇지 않다.

 

즉, viewModel에서 모든 플로를 노출하는 건 아니다. 예를 들어 이런 콜드 플로가 있다.

콜드 플로는 처음으로 수집될 때마다 다시 시작하기 때문에 리포지토리는 한번 회전 후 다시 노출된다.

 

리포지토리가 뭐지 ?

 

 

 

우리에게는 버퍼가 필요하다. 데이터를 보관하고 있다가 여러 컬렉터 사이에 공유하면 된다. 재생성 횟수는 관계없다.

이런 목적으로 StateFlow가 생성되었다. 

 

StateFlow는 물로 비유하면 물탱크이다. 컬렉터가 없더라도 데이터를 보관한다. 일회성 수집이 아닐 수 있으므로 액티비티나 프래그먼트와 함께 사용하는 게 안전하다.

 

StateFlow의 여러 버전을 사용하고 필요할 때마다 값을 업데이트할 수 있다. 예를 들어 아래와 같이 코루틴에서 가능하다.

하지만 반응형이라고 하기는 어렵다.

 

판쵸는 게임을 개선하라고 말했을 것이다. 대신 플로를 StateFlow로 변환한다. 이렇게 하면 StateFlow가 업스트림 플로에서 모든 업데이트를 받아 최신 값을 저장한다. 컬렉터가 없거나 많을 수 있으므로 뷰모델에 사용하기에 좋다.

여러 유형의 flow가 있지만 StateFlow를 매우 정확하게 최적화할 수 있으므로 이를 권장한다.

 

플로를 StateFlow로 변환할 때 stateIn 연산자를 사용할 수 있다.

세 가지 매개변수를 받는데,initalValue는 StateFlow에 항상 값이 있어야하기 때문이다. 코루틴 범위는 공유가 시작되는 시점을 제어하는데 여기에 뷰모델의 범위를 사용할 수 있다.

 

마지막으로 started 매개변수에 대해 알아보기 위해 2가지 시나리오를 보자

 

첫째, 플로의 컬렉터인 액티비티가 일정 시간 파괴되었다가 다시 생성시키는 회전이다.

둘쨰, 홈으로 이동해서 앱을 백그라운드에 넣는다.

 

회전 시나리오에서는 최대한 빠르게 전환하려면 Flow를 다시 시작해서는 안된다.

그러나 홈으로 이동하는 경우  배터리와 다른 리소스를 아끼기 위해 모든 플로를 중단해야한다.

 

그러면 어떤 시나리오인지 탐지할 수 있나? 시간 초과를 사용한다.

StateFlow의 수집이 중단되었을 때 모든 업스트림 플로를 즉시 중단하는 건 아니다. 오히려 약 5초정도를 잠시 기다린다.

시간 초과전에 플로를 수집하면 업스트림 플로가 취소되지 않는다.

 

 

WhileSubscribed(5000)이 바로 그런 일을 한다.

 

이 표에는 앱이 백그라운드로 갔을 때 반응이 나와있다. 홈 버튼을 누르기 전에 뷰가 업데이트를 수신하고 StateFlow는 정상적으로 업스트림 플로를 생성한다. 이제 뷰가 중단되면 컬렉션이 즉시 종료된다.  

그러나 StateFlow는 구성 방법으로 인해 업스트림 플로를 중단하는데 5초가 걸린다. 제한 시간이 지났고 업스트림 플로는 취소된다. 

 

사용자가 앱을 다시 열 경우 자동으로 업스트림 플로가 다시 시작된다.  

그러나 회전 시나리오에서 뷰는 잠시만 중단된다. 어쨋든 5초이내이다. 

따라서 StateFlow는 절대 복원하지 않고 모든 업스트림 플로를 활성상태로 유지하며 아무일도 없었던 것처럼 사용자에게 회전 인스턴스를 보낸다.

 

즉 다시 말해 StateFlow를 사용하여 뷰모델에서 플로를 노출하거나 asLiveData를 사용해서 이와 동일한 작업을 실행하는 게 좋다.

 

Testing Flows

두 가지 시나리오가 있다.

첫 번째는 테스트 대상이 무엇이든 UUT가 플로를 받는다. 종속성을 가상 생산자로 교체하여 테스트하는 게 편리하다.

 

예를 들어 이 가상 리포지토리를 프로그래밍하여 각 테스트 사례에 필요한 걸 전송할 수 있다.

간단한 콜드 플로의 예를 들어보자. 테스트 자체는 테스트 아래 주제의 결과에 대한 어설션을 만든다. 이는 플로나 다른 게 될 수 있다. 

 

 

 

두번째는 UUT가 플로를 노출하고 이 값이나 값 스트림을 인증하고 싶다면 여러 가지 방법으로 수집할 수 있는데 

플로에서 first( ) 메서드를 호출하면 첫 항목을 수신하고 수집을 중단할 때까지 계 수집한다.

또한 take(5) 연산자로 toList terminal 연산자를 호출해 메시지를 5개만 수집한다. 

---

일반적인 list 출력을 suspend와 Flow로 차이 살펴보기 

기본 list 출력 함수 

fun main() {

    foo().forEach { value ->
        println(value)
    }

}

fun foo(): List<Int> = listOf(1, 2, 3)

 

suspend 함수로 변경

suspend fun foo(): List<Int> {
    delay(1000) // pretend we are doing something asynchronous here
    return listOf(1, 2, 3)
}

fun main() = runBlocking<Unit> {
    foo().forEach {
        value -> println(value)
    }
}

 

flow로 변경 

fun foo(): Flow<Int> = flow { // flow builder
    for (i in 1..3) {
        delay(100) // pretend we are doing something useful here
        emit(i) // emit next value
    }
}

fun main() = runBlocking<Unit> {

    // Collect the flow
    foo().collect {
        value -> println(value)
    }
}

 

코드로 알아보기

   val chargedMoneyFlow: Flow<Int> = dataStore.data
        .catch {
            exception -> if (exception is IOException) {
                emit(emptyPreferences())
        } else{
            throw exception
        }
        }
        .map { preferences ->
            preferences[PreferencesKeys.CHARGED_MONEY] ?: 0 }

 

 이 코드는 datastore과 coroutine을 사용하여 잔액 값을 가져오는 비동기적인 작업을 수행한다.

chargedMoneyFlow는 데이터 저장소에서 가져온 정수값을 표현하는 Flow이다.

 

동작을 정리해보면 

datStore.data를 통해 dataStore에 값을 읽어오는데 사용하는 flow를 생성한다.

 

어떻게 dataStore.data를 통해 flow를 생성할 수 있는지 알고싶다면? 

dataStore.data를 살펴보면 반환값이 Flow<T>이다. 

dataStore.data는 DataStore에서 비동기적으로 데이터를 가져오는데 사용되고 반환된데이터는 Flow로 표현된다

따라서 이 Flow를 통해 데이터 저장소의 변화를 비동기적으로 감지하고 처리할 수 있다. 

 

 

 

map을 사용하여 값을 Preferences.CHARGED_MONEY 키에 해당하는 값으로 변환한다.

 이 때 만약 이 키에 대응하는 값이 없다면 기본값으로 0을 사용한다.

 .map { preferences ->
            preferences[PreferencesKeys.CHARGED_MONEY] ?: 0 }

 

.map 연산자를 사용하는 이유는?

데이터 변환때문이다.

이 부분은 chargedMoneyFlow의 데이터를 변환하여 최종적으로 사용하고자 하는 형태로 만들어주는 역할을 한다. 

chargedMoneyFlow는 datastore에서 가져온 설정 값에 대한 flow이다. 

 

preferences는 chargedMoneyFlow에서 방출된 데이터 즉, datastore에서 가져온 값을 나타내면,

이 값은 PreferencesKeys.CHARGED_MONEY에 해당하는 value를 가지고 있다. 

 

1️⃣ preferences[PreferencesKeys.CHARGED_MONEY] 를 통해서 charged_money 키에 해당하는 값을 가져온다.

2️⃣ 해당하는 키가 없다면 0을 사용한다. 

 

dataStore.data를 사용하여 datastore에서 데이터를 읽어오는 로직이다. 

추가로 .catch를 통해 예외를 처리하고 있고, IOException인 경우에는 emptyPreferences( )를 emit 해주었다.

 

 

 

공부한 자료 

https://philosopher-chan.tistory.com/1546

Coroutine flow

https://developer.android.com/kotlin/flow?hl=ko

Android의 Kotlin 흐름  |  Android Developers