Hilt는 타입으로 의존성을 구분한다.의존성이 Hilt 컴포넌트에 바인딩될때, 의존성을 식별할 수 있는 식별자로 class의 패키지명을 포함하고 있는 canonical name을 식별자로 쓰고있다. 어떤 의존성이 컴포넌트에 바인딩이 되고 바인딩된 의존성을 클라이언트가 컴포넌트에 요청할 때 정확하게 구분하고 수행할 수 있는 이유는 어노테이션이 마킹된 위치에 해당 의존성 타입이 명시되어 있기 때문이다.  그렇다면 동일한 타입이 두 번 바인딩될 경우는 어떻게 될까?Hilt입장에서는 클라이언트가 의존성을 요청할 때 어떤 의존성을 주입을 해야할지 모른다. 컴파일 타입에 object 그래프를 점검하고 중복 바인딩 문제가 있는 경우 컴파일을 중단한다. 그리고 DuplicateBindings 이라는 중복 바인딩 에러가..

0. Dagger HiltAndroid Framework는 각종 컴포넌트 간 의존성이 상당히 강하다. 클래스간 의존도를 낮추기 위해서는 의존성 주입(Dependency Injection)을 사용할 수 있다. 객체 생성 시 클래스 간 의존성이 생기게 되는데 이 때, 객체의 생성을 클래스 내부에서 하는 것이 아니라 클래스 외부에서 객체를 생성하여 주입시키는 의존성 주입의 디자인 패턴을 이용할 수 있는 것이다.  이전에는 개인이나 회사별로 수동 또는 별도 의존성 주입 솔루션을 직접 만들어 쓰기도 하였다. Java나 Kotlin 진영에서 널리 쓰이고 있는 라이브러리를 쓰기도 했다.  Android Framework는 자바 언어를 지원하는 것부터 시작했기 때문에 Guice를 사용하기도 했고 구글에서 안드로이드 전..

