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

데브식스 프로젝트를 진행하다가 동료 안드로이드 개발자분께서 view 에서만 에러처리를 하지말고 네트워크쪽 로직에서도 에러처리를 하자고 말씀하셨다. 이게 맞는 접근법인지는 모르겠지만 그말을 듣고 가만 생각해보니 view에서 발생하는 에러가 아니라 통신에서부터 에러가 생겨서 발생하는 문제를 view에서만 처리하는건 예상치 못한 상황이 발생할 수 있기도 했고 view까지 오지 않아도 사전에 에러로 인한 예기치 못한 상황을 방지 할 수 있기도 했다. 그러면서 정말 괜찮다고 느낀 방법을 소개해주셨는데 그 부분에 대해서 정리를 해보려한다. 전체적인 프로젝트 코드를 다 소개하지는 못하고 일부분만 가져와서 아이디어를 공유하는 정도로 이 글은 작성될 예정이다. 먼저 우리는 RemoteSource 라는 개념을 가져와서 쓰..

이전 포스팅에서는 BindingAdapter에 대해서 알아봤다. InverseBindingAdapter 에 대해 언급을 했었는데 이번엔 InverseBindingAdapter 에 대해 집중해서 포스팅한다. InverseBindingAdapter 은 양방향 데이터 결합을 지원한다. 갑자기 이게 뭔소린가 싶다면 기존의 BindingAdapter 와 차이가 뭔지를 봐보자. 기존의 Binding 은 Model To View InverseBinding 은 View To Model 이다. 그러나 InverseBinding 은 Binding의 역할도 포함하고 있기에 양방향이라고 볼 수 있다. 쉽게 말하면 Binding 은 Model 있는 값을 View 로 보내주기만 한다면 InverseBinding 은 view에서 ..

Databinding 관련 작업을 하다보면 BindingAdapter에 대해서 자주 보게 된다. 오늘은 BindingAdapter를 작업 할 일이 있었는데 생각이 난김에 정리를 해보려고 한다. 먼저 BindingAdapter는 뭐고 왜 쓰는걸까? BindingAdapter 는 view 의 속성을 커스텀하게 추가시킬 수 있는 것이다. 일단 잡다하게 BindingAdapter 을 적용하기 위해서 필요한 선작업들은 알고 있다는 상황으로 가정하고 적겠다. 먼저 viewmodel 부터 보자. @HiltViewModel class FeedViewModel @Inject constructor (private val feedUsecase: FeedReposUseCase): ViewModel() { private val..

코투린의 비동기 실행을 하다보면 코루틴을 시작할때 launch 를 사용하거나 async 를 사용하거나 하는데 동작은 비슷하게 하지만 둘의 차이가 있다. launch - 새로운 코루틴을 시작한다. 결과값을 전달하지 않을 때 사용한다. async - 결과를 리턴할 수 있는 코루틴을 시작할때만 사용한다. 둘의 차이는 리턴값이 있냐 없냐의 차이다. 뭘 사용하는가에 따라 메소드나 완료 대기에 대한 대응이 달라진다. 이 이야기를 한건 launch 을 사용하면 job 을 반환하고 async 를 사용하면 Deferred 를 반환하기 때문이다. 그럼 다시 제목의 내용으로 돌아와서 job 과 Deferred 에 대해 알아보자. 사실은 job 과 Deferred 는 비슷하다. 그도 그럴게 Deferred 는 job을 확장하..

코루틴은 일시중단 일단 일시중단이 가능하다. launch 든 async 든 내부에 일시중단을 하는 동작이 있다면 코루틴은 잠시 멈춘다. 코루틴은 일을 협력(?) 한다는 느낌을 내포하고 있는데 여러개의 코루틴이 존재 할 수 있고 어떤 스레드에서 동작할지 명시 해준다면 각각의 코루틴을 잠시 멈췄다가 다른 코루틴을 실행시키고 그리고 일이 마무리되면 다른 코루틴과 같이 결과를 전달하거나 서로 순서를 옮겨다니며 동작한다. 예를 들면 val job3 = CoroutineScope(Dispahchers.IO).async{ //2. IO 스레드에서 작업3을 수행 (1..100).sortedByDescending{it} //5. 작업3이 완료된다. } val job1 = CoroutineScope(Dispahchers...

둘다 비슷하게 쓰인다. 마치 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..