최데브는 오늘도 프로그래밍을 한다.

둘다 비슷하게 쓰인다. 마치 LiveData 와 비슷한 점이 많은데 분명 써보면 차이점은 있다. 난 이 차이점에 대해서 명확하게 설명하지 못했던 사람이고 이 글은 그걸 설명해보려고 적는 글이다. 둘다 데이터 스트림에서 hot 흐름을 가지는데 hot흐름 cold 흐름에 대해서는 코루틴은 아니지만 Rx 를 다루면서 말했었으니 아래 링크를 참고하길 바란다. https://choi-dev.tistory.com/138 RxJava - Hot Observable , Cold Observable 이전에 쓴 글(아래 링크 참고) 에서 뒷쪽에 https://choi-dev.tistory.com/107?category=972011 RxJava - Observable을 제외한 다른 생산자들 전 포스팅에서는 Observabl..

Databinding 에 대해서 알아보자. 프로젝트에서 쓰고는 있었지만 글로 정리해본 기억은 없는 것 같아서 정리하는 시간을 가지려 한다. databinding 을 사용하면 xml 파일에 data를 연결해서 activity에서 view를 따로 정의하지 않고도 xml에 연결해둔 곳으로 data를 전달하게 할 수 있는 장점이 있다. 불필요한 코드가 줄어들고 MVVM 패턴에서 쓰기에 잘 어울려서 함께 쓰는 경우가 많다. 일단 databinding 을 사용하려면 app 수준의 Build.gradle 수정이 필요하다. android { ... dataBinding { enabled = true } } //그리고 위쪽에 plugin 에도 apply plugin: 'kotlin-kapt' 라고 추가해주자. 기본 설정..

최근 코루틴 flow 에 대한 관심이 많아졌다. rx보다 라이브러리 종속성이 없고 쓰는 방법또한 간편하다. Rxjava도 충분히 좋은 라이브러리지만 러닝커브가 상대적으로 높고 너무나 많은 기능이 있어서 간단한 프로젝트를 할때는 오히려 과할수도 있다. 언제나 편하게 개발하고 싶은 극한의 효율을 추구하는 게으른 개발자인 나는 flow 를 이용해서 MVVM 이벤트를 제대로 관리하는 방법에 대해 공부해볼까 한다. 전에 flow에 대한 포스팅을 간단하게 한적이 있었는데 그 방식을 그대로 mvvm에 적용해도 사실 작동하는데는 큰 문제가 없다. 하지만 깊게 파보면 비효율적이고 예상치 못한 문제에 대처를 못하는걸 알 수 있을 것이다. 그걸 중점으로 이번 포스팅을 적어보겠다. 해당 포스팅은 https://medium.c..

개발에 관심을 가지고 있는 사람이라면 클린 아키텍쳐라는 말을 한번 쯤 들어 봤을거라고 생각한다. 나도 개념에 대해서는 어럼풋이 알고 있었지만 흉내만 낼뿐 원칙을 완벽하게 지킨다거나 하지는 못했던 것 같다. 이참에 개념에 대해서도 확실하게 정리 해볼까한다. 클린 아키텍쳐는 뭘까? 날이 갈수록 다양해지는 기능과 많은 일을 담당하게 되는 프로그램은 복잡도가 높아질 수 밖에 없는 운명을 타고났다. 만들려면 어떤 방법으로든지 만들수는 있지만 우리는 유지 보수하기 쉽고 고품질의 코드를 원한다. 기능이 추가된다거나 내부 로직이 변하는 일이 생겼을때 처음부터 다 뜯어고치면서 만드는건 예상치 못한 문제를 발생시키고 노력 또한 많이 든다. 이런 문제들을 해결하고자 등장한 개념이 클린 아키텍쳐다. 그렇다. 클린 아키텍쳐는 ..

