Android Manifests

...
 
    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
 
...

allowBackup 값이 true일 경우 앱을 삭제해도 데이터베이스가 살아있다.

안드로이드 6.0부터 업데이트된 상황

삭제하고 싶으면 false로 바꾸자

1. DI의 개념

DI란 Dependency Injection의 약자로 의존성 주입을 의미한다. 의존성 주입은 하나의 객체가 다른 객체의 의존성을 제공하는 기술이다. 비유하자면 '의존성'은 서비스로 사용할 수 있는 객체이고 '주입'은 의존성(서비스)을 사용하려는 객체로 전달하는 것을 의미한다. DI는 프로그래밍에 널리 사용되는 기법으로, DI의 원칙을 따르면 훌륭한 앱 아키텍처를 위한 토대를 마련할 수 있다.

DI를 클래스들로 예를 들어 설명하자면, Car 클래스와 Engine 클래스가 있는 경우 Car 클래스가 실행되기 위해서는 Engine 클래스의 인스턴스가 있어야 한다. 이러한 필요한 클래스(Engine)를 종속 항목(=의존성)이라고 한다. 클래스들은 흔히 다른 클래스 객체가 필요하다(의존적이다). 클래스가 필요한 객체를 얻는 방법은 다음 세 가지 방법이 있다.

1) 클래스가 필요한 종속 항목을 구성한다.

위 예에 적용하면 Car는 자체 Engine 인스턴스를 생성하여 초기화한다.

class Car {

    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

클래스들의 관계를 그림으로 나타내면 다음과 같다.

이미지 출처: 안드로이드 개발자 공식 문서

이러한 방법으로 클래스가 필요한 객체를 얻는 경우 Car와 Engine이 밀접하게 연결되어 있기 때문에 문제가 생길 수 있다. 우선, 코드의 재사용이 어려워진다. Car 인스턴스는 자신이 생성한 한 가지 유형의 Engine만을 사용하기 때문에 Engine 유형이 Gas와 Electric 두 가지라면 하나의 Car 인스턴스를 재사용하는 대신 두 가지 유형의 Car를 생성해야 한다. 또한 이처럼 종속 항목이 강하게 의존하고 있는 경우 다양한 테스트를 하기 어려워진다. Car가 실제 Engine 인스턴스를 사용하기 때문에 다양한 테스트 상황에서 Engine을 수정할 수 없게 된다.

2) 다른 곳에서 객체를 가져온다.

Context getter 혹은 getSystemService()와 같은 일부 안드로이드 API가 이러한 방식으로 작동한다.

3) 객체를 매개변수로 전달받는다.

앱은 클래스가 구성될 때 종속 항목을 제공하거나 각 종속 항목이 필요한 함수에 전달할 수 있다. 위 예에 적용하면 Car 인스턴스는 초기화 시 자체 Engine 객체를 구성하는 대신 Engine 객체를 생성자의 매개변수로 받는다.

class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}

클래스들의 관계를 그림으로 나타내면 다음과 같다.

이미지 출처: 안드로이드 개발자 공식 문서

이러한 방법을 사용하는 경우 앱은 Engine 인스턴스를 생성한 후 Car 인스턴스를 구성하기 때문에 다양한 유형의 Engine을 Car에 전달해 Car의 재사용이 가능해지며 다양한 시나리오를 테스트할 수 있다.

위의 세 가지 방법 중 이 세 번째 방법이 바로 '의존성 주입(DI)'이다.

2. DI의 장점

위에서 예시를 살펴보면서 설명한 것처럼 DI를 구현하면 다음과 같은 장점이 있다.

• 코드 재사용 가능: 종속 항목 객체를 쉽게 교체할 수 있다.
• 리팩토링 편의성: 종속 항목은 구현 세부정보로 숨겨지지 않고 노출되어 있어 검증 가능한 요소가 되므로 객체 생성 또는 컴파일 시 확인할 수 있다.
• 테스트 편의성: 클래스가 종속 항목을 관리하지 않으므로 다양한 모든 사례를 테스트할 수 있다.

3. 안드로이드에서 DI(의존성 주입) 실행하기

