본문 바로가기
플러터/플러터 사용기

플러터-프로바이더-라이브러리-정리

by 신재은👩🏼‍💻 2024. 2. 2.

클래스

 

  • ChangeNotifierProvider<T extends ChangeNotifier?>: ChangeNotifier를 청취하고, 이를 후손에게 제공하며, ChangeNotifier.notifyListeners가 호출될 때마다 의존하는 위젯들을 재구성합니다.

=> changenotifier, notifylisteners로 묶어서 상태 관리할 때 쓰는 가장 기본적인 형태.

  • ChangeNotifierProxyProvider: 다른 값을 기반으로 ChangeNotifier를 생성하고 동기화하는 ChangeNotifierProvider입니다. ChangeNotifierProxyProvider0부터 ChangeNotifierProxyProvider6까지 여러 값을 동기화할 수 있는 버전들이 있습니다.
  • ChangeNotifierProxyProvider0: 외부 의존성이 없이 ChangeNotifier를 생성하고 동기화합니다.
  • ChangeNotifierProxyProvider: 단일 외부 의존성을 기반으로 ChangeNotifier를 생성하고 동기화합니다.
  • ChangeNotifierProxyProvider2: 두 개의 외부 의존성을 기반으로 ChangeNotifier를 생성하고 동기화합니다.
  • ChangeNotifierProxyProvider3: 세 개의 외부 의존성을 기반으로 ChangeNotifier를 생성하고 동기화합니다.
  • ChangeNotifierProxyProvider4: 네 개의 외부 의존성을 기반으로 ChangeNotifier를 생성하고 동기화합니다.
  • ChangeNotifierProxyProvider5: 다섯 개의 외부 의존성을 기반으로 ChangeNotifier를 생성하고 동기화합니다.
  • ChangeNotifierProxyProvider6: 여섯 개의 외부 의존성을 기반으로 ChangeNotifier를 생성하고 동기화합니다.
  1. 프록시 패턴 간단 설명: 프록시 패턴은 어떤 객체에 대한 접근을 제어하고자 할 때 사용되는 디자인 패턴입니다. 이 패턴에서 프록시 객체는 다른 객체에 대한 접근을 대리하거나 중개하는 역할을 하며, 실제 객체에 대한 요청을 전달하기 전에 추가적인 작업을 수행할 수 있습니다(예: 접근 권한 확인, 요청 로깅, 요청 수정 등).
  2. 여기서 프록시라는 단어 사용 이유: ChangeNotifierProxyProvider에서 '프록시'라는 단어를 사용한 것은 이 클래스가 다른 값이나 프로바이더로부터 받은 데이터를 기반으로 ChangeNotifier를 생성하고, 해당 ChangeNotifier의 상태를 관리하며, 필요한 곳에 상태를 제공하는 일종의 '대리인' 또는 '중개자' 역할을 하기 때문입니다. 이는 프록시 패턴의 개념과 유사하며, 이를 통해 외부 의존성과 연동된 복잡한 상태 관리 로직을 캡슐화할 수 있습니다.
  3. ChangeNotifierProxyProvider0과 ChangeNotifier의 차이: ChangeNotifierProxyProvider0은 외부 의존성 없이 ChangeNotifier를 생성하고 동기화하는 역할을 합니다. 즉, 외부 데이터에 의존하지 않고 자체적으로 ChangeNotifier 인스턴스를 생성합니다. 이는 일반적인 ChangeNotifierProvider와 유사해 보일 수 있지만, ChangeNotifierProxyProvider0는 특정 상황에서 프록시 패턴의 역할을 수행할 수 있는 확장성을 가지고 있습니다.
  4. 외부 의존성과 DI(Dependency Injection)의 관련성: 외부 의존성은 다른 객체나 데이터에 대한 의존성을 의미하며, DI(Dependency Injection)는 이러한 의존성을 외부에서 주입하는 패턴입니다. DI는 객체가 자신의 의존성을 직접 생성하는 대신, 외부(예: 프레임워크나 컨테이너)로부터 필요한 의존성을 주입받아 사용하는 방식입니다. ChangeNotifierProxyProvider에서 다루는 '외부 의존성'도 이러한 DI 패턴의 일환으로 볼 수 있으며, 플러터에서의 provider 패키지가 DI 역할을 수행합니다.
  5. DI 쉽게 설명:
    • 일반적인 DI: Dependency Injection(의존성 주입)은 객체가 필요로 하는 의존성(다른 객체, 설정, 리소스 등)을 외부로부터 받아오는 디자인 패턴입니다. 이를 통해 객체 간의 결합도를 낮추고, 유연성 및 테스트 용이성을 높일 수 있습니다.
    • 플러터에서의 DI: 플러터에서 DI는 provider 패키지 등을 통해 구현됩니다. 예를 들어, ChangeNotifierProvider를 사용하여 ChangeNotifier 객체를 위젯 트리의 특정 위치에 주입하고, 이를 하위 위젯에서 접근하여 사용할 수 있습니다. 이는 의존성을 필요한 곳에 쉽게 제공하고 관리할 수 있게 해주며, 앱의 다양한 부분에서 재사용성과 테스트 용이성을 향상시킵니다.
  • Consumer<T>: 조상으로부터 Provider<T>를 얻어서 그 값을 builder로 전달합니다. Consumer2부터 Consumer6까지 여러 Provider 값을 동시에 다룰 수 있습니다.
  1. Provider + Consumer 조합 사용 여부:
    • 네, 맞습니다. Consumer<T> 위젯은 Provider<T>와 함께 사용됩니다. Provider 패키지에서 제공되는 Consumer 위젯은 Provider.of<T>(context)를 내부적으로 사용하여, 지정된 타입 T의 Provider로부터 값을 얻어옵니다. 그리고 이 값을 builder 함수에 전달하여 UI를 구성하게 합니다. Consumer2부터 Consumer6까지는 동시에 여러 타입의 Provider 값들을 사용할 수 있게 해줍니다. 이를 통해 여러 의존성을 한 곳에서 처리하고, 필요한 위젯 부분만 재구성할 수 있게 합니다.
  2. ChangeNotifier + notifyListeners 조합과의 차이점:
    • ChangeNotifier와 notifyListeners() 조합은 상태 관리 객체인 ChangeNotifier 내에서 상태 변경을 관리하고, notifyListeners()를 호출하여 상태 변경을 구독하는 위젯들에게 알리는 방식입니다. 이 때, Provider.of<T>(context)나 Consumer<T>를 사용하여 상태 변경을 구독할 수 있습니다.
    • Consumer<T>는 Provider.of<T>(context, listen: true)와 유사한 역할을 하지만, UI의 어느 부분을 재구성할 지 더 세밀하게 제어할 수 있는 장점이 있습니다. 즉, 전체 위젯이 아닌 Consumer의 builder 부분만 재구성되도록 할 수 있습니다.
    • watch와 read는 provider 패키지의 새로운 버전이나 riverpod와 같은 다른 상태 관리 패키지에서 제공하는 메서드입니다. watch는 주어진 Provider의 값이 변경될 때마다 위젯을 재구성하도록 합니다. read는 Provider의 현재 값을 읽지만, 값이 변경되어도 위젯을 재구성하지 않습니다. watch와 read는 Provider.of(context)의 listen 파라미터를 사용하는 것보다 코드를 더 간결하게 만들고, 의도를 명확히 표현하는 데 도움을 줍니다.

