지난 주부터 듣던 Flutter 기초 강의를 모두 들었다.
후반에 미세먼지 앱을 만드는 부분이 있었는데 모델링 부분에서 '이렇게 해도 되나?'라는 고민이 많았고, 이전 강의들보다 다루는 데이터도 많고 리팩토링도 계속 하다보니 조금 헷갈리는 부분이 많았다.
특히 상태관리를 StatelessWidget과 StatefulWidget만 사용하다보니 데이터를 전달하고 관리하는게 중요했다.
강의를 다 듣고 나서, 우리 앱에서도 사용하고 있는 상태관리 패키지인 riverpod을 공부하기 시작했는데 정리하면서 생각해보니, 왜 상태관리 패키지를 사용하는지 알 것 같다.
상태관리 패키지를 사용하면 훨씬 더 편하게 데이터들을 관리할 수 있고, 각 위젯에서 필요한 데이터들을 쉽게 접근하고 watch할 수 있을 것 같다.
그리고 드디어 api 통신을 해보았는데, dio라는 패키지를 사용하였다.
생각보다 데이터를 불러오는 건 간단한 거 같은데, 데이터를 잘 모델링해서 ui와 데이터가 잘 분리해서 의존성을 낮추는게 어려운 것 같다.
Riverpod
flutter에서 많이 사용하는 상태관리 패키지로는 GetX, Provider, Block 등이 있다.
riverpod의 공식 문서는 한국어도 지원하고 있다.
마침 구매한 flutter 중급 강의에서 riverpod에 대한 파트가 있어서 강의를 들으면서 공식문서를 같이 보았다.
https://www.inflearn.com/course/%ED%94%8C%EB%9F%AC%ED%84%B0-%EC%8B%A4%EC%A0%84/dashboard
riverpod은 provider와 같은 개발자가 만들어서인지, 기본적으로 provider를 사용한다.
상태관리를 해야하는 데이터는 provider로 제공하고, 이를 consumerWidget이 소비하는 개념으로 이해해도 될 것 같다.
기존의 statelessWidget은 ConsumerWidget이, statefulWidget은 ConsumerStatefulWidget로 대체된다.
주로 사용하는 메서드는 watch, read, listen인데 공식문서에서는 기본적으로 watch를 사용할 것을 권장하고 있다.
그러나 비동기처리에서는 watch와 listen 대신 read를 사용해야한다.
listen은 데이터를 저장하지 않고 다른 메서드를 사용하기 위해 상태관리하고 있는 데이터를 참고해야 할 때 사용한다.
또, 패키지에서 제공하는 provider들은 대부분 캐싱이 되기 때문에 한 번 데이터를 불러오고 나면 그 다음에는 캐싱된 데이터를 불러온다.
메모리도 자동적으로 해제해주는 provider도 있어서 최적화 측면에서도 유용하게 사용할 수 있을 것 같다.
뭔가 새로운 걸 만들어보려고 하는데 그래도 강의를 듣고, 우리 앱 코드를 보면서 크게 그림은 그려지는 것 같다.
다음에는 아키텍처에 대한 공부를 더 해보고 싶은데, 우선은 간단한 클론코딩을 하면서 플러터가 손에 익는 과정이 필요할 것 같다.
지금 생각으로는 ui와 데이터를 불러오는 부분을 구분하고 중간에 provider와 repository를 잘 사용해서 서로 의존성을 낮추고 싶다.
먼저 페이지를 그리면서 필요한 경우 widget들을 분리하고, 적절한 데이터 모델을 만들고, 마지막으로 서버와 데이터 모델을 연결해서 데이터를 실제 데이터로 바꿔주는 방식으로 작업을 하면 될 것 같다.
체력이 좀 떨어진 느낌이라 살짝 걱정되기는 하는데, 페이스 조절 잘 하면서 이것저것 해봐야겠다!
'회고' 카테고리의 다른 글
20220907-08 TIL #ui작업하기 #위젯 #비즈니스로직분리하기 (0) | 2022.09.13 |
---|---|
20220906 TIL #있는 위젯을 써야할까, 새로운 위젯을 만들어야 할까? (1) | 2022.09.06 |
[2022년 8월] 회고!! #Flutter (0) | 2022.08.31 |
20220829 TIL #비동기 then과 async/await (0) | 2022.08.30 |
[2022]0822-0828 WIL #Flutter 기본 정리 (0) | 2022.08.30 |