안드로이드에서 의존성 주입을 실행하는 두 가지 주요 방법은 다음과 같다.

• 생성자 삽입: 위에서 설명한 방법으로, 클래스의 종속 항목을 생성자에 전달하는 방법이다.
• 필트 삽입(setter 삽입): Activity나 Fragment 같은 특정 안드로이드 프레임워크 클래스는 시스템에서 인스턴스화하기 때문에 생성자 삽입이 불가능하다. 따라서 필드 삽입을 사용해 클래스가 생성된 후 종속 항목을 인스턴스화한다. 코드는 다음과 같다.

class Car {
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.engine = Engine()
    car.start()
}

4. 안드로이드의 DI 라이브러리

위의 예에서처럼 클래스의 종속 항목을 직접 생성, 제공, 관리하는 것을 수동 의존성 주입이라고 한다. 위의 예에서 Car에 종속 항목이 하나만 있었기 때문에 수동으로 의존성을 주입하는 것이 가능했지만 종속 항목과 클래스가 많아지면 수동 의존성 주입을 사용할 때 문제가 발생할 수 있다. 따라서 종속 항목을 생성하고 제공하는 프로세스를 자동화해서 문제를 해결하는 라이브러리를 사용하는 것이 좋다. 안드로이드의 주요 DI 라이브러리는 다음과 같다.

• Hilt
• Dagger

Dagger는 구글에서 유지 관리하며 자바, 코틀린 및 안드로이드용으로 널리 사용되는 라이브러리이다. 컴파일 타임 정확성, 런타임 성능, 확장성 및 안드로이드 스튜디오 지원 등의 장점이 있다. Hilt는 Dagger를 기반으로 빌드된 Jetpack의 권장 라이브러리로, 프로젝트의 모든 안드로이드 클래스에 컨테이너를 제공하고 생명주기를 자동으로 관리해 앱에서 DI를 실행하는 표준 방법을 정의한다.

참고

• 위키백과 - 의존성 주입
• 안드로이드 개발자 공식문서 - dependency injection

1. 디자인 패턴과 아키텍처 패턴의 개념

MVC, MVVM 패턴 등에 대한 검색을 했을 때 디자인 패턴이라고 하는 경우도 있고 아키텍처 패턴이라고 하는 경우도 있어서 둘의 차이가 무엇인지 궁금해서 알아보았다.

• 디자인 패턴: 소프트웨어 디자인에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책을 말한다. 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 템플릿을 의미한다. 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 패턴이다.
• 아키텍처 패턴: 아키텍처 패턴은 디자인 패턴과 유사하지만 범위가 더 넓다. 아키텍처 패턴은 소프트웨어 공학의 다양한 문제를 해결하는데, 예를 들어 컴퓨터 하드웨어 성능 제한, 비즈니스 위험의 최소화와 고가용성 등이 있다. 일부 아키텍처 패턴은 SW 프레임워크 안에 구현되어 있다. 아키텍처 패턴이 시스템의 이미지를 전달하기는 하지만 아키텍처 자체를 의미하는 것은 아니다. 다양한 아키텍처가 동일한 패턴을 구현하고 관련 특성을 공유할 수 있다.

출처: 위키백과 - 소프트웨어 디자인 패턴

간단하게 정리하자면 디자인 패턴과 아키텍처 패턴은 소프트웨어공학에서 발생하는 문제를 해결한다는 점에서 비슷하지만 디자인 패턴은 특정 문제를 해결하기 위한 방법이고, 아키텍처 패턴은 전체적인 소프트웨어에서 발생하는 문제들을 해결하기 위한 방법이라고 이해하면 될 것 같다.

또한 각 패턴들은 범위에 따라 디자인 패턴으로 사용될 수도 있고 아키텍처 패턴으로 사용될 수도 있으며, 안드로이드 분야에서 자주 언급되는 MVC, MVP, MVVM 패턴은 아키텍처 패턴이라고 하는 게 더 정확하다고 볼 수 있다.

2. 이러한 패턴들을 알아야 하는 이유

