현욱 정리장

Flow

cold/hot, stateflow, sharedflow, statein.sharedin, repeatOnLifecycle / collectLatest Flow를 처음 배울 때 우리는 대게 '코루틴으로 만드는 RxJava' 정도로 이해합니다.연산자를 체이닝하고, 마지막에 collect 를 붙이면 값이 흘러나옵니다. - 왜 Flow를 collect 할 때마다 API를 다시 호출하는가?- StateFlow와 SharedFlow는 뭐가 다른가, 언제 어느 걸 쓰는가- WhileSubscribed(5000) 의 5초는 대체 무슨 5초인가- Fragment에서 lifecycleScope.launch { flow.collect {} } ' 는 왜 위험한가 이 질문들의 답은 전부 하나의 축에서 갈림 (스트림이 Co..

1. 예외 전파 2. launch vs async 3. SupervisorJob4. CoroutineExceptionHandler5. CancellationException 1. 예외는 위로, 취소는 아래로모든 것의 출발점은 structured concurrency 코루틴은 부모-자식 Job 계층을 이룸.이 계층에서 예외와 취소는 반대 방향으로 흐름 자식 A에서 예외가 발생하면 1. 예외가 부모로 전파된다 (위로)2. 부모는 자기 자신을 취소한다3. 부모가 취소되면서 형제 B도 취소된다 (아래로)4. 다시 부모의 부모로 예외가 전파된다. 즉 하나가 실패하면 형제가 함께 죽는 것이 기본 동작입니다.이게 쿠로틴 예외 처리의 첫 번째 원칙이고, 나머지 모든 도구 (SupervisorJob, supervi..

1. 원칙코루틴은 반드시 부모-자식 계층 구조 안에서 생명주기가 관리되어야 한다 라는 설계 원칙 핵심 규칙 3가지1. 부모는 모든 자식이 끝날 때까지 기다린다 - 부모 코루틴은 자식이 완료되기 전에 완료될 수 없음2. 부모가 취소되면 자식도 전부 취소된다 - 취소가 계층을 따라 아래로 전파3. 자식이 실패하면 부모도 실패한다 - 예외가 계층을 따라 위로 전파 (SupervisorJob으로 차단 가능) 이 구조 덕분에 누수되는 코루틴 (leaked coroutine)이 원천적으로 불가능해집니다.스레드 시절에 'fire-and-forget' 후 잊혀진 백그라운드 작업 문제를 언어 차원에서 해결한것 2. 매커니즘 Job 계층 val parent = launch { // 부모 Job 생성 ..

핵심 원칙 * 객체를 this로 받고 + 람다 결과 반환 = run, with* 객체를 this로 받고 + 객체 자신 반환 = apply* 객체를 it으로 받고 + 람다 결과 반환 = let* 객체를 it으로 받고 + 객체 자신 반환 = also - this (수신 객체): 객체의 멤버를 직접 호출 -> 객체를 설정 / 구성하는 느낌- it (인자) : 객체에 이름을 붙여 참조 -> 객체를 사용 / 변환 하는 느낌- 람다 결과 반환: 변환 결과가 필요할 때 - 객체 자신 반환: 체이닝을 이어가거나 부수 효과 (로깅 등)을 끼워넣을 때 with 만 확장 함수가 아니라, 일반 함수 (with(obj) {} ) 차이가 있음 Scope function은 결국 람다 함수를 받는것,객체를 람다 안으로 넘겨 줄 ..

1. 클래스 위임 상속보다 합성: Kotlin은 언어 차원에서 지원상속 -> 부모 클래스를 물려받는다합성 -> 다른 객체를 멤버로 품고 그 기능을 사용 // 상속: MyLogger는 ConsoleLogger"이다" class MyLogger : ConsoleLogger() // 합성: MyLogger는 logger를 "가진다" class MyLogger(private val logger: ConsoleLogger) { fun log(msg: String) = logger.log(msg) // 품고 있는 객체에 일을 시킴 }상속 문제? 1. 부모의 내부 구현에 강결합 부모를 고치면 자식 전부가 영향을 받음 -> 자식 30개면..

variance란 Dog가 Animal의 하위 타입 일 때 , List가 List의 하위 타입이 되느냐에 문제 out T : T를 생산만 한다 (반환) -> 꺼내기만 하는 자판기in T: T를 소비만 한다 -> 넣기만 하는 쓰레기통T : 생산도, 소비도 한다 -> 넣고 빼는 상자 핵심 규칙 // out — 생산자. T를 반환 위치에만 쓸 수 있음 interface Producer { fun produce(): T // OK // fun consume(t: T) // 컴파일 에러! } // in — 소비자. T를 파라미터 위치에만 쓸 수 있음 interface Consumer { fun consume(t: T) // OK // fu..

enum class는 고정된 값의 집합 = 상수 data class는 데이터를 담는 그릇 = 값 객체sealed class 는 제한된 타입의 계층 = 상태/분기 enum class = 값이 고정되어 있을 때 enum class PaymentMethod { BANK_TRANSFER, E_WALLET, CASH;}인스턴스가 컴파일 타임에 확정, 런타임에 추가 불가각 값은 싱글톤 (하나의 인스턴스만 존재)values(), valueOf(), entries 제공 -> values()는 모든 값을 Array로 반환-> valuesOf()는 문자열로 값을 찾음 (없으면 예외)-> entires는 values()에 list버전 (성능 더 좋음) 각 값에 프로퍼티/메서드는 가능하지만 같은 형태만 가능 -..

inline 함수 * 컴파일 시 함수 호출 부에 함수 본문이 복사 (인라이닝) 된다. * 람다를 파라미터로 받을 때 Function 객체 생성 + 호출 오버헤드 제거* 고차 함수의 성능 비용을 0으로 만든다* stdlib의 let, run, apply, also, with 모두 inline인 이유 인라인이 없으면 코틀린에서 람다를 넘길 경우 내부적으로 Java 객체가 매번 만들어진다. let, apply, also 같은 것들이 inline 인 이유는 이것들을 매일 수백 번 호출하는데, 매번 객체가 만들어지면 앱 성능에 영향을 주니까 inline으로 만들어서 비용을 완전히 없앤 것 reified 제네릭 타입 실체화 일반 제네릭은 컴파일 후 타입이 지워진다. (type erasure). inline + r..

좋은 아키텍쳐는 몇 가지 조건을 갖춰야 한다고 생각.. 1. 결정과 실행이 분리되어야 함'무엇을 해야 하는가', '어떻게 실행하는가'가 섞이면, 변경 할 때 영향 범위를 예측할 수 없게 됨실제로 올해 인출 플로우 리팩토링에서 이 문제를 겪었는데,기존에는 각 화면이 서버에서 내려온 인증/검증 플래그를 직접 읽고 다음 화면을 스스로 결정하고 있었음.동일한 분기 로직이 여러 화면에 중복되어 있어서,세그먼트를 하나 추가 할 때마다 여러 화면을 동시에 수정해야 했고,QA에서 누락된 조건이 발견되는 일도 있었음.그래서 '다음 단계가 무엇인가' 라는 결정은 Domain UseCase로,실제 화면 이동은 NavigationHelper로 분리했음 화면은 UseCase가 내린 Destination만 받아서 이동하는 구조로..

보호되어 있는 글입니다.