결론적으로, Provider + Consumer 조합은 특정 위젯의 일부분만을 대상으로 상태 변경을 구독하고 싶을 때 유용하며, ChangeNotifier + notifyListeners는 상태 변경 로직을 관리합니다. watch와 read는 이러한 패턴을 더 편리하게 사용할 수 있도록 도와주는 메서드입니다. 상황에 따라 적절한 도구를 선택하여 사용하는 것이 중요합니다.

 

  1. Consumer2~6과 ProxyProvider2~6의 관계:
    • Consumer2부터 Consumer6까지는 Consumer 위젯의 변형으로, 동시에 여러 Provider의 값을 사용할 수 있게 해줍니다. 각각의 Consumer 위젯은 다른 타입의 Provider들로부터 값을 받아올 수 있습니다.
    • ProxyProvider2부터 ProxyProvider6까지는 ProxyProvider의 변형으로, 여러 Provider의 값을 결합하거나 변환하여 새로운 값을 생성하고 제공하는 역할을 합니다.
    • 따라서 Consumer2~6과 ProxyProvider2~6는 서로 다른 목적으로 사용됩니다. Consumer는 UI를 재구성하기 위해 여러 Provider의 값을 사용하는 반면, ProxyProvider는 여러 Provider의 값을 기반으로 새로운 값을 생성하고 제공하는 데 사용됩니다.
  2. Provider와 Consumer만으로 상태 관리 가능 여부:
    • Provider와 Consumer만으로도 상태 관리가 가능합니다. 하지만 상태 변경을 관리하고, 그 변경 사항에 따라 UI를 업데이트하려면 상태 변경을 알릴 수 있는 메커니즘이 필요합니다. ChangeNotifier와 notifyListeners()는 이러한 목적으로 자주 사용되며, 상태 변경을 쉽게 관리하고, 관련된 위젯들을 효과적으로 재구성할 수 있게 해줍니다.
    • Provider 패키지는 다양한 타입의 프로바이더를 제공하며, 각각의 사용 사례에 맞게 선택하여 사용할 수 있습니다. 예를 들어, ValueNotifier와 ValueListenableProvider를 사용하여 간단한 상태 관리를 수행할 수도 있습니다.
  3. 로직 구현 위치:
    • 상세한 로직이나 상태 관리 로직은 일반적으로 ChangeNotifier 내에 구현됩니다. ChangeNotifier 내에서 상태를 업데이트하고 notifyListeners()를 호출하여 상태 변경을 구독하는 위젯들에게 알립니다.
    • Provider와 Consumer는 ChangeNotifier로부터 제공받은 값을 UI에 반영하고, 필요에 따라 위젯을 재구성하는 데 사용됩니다. 즉, 상태 관리 로직은 ChangeNotifier에, UI 업데이트는 Provider와 Consumer를 통해 수행됩니다.
  4. watch와 read의 독립적 사용 여부:
    • watch와 read는 context의 확장 메서드로, provider 패키지의 일부입니다. 이 메서드들은 Provider로부터 상태를 읽어올 때 사용되며, 일반적으로 ChangeNotifier와 같은 상태 관리 클래스와 함께 사용됩니다.
    • watch는 Provider의 값이 변경될 때마다 위젯을 재구성하는 데 사용되고, read는 단순히 값을 읽어올 때 사용됩니다. 이 메서드들은 Provider 패키지의 상태 관리 메커니즘과 함께 사용되므로, 독립적으로 사용한다기보다는 Provider와 함께 사용된다고 보는 것이 더 정확합니다.
  • DeferredInheritedProvider<T, R>: 청취하는 객체가 방출하는 객체가 아닌 상황에서 사용되는 InheritedProvider의 변형입니다.