0. Annotation Hilt는 annotation 기반으로 돌아간다. annotation의 특징은 소스코드를 해치지 않으면서 컴파일러에게 부가정보를 제공하기 위함이다. Hilt annotation을 사용하여 부가정보를 제공컴파일 타임에 의존성 그래프에 이상이 없는지 확인생성된 소스코드를 기반으로 동작하므로 리플렉션을 사용하지 않아도 되어 퍼포먼스가 떨어질 일이 없음1.  코틀린에서의 Hilt Annotation Processingdependencies { implementation 'com.google.dagger:hilt-android:2.48.1' kapt 'com.google.dagger:hilt-compiler:2.48.1'}kapt { correctErrorTypes tr..

- 24년 1월 1일의 검단산에서 회고란 모름지기 한 해를 돌아보며 연말에 쓰기 마련인데 1월 말이 되서야 글을 써본다. 기록하고 싶은 순간들과 큰 이벤트들이 있었기 때문에 기록으로 남기고자 한다. 이직 2023년 가장 큰 키워드는 역시 이직이다. 2년 반 남짓몸 담았던 회사를 떠나 다른 둥지를 틀게 되었다. 얼어붙은 IT 업계의 채용시장과 연이은 동료들의 퇴사, 독서실을 끊어 퇴근 후 새벽까지 남아 스터디를 하던 시간까지, 견뎌내야 했던 시간들도 있었지만 모든 일에는 끝이 있기 마련이니 스스로를 잘 다독이며 인내의 시간을 보냈던 것 같다. 연말이 되기 전 많은 축하를 받으며 귀한 결실을 맺게 되었다. 이직을 결심하며 회사를 정하는 기준을 구체화 해본 계기도 되었다. 나에게는 뚜렷한 2가지의 이유가 있..

0. FCM 푸쉬 알림이란 서버에서 모바일 장치에 보내는 알림 또는 메세지이다. 직접 구현한 서버에서 사용자 장치로 알림을 보내기 위해서는 앱과 서버의 연결을 지속적으로 유지해야 한다. 하지만 FCM(Firebase Cloud Messaging)은 구글 클라우드 서버를 이용해 앱에서 서버에 연결하지 않아도 기기의 내부 연결을 통해 메세지를 보낼 수 있다. Firebase console 에서도 FCM token 을 넣어 푸쉬 메세지를 보낼 수 있지만, 서버와 연결한다면 이러한 과정을 거치게 된다. 1. FCM Message Type when your app in background, the method onMessageReceived never invoked FCM에서 보내는 메세지의 타입에 따라 앱의 포..

기존 안드로이드 OS에서는 유저의 동의없이 푸쉬 알림을 띄울 수 있었지만, 안드로이드 13 부터는 다른 permission 들처럼 알람 권한이 새로 생겼다. 알림 권한은 유저 기기의 OS가 13인 경우 모두 해당 된다. 즉 대응을 하지 않으면 유저들이 알림을 받지 못한다. 1. Delcare The Permission POST_NOTIFICATIONS (Notification Permission) 은 Target SDK API 33 이상부터 추가 가능 2. Scenario Target SDK API 32 이하의 앱이 Android 13 디바이스에 설치되면 Notification Channel을 등록할 때 자동으로 Notification 권한 요청 팝업이 나옴 Target SDK API 33 이상의 앱..

0. 결심 당시 한꺼번에 장애를 겪으며 '어떻게 대응해야 효율적으로 할 수 있지? 이걸 어떻게 모두에게 전파할 수 있지? 그리고 이해관계자들에게는 어떻게 전파해야하지?' 라는 생각을 했었다. 하이브리드앱이라는 새로운 플랫폼이 생기면서 얽히게 되는 이해관계자들은 더 많아질 수밖에 없었다. 애초에 '이 에러가 나도 확인해야하는 에러였어?' 라며 자신이 이해관계자인지도 불분명한 경우도 있었다. 앱에서 디버깅이 불가하여 웹 개발자에게 요청해야하는 순간들도 있었으며 '이게 왜 앱에서 에러가 나는거야?'라며 이해도가 서로 일치하지 않는 경우가 있었다. 그리고 이렇게 취합된 문제정의와 해결 과정들을 운영팀과 소통하면서 전달하는 과정도 순탄치 않았다. 커뮤니케이션 코스트를 줄이면서도 운영팀은 문제 정의를 빠르게하여 서..

이번 글은 1년 전 하이브리드앱을 출시하며 겪은 앱 안정화의 과정에서 느꼈던 것들을 얘기하고자 한다. 하이브리드앱이기에 웹과 앱의 통신과정에서 발생한 에러들도 많았다. 안드로이드 개발자는 나 혼자뿐이었으므로 하이브리드앱의 설계를 처음부터 끝까지 혼자서 담당했고 디버깅하는 과정에서도 웹 개발자와도 소통을 많이 했었어야 했다. 소프트웨어 개발을 하는 곳이라면 어느 곳에서든 장애가 없을 수 없다. 하지만 체감상 거의 대부분은 상대적으로 빠르게 해결할 수 있는 것들이다. 큰 장애는 1년에 몇 번정도 발생한다던데(by 개발팀장님) 그 일들을 한꺼번에 겪으면서 '앱 안정화'란 Task를 직접 만들고 프로덕트 팀 내 에러 대응 프로세스 정립까지 한 이야기를 써보고자한다. 1편은 당시 내가 짧은시간에 한꺼번에 겪었던 ..

구독시점과 발행시점에 주의해서 Hot & Cold Observable에 대해 살펴보자. 1. Cold Observable Cold Observable은 구독시에 데이터 발행을 시작한다. 옵저버가 구독할 때마다 새로운 데이터 스트림을 시작하고 처음부터 데이터를 방출한다. 이것은 옵저버가 Cold Observable을 구독할 때마다 독립적인 데이터 스트림을 생성하고 발행하는 것을 의미한다. 아래의 예시는 interval 연산자를 이용하여 1초마다 아이템을 발행하는 Cold Observable 이다. 아래는 두 개의 구독자가 있다. 첫 번째 구독자가 구독을 시작하고 3초후 두 번째 구독자가 구독을 시작한다. val ob = Observable.interval(1, TimeUnit.SECONDS) ob.subs..

RxJava2부터는 다양한 타입의 Observable을 사용할 수 있다. Observable과 Single은 RxJava 1버전부터 존재했고 Maybe와 Completable은 그 이후에 등장했다. 때문에 현재 Rx 공식문서에도 Observable과 Single 타입만 설명이 있다. 필자도 사실상 Observable 원형 그대로 먼저 실무에서 사용한 것이 아니라 이렇게 변형된 타입들부터 익힌 경우이다. Single, Maybe Completable 세 가지에 대해 다뤄보고자 한다. Observable can emit multiple items Single, Maybe and Completable are one or no emission of items. Single it always either emit..