Flutter / 4탄 : Flutter의 상태관리

 

클라이언트 개발을 한 단어로 표현하자면 다음과 같습니다 “상태 관리”. 오늘은 Flutter가 상태관리를 하는 법에 대해서 알아보도록 하겠습니다. 이번 내용은 Flutter의 UI 작동방식에 대해서 잘모르시면 이해가 어려우실 수 있습니다. 만약 잘 모르신다면 먼저 Flutter UI 작동방식에 대해 공부해주세요

 

Flutter / 3탄 : Flutter의 UI에 관하여

Flutter / 3탄 : Flutter의 UI에 관하여

 

목차

1. 선언적 UI 방식(Declaratively UI Programming)
2. Ephemeral(임시) State Vs. App State
3. Provider를 통한 AppState관리
4. 마치면서

 

선언적 UI 방식

Flutter의 상태관리를 이해하기 위해서는 Flutter의 UI 작성방법인 ‘선언적 UI 방식’에 대해 이해해야 합니다. 간략하게 설명하자면 ‘선언적 UI 방식’에서는 UI 객체를 직접 생성하지 않고, UI 객체에 대한 설계도를 작성합니다. 그러면 Framework가 설계도를 바탕으로 UI 객체의 생성, 관리를 전부 처리해줍니다. 즉 우리는 UI 객체의 세세한 요소에 대해서 알 필요없이 설계도만 작성하면 되는 것 입니다.

 

하지만 UI 객체 생성, 관리를 Framework가 처리해준다면 UI 변경에는 어떻게 대처해야 할까요? UI 객체를 갖고있지 않으니 직접 UI객체에 접근하여 변경하는 것은 불가능합니다. ‘선언적 UI 방식’에서는 변경이 일어날때 해당 변경에 맞추어 새로운 UI 객체를 생성합니다. 이제 이 뒤에 얘기할 Flutter의 상태관리에서 해당 개념에 대해서 명료하게 이해하실 수 있을 것 입니다. 만약 이해를 못하셨다면, 아래의 내용을 보고 다시 보면 이해가 보다 쉬우실 겁니다.

 

좀 더 자세한 설명을 원하시는 분은 아래의 글을 읽어주세요 :)

 

Flutter 공식문서 (선언적 UI 방식)

Introduction to declarative UI

 

Ephemeral(임시) State Vs. App State

Flutter에는 크게 두 가지의 상태가 존재합니다. Ephemeral State, App State 이 둘에 대해서 이제부터 알아보도록 하겠습니다. 여기서 부터는 Flutter의 UI 작동방식(Widget, Stateless Widget, Stateful Widget, etc..)에 대해서 명확히 이해하셔야 합니다.

 

1. Ephemeral(임시) State

Ephemeral State(UI State, Local State)는 단일 위젯에 깔끔하게 포함할 수 있는 상태입니다. 정의가 굉장히 추상적이고 모호한데 이것은 일부로 이렇게 정의한 것이라고 합니다. 아마 정확히 한 가지로 정의하기 어려웠던 것 같습니다. 그렇기에 이해를 돕기위해 몇 가지의 예시를 들겠습니다.

 

1. 현재페이지에 PageView

 

2. 복잡한 애니메이션의 현재 진행 상황

 

3. 현재 선택된 BottomNavigationBar

 

대충 감이 오시나요? 위에 해당되는 것은 StatefulWidget들에 해당되는 내용들입니다. 굳이 해당 StateFulWidget외에 다른 Widget들이 알 필요가 없는 상태들입니다. 위의 Ephemeral State(UI State, Local State)의 정의가 기억나시나요? “단일 위젯에 깔끔하게 포함할 수 있는 상태”

 

2. App State

App State(Application State, Shared State)는 Ephemeral State 와는 다르게 앱의 여러부분에서 공유하고 사용자 세션간에 유지되어야하는 상태입니다. 설명이 난해한데 아래의 예시를 보시면 이해가 쉬우실 것 입니다.

 

1. 사용자 환경설정

2. 로그인 정보

3. 전자 상거래 앱(쿠팡)의 장바구니

4. 뉴스 앱의 Read/Unread State

 

App State를 구현하는 방법은 다음 챕터인 Provider를 이용한 상태관리에서 다뤄보도록 하겠습니다.

 

3. Ephemeral(임시) State, App State 사용 규칙

과연 어떨때 Ephemeral State를 사용하고 어떨때 App State를 사용해야하는지에 관한 명확한 규칙이 있을까요? 정답은 ‘없다’입니다. 이에 대해 Redux의 개발자인 Dan Abramov 는 다음과 같이 말합니다.

 

“덜 어색한 것을 하십시오”

 

설명이 부족하신 분은 아래의 링크를 참고해주세요

 

