Dagger 2 소개, 안드로이드에서 Dependency Injection 사용하기전에

이 글은 Janishar Ali가 작성한 Introduction to Dagger 2, Using Dependency Injection in Android: Part 1을 번역하였습니다.

Android에서 Dagger2 사용법을 이해하려면 왜 필요한지를 먼저 알아야 합니다. 중요한 질문은 다음과 같습니다.

왜 의존성 주입(Dependency Injection)이 필요한가?
의존성 주입은 Inversion of Control 개념을 바탕으로합니다. 클래스가 외부로부터 의존성을 가져야합니다. 간단히 말해 클래스는 다른 클래스를 인스턴스화해야하지만 구성 클래스에서 인스턴스를 가져와야합니다.
Java 클래스가 new 연산자를 통해 다른 클래스의 인스턴스를 생성하면 해당 클래스와 독립적으로 테스트하고 사용할 수 없으며 이를 하드종속성이라고합니다.

그렇다면 클래스 외부에서 종속성을 제공하면 어떤 이점이 있을까요?
가장 중요한 장점은 클래스를 재사용 할 가능성을 높이고 다른 클래스와 독립적으로 클래스를 테스트 할 수 있다는 것입니다.
이것은 비즈니스 로직의 특정 구현이 아닌 클래스를 생성하는데 매우 효과적입니다.
이제 조금은 이해 했으므로 종속성 삽입 탐색을 진행할 수 있습니다.

큰 문제는 바로 DI(Dependency Injection)를 어떻게 할 것인가입니다.
이 질문에 답하기 위해 우리는 과거를 되돌아 봐야합니다.
종속성 컨테이너라는 프레임워크 클래스는 클래스의 종속성을 분석하는데 사용되었습니다. 이 분석을 통해 Java Reflection을 통해 클래스의 인스턴스를 만들고 정의 된 종속성에 객체를 삽입 할 수있었습니다. 이로 인해 어려운 의존성이 제거되었습니다. 그런 식으로 클래스를 독립적으로 테스트 할 수 있습니다. mock 객체를 사용합니다. 이것은 Dagger 1이었습니다.

이 과정의 주요 단점은 두 가지입니다.
첫째, Reflection 자체가 느림.
번째로, 런타임에 종속성 해결을 수행하여 예기치 않은 충돌 발생.

이것은 Dagger2의 탄생으로 이어졌습니다. Dagger2는 Google의 Square Dagger1에서 분기되었습니다.

Dagger2에서 가져온 큰 변화는 주석 처리기(Annotation Processor)를 사용하여 종속성 그래프를 생성하는 것이 었습니다. 의존성을 제공하는 클래스는 이제 javax injection 패키지를 사용하여 빌드시 생성됩니다. 이것은 응용 프로그램이 실행되기 전에 가능한 오류 검사를 용이하게합니다. 생성된 코드는 직접 작성한것 처럼 보기 쉽습니다.

참고: 주석 처리기는 프로젝트에서 사용할 소스코드 파일을 생성하기 위해 컴파일하는 동안 컴파일 된 파일을 읽는 방법입니다.
그래도 잘 이해 되지 않는다면 다음 파트2의 예제를 보기위해 기다리면 됩니다.

DI작동 방식에 대한 몇가지 정보를 드리겠습니다.
클래스의 종속성을 설명하기위한 표준 Java 주석은 Java Specification Request 330(JSR 330)에 정의되어 있습니다.

Injection 모드 :
1. Constructor Injection: 생성자 삽입.
2. Field Injection: 멤버 변수 삽입 (비공개이면 안됨).
3. Method Injection: 메소드 매개 변수 삽입.

JSR330에 따른 종속성 주입 순서
1. Constructor
2. Field
3. Method

@Inject로 주석처리된 메소드나 필드가 호출되는 순서는 JSR330에 의해 정의되지 않습니다. 메서드나 필드가 클래스에서 선언 된 순서대로 호출된다고 가정 할 수 없습니다.
생성자가 호출 된 후에 필드 및 메서드 매개 변수가 삽입되므로 생성자에서 삽입 된 멤버 변수를 사용할 수 없습니다.

Dagger2를 사용하여 종속성 주입 프로세스를 시각화하는 경향이 있습니다.

