상세 컨텐츠

본문 제목

[Flutter] Todo 앱 (상태관리 Cubit, BLoC, riverpod, get_it, GetX, 아키텍처)

notes

by 서울의볼 2024. 4. 30. 17:09

본문

- State Management는 최초 개발을 빠르게 하고 앱 스펙이 수정되었을 때 필요한 부분을 빠르게 찾고 수정할 수 있게함.

- MVC -> MVP -> MVVM으로 진화해왔는데, 이젠 선언형 UI, declarative UI로 전국통일함.

- Statement Management는 scoped model과 static model로 나뉘는데,

- scoped model은 화면/위젯에 국한하여 영향을 미치도록 범위를 조정하는 방식.

- static model은 전역으로, 앱 전체에서 누구나 해당 스테이트로 접근할 수 있는 형태.

- 가령 유튜브 화면을 예시로 들었을 때, 둘 다 가능함:

- 또 다른 예를 들어, 새로운 문서의 doc를 작성한다 하면 각 문서별로 스코프 모델을 활용해야 할 것임.

- 정리하자면, 스코프는 1) 해당 스코프 화면이 사라지면 자동으로 메모리 해제가 됨. 2) child에서 데이터 참조를 할 때 id(구별자) 없이도 상위 데이터 참조 가능함.

- 스태틱은 1) 메모리 관리를 개발자가 직접 관리해야함 (들고있는 걸 언제 날릴 지 결정해야 함) 2) child에서 데이터를 참조할 때 id(구별자)가 항상 필요함. 3) 스코프 대비 구현이 쉽고, 4) 모든 코드에서 원하는 스테이트에 접근하고 수정이 가능함. --- 노드 할 땐 스태틱으로 한 것으로 추정됨.

 

- 기존에 보통 emptyExpanded 썼는데, spacer로 하니 좋음. 스페이서 쓰자.

 

- 3.5.2에선 inherited widget을 썼는데, getx (+RxList) & obs/Obx 위젯으로 상태관리 수정함. 더 간단해짐. 

 

- Cubit vs Bloc 가장 큰 차이는, 큐빗은 UI에서 바로 큐빗에 함수를 이용해 명령을 내리고, 블럭은 직접적인 명령이 아닌, 중간에 이벤트를 통해 명령을 내림.

 

- Riverpod은 여러 패키지들이 서로 유기적으로 연동이 될 수 있게 도와줌.

- 리버팟은 전역적인 변수 선언을 해서 설계함. 데이터가 전역으로 들어있는 것은 아니래.

 

- hook 전망 좋음. Custom한 use함수 사용하기 좋음.

 

- 좋은 앱은 1) 구조파악 쉬워야 하고, 2) 작성하는 코드 양 및 좋은 가독성이 필요. 3) 안정성이 높아야 하는데, 이 말은 테스트코드 작성이 가능해야 한다는 뜻. 4) 확장성도 신경써야함.

- 상태관리 비교:

- GetxController 안에 직접 필드로 들고있어 GetX는 별도의 스테이트 형태가 아닌, 변수처럼 사용 가능.

- Cubit, Bloc은 한 종류의 스테이트 객체만 관리하고, 기능/화면 별 wrapping state data 필요함. copyWith 함수도 항상 필요함.

- Riverpod도 비슷한데, StateNotifier 안에 State 객체를 한 종류만 넣을 수 있고, 가이드에서는 새 state객체 사용을 권함.

- 내 소감은 리버팟이 가장 직관적이고 합리적인 것 같음.

 

 

 

아키텍처 & 상태관리

3.5.1) Scope vs Static Model 개념

3.5.2) 상태 관리 없는 ToDo 앱 처음부터 만듦

3.5.3) Getx로 상태관리, 기존에 참고했던 data holder를 mixin class 이용해서 수정

3.5.4) Bloc을 이용해서 상태관리 (GetX -> Cubit/Bloc)

3.5.5) Riverpod으로 변환

3.5.6) Flutter Hooks - stateful widget 대체, hooks riverpod 활용

 

 

 

출처: 패스트캠퍼스

관련글 더보기