1. MVI란?Model, View, Intent의 앞글자를 따와 만든 아키텍쳐 패턴을 일컫는다.GUI 프로그래밍에서 주로 언급되는 패턴이며 세 가지의 키워드로 나누는 것도 일종의 관심사의 분리를 위한 것이다. 특히 UI와 연관된 것에 한정하여 관심사를 분리한 것이다.Model: UI의 상태(State)View: View, Compose 등Intent: 의도, 사용자의 액션 또는 이벤트.안드로이드에서의 Intent와는 다른 개념의 Intent이다.이 Intent는 어떠한 의도를 나타내며, 사용자가 화면을 클릭하여 데이터를 로딩하거나 다른 화면으로 이동하는 그러한 의도를 말한다. 2. MVI는 순수함수그래서 MVI의 가장 큰 특징은 순수함수 사이클 형태를 갖는다는 것이다.view(model(intent()..

클린 아키텍처의 개요1. 경계(boundary) 만들기저수준 모듈: 상세한 기능 구현, 변경이 잦을만한 요소들의 집합 (예: 문자열 암호화 이후, 로컬 및 원격 DB에 저장) 고수준 모듈: 핵심적인 비즈니스 로직, 추상적으로 서술 (예: 문자열 저장) 2. 클린 아키텍처란? 소프트웨어 구조를 설계할 때 지켜야 할 원칙과 방법을 정의한 개념 2-1. 의존성 규칙 의존성은 반드시 바깥에서 안쪽으로. 소스코드의 의존성 방향이 동심원 안쪽으로 향하고 있다.내부의 원을 Entities라고 가정하면, 내부의 원은 외부에 대해서 몰라야 한다.외부의 원은 내부의 것을 의존하기 때문에 내부를 알 수 있다. 예를 들어, UI의 변경(외부의 원)으로 인해서 이 Entities(내부의 원)을 변경하면 안된다. 2-2. 엔티티..

아키텍처 설계와 원칙1. 아키텍처란(Architecture)?소프트웨어에서 말하는 아키텍처란, 해당 소프트웨어를 구현한 시스템의 형태를 말하는 것이다. 그러한 형태는 개발, 배포, 운영, 유지보수를 쉽게 할 수 있도록 도와준다. 목표는 개발을 할때 투입되는 비용을 최소화하는 것이다. 아키텍쳐는 스파게티 코드처럼 코드가 엉망이 되어가는 것을 방지하는 규약이자 약속이다.일부 개발자들은 지저분하더라도 우선 개발을 빨리 하고 아키텍쳐는 나중에 하자고 한다. 하지만 엉망이 된 코드를 다시 정리하는데 걸리는 시간은 처음부터 깔끔하게 만드는 것보다 배로 시간이 걸릴 것이다. 개발하는 사람 본인의 더 중요한 가치가 시간이라면 아키텍처가 더 나은 선택이 될 것이다. 2. 설계 원칙 (SOLID)단일 책임 원칙 (Sing..

Custom 컴포넌트 만들기커스텀 컴포넌트란, 사용자가 정의한 컴포넌트로 표준 컴포넌트 하위에 위치시킬 수 있다 1. Custom 컴포넌트 정의하기@DefineComponent(parent = SingletonComponent::class)interface MyCustomComponent 인터페이스를 선언하고 @DefineCompoent 애노테이션을 사용한다. 2. Custom 컴포넌트 빌더 정의하기@DefineComponent.Builderinterface MyCustomComponentBuilder { fun setFoo(foo: Foo): MyCustomComponentBuilder fun build(): MyCustomComponent} 컴포넌트를 만들기 위한 컴포넌트 빌더를 만든다.D..

ViewModel안드로이드에서 뷰모델을 사용하는 이유는 애플리케이션에서 상태를 유지하기 위함이다. 상태(State)라는 것은 간단하게 말하자면 시스템에 정보가 기억되는 것을 의미한다. 안드로이드는 PC 운영체제와 비교하여 상대적으로 낮은 사양에서도 애플리케이션이 원활히 실행될 수 있도록 설계된다. 그렇기에 필요없다 판단되는 것들은 전부 종료하여 메모리를 확보한다. 이 과정에서 액티비티와 같은 안드로이드 컴포넌트들이 수명주기에 따라 파괴되기도 한다. 대표적으로 구성변경이 발생할때다. 예) 화면 회전, 화면 크기 변경, 라이트/다크 모드 변경 등등 화면 회전의 경우, 액티비티가 파괴되고 다시 onCreate되며 재생성된다. 액티비티 인스턴스 내 레퍼런스되고 있던 모든 객체들이 GC 대상이 된다. 예외적으로 ..

Qualifier 활용Hilt는 타입으로 의존성을 구분한다. 타입이 명시되어있기 때문에 타입으로 구분하여 의존성을 바인딩하고 주입하는 것이 가능하다. 그런데 동일한 타입이 두 번 바인딩 된다면?  Hilt 입장에선 Client에서 의존성을 요청할때 어떤 바인딩을 주입해야할지 애매해질 것이다  그렇기에 컴파일 타임에 중복 바인딩 에러를 띄우게 된다. 이러한 양상의 오류가 발생할 경우 중복된 바인딩 요소를 제거하면 간단히 해결된다. 그러나 중복바인딩을 하고 싶을 수도 있다. 이 해결방법의 핵심이 @Qualifier 애노테이션이다. 1. 커스텀 Qualifier 선언Qualifier를 애노테이션으로 갖는 새로운 애노테이션을 선언해야한다. 실제 프로젝트 진행 시 필요하다면 상황에 맞게 Qualifier를 선어하..

AndroidEntryPoint의 이해Dagger에서 말하는 Component는 의존성을 관리하는 컨테이너를 말한다. SubComponent는 어떤 컴포넌트의 하위에 속하는 컴포넌트를 일컫는다. SubComponent의 하위에 있는 또다른 컴포넌트 또한 SubComponent이다. 그렇기에 엄밀히 따지면 Hilt에서 말하는 Component는 Singleton Component 하나 뿐이다. 나머지는 전부 SubComponent이다. Dagger에서는 여러 컴포넌트를 정의하고 인스턴스화 하는게 가능하지만, Hilt에서는 표준 컴포넌트를 사용하고 그것들이 계층을 이루고 있으므로 엄밀히 따지면 Singleton Component만 컴포넌트라고 할 수 있다는 것이다. Hilt에서 SubComponent를 인스..

기존 Dagger와는 다르게 표준 컴포넌트를 제공하기 때문에 개발자가 따로 커스텀 컴포넌트를 만들 필요는 없다.물론 커스텀 컴포넌트를 정의하는 방법은 있으나 일반적이진 않으며 권장하지 않는 방법이다. Dagger와 달리 표준 컴포넌트 조차 소스 코드내에서 인스턴스화 하지 않는다. 컴포넌트 계층 이미지에서 볼 수 있는 각 컴포넌트 명칭 위의 스코프 애노테이션은 해당 컴포넌트의 생명주기에 대한 의존성 범위를 지정할때 사용되는 애노테이션이다. 컴포넌트간 화살표 방향은 하위 컴포넌트를 가르키는 것이다. 일반적으로 하위 컴포넌트는 상위 컴포넌트의 바인딩에 접근할 수 있다. 하지만 역방향으로는 불가능하다. 예를들어, FragmentComponent에서 ActivityComponent의 의존성으로 접근하는 것은 가능..

애노테이션은 여러가지 속성을 가질 수 있다. 정의된 애노테이션은 클래스에 마킹할 수 있다. 뿐만아니라 필드 메서드 파라미터 등에서도 선택적으로 사용가능하다. 안드로이드에서 많이 사용해본 표준 애노테이션으로 @Override @Non-null 등이 있을 것이다. Hilt의 주요 Annotation의 종류@HiltAndroidApp@AndroidEntryPoint@Module@InstallIn@HiltViewModel 애노테이션의 특징JDK 1.5부터 추가자바(또는 코틀린) 소스코드에 추가하는 메타데이터컴파일러에게 부가정보 제공클래스, 필드, 메서드 및 기타 요소에 선택적으로 선언 가능런타임에서도 참조 가능애노테이션의 목적은 소스코드를 해치지 않으면서 컴파일러에게 부가정보를 제공하기 위해 추가되었다. Ann..

import android.app.Applicationimport dagger.hilt.android.HiltAndroidApp@HiltAndroidAppclass App: Application() {} Hilt의 출발점은 @HiltAndroidApp 애노테이션으로부터 시작된다.이 애노테이션은 애플리케이션 클래스에 마킹하고 빌드하면 기본적인 설정이 끝난다.빌드 이후, 싱글톤 컴포넌트(Container)가 자동적으로 생성된다.  이 싱글톤 컴포넌트에 의존성을 추가할 수 있다.생성자 바인드, 모듈의 프로바이드 어노테이션을 통한 바인딩 기법 두 가지가 존재한다.컴포넌트에 의존성을 추가하는 것을 바인딩, 바인딩을 한다고 표현한다.클라이언트는 컴포넌트에 바인딩된 의존성들을 요청할 수 있다. @AndroidEntr..