DeferredInheritedProvider<T, R>는 InheritedProvider의 변형으로, 특정한 사용 사례에서 유용합니다. 이 변형은 청취하는 객체(T)가 실제 위젯 트리에 제공하는 객체(R)와 다를 때 사용됩니다. 즉, DeferredInheritedProvider를 사용하면, 하위 위젯이 T 타입의 객체를 청취하지만, 실제로 InheritedWidget을 통해 제공되는 객체는 R 타입이라는 의미입니다.

이를 사용하는 이유:

  1. 성능 최적화: DeferredInheritedProvider를 사용하는 주된 이유 중 하나는 성능 최적화입니다. 예를 들어, 복잡한 객체를 생성하는 데 비용이 많이 드는 경우, 실제로 필요할 때까지 객체의 생성을 지연시키고 싶을 수 있습니다. 이럴 때, DeferredInheritedProvider를 사용하여 객체의 생성을 지연시키고, 실제로 필요한 하위 위젯에서만 객체를 생성하도록 할 수 있습니다.
  2. 조건부 노출: 특정 조건에 따라 다른 타입의 객체를 하위 위젯에 노출하고 싶은 경우에 사용할 수 있습니다. 예를 들어, 사용자의 권한 수준에 따라 다른 서비스를 제공하고 싶은 경우, DeferredInheritedProvider를 사용하여 사용자의 권한 수준에 맞는 서비스 객체를 선택적으로 하위 위젯에 노출할 수 있습니다.
  3. 유연성 제공: DeferredInheritedProvider는 개발자에게 더 많은 유연성을 제공합니다. 특정 타입의 객체를 청취하면서도, 실제로는 다른 타입의 객체를 위젯 트리에 제공할 수 있으므로, 다양한 상황에서 앱의 동작을 맞춤 설정할 수 있습니다.
  • FutureProvider<T>: Future를 청취하고, 그 결과를 자식과 그 후손에게 노출합니다.

FutureProvider<T>는 비동기적으로 데이터를 로드하고 있는 경우에 특히 유용합니다. 예를 들어, 네트워크 요청을 통해 데이터를 가져오거나, 파일 시스템에서 파일을 읽는 등의 작업이 Future를 사용하여 처리될 때 FutureProvider를 사용할 수 있습니다.

FutureProvider는 Future의 결과를 위젯 트리에 자동으로 제공하고, Future의 상태(로딩 중, 완료, 에러)에 따라 UI를 적절하게 업데이트할 수 있도록 도와줍니다. 이는 UI와 데이터 로딩 로직을 분리하여, 코드를 더 깔끔하게 관리할 수 있게 해줍니다.

사용 사례:

  • 네트워크로부터 데이터 로드: 앱이 시작될 때 서버로부터 사용자 정보, 설정 등을 로드해야 하는 경우.
  • 데이터베이스 쿼리: 로컬 데이터베이스에서 큰 데이터 세트를 비동기적으로 쿼리해야 하는 경우.
  • 파일 읽기/쓰기: 앱이 파일 시스템에서 데이터를 읽거나 쓸 때.

사용 방법 예시:

FutureProvider<MyData>(
  create: (context) => fetchMyData(), // 여기서 fetchMyData는 Future<MyData>를 반환하는 함수
  initialData: null, // Future가 완료되기 전에 사용할 초기 데이터
  child: MyWidget(), // 이 위젯 트리는 FutureProvider가 제공하는 데이터에 접근할 수 있음
);

 

FutureProvider를 사용하면 비동기 데이터 로딩 과정을 위젯 트리와 잘 통합할 수 있으며, Future의 완료 상태에 따라 로딩 인디케이터, 데이터를 표시하는 UI, 에러 메시지 등을 쉽게 전환할 수 있습니다. 따라서, 비동기 데이터 로드가 필요한 경우 FutureProvider 사용을 고려해보는 것이 좋습니다.

  • InheritedProvider<T>: InheritedWidget의 일반적인 구현으로, 제네릭 타입을 제공합니다.
  1. InheritedWidget이란?
    • InheritedWidget은 Flutter 프레임워크에서 상태 공유를 위해 사용되는 특별한 유형의 위젯입니다. InheritedWidget은 위젯 트리에서 데이터를 효율적으로 전달하고, 하위 위젯이 상위 위젯으로부터 데이터를 쉽게 접근할 수 있게 해줍니다. InheritedWidget의 인스턴스는 BuildContext를 통해 하위 위젯들에 접근할 수 있으며, 이를 통해 데이터를 공유할 수 있습니다.
  2. Flutter에서 InheritedWidget이 사용된 이유
    • Flutter에서 InheritedWidget이 사용되는 주된 이유는 위젯 트리의 상위에서 하위로 데이터를 효과적으로 전달하고, 데이터 변경 시 특정 하위 위젯들을 선택적으로 재빌드하기 위함입니다. 이를 통해 상태 관리가 필요한 앱의 여러 부분에서 데이터를 공유하고, UI를 동적으로 업데이트할 수 있습니다.
  3. Flutter 상태 관리로 InheritedWidget만 사용하면 곤란한 이유
    • InheritedWidget만을 사용하여 상태 관리를 하는 것은 몇 가지 한계가 있습니다. 예를 들어, InheritedWidget은 데이터를 전달하는 메커니즘을 제공하지만, 상태 변경을 감지하고 통보하는 내장 메커니즘이 없습니다. 따라서 개발자가 수동으로 상태 변경을 관리하고, 필요한 부분에서 InheritedWidget을 사용하여 데이터를 업데이트해야 합니다. 이는 상태 관리 로직을 복잡하게 만들 수 있으며, 대규모 애플리케이션에서는 유지보수가 어려워질 수 있습니다.
  4. InheritedWidget을 Provider로 구현한 것의 의미
    • InheritedProvider<T>는 InheritedWidget의 일반적인 구현으로서, Provider 패키지에서 제공됩니다. InheritedProvider<T>는 InheritedWidget의 기능을 활용하여 데이터를 전달하는 동시에, Provider 패키지의 편리한 API와 상태 관리 기능을 제공합니다. 이를 통해 개발자는 InheritedWidget의 상속 메커니즘을 활용하면서도, 보다 쉽게 상태 관리를 할 수 있게 됩니다.
  5. 제네릭 타입을 구현한 이유
    • 제네릭 타입을 사용하는 이유는 타입 안전성을 보장하고, 코드의 재사용성을 높이기 위함입니다. InheritedProvider<T>에서 제네릭 타입 T를 사용함으로써, 다양한 타입의 데이터를 효율적으로 관리하고 전달할 수 있습니다. 제네릭을 사용하면 개발자는 명시적으로 타입을 지정할 수 있으며, 컴파일 타임에 타입 체크를 수행하여 오류를 사전에 방지할 수 있습니다. 이는 앱의 안정성을 향상시키고, 유지보수를 용이하게 합니다.
  • ListenableProvider<T extends Listenable?>: Listenable을 청취하고, 이를 후손에게 노출하며, 리스너가 이벤트를 발생시킬 때마다 의존하는 위젯들을 재구성합니다. 여러 값을 동기화할 수 있는 ListenableProxyProvider 변형들도 있습니다.
  1. Listenable과 ChangeNotifier의 차이점:
    • Listenable은 Flutter에서 이벤트 리스너를 추가하거나 제거할 수 있는 간단한 인터페이스를 제공합니다. ChangeNotifier는 Listenable을 확장한 클래스로, notifyListeners() 메서드를 통해 등록된 모든 리스너들에게 알림을 보낼 수 있습니다. ChangeNotifier는 상태 관리에 더 특화되어 있으며, Listenable보다 더 복잡한 상태 변화를 관리할 때 주로 사용됩니다. Listenable은 보다 일반적인 용도로 사용되며, 상태 관리뿐만 아니라 다양한 이벤트 리스닝 시나리오에서 활용될 수 있습니다.
  2. Notify하는 것과 Listen하는 것의 차이:
    • notify는 어떤 이벤트나 상태 변화가 발생했음을 구독자(리스너)들에게 알리는 동작을 의미합니다. 예를 들어, ChangeNotifier에서 notifyListeners() 메서드를 호출하면, 이 객체에 등록된 모든 리스너들에게 변화가 있었음을 알립니다.
    • listen은 리스너(구독자)가 특정 이벤트나 상태 변화를 감지하고 이에 반응하기 위해 대기하는 동작을 의미합니다. 리스너는 Listenable 객체에 등록되어, 해당 객체에서 notify가 발생했을 때 반응할 수 있습니다.
  3. Listenable과 데이터 전송:
    • Listenable한 쪽(A)은 이벤트나 상태 변화를 발생시키는 주체입니다. 이 경우, B는 A의 변화를 감지하는 리스너가 됩니다. 즉, A에서 변화가 일어나면, A는 자신에게 등록된 리스너들(B 포함)에게 이를 알립니다(notify).
  4. 이벤트 리스너의 역할:
    • 이벤트 리스너는 이벤트에 반응하는 쪽입니다. 리스너는 특정 이벤트가 발생했을 때 실행될 콜백 함수나 메서드를 정의하며, 이를 통해 이벤트 발생 시 특정 동작을 수행합니다. 예를 들어, Listenable 객체에 이벤트 리스너를 등록하면, 해당 객체에서 이벤트가 발생할 때마다 리스너가 정의한 콜백이 실행됩니다.
  5. ListenableProxyProvider의 용도:
    • ListenableProxyProvider는 여러 Listenable 객체들로부터 발생하는 이벤트들을 통합하여 관리하고, 이를 기반으로 새로운 데이터나 객체를 생성하는 데 사용됩니다. 예를 들어, 두 개의 다른 Listenable 객체가 각각 다른 데이터 변화를 감지하고 있을 때, ListenableProxyProvider를 사용하여 이 두 변화를 기반으로 새로운 데이터를 생성하고, 이 데이터를 위젯 트리에 제공할 수 있습니다. 이를 통해 여러 데이터 소스의 변화를 동기화하고, 이에 기반한 새로운 상태나 데이터를 효율적으로 생성할 수 있습니다.
  • MultiProvider: 여러 프로바이더를 단일 위젯 트리로 결합하여, 중첩된 여러 계층의 프로바이더를 간소화합니다.

