⭐ riverpod : 2️⃣

riverpod 라이브러리에 대해 학습한지 벌써 약 2주가 흘렀다.
개인 과제 시작 전, provider를 접한 뒤 비슷하다고 생각해 금방 적응할 수 있을 줄 알았다.

Provider와의 가장 큰 차이점은 상태를 하나밖에 관리 할 수 없기에 다른 접근 방식이 필요하다.
또 다른 차이점으로는 Provider끼리 ref를 통해 참조할 수 있다.
따라서, 주요 logic을 위주로 viewmodel을 분류하고 해당 logic끼리 데이터를 주고 받는 과정이 필요하다.

주의할 점으로는 provider의 생명주기는 참조 카운팅 메커니즘에 의해 결정된다.
Generator를 사용한다면, autoDispose 기능으로 생명주기를 알아서 관리해주지만, 레거시 방식을 선택했다면 상태의 초기화가 언제 되는지 잘 살펴볼 필요가 있다.

1. Provider는 선언되었다고 해서 메모리에 바로 올라가지 않는다.
   단순 class 정의이기 때문에 UI에서 wacth를 호출하거나 해당 Provider를 처음 참조하기 시작할 때 메모리 상에 올라가게 된다.

2. 이후, Provider는 자신에게 빨대 꽂은, 즉 자신을 참조 중인 리스너의 수를 기억한다.
   watch를 통해 구독중이거나 참조중인 Provider가 있다면 생명은 유지된다.

3. Provider를 watch하던 마지막 위젯이 dispose 될 때, 같이 dispose 된다.

참고로 read는 생명주기와는 관계없이 파괴될 수 있다.
다시 다른 곳에서 참조되면 초기화부터 다시 시작된다.

⭐ Widget , Element, Render : 2️⃣

내가 적는 건 단지 class들인데 어떻게 디바이스의 화면에 나타날 수 있을까?
궁금증을 해결하기 위해 튜터님을 찾아갔다.

결론부터 말하자면, Widget Tree, Elemenet Tree, RenderObject Tree는 개발자의 손에서부터 단계별로 거쳐간다.

Widget는 설계 단계이다.
코드를 입력하면 Widget은 Tree에 부모 자식 관계로 연결된다.
최상위 MaterialApp부터 각 Page가 위치하게 되며, 여기서 Widget은 다시 화면에 그릴 수 있는 위젯과 없는 위젯으로 나뉜다.

Element는 설계도에 무엇을 끼워넣을지 고민하는 단계이다.
Widget에 대한 실질적인 정보(BuildContext)를 가지고 있으며, 만약 Widget Tree에서 Key 값과 RuntimeType이 다른 Widget이 발견되면 rebuild를 실행하고 Element를 수정한다.
추가적으로, RenderObject Element는 Render Tree로 넘긴다.

Render Tree에서는 Element Tree에서 넘겨받은 Object를 바탕으로 자체 그래픽 엔진을 이용해 화면을 일부 완성한 뒤, 그리지 못한 부분의 정보와 함께 iOS와 Android에게 넘긴다.

추가적으로 학습 할 것들

• DIO 라이브러리
• REST API Docker 통해 받아오기
• Web Socket