Lesson 5: App Architecture(UI Layer)

5. What is Architecture

Application Architecture란 앱의 클래스들에 대한 디자인과 그들 사이의 관계. 
앱을 구성하는데 한 가지 방법만 있는 것은 아니다. 집을 설계하는 것은 상황, 필요, 취향 등에 강한 의존성을 띈다. 
이와 마찬가지로 안드로이드 앱도 다양한 설계 스타일이 있다. 또 각 방식은 장단점이 있다. 서로가 공통점을 갖기도 한다. 각기 다른 앱의 필요나 팀의 크기, 팀의 성향 등에 따라 적합한 스타일이 다를 수 있다. 
이번 lesson에서는 a single multipurpose architectural pattern을 사용하는데 MVVM과 비슷하다. 

6. Our App Architecture

Software design principle
- Separation of concerns: Divide your code into classes, each with separate, well defined responsibilities. 

Architecture는 어느 클래스가 어떤 역할을 해야하는지 figure out 하기위해 가이드라인을 준다. 

LiveData는 ViewModel과 UIController 간에 정보를 교류하는데 매우 중요하다. communicating update and redraw the screen.

7. ViewModel

앱의 UI 데이터를 가지고 있는 abstract class 이다. 그리고 configuration changes를 생존한다. 

ViewModel이 유용한 이유는 무엇인가?

스크린을 회전하는 것과 같은 configuration change가 발생하면 activity와 내부에 있는 모든 fragments는 파괴되고 OS에 의해서 rebuild 되는데 개발자가 데이터에 대해서 올바른 처리를 하지 않으면 데이터는 사라져버린다. 앞에서 onSaveInstanceState로 문제를 해결하는 방법을 봤지만 저장해야할 복잡한 데이터가 많다면 좋은 해결 방법은 아니다. 그래서 ViewModel이 도입된다.

UI 데이터를 Fragment에 두지 않고 ViewModel에 둔다. 그리고 fragment가 ViewModel에 대한 reference를 갖는다. ViewModel은 Configuration changes를 생존할 수 있다. 그렇기 때문에 fragment가 파괴되고 다시 만들어지는 동안에도 모든 fragment에 보여져야하는 데이터는 ViewModel에 남아있다. 다시 생성된 fragment를 동일한 ViewModel에 연결해준다면 데이터는 그대로 있다! 

10. Exercise: Populate the GameViewModel

ViewModel vs. UI Controller

• ViewModel holds data for UI
• UI Controller only displays and gets user/OS events.
  (Should have as little responsibility as possible, 화면에 그리고 input 이벤트를 감지) 
• UI Controller does NOT make decisions.
  UI Controller는 views를 instantiate하고 contain한다. 
• ViewModel should never contain references to activities, fragments or views. 
  Why? 우리가 ViewModel을 사용하는 이유에 대해 생각해보라. ViewModel이 configuration changes를 살아남기 때문이다. 
  본래 acitivity, fragment and view는 configuration changes 에서 살아남을 수 없다. 

Why ViewModel should never contain references to activities, fragments or views?

ViewModel에서 configuration changes로 더 이상 화면에 보여지지 않는 acitivity, view, fragment에 대한 reference를 가지고 있다면 clean up 되어야하는 reference를 가지고 있는 것이다. 
Best case scenario에서는 사소한 메모리 누수이지만, worst case scenario에서는 스크린에 없는 old fragment로 무언가를 하려는 것이기 때문에 error를 발생시킬 수 있다. 

11. The Benefit of a Good Architecture

이 디자인의 다른 부면으로 code가 modular하다는 것인데, UI Controller는 ViewModel에 대해서 알지만 ViewModel은 UI Controller에 대해서 모른다.

이 architecture의 목표 중 하나는 class 간에 reference의 수를 적게 유지하는 것이다. 또 다른 측면 및 유익은 ViewModel이 activity나 fragments, views에 대해 reference를 가지고 있지 않다는 것이다. 이것은 testing 시에 유용하다. 프로젝트에는 2가지 Test가 존재하는데 android Test(에뮬레이터가 필요한)와 Test(에뮬레이터가 필요없는)이다. ViewModel에 대한 reference가 없기 때문에 pure lightweight 안드로이드 프레임워크에 의존하지 않는 유닛 테스트를 진행 할 수 있고 따라서 테스트를 작성하는데에 더 빠르고 쉽다. 

- organized: the code is more organized, manageable, and debuggable
- easier to debug: protect yourself from having to worry about lifecycle problems and bugs. 
- fewer lifecycle issues
- modular: easier to swap out and update sections of code
- testable

13. LiveData

LiveData: An observable data holder class that is lifecycle-aware

 

LiveData 내부에 싸여있는 Data가 바뀌면 state가 변하는 것과 같다. 

15. Lifecycle Awareness

• LiveData will only update UI Controllers that are actually on-screen
  - If your fragment goes off-screen and the value of LiveData changes, it would not update the off-screen fragment. If UI Controller is off-screen, it gets no updates. 
• If UI Controller comes back on-screen, get the current data immediately
• If UI Controller observes, it gets the current data immediately
• If UI Controller is destroyed, it cleans up the connection. 

16. Exercise: Add LiveData Encapsulation to GameViewModel

캡슐화(Encapsulation): The notion of restricted direct access to the object's fields. 외부에서 내부의 값을 쉽게 수정할 수 있다면 여러 버그를 야기할 것. 버그를 찾기도 어려워짐. 

해결방법
내부에는 mutableLiveData, 외부에는 LiveData. Kotlin backing property라고 부름. It allows you to return something from a getter other than the exact object. 

22. Exercise: Add a ViewModelFactory

ViewModelFactory: A class that knows how to create ViewModels. Factories are classes that knows how to initiate object.