오늘 이야기 하는 Tips 은 거의 활용되기 뻘팁이 될 확률이 높고, 그냥 "이렇게도 가능하다" 정도로만 이해해주시면 감사합니다. 해당 프로젝트 주소는 하단에 적어두었습니다. 일반적으로 Domain 은 Pure Java/Kotlin 으로 하는 경우가 많습니다. 따라서 Paging3 를 사용하다보면 도메인에 PagingSource, PagingData 등의 자료구조를 활용하지 못하기 때문에 고민에 빠지게 됩니다. 거의 대부분 아티클을 보면 // alternatively - without Android dependencies for tests implementation "androidx.paging:paging-common:$paging_version" 를 추가해서 사용해라 라는 이야기가 많습니다. 하지만 ..
이전에 추천 받은 기억이 있어서, 서점에서 그냥 지나칠수 없어서 앞부분만 읽어 봤다가," 경력, 그 견딜 수 없는 무거움" 에 공감이 가서 구매 했습니다. 약 200 페이지로 길지 않은 책 입니다. 기억에 남는 문장이 있다면, 두려워도 중요하다면 시도해봐야 한다.(실패할 각오를 필요하다) 어떤 일을 진행할 때, 의식 해야 한다(어제의 나보다 나아지기를 희망한다) 애자일은 불확실한 상황에 대한 접근법이니, 애자일을 시작할 때, 무엇을 도입해야 할지, 먼저 해야할지 명확하게 안다는 것 자체가 모순적일 수 있다.(따라서 동료들과 주변을 탐색하며 더 나은 방법을 찾아가는 모습이 DFS + BFS 을 합친 알고리즘의 모습이 스쳐갔다) 실수는 예방하는 것이 아니라, 관리하는 것이다. 소위 높은 평가 받는 개발자는 ..
이따금식 LifecycleOnwer 를 사용하기 위해, View 의 확장함수인 findViewTreeLifecycleOwner 를 사용하는 경우가 있습니다. 간혹 아무 생각 없이 사용하다보면 findViewTreeLifecycleOwner 가 null 을 반환하는 경우가 있습니다. RecyclerView 에서 사용하는 케이스는 https://pluu.github.io/blog/android/2021/09/20/lifecycleowner/ 에서 잘 설명하고 있어서 해당 글을 참고 해도 좋을 것 같습니다. RecyclerView 에서는 doOnAttach 함수를 사용하여, Lifecycle 을 얻어올 수 있지만, doOnAttach 로 해결되지 않는 케이스들도 존재 합니다. 먼저 ViewTreeLifecyc..
TL;DR "네트워크 응답을 Result 와 같은 클래스로 래핑하면 실수할 확률이 높습니다." 상태 코드가 필요하면 awaitResponse 를 이용하고 아니라면 await 를 사용 합시다 해당 게시물은 실무에 도움이 되는 지식은 없고, 단순히 호기심으로 진행되었습니다. 회사에서 레거시 코드를 건드리는 중에, 신기한 일을 경험하였습니다. runCatching { apiCall.await() } .onSuccess { // ... } .onFailure { // ... } 와 같은 코드에서 네트워크 요청이 실패하여 400 이상 상태 코드들이 내려오는데 모두 onSuccess 를 타고 있었습니다. 문제가 있던 apiCall.await() 의 자료형은 아래와 같았습니다. apiCall 이 RxJava Sing..
히스토리를 찾아보니, Compose 를 현업에 처음 사용한 것이 작년 11월이네요. 주기적으로 밀도 있게 쓰지는 않았지만, 시간 될 때마다 조금식 기여하여 회사 프로젝트에 20 개 넘는 화면을 Compose 로 구성하였고, QDSC(Qanda-design-system-compose) Sample App 을 만들기도 하였습니다. QDSC 는 아직 완성 단계는 아니지만, 거의 마무리 단계인듯 보이네요. 앞으로 적을 글은 매우 주관적인 내용들을 담고 있습니다. 장점1 주관적으로 생각하는 Compose 의 가장 큰 장점을 하나만 선택하자면 "직관적" 이라고 말할 수 있을 것 같습니다. 선언형이기 때문에 컴포넌트(Box, Column, Row, Chip, Lazy* ...) 의 특성을 이해 한 뒤에 이를 나열하기..
시간이 꽤나 지나서 잊기 전에 적어두는 2가지 면접 이야기. 시장에서의 나의 가치를 판단하는데는 면접 만큼 좋은 것이 없다고 생각합니다. 따라서 이직의사가 적어도 주기적으로 면접을 보라는 글들도 많이 접하였는데, 저도 동의합니다. 1. 지인의 추천을 받아 좋은 기회로 뤼xx 회사에 면접을 봤습니다. 서류 -> 1차 면접 -> 2차 면접으로 진행이 되었고, 추천을 받아 서류 이후 코딩 테스트는 생략이 되었습니다. 1 차 면접에서는 실무 면접을 봤고, 함께 일 할 수 있는 동료인지를 가장 중요하게 판단하는 것으로 느껴졌습니다. 면접인데도, 질문 답변 과정이나, 커뮤니케이션 하는 과정에서 상당히 즐겁고 편안하게 저의 생각 & 경험을 이야기 하는 시간을 가졌습니다. (면접관분들이 저를 잘 맞춰주신 것 같습니다)..
1부 기초 좋은 코드? * No silver bullet (trade-off) * 협업 가능한 코드 * 서로의 기준을 충족 하는 코드 당시 개발자의 지식(외부 + 내부 도움)내의 최선의 선택이였고, 비즈니스를 잘 수행했다면 좋은 코드고 이를 개선하는 코드를 작성하는 것은 멋진 경험이라고 생각합니다. 신기능도 즐겁지만, 당시에 코드 작성자가 어떤 생각이였고, 이를 추적하는 과정도 즐거움의 과정 코드명세? 문제를 정의하고(Input), 해결(Output) 하기 위한 명세 프로그래머는 정제된 기능 명세를 아키텍처와 코드로 번역 개인적으로 조엘 온 소프트웨어 책의 손 쉬운 기능 명세 작성법이 큰 도움이 되는 것 같음. 코딩의 시간이 길어질수록 비용은 오름(개발자에 따라 선형적, 지수적일 수도 있음) => 따라서..
해당 글은 주관적인 의견이 많이 들어가고, 잘못된 내용이 있을 수도 있습니다 :) 코드는 아래 링크로 첨부해두겠습니다 이번 주제는 서버에서 etag, last-modified 등의 캐시 처리를 지원해주지 않을 때, 안드로이드에서 간단히 처리할 수 있는 방법에 대해 알아보려고 합니다. *서버에서 캐시 처리를 위한 정보(Cache-Control) 를 잘 내려준다면, OkHttp 를 이용하여 CacheDirectory 만 생성해주면 알아서 처리해주기 때문에 해당 포스트를 읽지 않아도 됩니다. 먼저 안드로이드에서 캐시하면 가장 바로 떠오르는 것중 하나가 Room, sqlite, realm 과 같은 로컬 데이터 베이스를 사용하는 것 입니다. 해당 방식의 처리도 좋지만, Table 과 Entity 를 정의해야 한다..
스레드 사이에서 공유 상태는 어떤식으로 관리 될 수 있을까요 ? 먼저 문제가 있는 코드를 한번 보고, 어떤식으로 해결할 수 있을지 확인해보겠습니다. 해당 코드를 돌려보면? 성공 할 때도 있지만, 실패하는 경우도 있습니다. while (balance.getBalance() > 0) 잔고가 0 보다 큰 경우에만 동작할 것이라 예상했지만, 우리의 예상을 깨고 마이너스 잔고가 보입니다.(여담이지만 코드만 보고 동시성 문제가 있을것이라 판단하는 것도 꽤 어려운 일이라고 생각합니다. 경우에 따라서는 제대로 동작하는 코드 처럼 보일경우도 있으니까요) 가시성, 원자성 문제를 모두 해결해야, 동시성(MultiThreading)으로 부터 자유로워질 수 있습니다. 해결에 주목적을 가지고 있기 때문에, 간단하게 짚고만 넘어가..