안드로이드 앱에는 activity, fragment, service, content provider, broadcast receiver 등 다양한 컴포넌트가 포함되며 사용자는 짧은 시간 동안 여러 앱과 상호작용하는 경우도 많다. 예를 들어 앱을 사용하는 도중 전화나 알림에 의해 사용 환경이 중단될 수 있고 사용자는 이 중단이 끝난 후(다른 앱에서 활동을 끝낸 후) 다시 작업을 이어갈 수 있기를 기대한다. 그렇기 때문에 앱에서 이러한 흐름을 올바르게 처리하기 위해 좋은 아키텍처 패턴을 적용하는 것이 중요하다.

1. 클린 아키텍처란?

클린 아키텍처는 의존성 규칙을 따라 관심사를 분리하고, 본질적으로 테스트하기 쉬운 시스템을 만들 수 있는 아키텍처 구조이다. 클린 아키텍처를 적용하면 변화의 위치가 명확하기 때문에 생산성을 증대시킬 수 있고 변화에 더 잘 대응할 수 있다.

레이어의 가장 바깥 쪽이 사용자와의 접점에 있는 Presentation이고 가장 안쪽의 Entities가 사용자가 실제로 생각하는 개념 단위이다. 클린 아키텍처에서는 서버 쪽 내용이지만 안드로이드에도 이 원리를 적용시켜 UI를 독립시키고, Database를 분리시키고, 외부적인 설정에 독립적인 구조를 적용하면 프레임워크에 의존적이지 않은 코드를 짤 수 있다.

각 레이어의 역할

1) Entities

• 애플리케이션에서 핵심적인 기능인 Business Rule들을 담고 있다.
• Entity들은 outer layer들에 속한 다른 class나 component들에 대해 전혀 몰라도 된다.

2) Use cases

• 특정 애플리케이션에 대한 Business Rules
• 시스템이 어떻게 자동화될 것인지 정의하고 애플리케이션의 행위를 결정한다.
• 즉, 프로젝트 레벨의 Business Rules(Entities)를 사용하여 목적을 달성한다.

3) Adapters

• domain과 infrastructure 사이의 번역기 역할
• GUI로부터 입력을 받아 Use cases와 Entities에게 편리한 형태로 repackage한다.
• GUI의 MVC 아키텍처를 완전히 내포하며, Presenter, View, Controller가 모두 여기에 속한다.

4) Infrastructure

• 모든 I/O components (UI, DB, frameworkds, devices)가 있는 곳
• 변화될 가능성이 매우 높기 때문에 stable한 domain과는 확실히 분리가 되어있고, 따라서 비교적 쉽게 변하고 component 또한 쉽게 교환된다.

2. 안드로이드에 클린 아키텍처 적용하기

• 결과적으로 4개의 계층을 재구성하여 3개의 계층으로 분리하는 것으로 일반화
• 각 계층이 자체 데이터 모델을 사용하므로 계층 간 독립성을 확보할 수 있다는 것이 중요
  • 이때 계층 간 데이터 변환을 수행하기 위해 Mapper가 필요

비즈니스 로직이란

하나의 프로젝트나 프로그램 중 업무와 관련된 처리를 하는 일부분을 뜻하는데 프로젝트를 하면서 데이터베이스에서 어떠한 자료를 가져와 웹에서 출력을 할 때 데이터베이스 연결, 통신 , 자료, 가공, 페이지 구성 등 여러 작업을 하지만  그중에서 사용자가 원하는 자료의 가공 부분을 의미 즉 어떻게 데이터가 생성, 저장되고 수정되는지를 정의한 것

Domain Layer

• 비즈니스 로직을 포함하고 있으며, 이에 필요한 Entity와 Usecase, Repository를 포함
• Domain 계층은 Presentation 계층, Data 계층과 어떠한 의존성을 맺지 않아야 합니다.
• 순수 코틀린 혹은 자바 코드로 구성되어 있어 다른 프레임 워크에서도 유연하게 사용이 가능

UseCase