Flutter 공식문서 (Differentiate between ephemeral state and app state)

Differentiate between ephemeral state and app state

 

Provider를 이용한 App State관리

Provider는 App State를 관리하기 위해 Flutter에서 제공하는 라이브러리입니다. Provider외에도 (Redux, Rx, Hook)등을 사용할 수 는 있지만 별다른 이유가 없다면 Flutter에서 지원해주는 Provider를 사용하는게 좋습니다. 그럼 지금부터 Provider에 대해서 알아보도록 하겠습니다.

 

Provider에는 여러가지의 요소가 존재하지만, 가장 대표적인 것 4개에 대해서 살펴보도록 하겠습니다.

 

1. ChangeNotifer

2. ChangeNotiferProvider

3. Consumer

4. Provider.of

 

각각 요소들에 대해서 살펴보도록 하겠습니다.

Provider를 사용하기 위해서는 pubspec.yaml에 다음과 같은 의존성을 추가해야 됩니다. (예제 코드를 쳐보고 싶으신 분들을 위해)

dependencies:
  flutter:
    sdk: flutter

  provider: ^3.0.0 // 추가해주세요

dev_dependencies:

 

1. ChangeNotifier

말그대로 변경사항을 알릴 수 있는 클래스입니다. notifyListener()를 사용하면 ChangeNotifier를 구독하고 있는 Listener에게 변경사항이 전달됩니다. 지금은 잘 이해가 안되실 수 있으나, 나머지(ChangeNotifierProvider, Consumer)를 살펴보고 난 후에는 이해하시는게 보다 쉬우실 것 입니다. 만약 Reactive Porgramming 혹은 Observer Pattern에 대해서 알고계신 분들은 익숙하신 개념이라 이해하기 쉬우실 것 입니다. 아래는 이해를 돕기위한 예제 코드입니다.

class CartModel extends ChangeNotifier { // ChangeNotifier를 상속함
  CatalogModel _catalog;

  final List<int> _itemIds = [];

  CatalogModel get catalog => _catalog;

  set catalog(CatalogModel newCatalog) {
    _catalog = newCatalog;
    notifyListeners(); // 변경사항을 구독하고 있는 리스너에게 전달함
  }

  List<Item> get items => _itemIds.map((id) => _catalog.getById(id)).toList();

  int get totalPrice =>
      items.fold(0, (total, current) => total + current.price);

  void add(Item item) {
    _itemIds.add(item.id);
    notifyListeners();
  }
}

추가적으로 ChangeNotifier는 flutter:foundaition에 있고 higher-level classes(고수준 클래스 : Widget, etc,,) 에 의존성이 없어서 테스트하기가 쉽다고 합니다. 만약 Widget과 같은 복잡한 클래스(Widget 생성, 관리 코드 등등)를 상속하거나 알고있으면 테스트하기가 어렵겠죠,,, 아래는 간단한 단위 테스트입니다.

test('adding item increases total cost', () {
  final cart = CartModel();
  final startingPrice = cart.totalPrice;
  cart.addListener(() {
    expect(cart.totalPrice, greaterThan(startingPrice));
  });
  cart.add(Item('Dash'));
});

 

2. ChangeNotifierProvider

ChangeNotifierProvider는 ChangeNotifier를 하위 항목에 제공하는 위젯입니다. 아까전에 ChangeNotifier를 구독하고 있는 Listener에게 변경사항이 전달된다고 하였습니다. ChangeNotifierProvider는 하위 항목들에게 ChangeNotifier를 제공하여 구독할 수 있도록 해줍니다.

 

다음은 ChangeNotifierProvider를 정의하는 코드입니다.

void main() {
  runApp(
    ChangeNotifierProvider( // 여기에 집중
      create: (context) => CartModel(),
      child: MyApp(),
    ),
  );
}

ChangeNotifierProvider는 똑똑해서 CartModel의 Instance를 잘 관리해줍니다. CartModel의 Instance를 굳이 다시 rebuild 할 필요가 없고, dispose() 또한 ChangeNotifierProvider가 적절한 시점에(CartModel이 더 이상 필요없을때)자동으로 호출해줍니다. 한 문장으로 말하자면 ChangeNotifierProvider에서 생성한 ChangeNotifier(CartModel)은 이후에 신경쓸 필요없습니다.

 

위의 예제는 단 한개만의 ChangeProvider를 선언하였는데요. 다음과 같이 여러개의 ChangeProvider를 선언할 수 도 있습니다.

void main() {
  runApp(
    MultiProvider(
      providers: [
        ChangeNotifierProvider(create:(context) => CartModel()),// 1
        Provider(create: (context) => SomeOtherClass()), // 2
      ],
      child: MyApp(),
    ),
  );
}

 

3. Consumer