MultiProvider는 여러 프로바이더를 하나의 위젯 트리 안에서 관리할 수 있게 해주는 위젯입니다. 이는 주로 애플리케이션의 최상위 레벨에서 여러 상태 관리 객체들을 초기화하고 전체 앱에 걸쳐 이들을 사용할 수 있도록 할 때 사용됩니다. 하지만, MultiProvider의 사용은 메인에서 라우팅하는 경우에만 국한되지 않으며, 앱의 다른 부분에서도 여러 프로바이더를 사용해야 할 때 유용하게 사용할 수 있습니다.

사용 사례:

  1. 앱 초기화 시점: 애플리케이션의 최상위에서 여러 상태 관리 객체를 초기화하고, 이를 앱 전반에 걸쳐 사용할 수 있도록 할 때 MultiProvider를 사용합니다. 예를 들어, 사용자 정보, 테마 설정, 로케일 설정 등 다양한 상태 관리 객체를 초기화하고 제공할 수 있습니다.
  2. 특정 기능 모듈: 앱 내 특정 기능 모듈이나 화면에서 여러 상태 관리 객체를 필요로 할 때, 해당 모듈이나 화면의 최상위에 MultiProvider를 배치하여 필요한 모든 상태 관리 객체들을 제공할 수 있습니다. 이렇게 하면 해당 기능 모듈이나 화면에서 필요한 모든 데이터와 로직에 접근할 수 있습니다.
  3. 조건부 프로바이더 제공: 사용자의 권한이나 앱의 상태에 따라 다른 프로바이더를 제공해야 하는 경우, MultiProvider 내에서 조건부 로직을 사용하여 다른 프로바이더 세트를 제공할 수 있습니다.

예시 코드:

MultiProvider(
  providers: [
    ChangeNotifierProvider(create: (context) => SomeModel()),
    Provider(create: (context) => AnotherService()),
    // 여기에 필요한 만큼 프로바이더를 추가할 수 있습니다.
  ],
  child: MyApp(),
)

 