이론으로만 알고 있는것과 직접 써보는건 많이 차이가 난다. 간단한 깃허브 api 호출 예제로 flow를 사용해보자. 설명에 앞서 해당 예제는 MVVM 패턴으로 구성 되었다. hilt , retrofit2 등 라이브러리를 사용했지만 해당 라이브러리에 대한 사용법은 따로 적지 않겠다. 이해를 편하게 하기 위해 생성자 - 중간연산자 - 소비자 순서로 코드 설명을 진행하겠다. 먼저 생성자다. interface GitModel { suspend fun getRepos(owner: String) : List } interface RetroServiceInstance { @GET("users/{owner}/repos") suspend fun getRepos(@Path("owner") owner: String) :Li..

Coroutine 에 대해서는 몇번 포스팅 한 적이 있다. 오늘은 Coroutine 에 있는 Flow 라는 놈에 대해서 한번 적어볼까한다. 리액티브 프로그래밍을 지원하기 위해 탄생했는데 Rx에서 볼 수 있는 개념인 데이터스트림을 담당하고 있다. 리액티브 프로그래밍은 데이터가 변경 될 때 이벤트를 발생시켜서 데이터를 계속해서 전달받는 방식을 말하는데 기존의 명령형 프로그래밍과는 완전히 다른 느낌이다. 보통 여기서 데이터스트림이 나오는데 이는 데이터를 발행하는 발행자가 있고 발행자는 데이터의 소비자에게 지속적으로 데이터를 전달하는 흐름을 말한다. 본론으로 들어가서 Coroutine Flow 는 그럼 어떻게 되는데? 에 대해서 보자. 구성요소는 크게 3개로 나눠볼 수 있겠다. 1. 생산자 -> 데이터를 데이터..

Awiki라는 모바일 위키 작성 개인 프로젝트를 하면서 html 관련 라이브러리를 쓸 일이 있었는데 그때 라이브러리를 모듈로 받아와서 써본 경험이 있어서 대충 어떤 개념인지는 알겠지만 직접 멀티 모듈로 만들어 본 적이 없어서 이번 기회에 정리 해보려한다. 먼저 Multi Module 로 굳이 만드는 이유가 뭘까? 그냥 원래 만들던대로 app Module에 전부 넣어서 만들면 되는거 아닐까? 맞다 사실 그래도 문제는 없다. 하지만 그건 혼자 프로젝트를 할 때 이야기다. 준비가 되어있지 않은 상황에서 새로운 인원이 프로젝트에 투입되어 의존성 규칙을 잘 지키면서 구조화된 기능을 구현하기에는 어려 어려움을 겪게 될 것이다. 그리고 따라오는 오류는 덤일테고. 모듈은 간단히 소스파일과 빌드설정으로 구성된 모음인데 ..

이것도 Dev6 팀에서 안드로이드분이 알려주신거다.. 아직 이 분이 알려주신거에 대한 포스팅이 하나 더 있다 ㅎㅎㅎ 혼자서 생존하던 안드개발자에게 새로운 방안을 제시해주셔서 감사하게 생각하고 있다. 먼저 나는 프로젝트를 생성했을때 나오는 build.gradle 이 Groovy 방식으로 되어있다는 사실 조차도 몰랐다. 이걸 찾아보면서 알게 됐는데 Kotlin DSL 로 왜 바꿔야하는가 부터 설명하자면 컴파일 타임에 에러 확인 코드 탐색 자동 완성 구문 강조 IDE의 지원으로 향상된 편집환경 소스코드와 동일한 언어의 사용 의 장점이 있다고 한다. 하지만 장점만 있는건 이 세상에 없지. 단점도 존재한다. https://developer.android.com/studio/build/migrate-to-kts?h..

최근 개설한 개발팀 Dev6 에서 같이 안드로이드 개발을 하는 팀원분께서 2인이상이 개발하고 또 프로젝트의 단위가 커질 것 같으니 이런 방법들로 프로젝트를 관리하면 어떻겠냐고 말씀해주신게 여럿 있었다. 그 중 buildSrc 로 Dependency 를 관리하는 방법에 대해 먼저 정리 해볼까한다. 찾아보니까 다른 깃허브에서 이렇게 관리하는걸 본적이 있는데 이게 도대체 뭘까? 라고 생각하고 뭐라고 찾아야할지도 모르겠어서 그냥 넘어갔던 기억이 있는데 이번 기회에 한번 적용해볼까 한다. buildSrc 는 사실 의존성 관리를 좀 더 편하게 하고 가독성을 올리기 위해 사용하는것뿐 그게 다다. 하지만? 개발자에겐 그건 아주 중요하고 프로젝트에 참여하는 인원이 많을수록 그 중요도는 더욱 올라간다. 그럼 바로 어떻게 ..

코루틴을 사용하다보면 비동기적으로 동작하는 예를 들면 네트워크 작업 같은게 있다고 예를 들어보자. 간단한 코드부터 보자. class MainActivity : AppCompatActivity() { val TAG = "MainActivity" override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) GlobalScope.launch(Dispatchers.IO) { val time = measureTimeMillis { val answer1 = networkCall() val answer2 = networkCall2() Log.d(TAG,..