AAC (Android Architecture Components)

• 2017 구글 I/O에서 발표
• 2018 구글 I/O에서 발표된 Jetpack으로 통합
• 아키텍처 컴포넌트가 공개되기 전까지는 안드로이드 앱에서 특정 아키텍처가 권장되지 않았다.
• 개발자들에 따라서 MVP, MVC, MVVM, MVPP 등 다양한 아키텍처가 선택되었다.
• 안드로이드 앱을 위한 아키텍처를 정의하고 이를 구현하는 라이브러리를 제공하고자 구글에서 아키텍처 컴포넌트를 공개하였다.

DataBinding

• 데이터를 UI에 쉽게 바인딩하기 위한 라이브러리인데, 뷰와 관련된 코드는 모두 xml에서 작성한다는 점에서 아키텍처 요소라고 볼 수 있다.
• findViewById()에 의한 뷰 객체 획득 및 이용의 번거로움을 제거하기 위한 목적
• Butterknife 등의 라이브러리 이용보다 효율적
• 안드로이드 아키텍처 컴포넌트의 구성요소

<layout>
  <data>
  	<variable name="model1" type="com.example.test_databinding.User" />
  </data>
  
  <TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text='@{"i am include xml.. binding data : " + model1.name}' />
</layout>

Lifecycle Aware Components

• 액티비티, 프래그먼트의 생명주기를 옵저버에서 따로 처리하도록 설계
• 생명주기를 갖는 Owner와 이를 관찰하고 있다가 처리하는 Observer

Navigation Components

• 화면 간 이동을 간편하게 작성할 수 있도록 도와주는 Jetpack의 라이브러리 혹은 툴
• 하나의 메인 액티비티에 여러 개의 프래그먼트로 화면을 설계하는 것을 목적으로 한다.

Room

• SQLite를 사용함에 있어 별도의 Query문 작성없이 간편하게 Insert, Delete 등의 동작을 할 수 있게끔 도와주는 ORM 라이브러리
• 안드로이드 앱에서 사용하는 데이터베이스를 Room으로 권고

Paging

• 리사이클러뷰에서 페이징 처리를 쉽고 효율적으로 작성할 수 있게 해주는 라이브러리
• 페이징 된 데이터는 메모리 내에 캐싱된다.
• 데이터 요청 및 중복 제거 기능이 기본적으로 제공된다.
• 데이터의 끝까지 스크롤을 하면, 어댑터가 자동으로 데이터를 요청한다.

WorkManager

• WorkManager는 특정 작업의 유예 (Defer) 처리 및 비동기 처리 방법을 제공한다.
• JobScheduler, FirebaseJobDispatcher, AlarmManager 등을 통합한 라이브러리

---

MVC vs MVVM

참고한 포스팅

MVC

1. Controller가 사용자 동작을 받아들임. (텍스트 입력, 버튼 터치 등)
2. Controller가 사용자의 동작에 따른 Model 업데이트를 요청함.
3. Controller가 Model을 나타낼 View를 선택함.
4. View는 Model을 참조하여 UI를 업데이트함.

MVC의 단점

• 자연스레 View와 Model 간의 의존성이 높아진다.
• 컨트롤러가 Model과 View 사이에서 바쁘게 움직이고 있다. (혼자서 여기저기 요청을 보내야 하는 컨트롤러의 동작은 당연히 무거워질 수밖에 없다.)
• 따라서 유지보수를 위해 코드를 잘못 건드렸다가, UI 프레임 스킵 현상이나 메모리 누수 같은 문제가 발생할 수 있다.
• 이처럼 MVC 패턴은 구현하기 쉬운 장점이 있는 반면에, 기능 추가 및 변경에 있어서 유지보수가 어렵다.

MVVM

• MVC의 단점을 보완하고자 등장한 디자인 패턴
• 기존의 MVC에서 컨트롤러에게 막중한 역할을 부여하기보다, View와 Model의 동작 자체를 분리하여 유지보수를 편리하게 할 수 있도록 도와준다.

View

• Activity/Fragment가 View 역할을 함.
• 사용자의 동작을 받아들임.
• ViewModel의 데이터를 관찰하여 UI 갱신

ViewModel

• View가 요청한 데이터를 Model에 요청함.
• Model로부터 요청한 데이터를 받음.

Model

