Clean Software
3. Android 에서 Dagger로 DI 적용하기
Application에 Dagger 컴포넌트(그래프) 만들기 @Component Android에서 개발자는 앱이 실행되는 동안 Dagger 그래프 인스턴스가 계속 메모리에 있기를 원하기 때문에 일반적으로 Application 클래스에 Dagger 그래프를 만듭니다. 이렇게 하면 그래프는 앱 수명 주기 전체에 연결됩니다. Dagger 그래프를 생성하는 인터페이스는 @Component로 어노테이션 하여 ApplicationComponent 또는 ApplicationGraph로 호출할 수 있습니다. 일반적으로 다음 코드에서와 같이 Application 클래스에 컴포넌트의 인스턴스를 정의하고 Application 그래프가 필요할 때마다 인스턴스를 호출합니다. // 애플리케이션 그래프의 정의 @Componen..
2. Dagger로 DI 적용하기
"hello world" 의존성 주입하기 (@Module, @Provides, @Componet) Hello world 문자열을 제공할 모듈 만들기 @Module은 의존성을 제공하는 클래스에 붙이고, @Provides는 의존성을 제공하는 메서드에 붙인다. Dagger는 컴파일타임에 @Module과 @Provides 어노테이션을 읽고 의존성 주입에 필요한 파일들을 생성한다. @Module class MyModule { @Provides fun provideHelloWorld: String{ return "Hello World" } } Hello world 문자열 제공받을 컴포넌트 만들기 @Componet는 참조된 모든 의존성을 제공받을 인터페이스에 붙인다. 이때 인터페이스 내에는 제공할 의존성들을 메서드로..
1. Android에서 수동으로 DI 적용하기
안드로이드 앱 아키텍처에 따라 수동으로 의존성 주입하기 Android 앱의 로그인 흐름을 다룰 때 LoginActivity는 LoginViewModel에 종속되고 LoginViewModel은 UserRepository에 종속됩니다. 그러면 UserRepository는 UserLocalDataSource와 UserRemoteDataSource에 종속되고 UserLocalDataSource와 UserRemoteDataSource는 Retrofit 서비스에 종속됩니다. 따라서 다음과 같이 구현해야 합니다. Repository.kt class UserRepository( private val localDataSource: UserLocalDataSource, private val remoteDataSource:..
의존성 주입 (목차)
의존성주입은 일반적인 프로그래밍 영역에서 널리 알려진 기술이고 안드로이드 개발에도 잘 적용이 되는 기술입니다. 이 의존성 주입 원칙을 따르면 훌륭한 앱 아키텍처를 만들 수 있게 됩니다. 널리 알려진 장점으로는 코드간의 종속성을 없애기 때문에 재사용성이 높아지고 리팩토링과 테스트 편의성이 높다는 장점이 있습니다. 그럼 이렇게 무서운 두 단어, '의존성'과 '주입' 이라는 단어로 되어있는 의존성 주입의 정의와 필요성, 그리고 실제 구현 방법에 대하여 간단하게 알아보려 합니다. 의존성 주입이란 먼저 의존성의 정의를 살펴봅시다. 보통 한 클래스(viewmodel)가 다른 클래스(datasource) 객체를 사용할 때, viewmodel클래스 내부에 사용하고자 하는 datasource클래스의 인스턴스를 생성해서 ..
클린아키텍쳐
클린 아키텍처 4개 계층 Entity (Domain) 비즈니스 규칙을 캡슐화 Enterprise Business Roles 가장 일반적이면서 고수준의 규칙으로, 가장 변경될 가능성이 적음 Use Case (Domain) 어플리케이션 고유 규칙을 캡슐화 Entity로부터의 데이터 흐름을 조합 Interface Adapters(presentor) (Presentation, Data) Entity 및 UseCase의 편리한 형식에서 DB나 Web에 적용할 수 있는 형식으로 변환(Repository) Mvp 패턴의 presenter, mvvm패턴의 viewmodel이 포함된다 즉, 순수한 비즈니스 로직만을 담당 Frameworks drivers, Web, Db (Presentation, Data) 프레임워크와 ..
Future 패턴
스레드는 코드의 실행에 초점이 맞춰져 있고, 그 결과를 받는 시점이 불분명하다. 스레드가 단순히 코드를 실행하는 것에서 끝나는 것이 아니라, 그 실행의 결과를 다른 스레드에서 받기 위한 패턴이다. B 에서 일을 처리한 결과를 C 에 입력해서 처리하고 결과를 받아야 한다고 할때 (체이닝이 필요할때) 메인쓰레드에서는 B 의 결과를 기다렸다가 C 에게 넣어주고 또 C 의 결과를 기다리는 것보다 (비록 멀티쓰레드 프로그래밍을 하고는 있다지만 먼가 답답하다) 메인쓰레드는 그냥 모든것을 잊어버리고 자기 주력의 일을 하고, B 에게 던진일은 알아서 B -> C-> Somthing 이 되게 한다면 효율적일 것이다. 웹어플리케이션으로 얘기하자면 클라이언트의 요청을 받는 놈은 계속 받는일에만 신경쓰고, (요청이 어떻게 처..