• 각 기능 혹은 비즈니스 로직 단위로 구성
• 이름만 보고 어떤 기능을 수행하는지 짐작할 수 있어야 한다.
• Presentation 계층의 UI에서 어떤 이벤트 혹은 동작에 의해 호출되는 방향으로 설계
• Data계층에서 실제 데이터를 어떻게 가져올지 정의는 하지 않고, 해당 메서드를 호출하는 방식으로 데이터를 저장

Translator

• Data 계층의 Entity를 Domain 계층의 Model로 변환

Repository

• Domain 계층에서는 인터페이스로 정의하고, 실제 구현은 Data 계층에서 진행

Model

• 애플리케이션의 실질적 데이터가 여기에 구현
• 안드로이드와 의존성을 가지고 있어선 안되고, 다른 프로젝트에서도 동일하게 사용할 수 있는 클래스를 작성해야 함

Data Layer

• Data 계층은 Domain 계층의 의존성을 갖는다

Repository

• UseCase가 필요로 하는 데이터 저장, 수정 등의 기능을 제공
• 위의 Domain계층에서 설계한 Repository를 실제고 구현

DataSource

• 실제 데이터의 입출력을 진행
• Room을 사용한다고 하면 Dao를 이 부분에서 접근하고 결과를 출력

Entity

• Domain 계층의 Model과는 다르게, REST API의 요청/응답을 위한 JOSN, 로컬 DB에 저장하기 위한 테이블에 저장하기 위한 데이터를 저장.

Presentation Layer

• 내부적으로 프레임워크 의존성을 처리하기 위해 MVP 혹은 MVVM 패턴을 사용
• Activity, Fragment, Presenter, ViewModel을 포함

View

• UI 구현과 사용자 입력만을 담당
• 화면에 그려지는 것이 어떤 의미가 있는지 전혀 알지 못해야 한다
• 데이터를 지니고 있더라도 화면과 관련된 데이터만 지니고 있어야 한다.

Presenter or ViewModel

• View와 달리 플랫폼에 직접적으로 의존하지 않으므로 단위 테스트가 가능
• 또한 화면에 그려지는 것이 어떤 의미를 가지고 있는지 알고 있습니다.
• 사용자 입력이 왔을 때 어떤 반응을 해야 하는지에 대한 판단도 이곳에서 진행
• Domain 계층의 UseCase를 주입받아 데이터를 가져옵니다.
• 당연히, Data 계층에 의존성이 없기 때문에 데이터를 가져오는 과정에 접근할 수 없음

Retrofit이란?

• REST API 통신을 위해 구현된 
• 동일 Squareup사의 OkHttp 라이브러리의 상위 구현체
    : Retrofit은 OkHttp를 네트워크 계층으로 활용하고 그 위에 구축됨
• AsyncTask 없이 Background Thread 실행 -> Callback을 통해 Main Thread에서 UI 업데이트

Retrofit : (기계 속에 원래 없던 부품 등을) 새로 장착하다 / 넣다 / 제공하다

안드로이드에서의 Retrofit : 서버와의 HTTP 통신을 통해 전달된 데이터를 앱에서 특정 형태로 받아볼 수 있게 하는 라이브러리

레트로핏을 한 문장으로 정의하라고 하면 서버와 HTTP 통신을 해서, 서버로부터 받은 데이터를 앱에서 출력해 사용자가 볼 수 있게 하는 라이브러리라고 할 수 있겠다.

일반적인 앱은 서버와 클라이언트가 네트워크 통신으로 정보를 주고받고 이 정보를 화면에 뿌리기도 하며, 입력된 정보를 저장하는 등의 기능들이 구현돼 있다. 이걸 네트워킹 기능이라고 한다.

요즘은 서버와 클라이언트가 데이터를 주고받는 과정에서 REST API라는 방식을 써서 네트워크 통신을 한다고 한다.

AsyncTask와 HttpURLConnection을 쓰면 되지만 직접 구현해줘야 하는 것들이 꽤 많다.

네트워크 연결과 해제, 데이터 파싱, 파싱된 데이터를 데이터 클래스에 저장, 에러처리 등. 이것들을 우리 대신 처리해주는 도구도 있을 것이다. 그 중 하나가 레트로핏이다.