• ViewModel이 요청한 데이터 반환
• Room, Realm과 같은 DB 사용이나 Retrofit을 통한 백엔드 API 호출 (네트워킹)이 보편적

MVVM의 장점

• View는 ViewModel이 쥐고 있는 데이터를 관찰한다. 따라서 MVC 패턴처럼 View가 Model에 직접 접근하지 않기 때문에 View는 UI 갱신에만 집중할 수 있다. 그리고 데이터를 관찰하고 있는 만큼 데이터의 변화에 더욱 능동적으로 움직이게 된다.
• ViewModel이 데이터를 쥐고 있으므로, 메모리 누수 가능성 배제 (데이터가 Activity/Fragment와 같은 View의 라이프사이클에 의존하지 않기 때문에)
• 기능별 모듈화가 잘 되어 있어 유지보수에 용이하다. (ViewModel 재사용, DB 교체 등의 작업이 편리해진다.)

MVVM을 적용한 AAC

Activity/Fragment: View

• UI를 구성하고 유저와 상호작용 하는 부분 (생명주기의 변경을 감지)
• 생명주기의 변경이 발생하면 ViewModel에 데이터 갱신 요청
• ViewModel에서 전달한 LiveData의 내용을 화면에 출력

ViewModel: View와 Model의 분리

• View와 Model을 분리시키기 위한 가교 (임시 다리) 역할
• View의 생명주기 변경을 감지하고 변경이 발생하면 Repository를 실행
• Repository에서 발생한 LiveData를 View에 전달

Repository: 데이터 처리 (Model)

• 데이터의 저장 및 획득이 주목적
• SQLite에 저장된 데이터를 사용할 때는 Room, 네트워크 통신으로 서버로부터 데이터를 가져올 때는 Retrofit을 주로 사용

---

ViewModel

• MVVM의 핵심은 화면 (View)에서 비즈니스 로직 (Model)을 분리하여 개발하는 것
• Activity, Fragment에서 UI를 처리하고 ViewModel에서 비즈니스 로직을 처리
• Activity에서 onSaveInstanceState() 함수를 이용해 Bundle에 액티비티의 상태 데이터를 저장하는 것도 ViewModel로 대체할 수 있다.

사용 방법

• build.gradle 파일에서 라이브러리 dependency 설정

implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1

• ViewModel 클래스를 상속 받아서 작성

class MyViewModel: ViewModel() {
	val user: MutableLiveData<User>
  		get() {
        	// LiveData에 저장된 데이터 업데이트 
    		val user = MutableLiveData<User>()
    		user.postValue(User("gildong", "hong1"))
    		return user
  		}
}

액티비티에서 ViewModel을 사용하는 경우

• ViewModel 객체를 직접 생성할 수도 있으나, ViewModelProvider를 이용하는 게 권장된다.
• 왜냐하면, ViewModel의 이점 중 하나가 액티비티의 상태 데이터를 Bundle을 이용하지 않고서도 쉽게 저장할 수 있다는 건데, 객체를 직접 생성하면 이 이점이 사라진다.
• ViewModelProvider를 사용해서 객체를 생성해야 ViewModel의 생명주기가 액티비티와 다르게 움직인다. 그런데, 객체를 직접 생성하는 경우에는 ViewModel의 생명주기가 액티비티와 동일하게 움직이므로, 액티비티가 소멸될 때 뷰모델도 같이 소멸되어 액티비티의 상태 데이터를 저장할 수 없다. 또는 액티비티가 생성될 때 뷰모델이 다시 생성되는 문제도 발생할 수 있다.

val model = ViewModelProvider(this).get(MyViewModel::class.java)

model.user.observe(this, {
	binding.textView.text = "${it.firstName}, ${it.lastName}"
})

• kotlin property delegator를 사용하여 다음과 같이 간결한 코드로 뷰모델 객체를 생성할 수도 있다.

implementation "androidx.activity:activity-ktx:$activity_version"

val model: MyViewModel by viewModels()

• 뷰모델 내에서 어플리케이션 객체를 필요로 하는 경우에는 ViewModel의 서브 클래스인 AndroidViewModel을 사용하면 된다.
• ViewModel() : 기본적으로는 매개변수 없음.
• AndroidViewModel(Application application) : 어플리케이션 객체를 뷰모델에 넘겨줌.

ViewModel의 생명주기

