전체 글 썸네일형 리스트형 Flow 2주차 3차 스터디 Processing the latest value까지 Flow context Flow 생성자가 어떻게 생겨먹었든 간에 이것이 수집되는 블록의 코루틴 Context를 따른다(변경 방법이야 있겠지만) 그래서 이러한 특성을 context preservation(컨텍스트 보존) 이라고 부른다고 한다. 이에 대한 예시를 들어주는데 fun simple(): Flow = flow { log("Started simple flow") for (i in 1..3) { emit(i) } } fun main() = runBlocking { simple().collect { value -> log("Collected $value") } } //결과 //[main @coroutine#1] Started simple flow //[main @coroutine#1] Collec.. 더보기 Flow 2주차 2차 스터디 Flows are sequential 까지 Flows Are Cold Flow가 cold stream 임을 설명한다. 우리는 Cold Stream 이 무엇인지 선행학습을 했으니 그냥 키워드만 들어도 어떤것인지 알 수 있었다. 결론적으로 공식문서에서는 Lazy하게 값을 뽑아온다는것을 설명하고있다. Flow cancellation basics Flow는 general cooperative cancellation of coroutines를 따른다고 하는데 직역하면 코루틴의 협력적 취소이다. Coroutine의 취소되는 메커니즘은 생각보다 간단하지는 않다. -> 많은 내부적인 동작원리들을 알아야한다. 만약 코루틴의 cancelleation이 익숙치 않다면 이글을 보고오자 만약 글을 보고와서 예제를 살펴본다면 그냥 당연한소리 하면서 와닿을것이다 Flow .. 더보기 Flow 2주차 2차 스터디 부록 Cancellation and timeouts(코루틴 cancel) Cancellation and timeouts flow를 공부하다 눈을 떠보니 여기와서 이부분을 학습하고있었다. flow의 cancel을 알려면 coroutine의 cancel을 알아야했다.-> coroutine의 cancel 에 관한 내용이다 각설하고 내용을 살펴보자 별것 아닌것처럼 보이지만 취소가 가능하다는것 자체가 굉장히 강력한 기능중 하나이다. (코틀린 코루틴 책 초반부에 잘 나와있다.) 일반적으로 비동기 처리를 할때 콜백, 쓰레드 같은 것들을 사용하면 비동기처리 작업을 도중에 취소하기 어렵거나 취소할수 없다. 이제 코루틴의 Cancellation 과 timeouts 에 대해 알아보자 -> 링크 요약본이다. Cancelling coroutine execution 일반적으로 우리가 job객체를 통해.. 더보기 Flow 2주차 1차 스터디 flows 까지 Asynchronous Flow 공식문서 정리 이 글은Flow 공식문서를 정리한 글입니다. -> 학습을 위해 사용한다면 공식문서를 옆에 띄워놓고 목차와 함께 봐주세요 Representing Multiple Value 일반적으로 비동기처리 할때 suspend funtion을 이용해서 single value 를 얻어오는데 사용했다. 하지만 일반적으로 Stream 개념을 사용해서 여러 값을 전달 받을수 있는 Reactive Programming(Ex: RxJava)과 같은 기능을 Kotlin 에서는 Flow를 통해서 사용할 수 있다. Stream Hot Stream, Cold Stream 개념에 대해서 학습했을때 말했듯이 stream은 데이터를 나타내는 하나의 형태라고 볼 수 있다. 이런 stream 이라는 .. 더보기 Flow 1차 스터디(Hot vs Cold, shared vs state) 기본 용어정리 Cold flow vs Hot flow (이해해야하는 기본개념 🚨) cold, hot은 flow 뿐만 아니라 RX 등등 Stream개념이 사용되는 곳에서 통용된다. 위키피디아에서 찾은 Stream 의 정의는 이러하다 컴퓨터 처리 환경에서 스트림(stream)은 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 수많은 방식에서 쓰인다. 이런식으로 개발에서 일반적으로 쓰이는 데이터의 형태를 정의한것이다. 이러한 스트림을 특징에 맞춰서 크게 두 분류로 나눈것이 Cold Hot 인것이다. 분류기준 데이터의 생성위치 리시버의 수 (multiCast, UniCast) 데이터 방출 시점(Laziness) cold 스트림 내부에서 데이터 생성 Cold stream 인 flow는 Fl.. 더보기 리플렉션으로 DI를 만들어보자 2 부제 자동 DI를 위한 여정이였던것 -> 테스트 편의성만 남음 자 이번 여정도 고난이다. 사실 2편에서는 안드로이드 컴포넌트 생명주기관련 특화기능 테스트 편의성을 위한 처리 힐트의 좋은 부분 뽑아오기(어노테이션을 좀 활용해야할듯 -> 미션임) 창의적인 추가기능 서비스로케이터와 DI에 대한 고찰 이런 주제에 대해서 전부 다루려 했다. 하지만 이중 2번과만 다루게 될것 같다. 왜냐하면 2번만 너무 빡셌기 때문이다. -> 미션 제출날 까지 씨름중 (사실 4번 창의적인 추가기능에 대한 내용이있지만 시간에 쫓겨서 학습을 마무리하지 못하여 당장 블로그 글은 작성하지 못할것같다. 언젠간 작성해야지 키워드는 진정한 자동 DI를 위한여정 Dalvik도 나오고 classLoader 등 첨보는것 투성이의 내용이다.) 일단 .. 더보기 리플렉션으로 DI를 만들어보자 DI 진하게 맛봐볼래? 우아한테크코스의 꽃인 레벨4의 첫 주제는 "DI툴을 직접 만들어보라"였다. 이를 통해 라이브러리가 전지전능한 존재가 아니라 직접 구현해 볼 수 있는 것임을 느끼고 겸사겸사 DI도 진하게 학습하는것이 목표였다. 또한 DI는 개발 전반에 제일 중요한 개념 중 하나이고 안드로이드 진영만해도 Dagger,Hilt(Dagger 기반이지만), Koin, Kodein??(사실 글쓴다고 자료조사 하면서 첨봄) 등등 라이브러리가 정말 많다. 만약 자동 의존성 주입 라이브러리를 손수 빚어본다면 본질을 파악할 수 있으므로 어느 툴을 쓰던 강력하게 사용할수 있으니 바퀴를 한번 만들어보라였다. 사실 취준을 해야겠다고 생각했던 나에게 너무나도 달콤한 주제라서 그냥 넘어갈수가 없어서 글을 쓰게되었다. 들어가.. 더보기 오류처리의 시작은 의미있는 로그와 그것을 부릅뜨고 관찰하는 개발자이다 꼼꼼한 오류처리 달성하셨나요? 우테코에서 진행한 Trip Draw 프로젝트의 제1 목표로 삼은것이 꼼꼼한 오류처리였다. 물론 원래도 오류처리를 좋아하지만 이번에는 혼신을 다해서 진짜 기존까지 했던 기술들을 총동원하자는 목표가 있었다. 물론 우테코 특성상 레벨 3가 끝난 2023.08.22 시점에 Crashlytics 를 통한 모니터링 환경 구축(추가 작업 필요), sealed class 로 경우의 수를 나눈 callAdpater, callAdapter를 거쳐나온 코드의 보일러 플레이트를 제거하며 default handler 를 제공할 수 있는 util 함수 process 밖에 적용하지 못했다.(그래도 process 를 직접 손으로 빚어가며 만든 예쁜 내새끼라 맘에든다.) 그래서 이번 프로젝트의 오류처리에.. 더보기 이전 1 2 3 4 5 6 ··· 16 다음