레트로핏을 써본 결과, 의존성 추가를 제외하고 크게 5가지가 필요하다.

• 웹 서버(더미 데이터를 써서 레트로핏을 쓸 수도 있다)
• 웹 서버 주소를 변수로 가진 클라이언트 클래스 (XXXApiClient.java 형태로 쓰기도 하더라. 역시 더미 데이터를 쓸 수도 있다)
• PHP 파일에 접근해 해당 파일의 기능을 수행하는 함수들을 담은 인터페이스 (더미 데이터를 쓴다면 필요없을 수도 있다)
• PHP 파일 : 서버에 쿼리 때려야 하니까 당연히 필요.
• 모델 클래스 : 리사이클러뷰를 사용할 때 쓰는 그 클래스. POJO, DTO 등 불리는 방식은 많은데 여기선 모델 클래스라고 부른다. 서버에서 값을 받아와 담을 변수를 정할 때 사용한다.

레트로핏에선 어노테이션(@)이라는 특수 주석을 사용하기 때문에 어노테이션에 대한 약간의 공부도 필요하다.

웹 서버의 주소를 변수 혹은 상수로 할당할 때 http://가 들어가야 하며, 주소 끝에 /를 붙여줘야 한다.

공식문서를 읽어보면 baseURL()에 설정된 서버 URL에 /가 없다.

그런데 실제로 이걸 써주지 않으면 앱에서 데이터를 받아오지 못하는 경우가 드물게 발생했다. 그 뒤로는 http://~~~.~~.~~.~~/ 식으로 내 웹 서버의 주소를 적어주기 시작했다.

변수 혹은 상수로 설정한 웹 서버 URL의 마지막에는 /을 꼭 넣어주자.

<?xml version="1.0" encoding="utf-8"?>

가장 위쪽에 있는 코드는 XML 파일에 일반적으로 추가 하는 정보이고, 이 파일이 XML 형식으로 된 것을 알려준다.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

...중략...

</LinearLayout>

태그 속성에 xmlns:로 시작하는 속성이 있다.

xmlns: 뒤에 있는 android는 나머지 속성의 접두어로 사용 된다.

<LinearLayout xmlns:love="http://schemas.android.com/apk/res/android"
    love:layout_width="match_parent"
    love:layout_height="match_parent"
    love:orientation="vertical">
   
   ...중략...
   
</LinearLayout>

접두어는 위 코드처럼 사용자가 원하는 단어로 변경할 수 있다.

xmlns 접두어

id 속성

<Button
            android:id="@+id/btnButton"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="버튼" />

id 속성 값은 아래와 같은 형식으로 정의하고 사용함

@+id/아이디 값

DataBinding?

• Ui 요소와 데이터를 프로그램적 방식으로 연결하지 않고, 선언적 형식으로 결합할 수 있게 도와주는 라이브러리
• xml에 Data를 연결하는 작업
• Android JetPack 라이브러리 중 하나
• findViewById를 사용하지 않아도 되며, 주로 MVVM패턴, LiveData와 함께 사용

안드로이드 공식 문서 Data Biniding Library : https://developer.android.com/topic/libraries/data-binding

DataBinding의 장점

• 데이터 바인딩을 사용하면, 데이터를 UI 요소에 연결하기 위해 필요한 코드를 최소화할 수 있다.
  • findViewId() 를 호출하지 않아도, 자동으로 xml 에 있는 VIew 들을 만들어준다.
  • RecyclerView 에 각각의 item 을 set 해주는 작업도 자동으로 진행된다.
  • data 가 바뀌면 자동으로 View 를 변경하게 할 수 있다.
  • xml 리소스만 보고도 View 에 어떤 데이터가 들어가는지 파악이 가능하다.
  • 코드 가독성이 좋아지고, 상대적으로 코드량이 줄어든다.
• 데이터 바인딩은 MVP 또는 MVVM 패턴을 구현하기 위해 유용하게 사용된다

DataBinding의 단점

• 클래스 파일이 많이 생기고, 빌드 속도가 느려지는 등 단점들도 존재한다.

MVVM 아키텍처