이 예시에서 MultiProvider는 SomeModel과 AnotherService 두 개의 상태 관리 객체를 앱 전반에 걸쳐 제공합니다. 이를 통해 개발자는 앱의 여러 부분에서 이러한 객체들에 쉽게 접근할 수 있으며, 프로바이더들을 중첩하여 사용하는 복잡성을 줄일 수 있습니다. 따라서 MultiProvider는 앱의 구조를 더 깔끔하고 관리하기 쉽게 만들어 줍니다.

  • Provider<T>: 값의 생명주기를 관리하며, 생성과 제거를 위임하는 프로바이더입니다.

 

Provider<T>는 가장 기본적인 프로바이더로, 값의 생명주기를 관리합니다. 이는 특정 타입의 데이터 또는 객체를 생성하고, 위젯 트리에서 필요한 곳에 제공하는 역할을 합니다. Consumer<T> 위젯은 Provider 패키지에 포함된 위젯 중 하나로, Provider로부터 제공된 데이터에 접근하여 UI를 구성할 때 사용됩니다.

  1. Consumer의 범용성:
    • Consumer<T> 위젯은 Provider 패키지 내에서 제공되는 모든 종류의 프로바이더와 함께 사용될 수 있습니다. 예를 들어, Provider<T>, ChangeNotifierProvider<T>, ListenableProvider<T>, ValueListenableProvider<T>, StreamProvider<T> 등 다양한 프로바이더와 함께 Consumer<T>를 사용하여 해당 프로바이더가 제공하는 데이터에 접근하고, 이를 기반으로 위젯을 구성할 수 있습니다. Consumer<T>는 제네릭 타입 T를 통해 어떤 타입의 데이터에 접근할 것인지를 명시하며, Provider로부터 해당 타입의 데이터를 받아서 사용합니다.
  • ProxyProvider: 다른 프로바이더들로부터 얻은 값에 기반하여 값을 빌드하는 프로바이더입니다. ProxyProvider0부터 ProxyProvider6까지 여러 값을 동기화할 수 있는 버전들이 있습니다.

ProxyProvider와 앞서 언급된 ChangeNotifierProxyProvider 및 ListenableProxyProvider는 모두 ProxyProvider의 변형입니다. 이들 모두는 다른 프로바이더로부터 얻은 값들을 기반으로 새로운 값이나 객체를 생성하고, 이를 위젯 트리에 제공하는 공통적인 역할을 합니다. 하지만, 각각의 ProxyProvider 변형들은 다루는 객체의 타입과 사용 사례에 따라 차이가 있습니다.

  1. ProxyProvider:
    • ProxyProvider는 가장 일반적인 형태의 ProxyProvider로, 다른 프로바이더들로부터 얻은 값들을 기반으로 새로운 값 또는 객체를 생성합니다. 특정 타입에 제한되지 않고, 일반적인 용도로 사용됩니다.
  2. ChangeNotifierProxyProvider:
    • ChangeNotifierProxyProvider는 다른 프로바이더들로부터 얻은 값들을 기반으로 ChangeNotifier 객체를 생성하고, 이 객체의 변화를 청취할 수 있게 합니다. 주로 ChangeNotifier를 사용하는 상태 관리에서 사용됩니다. ChangeNotifier 객체가 변화할 때마다 리스너들에게 알림을 보내 UI를 업데이트할 수 있습니다.
  3. ListenableProxyProvider:
    • ListenableProxyProvider는 Listenable 객체를 기반으로 새로운 객체를 생성합니다. Listenable 인터페이스는 ChangeNotifier와 같이 리스너를 추가하고 제거할 수 있는 기능을 제공하지만, 더 일반적인 이벤트 리스닝에 사용될 수 있습니다.

ProxyProvider0부터 ProxyProvider6까지의 버전들은 제공되는 프로바이더의 수에 따라 다릅니다. 예를 들어, ProxyProvider2는 두 개의 다른 프로바이더로부터 값을 받아 새로운 객체를 생성하고, ProxyProvider3는 세 개의 값을 받아 사용합니다.