드디어 ChangeNotifier를 구독하고 있는 Listener 구간까지 도달했습니다. Consumer는 ChangeNotifierProvider에서 하위 항목에서 ChangeNotifier에 접근할 수 있게 하였습니다. 따라서 다음과 같은 코드가 가능합니다.

return HumongousWidget(
  child: AnotherMonstrousWidget(
    child: Consumer<CartModel>( // 여기에 집중
      builder: (context, cart, child) {
        return Text('Total price: ${cart.totalPrice}');
      },
    ),
  ),
);

우리가 위에서 정의했던 ChangeNotifier의 이름은 CartModel입니다. 따라서 Consumer<CartModel> 과 같이 표기합니다. 그 다음 눈에 들어오는 것은 builder 함수입니다. Consumer 위젯의 유일한 필수 인자가 바로 builder 함수입니다. builder함수는 3가지의 인수로 작동합니다.

 

1. context
2. 모든 build함수는 context를 인수를 가집니다.
3. ChangeNotifier
4. 우리가 정의한 ChangeNotifier(CartModel)입니다. ChangeNotifier의 데이터를 통해서 우리가 원하는 Widget을 작성할 수 있습니다.
5. child
6. 이름 그대로 가지고 있었던 서브트리 위젯입니다. 이를 이용해서 다시 서브트리를 작성하지 않고 재활용할 수 있습니다. 즉 최적화를 하는데 유용하게 사용할 수 있습니다. 아래는 해당 코드입니다.

Consumer<CartModel>(
  builder: (context, cart, child) => Stack(
        children: [
          child, // 다시 사용함
          Text("Total price: ${cart.totalPrice}"),
        ],
      ),
  child: SomeExpensiveWidget(),
);

이렇게 작성된 Consumer 위젯은 ChangeNotifier(CartModel)에서 notifyListener()가 호출되면, 정의한 builder함수를 호출하여 새로운 위젯을 반환합니다. 여기까지 도달하셨다면 ChangeNotifier에 대해서 보다 쉽게 이해하실 수 있으실 것 입니다.

 

4. Provider.of

Provider.of 도 Consumer와 같이 ChangeNotifier를 구독하고 있는 Listener입니다. Consumer와 다른 점이라고 한다면 Provider.of는 위젯이 아니라 ChangeNotifier 그 자체를 반환합니다. 아래의 코드를 보면 보다 명확히 이해하실 것 입니다.

 

class _CartList extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // 그냥 CartModel을 반환함
    var cart = Provider.of<CartModel>(context); 
    
    return ListView.builder(
      itemCount: cart.items.length, // 사용 지점
      itemBuilder: (context, index) =>
          ListTile(
            leading: Icon(Icons.done),
            title: Text(
              cart.items[index].name // 사용 지점
            ),
          ),
    );
  }

만약 ChangeNotifier에서 notifyListener()가 호출되면 해당 StatelessWidget의 build() 다시 호출합니다. 만약 StatefulWidget 이라면 State.didChangeDependencies를 호출합니다. 간단히 말하자면 해당 Widget을 재빌드합니다.

 

Provider.of 에는 특별한 사용법이 하나 더 있습니다. 만약 ChangeNotifier(CartModel)을 통해 UI를 구성하는게 아니라, 데이터를 초기화(removeAll() 함수와 같은 작업) 하려고 했다면 Widget을 다시 build()하는 것은 비용적 손해이지 않을까요? 그럴때는 다음과 같이 코드를 작성하면 됩니다.

 

Provider.of<CartModel>(context, listen: false).removeAll();

 

이런식으로 Provider.of 에서 lsitener 인자를 false로 설정하게 되면, notifyListener()가 호출되어도 Widget이 다시 build 되지 않습니다.

 

설명이 부족하신 분은 아래의 링크를 참고해주세요

 

Flutter 공식 문서 (상태관리 앱 샘플)

Simple app state management

Flutter 공식 문서 (Provider API docs)

provider | Flutter Package

FLutter 상태관리 예제 앱 Github

flutter/samples

 

마치면서

Client 개발은 어쩔 수 없이 결국에는 “상태 관리”라는 것을 Flutter를 하면서 많이 느끼고 있습니다. 결국에 UI 자체는 상태를 나타내는 것 뿐이고, 네트워크는 서버로부터 상태를 받아오고 업데이트 하는 것 입니다. 즉 Client 개발의 근본은 ‘상태’에 있는 것 입니다. 그렇기에 오늘의 글(Flutter 상태관리)은 좀 더 집중하게 되고 재미있었던 편인 것 같습니다.

 

틀린 부분이 있으면 댓글로 지적해주세요 ㅎㅎ

 

감사한 마음으로 수정하겠습니다.

 

감사합니다 :)