• Model : MVC의 Model과 동일한 역할
  • DataModel이라고도 하며, 다양한 데이터 소스로부터 필요한 데이터를 준비함
  • ViewModel에서 데이터를 가져갈 수 있게 데이터를 준비하고 그에 대한 이벤트를 보냄
• View : 레이아웃을 정의함
  • 기본적으로 데이터를 보여주기만 하기 때문에 비즈니스 로직을 포함하지 않지만 UI 변경과 관련된 일부 로직은 포함될 수 있음 (Android는 생명주기라는 플로우를 가지고 있기 때문에 이것을 처리하는 것만으로도 복잡해짐)
  • ViewModel을 관찰하고 있다가 상태 변화가 전달되면 화면을 갱신해야 함
• ViewModel : View와 Model 사이의 매개체 역할
  • View와 관련된 비즈니스 로직이 들어가며 데이터를 가공해서 View에 뿌리기 쉬운 Model로 바꾸는 역할
  • MVP와 달리 View와 ViewModel이 1:n의 관계를 가질 수 있음(Presenter와 달리 View에 대한 참조가 없음)
  • View가 데이터 바인딩(Data Binding) 할 수 있는 속성과 명령으로 구성되어 있음

다시 정리해 보자면

• 사용자 입력은 View로 전달되며, View는 ViewModel이 제공하는 데이터를 관찰하여 UI를 업데이트 한다. 
  → View는 자신이 이용할 ViewModel을 선택하여 데이터를 바인딩(binding)하여 업데이트 받게 되는 것
• Model의 상태나 데이터가 변경되면 해당하는 ViewModel을 이용하는 View가 자동으로 업데이트 된다.
  → ViewModel은 View를 나타내기 위한 Model이며, View의 Presentation Logic을 처리하는 것

[ 장점 ]

• View가 데이터를 실시간으로 관찰할 수 있음
  • LiveData(Observable 패턴)을 사용하기 때문에 데이터베이스를 관찰하고 자동으로 UI를 갱신함
  • 직접 View를 바꾸는 번거로움이 없고 데이터와 불일치할 확률이 줄어듦
• 생명주기로부터 안전하며 메모리 누수를 방지함
  • ViewModel을 통해 데이터를 참조하기 때문에 Activity나 Fragment의 생명주기를 따르지 않음
  • 화면 전환과 같이 Activity가 내려갔다가 다시 재구성되어도 ViewModel이 데이터를 유지하고 있기 때문에 영향받지 않음
  • View가 활성화되어 있을 경우에만 작동하기 때문에 불필요한 메모리 사용을 줄일 수 있음
• 역할을 분리함으로써 모듈화함
  • UI, 비즈니스 로직, DB가 기능별로 모듈화됨
  • 유닛테스트가 용이해짐

[ 단점 ]

• 기존에 비해 추가로 만들어주어야 하는 클래스가 많고, 이 클래스들을 코딩으로 연결해주어야 함
• 단순 UI 작업에서는 MVVM을 구현하는 부담이 지나치게 과해질 수 있음
• 아주 큰 응용 프로그램에서 데이터 바인딩을 사용한다면 눈에 띄게 메모리를 소모하게 됨

Android Architecture Component AAC

AAC는 테스트와 유지보수가 쉬운 앱을 디자인할 수 있도록 돕는 라이브러리

안드로이드는 Activity, BroadcastReceiver, Service 등 여러 컴포넌트들이 있고, 생명주기가 다르게 얽혀있다. 앱을 잘 만들기 위해서 이러한 컴포넌트들을 부드럽게 연결해야 하는데, 생명주기를 학습하고 엉키지 않게 고민하는 것은 개발자의 몫

구글이 SDK에서 제공하는 컴포넌트들에 대해 개발자들에게 더 가이드를 주기를 원했고, 결과적으로 AAC를 만들게 된 것이다

• Lifecycles (Easy handling lifecycles) 
• LiveData (Lifecycle aware observable) 
• ViewModel (Managing data in lifecycle) 
• Room (Object Mapping for SQLite)
• Paging (Gradually loading information)