종속성 소비자는 커넥터를 통해 종속성 공급자의 종속성(Object)을 필요로합니다.

  1. Dependency provider: @Module로 주석 된 클래스는 삽입 할 수있는 객체를 제공합니다. 이러한 클래스는 @Provides로 주석 된 메소드를 정의합니다. 이 메소드의 리턴 된 오브젝트는 종속성 삽입에 사용 가능합니다.
  2. Dependency consumer: @Inject 어노테이션은 의존성을 정의하는데 사용된다.
  3. Connecting consumer and producer: @Component 주석이 달린 인터페이스는 객체 제공자(모듈)와 의존 관계를 표현하는 객체 사이의 연결을 정의합니다. 이 연결에 대한 클래스는 Dagger에 의해 생성됩니다.

Dagger2의 한계 :
1. Dagger2는 필드를 자동으로 주입하지 않습니다.
2. 비공개 필드를 주입 할 수 없습니다.
3. 필드 주입을 사용하려면 @Component 주석이 달린 인터페이스에서 멤버 변수를 삽입 할 클래스의 인스턴스를 취하는 메소드를 정의해야합니다.

ConstraintLayout으로 아름다운 애니메이션하기

이 글은 Jinyan Cao가 작성한 Beautiful animations using Android ConstraintLayout 번역글입니다.

ConstraintLayout은 날이 갈 수록 인기를 더해가고 있습니다. 수평적인 뷰 계층 구조와 성능을 향상시키고, 임의의 경계 규칙을 지원합니다. 이전 레이아웃의 단점을 모두해결 할 것입니다. ConstraintLayout의 이점 중 하나는 매우 적은 코드로 멋진 애니메이션을 수행 할 수 있습니다. 이는 대부분의 개발자들이 알지못하며, 공식 문서에도 아무것도 언급되어 있지 않습니다.

방법?

ConstraintLayout의 기본 사항을 알고 있다고 가정합니다 (예: app:layout_constraintLeft_toLeftOf 및 다른 속성). 대부분의 문서또는 사이트에서는 새로 개선 된 Android Studio 레이아웃 디자인 패널을 사용하여 다양한 Constraint를 드래그/드롭/시각화 하는 방법만 소개되어 있습니다. 애니메이션의 목적을 위해서는 Constraint를 정확하게 이해하고 있어야만 조작이 가능합니다.

가장 간단한 형식인 TransitionManager(API 19 이상 또는 서포트 라이브러리에서 사용가능)를 통해 두 가지 Constraint 집합간에 애니메이션을 적용 할 수 있습니다. 긴 설명 보다 간단한 예제를 살펴 보겠습니다.

예제

Activity 실행시 초기화되는 XML 레이아웃부터 살펴 보겠습니다.

이것은 화면의 너비와 일치하는 화면 상단에 ImageView를 정의하는 기본 XML 파일입니다. (ConstraintLayout은 match_parent를 지원하지 않습니다.) 이제 하나의 추가 Constraint를 가진 대체 XML 레이아웃을 정의합시다.

여기서 유일한 차이점은 새 XML 레이아웃이 부모의 높이와 일치하는 높이로 설정하는것 입니다. 결과적으로 ImageView는 수직으로 가운데 정렬됩니다.
이제 두 개의 서로 다른 제약 조건 세트 (하나는 ImageView를 수직으로 중심에 배치하지 않고, 하나는 수직으로 가운데 배치)간에 애니메이션을 적용하려면 다음 코드를 Activity에 추가해야합니다.
(참고: 여기서는 Kotlin에 쓰여 있습니다. Kotlin에 익숙하지 않은 분은 Java 코드와 완전히 역 호환되는 동시에 최신 프로그래밍 언어의 많은 이점을 제공하므로 지금 시작하는 것이 좋습니다. 이제 Android에서 공식적으로 지원되는 언어입니다!)

constraintSet1과 constraintSet2는 비 수직 가운데 정렬과 수직 가운데 정렬에 대응하도록 설정합니다. 먼저 TransitionManager에 ConstraintLayout에서 지연된 전환을 시작하라고 지시합니다. 그런 다음 ConstraintLayout에 다른 Constraint 집합을 적용합니다. TransitionManager는 자동으로 애니메이션을 수행하여 Constraint의 변경 사항을 표시합니다.

실제로 XML 레이아웃을 복제하나요?

무엇을 생각하는지 알고 있습니다. 이 접근법은 Constraint 변경을 위해 레이아웃 파일을 복제해야합니다. 아무도 중복 된 코드를 좋아하지 않습니다.
이것은 실제로 생각만큼 나쁘지 않습니다. 전환을 위해 대체 XML파일 생성하는 경우 레이아웃의 모든 속성(예 : textSize)을 생략 할 수 있습니다. ConstraintSet은 각 뷰의 Constraint의 속성을 제외한 나머지 속성을 무시합니다. 이렇게하면 두 파일에서 일관된 스타일을 유지할 필요가 없습니다.(예: 원래 XML에서 textSize를 변경하면 대체 XML에서 이를 변경할 필요는 없습니다.)
XML 코드 복제를 하고 싶지 않는 경우, 코드에서 동적으로 속성을 변경하면 됩니다.
위의 예를 하나의 레이아웃 XML로 어떻게 변경하는지 살펴 보겠습니다.