• 화면 회전에 의해 액티비티가 소멸된다고 해도 그 상태 데이터는 ViewModel에 여전히 저장되어있다. 그래서 액티비티가 다시 재개되면 그 데이터를 그대로 사용할 수 있다.

프래그먼트에서 ViewModel을 사용하는 경우

• 액티비티 내에 여러 개의 프래그먼트가 있는 경우, 프래그먼트 간에 뷰모델을 공유해야 할 때가 있다.

• ViewModel의 Lifecycle Owner를 액티비티로 변경하면, 여러 프래그먼트가 하나의 뷰모델을 공유할 수 있다.
• ViewModelProvider의 매개변수로 Lifecycle Owner를 지정하면 된다.

// 현재 액티비티를 Lifecycle Owner로 설정 (프래그먼트 간에 뷰모델 공유) 
val model = ViewModelProvider(requireActivity()).get(MyFragmentViewModel::class.java)

---

LiveData

• ViewModel의 결과를 View에 넘길 때, LiveData 타입으로 넘긴다.
• ViewModel에서 String 등의 타입으로 결과를 리턴할 수도 있지만, LivaData 타입으로 리턴해야 Observer가 그 결과값을 받아 이용할 수 있다.
• LiveData에 저장된 데이터를 업데이트 하고 싶을 경우 setValue(T) 및 postValue(T) 메서드를 이용하면, LiveData를 관찰하는 observer에게 업데이트 된 데이터를 넘겨준다.

class MyViewModel: ViewModel() {
  fun someData(): String { 
  	// 여기서 작업 처리가 오래 걸리면 
    // View가 결과값을 받을 때까지 계속 대기하는 문제가 발생할 수 있다.
  	return "hello"
  }
  
  // LiveData 타입으로 리턴하면 비동기 처리 가능 
  fun someData2(): MutableLiveData<String> {
    val liveData = MutableLiveData<String>()
    
    thread {
      SystemClock.sleep(3000)
      liveData.postValue("world") // 3초 뒤에 실행 (View는 계속 돌아가고 있음) 
    }
    
    return liveData // 일단 결과 리턴
  }
}

• LiveData의 변경을 감지하는 Observer
• LiveData의 값이 변경되면 Observer의 onChanged() 함수가 자동으로 호출된다.
• 더 이상 상태 변화를 감지할 필요가 없어지면, 명시적으로 removeObservers() 함수를 호출한다.

val observer = object: Observer<String> {
  override fun onChanged(t: String?) {
  	Log.d("kkang","onChanged......$t")
  }
}

// someData2 함수가 리턴하는 LiveData의 값이 변경되면 
// observer의 onChanged() 함수 실행 
model.someData2().observe(this, observer)

val liveData = model.someData2()

// ...........................

liveData.removeObservers(this)

• Custom LiveData는 LiveData를 상속 받아 작성
• ViewModel 이외에 다른 곳에서 사용 가능

class MyLiveData : LiveData<String>() {
  fun sayHello(name: String) {
 	postValue("Hello $name")
  }
}

val liveData1 = MyLiveData()

// MyLiveData의 값이 변경되면 중괄호 블럭 내용 실행 
liveData1.observe(this) {
  Log.d("kkang", "result : $it")
}

liveData1.sayHello("kkang") 

실습 예제

implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.5.1'
implementation 'androidx.activity:activity-ktx:1.2.3'

package com.tutorial.c100

import android.os.SystemClock
import androidx.lifecycle.MutableLiveData
import androidx.lifecycle.ViewModel
import kotlin.concurrent.thread

class MyViewModel: ViewModel() {
    var sum = 0

    fun callSum(): MutableLiveData<String> {
        val liveData = MutableLiveData<String>()
        
        thread {
            for(i in 1..10){
                sum += i
                // LiveData에 저장된 데이터 업데이트 
                // Observer에게 업데이트 된 값을 넘겨준다. 
                liveData.postValue(sum.toString())
                SystemClock.sleep(1000)
            }
        }

        return liveData
    }
}

package com.tutorial.c100

import android.os.Bundle
import androidx.activity.viewModels
import androidx.appcompat.app.AppCompatActivity
import com.tutorial.c100.databinding.ActivityMainBinding

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)

        val model: MyViewModel by viewModels()

        binding.button.setOnClickListener {
        	// LiveData의 값이 변경될 때마다 View에 반영 
            model.callSum().observe(this) {
                binding.resultView.text = it
            }
        }
    }
}