결론적으로, 이들 모두는 프로바이더로부터 값을 받아 새로운 객체를 생성하는 공통된 목적을 가지고 있지만, 생성하는 객체의 타입(ChangeNotifier, Listenable, 일반 객체 등)과 사용하는 프로바이더의 수에 따라 구분됩니다.

  • ReassembleHandler: '핫 리로드' 발생 시 프로바이더가 알림을 받아야 할 경우 사용됩니다.
  1. 핫 리로드와 상태 유지: Flutter의 핫 리로드 기능은 개발자가 코드를 변경했을 때 빠르게 이러한 변경 사항을 반영하도록 설계되어 있습니다. 대부분의 경우, 핫 리로드는 앱의 상태를 유지하면서 UI만을 재빌드합니다. 즉, 전역 상태 관리 객체나 Singleton 객체들은 핫 리로드 시에도 그 상태가 유지되며, 이는 개발 과정을 효율적으로 만들어 줍니다.
  2. 비동기 작업과 핫 리로드: 핫 리로드 시에 비동기 작업이 자동으로 재실행되지는 않습니다. 예를 들어, 앱의 초기화 과정에서 실행되는 네트워크 요청이나 데이터베이스 쿼리 같은 비동기 작업은 핫 리로드가 발생해도 자동으로 다시 실행되지 않습니다. 이는 핫 리로드의 목적이 가능한 빠르게 UI의 변경 사항을 반영하는 것이기 때문입니다.
  3. ReassembleHandler의 역할: ReassembleHandler는 핫 리로드 시 특정 작업을 수행할 필요가 있을 때 유용합니다. 예를 들어, 개발 과정에서 특정 데이터를 다시 로드하거나, 애니메이션을 재시작하는 등의 작업을 핫 리로드 시에 수행해야 할 경우 ReassembleHandler를 사용할 수 있습니다. 하지만 모든 상황에서 ReassembleHandler가 필요한 것은 아니며, 대부분의 상태 관리 작업은 Provider와 같은 상태 관리 솔루션을 통해 이미 충분히 관리됩니다.

요약하자면, 핫 리로드는 주로 UI의 빠른 반복 개발을 위해 설계되었으며, 대부분의 상태는 유지됩니다. 하지만 특정 비동기 작업이나 초기화 코드는 핫 리로드 시 자동으로 재실행되지 않으므로, 필요한 경우 ReassembleHandler를 사용해 이를 관리할 수 있습니다. 모든 프로바이더에 ReassembleHandler를 구현할 필요는 없으며, 실제 필요한 경우에만 선택적으로 사용하면 됩니다.

  • Selector: Consumer와 유사하나, 제한된 수의 값만 선택하여 업데이트를 필터링하고, 변경되지 않으면 재구성을 방지할 수 있습니다. Selector0부터 Selector6까지 다양한 값을 다룰 수 있습니다.

Selector는 Provider 패키지의 유용한 위젯 중 하나로, Consumer 위젯과 유사한 역할을 하지만 더 세밀한 컨트롤을 제공합니다. Selector를 사용하면, 위젯 트리 내에서 Provider로부터 제공받는 데이터 중 특정 필드나 값을 선택하여 그 부분만을 기준으로 위젯을 재빌드할 수 있습니다. 이를 통해 앱의 성능을 최적화할 수 있으며, 불필요한 재빌드를 줄일 수 있습니다.

작동 방식:

  • Selector는 두 가지 주요 파라미터를 받습니다: selector와 builder.
  • selector 함수는 Provider로부터 제공받는 전체 데이터 모델 중에서 특정 데이터 조각을 선택하는 역할을 합니다. 이 함수는 선택된 데이터가 이전 빌드에서 선택된 데이터와 다를 때만 builder 함수를 호출하여 위젯을 재빌드하도록 합니다.
  • builder 함수는 선택된 데이터를 기반으로 UI를 구성합니다. selector에 의해 선택된 데이터가 변경되었을 때만 호출됩니다.

사용 사례:

Selector는 특히 데이터 모델 내 여러 필드가 있는 경우 유용하며, 그 중 일부만이 UI 업데이트에 영향을 주는 경우에 적합합니다. 예를 들어, 사용자 프로필 정보를 다루는 데이터 모델이 있고, UI에서는 단지 사용자의 이름만을 표시한다고 가정해 봅시다. 이 경우, 사용자의 다른 정보(예: 이메일, 프로필 사진 등)가 변경되어도 이름이 변경되지 않는 한 UI를 재빌드할 필요가 없습니다. Selector를 사용하면, 이름 필드만을 감지하여 해당 필드에 변경이 있을 때만 UI를 재빌드할 수 있습니다.

예시 코드:

Selector<UserModel, String>(
  selector: (_, userModel) => userModel.name, // UserModel에서 name 필드만 선택
  builder: (_, name, __) {
    return Text(name); // 선택된 이름을 텍스트 위젯으로 표시
  },
)

 

 

Selector0부터 Selector6까지의 버전은 동시에 여러 값을 선택하여 감지할 수 있게 해줍니다. 예를 들어, Selector2<A, B, S>는 두 개의 다른 값 A와 B를 선택하고 이 두 값의 조합에 따라 builder를 호출할지 결정합니다.

요약하자면, Selector는 성능 최적화를 위해 특정 데이터 조각의 변경에만 반응하여 위젯을 재빌드하고 싶을 때 매우 유용한 위젯입니다.

  • StreamProvider<T>: Stream을 청취하고, 그 내용을 자식과 후손에게 노출합니다.