위의 코드에서 constraintSet2에 속성을 코드에서 변경하여 애니메이션을 수행하고 있습니다. 이렇게하면 우리는 Constraint 속성을 그대로 유지하고 코드 복제를 피할 수 있습니다.

하지만 이미 Transition 프레임워크를 사용하여 동일하게 사용할 수 있다!
이것은 전혀 새로운 방식이 아닙니다. Transition 프레임워크 또는 animateLayoutChanges와 같은 속성을 사용하여 동일한 작업을 수행 할 수 있습니다. 그러나 Constraint를 지정할 수 있기때문에 훤씬 강력합니다.
또 다른 이 점은 많은 요소를 애니메이션으로 만들려고 할 때입니다. 이 애니메이션을 살펴 보겠습니다.

Robinhood가 ConstraintLayout을 사용하여 주문 애니메이션을 만듭니다.
Robinhood (Android)의 주문 흐름 애니메이션입니다. 페이지의 모든 단일 요소(카드, 사용자 정의 키패드, FAB 등)를 수동으로 애니메이팅 하도록 구현되어 있습니다. 이 코드는 특히 앞뒤 애니메이션을 따로 작업한다는 점을 감안할 때 읽기에 약간의 문제가 있습니다.
대신이 애니메이션에 ConstraintLayout을 사용하는 샘플 앱을 만들었습니다. 이 구현은 훨씬 간단합니다. 변경되어야 할 속성만 바꾼다음 대체 XML 레이아웃 파일을 지정하면 애니메이션 프레임워크가 모든 것을 애니메이션으로 변환합니다. UI에서 이 애니메이션을 처리하는 코드는 ~250라인에서 ~30라인으로 간단해졌습니다.

 

추가 팁!

ConstraintLayout 애니메이션을 시작하는 데 사용하는 코드를 기억하십니까?

두번째 파라미터를 이용하여 애니메이션을 커스터마이징 할 수있습니다!(기본은 내부에 구현된 기본 Transition 사용) 예를들어 애니메이션 속도를 쉽게 변경할 수 있습니다.

사소한주의 사항

ConstraintLayout 애니메이션으로 사용해본 후, 나는 애니메이션을 구현할 때 고려해야 할 몇 가지주의 사항을 발견했습니다.

  1. ConstraintLayout은 핸들링하는 자식에 대한 속성변경을 알고 있기때문에 직접 자식에 대해서만 애니메이션을 수행합니다. 이는 중첩 된 ViewGroups인 경우 잘 처리 되지 않음을 의미합니다. 위의 예제에서 CardView 내부의 텍스트는 외부 ConstraintLayout에 의해 처리되지 않으므로 코드에서 수동으로 애니메이션을 적용해야합니다. 이것은 아마도 중첩 된 ConstraintLayout을 사용하여 해결할 수 있지만 여기서는 사용하지 않았습니다.

  2. ConstraintLayout은 레이아웃 관련 변경 사항 만 애니메이션으로 나타냅니다. 대체 XML에서 다른 속성(예: elevation, text)을 읽을 수 없으며 프레임워크가 모든 것을 처리 합니다. ConstraintSet.clone()은 레이아웃/Constraint 변경 사항을 복사하고 다른 모든 항목은 삭제합니다.

  3. constraint-layout:1.0.2에서 ConstraintLayout 속성을 동적으로 변경하면 업데이트 된 속성을 고려하지 않고 애니메이션됩니다.(예: translationY). 즉, 애니메이션을 실행하면 변경전의 속성의 값으로 되돌아 간뒤 새로운 값으로 애니메이션이 적용됩니다.

마치며..

ConstraintLayout을 사용하는 페이지에서 애니메이션을 구현할 함으로 Transition 프레임 워크 보다 많은 기본 레이아웃 변경 애니메이션을 수행 할 수 있습니다. 이를 통해 Activity/Fragment에서 UI/애니메이션 로직을 압축하고 XML로 통합 할 수 있습니다. 또한 더 읽기 쉬운 애니메이션 구조를 만듭니다. (아무도 코드로 작성된 방식의 애니메이션을 읽는 것을 좋아하지 않습니다).