
며칠전 갑자기 테스트 중인 앱이 원인을 알 수 없는 오류가 잔뜩 발생했다. 정식 출시는 한참 전이었는데 안드로이드 기기에서의 업데이트는 왜 이제서야 자동 업데이트가 진행된걸까. 절대로 내가 게을러서 이제서야 알게 된게 아니다. 진짜다. 일단 공식 문서부터 훑어봤다.

안드로이드 개발을 한지 벌써 수년이 지났지만, 오랫동안 묵혀둿던 버킷 리스트를 드디어 실천하게 되었다. 의외로 오래 걸리지 않았고, 그리고 예상외로 재미있었고, 결과적으로는아무튼 간에, 만 이틀 동안에 걸쳐 진행한 과정에 대한 기록을 남겨보려 한다.시간은 아주 사소한

한동안 여러가지 핑계로 실무에서 주먹구구로 도입해서 사용하던 기술을 다시 재정비하며, 기본 프레임워크로 구축해두기 위해 포스팅과 함께 달려보자. (이렇게 채찍질해야 끝까지 하지...)일단 큰 틀에서 목표를 설정해보자.android 개발을 위한 기본 프레임워크를 구축한다

이전 포스팅에 이어 진행해보자.구글은 공식 문서를 통해 안드로이드 앱에 클린 아키텍처 철학을 녹여낸 'Modern Android Architecture (MAA)'를 권장하고 있다.아래와 같이 크게 세가지로 분류한다.UI 레이어 (Presentation Layer)도메

nowinandroid 의 프로젝트 구성에 대해 분석을 시작해보자.처음 안드로이드 클린 아키텍처에 대해 알게 되었을 때는 분명, 크게 3가지 모듈로 분리되었다고 했다.presentationmodaindata헌데 nowinandroid 는 그렇게 단순하지 않았다. 심지어

이제 실제 개발을 진행해보자.첫 포스팅에서 언급한대로 기본 프레임워크에 간단한 데모 기능을 넣고자 한다.MVVM 패턴 ( 가능하다면 MVI 패턴 도입 고려 )ComposeHiltCoroutine & FlowRoomTest Code ( Junit, Kotest, Espr
안드로이드 11에서 12로 업데이트가 자동적으로 진행되던 시기에, 새로 투입된 프로젝트의 심각한 이슈가 발생했었다. MPAndroidChart 를 사용해서, 차트 16개를 동시에 그리는 화면에서 화면 처리 속도가 현저히 떨어지는 현상이 발생했다. 11버전과 비교했을

4편에서는 build-logic 모듈을 생성하고, AGP(Android Gradle Plugin)와 Kotlin 플러그인 의존성을 build.gradle.kts에 compileOnly로 연결하는 것까지 마쳤다. 솔직히 그때까지는 "여기에 뭔가를 작성하면 되는구나" 정도

5편에서 Convention Plugin 3개를 만들고 각 모듈에 id() 방식으로 적용했다. 빌드도 통과했고, "오, 됐다!" 싶었는데 코드를 다시 들여다보니 뭔가 완전히 정리된 느낌이 아니었다.구체적으로 두 가지가 눈에 걸렸다.app/build.gradle.kts에
6편까지 Convention Plugin 만들고, 빌드 설정 정리하고, boilerplate 제거하고... 솔직히 그동안 "그래서 앱이 뭘 만드는 건데?"라는 질문을 계속 미뤄왔다. 이번 편에서 드디어 그 답을 공개하고, 클린 아키텍처의 핵심인 Domain 레이어 설계

7편에서 FaceDetectionRepository 인터페이스를 선언했다. Flow<List<DetectedFace>>를 내보내고, startDetection()과 stopDetection()을 제공하는 계약서. 근데 그 계약서를 이행하는 주체가 아직 없었다

Domain 레이어를 만들고, Data 레이어를 만들고, 나름 뿌듯했다.그런데 잠깐 멈추고 생각해보니 문제가 보였다.ObserveFaceDetectionUseCase는 FaceDetectionRepository를 필요로 한다.FaceDetectionRepositoryI