StreamProvider<T>는 Flutter의 Provider 패키지에서 제공하는 또 다른 유용한 프로바이더 유형입니다. Stream을 사용하는 경우, 특히 실시간 데이터나 비동기 데이터 스트림을 다루는 애플리케이션에서 매우 중요합니다. StreamProvider는 Stream으로부터 오는 데이터를 청취하고, 이 데이터를 앱의 다른 부분에 쉽게 제공할 수 있게 해줍니다.

특징 및 사용 사례:

  • 실시간 데이터: StreamProvider는 실시간으로 업데이트되는 데이터를 다룰 때 매우 유용합니다. 예를 들어, 채팅 애플리케이션에서 새 메시지 스트림이나, 주식 애플리케이션에서 실시간 주식 가격 업데이트 등을 처리할 때 사용할 수 있습니다.
  • 비동기 데이터 흐름: 비동기적으로 데이터를 생성하고 소비하는 경우, StreamProvider를 사용하여 이러한 비동기 데이터 흐름을 위젯 트리의 다른 부분에 쉽게 제공하고 반응할 수 있습니다.
  • 리소스 해제 관리: StreamProvider는 자동으로 리소스 관리를 도와줍니다. Stream을 청취하고 있을 때 연결된 리소스가 필요 없어지면, StreamProvider는 자동으로 이러한 리소스를 해제할 수 있도록 도와줍니다.

예시 코드:

StreamProvider<MyData>(
  create: (context) => myDataStream, // myDataStream은 MyData 객체를 방출하는 Stream
  initialData: MyData.initial(), // 스트림이 초기 데이터를 아직 방출하지 않았을 때 사용할 초기 데이터
  child: MyApp(),
)

 

이 예시에서 StreamProvider는 myDataStream이라는 Stream을 청취하고, 이 스트림이 방출하는 MyData 객체를 애플리케이션의 다른 부분에서 접근 가능하게 합니다. initialData는 스트림이 최초의 데이터를 방출하기 전에 사용할 초기 데이터를 제공합니다.

요약하자면, StreamProvider<T>는 Stream을 통해 비동기적으로 업데이트되는 데이터를 앱 전반에 걸쳐 제공하고 반응할 수 있게 해주는 강력한 도구입니다. 실시간 데이터 흐름이나 비동기 작업의 결과를 UI에 반영해야 하는 경우에 특히 유용합니다.

  • ValueListenableProvider<T>: ValueListenable을 청취하고, 그 현재 값을 노출합니다.

ValueListenableProvider<T>는 특별히 ValueListenable<T> 객체를 사용하는 경우에 적합한 프로바이더입니다. ValueListenable<T>는 Flutter에서 제공하는, 값의 변화를 알릴 수 있는 간단한 리스너 인터페이스입니다. ValueListenableProvider는 이 ValueListenable 객체를 청취하고, 그 현재 값을 위젯 트리에 제공합니다.

ValueListenableProvider와 다른 프로바이더들의 주요 차이점은 다음과 같습니다:

  1. 특정 인터페이스 사용: ValueListenableProvider는 ValueListenable 인터페이스에 특화되어 있습니다. 이는 단일 값의 변화를 감지하고 이에 반응하는 구체적인 시나리오에 적합합니다. 예를 들어, 애니메이션의 진행 상태나 슬라이더의 현재 값 같은 단일 값의 변화를 다룰 때 사용할 수 있습니다.
  2. 값의 직접적 노출: ValueListenableProvider는 ValueListenable 객체가 가진 현재 값을 직접적으로 노출합니다. 이는 StreamProvider나 FutureProvider와는 다르게, 시간에 따른 데이터 시퀀스나 미래의 한 번의 값이 아닌, 현재의 단일 값에 초점을 맞춥니다.
  3. 간결한 사용: ValueListenable를 사용하는 경우, ValueListenableProvider는 간결하고 명확한 코드를 작성할 수 있게 합니다. ValueListenableBuilder 위젯을 직접 사용하는 대신, ValueListenableProvider를 사용하여 데이터 흐름을 더 효율적으로 관리하고, 상태 관리 코드를 더 간단하게 만들 수 있습니다.

요약하자면, ValueListenableProvider<T>는 ValueListenable<T> 객체의 변화를 청취하고, 이를 위젯 트리에 제공하는 데 특화된 프로바이더입니다. 단일 값의 변화를 감지하고 이에 반응해야 하는 특정 시나리오에서 유용하게 사용할 수 있습니다. 다른 프로바이더들과 비교했을 때, ValueListenableProvider는 ValueListenable 인터페이스에 특화된 사용 사례와 효율성을 제공한다는 점에서 차이가 있습니다.

'플러터 > 플러터 사용기' 카테고리의 다른 글

(플러터) 리팩토링의 기본  (1) 2024.02.06
프로바이더 뽀개기 프로젝트  (1) 2024.02.03
플러터-프로바이더-궁금했던-내용들  (0) 2024.02.02

관련글

티스토리툴바