In this article, we'll explore how to use ValueNotifier and ValueListenableBuilder for effective state management, from simple use cases to complex scenarios.

We'll build an e-commerce app to demonstrate these concepts in action.

Basic Concepts

ValueNotifier

ValueNotifier is a simple way to wrap a value and notify listeners when that value changes. It's part of Flutter's foundation library.

final counter = ValueNotifier<int>(0);

In this example, we create a ValueNotifier that holds an integer value, initially set to 0.

ValueListenableBuilder

ValueListenableBuilder is a widget that rebuilds its child when the value in a ValueNotifier changes.

ValueListenableBuilder<int>(
  valueListenable: counter,
  builder: (context, value, child) {
    return Text('Count: $value');
  },
)

You might ask, what is the relationship between ValueNotifier and ValueListenableBuilder?

ValueNotifier is a way to wrap a value that can change over time. It's part of the data/state management side of your application.
In the example above, the counter is a ValueNotifier that holds an integer value. You can change this value like this:

counter.value = 1;

However, just changing the value doesn't automatically update your UI. This is where ValueListenableBuilder comes in. It's a widget that listens to a ValueNotifier and rebuilds its child whenever the notifier's value changes. In the example above, the builder listens to the counter notifier to rebuild it’s child when the value changes.

The ValueListenableBuilder is the bridge between your data (ValueNotifier) and your UI. It's responsible for:

• Listening to changes in the ValueNotifier

• Rebuilding the widget tree when the value changes

• Providing the current value to its builder function

Without ValueListenableBuilder:

• Your UI wouldn't know when to update in response to changes in the ValueNotifier.

• You'd have to manually trigger rebuilds of your widget tree every time the value changes, which would be inefficient and error-prone.

Combining them together:

class CounterPage extends StatelessWidget {
  final counter = ValueNotifier<int>(0);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: ValueListenableBuilder<int>(
          valueListenable: counter,
          builder: (context, value, child) {
            return Text('Count: $value');
          },
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => counter.value++,
        child: Icon(Icons.add),
      ),
    );
  }
}

In this example:

• The ValueNotifier (counter) holds the state.

• The ValueListenableBuilder listens for changes to counter and updates the Text widget.

• When the FloatingActionButton is pressed, it increments counter.value.

• The ValueListenableBuilder detects this change and rebuilds the Text widget with the new value.

Without the ValueListenableBuilder, the Text widget wouldn't update when counter.value changes.

Now that we have got the basics out of the way, let’s deep dive some advanced concepts.

MultiValueListenableBuilder

When dealing with multiple ValueNotifiers, we can create a custom MultiValueListenableBuilder to simplify our code:

class MultiValueListenableBuilder extends StatelessWidget {
  final List<ValueListenable> valueListenables;
  final Widget Function(BuildContext context, List<dynamic> values, Widget? child) builder;
  final Widget? child;

  const MultiValueListenableBuilder({
    Key? key,
    required this.valueListenables,
    required this.builder,
    this.child,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return ValueListenableBuilder<dynamic>(
      valueListenable: valueListenables[0],
      builder: (context, value, _) {
        return _buildNested(context, [value], 1);
      },
    );
  }

  Widget _buildNested(BuildContext context, List<dynamic> values, int index) {
    if (index >= valueListenables.length) {
      return builder(context, values, child);
    }
    return ValueListenableBuilder<dynamic>(
      valueListenable: valueListenables[index],
      builder: (context, value, _) {
        return _buildNested(context, [...values, value], index + 1);
      },
    );
  }
}

Let's break down this MultiValueListenableBuilder class:

This class is designed to listen to multiple ValueNotifiers at once and rebuild a widget when any of them change.

It's a StatelessWidget, meaning it doesn't maintain its own state. It takes a list of ValueListenables, a builder function, and an optional child widget. It starts with the first ValueListenable. It then creates nested ValueListenableBuilders for each subsequent ValueListenable. At the innermost level, when all values are collected, it calls the provided builder function. If any ValueListenable changes, it triggers a rebuild of its corresponding ValueListenableBuilder and all inner ones. This creates a widget that rebuilds whenever any of the provided ValueListenables change. The builder function receives a list of all current values, allowing you to build your UI based on all of them.

In essence, this class is a more flexible version of the standard ValueListenableBuilder, allowing you to react to changes in multiple values at once, which is often needed in more complex state management scenarios.

Listenable.merge

An alternative to having a custom MultiValueListenableBuilder is to use the Listenable.merge constructor: https://api.flutter.dev/flutter/foundation/Listenable/Listenable.merge.html
With this, it returns a Listenable that triggers when any of the given Listenables themselves trigger.

E-Commerce App Implementation

Let's build an e-commerce app using ValueNotifier and ValueListenableBuilder. We'll implement product listing, a shopping cart, and checkout functionality.

1. Models

First, let's define our data models:

class Product {
  final int id;
  final String name;
  final double price;
  final String imageUrl;

  Product({required this.id, required this.name, required this.price, required this.imageUrl});
}

class CartItem {
  final Product product;
  final ValueNotifier<int> quantity;

  CartItem({required this.product, int initialQuantity = 1})
      : quantity = ValueNotifier(initialQuantity);
}

The Product class represents a product in our catalog. The CartItem class represents a product in the shopping cart, with a ValueNotifier for the quantity to allow for easy updates and UI rebuilds.

2. Services

Let's simulate a backend service:

class ApiService {
  Future<List<Product>> fetchProducts() async {
    // Simulate API delay
    await Future.delayed(Duration(seconds: 1));
    return [
      Product(id: 1, name: 'Laptop', price: 999.99, imageUrl: 'https://example.com/laptop.jpg'),
      Product(id: 2, name: 'Smartphone', price: 499.99, imageUrl: 'https://example.com/smartphone.jpg'),
      Product(id: 3, name: 'Headphones', price: 99.99, imageUrl: 'https://example.com/headphones.jpg'),
    ];
  }

  Future<bool> submitOrder(List<CartItem> items, double total) async {
    // Simulate API delay and always return success for this example
    await Future.delayed(Duration(seconds: 1));
    return true;
  }
}

This ApiService class simulates API calls to fetch products and submit orders.

3. State Management

Now, let's implement our state management classes:

class ProductCatalogNotifier {
  final ApiService _apiService;
  final ValueNotifier<List<Product>> _products = ValueNotifier([]);
  final ValueNotifier<bool> _isLoading = ValueNotifier(false);
  final ValueNotifier<String?> _error = ValueNotifier(null);

  ProductCatalogNotifier(this._apiService);

  ValueNotifier<List<Product>> get products => _products;
  ValueNotifier<bool> get isLoading => _isLoading;
  ValueNotifier<String?> get error => _error;

  Future<void> fetchProducts() async {
    _isLoading.value = true;
    _error.value = null;
    try {
      final fetchedProducts = await _apiService.fetchProducts();
      _products.value = fetchedProducts;
    } catch (e) {
      _error.value = 'Failed to fetch products: ${e.toString()}';
    } finally {
      _isLoading.value = false;
    }
  }

  void dispose() {
    _products.dispose();
    _isLoading.dispose();
    _error.dispose();
  }
}

This class encapsulates all the logic for managing product catalog state. By using ValueNotifiers, it can notify listeners (like UI widgets) whenever the products, loading state, or error state changes, allowing for reactive updates to the user interface.

The ProductCatalogNotifier manages the state of our product catalog. It uses separate ValueNotifiers for the product list, loading state, and error state. The fetchProducts method updates these states as it fetches products from the API.

Now, we need a cart to store our products before we submit them.

class CartNotifier {
  final ValueNotifier<List<CartItem>> _items = ValueNotifier([]);
  final ValueNotifier<double> _totalPrice = ValueNotifier(0.0);

  ValueNotifier<List<CartItem>> get items => _items;
  ValueNotifier<double> get totalPrice => _totalPrice;

  void addItem(Product product) {
    final existingItem = _items.value.firstWhere(
      (item) => item.product.id == product.id,
      orElse: () => CartItem(product: product, initialQuantity: 0),
    );

    if (existingItem.quantity.value == 0) {
      _items.value = [..._items.value, existingItem];
    }
    existingItem.quantity.value++;
    _updateTotalPrice();
  }

  void removeItem(Product product) {
    _items.value = _items.value.where((item) => item.product.id != product.id).toList();
    _updateTotalPrice();
  }

  void _updateTotalPrice() {
    _totalPrice.value = _items.value.fold(
      0.0,
      (total, item) => total + (item.product.price * item.quantity.value),
    );
  }

  void dispose() {
    for (var item in _items.value) {
      item.quantity.dispose();
    }
    _items.dispose();
    _totalPrice.dispose();
  }
}

1. Purpose:

   This class manages the state of a shopping cart, including the items in the cart and the total price.

2. Properties:

   _items: A ValueNotifier holding a list of CartItem objects. It represents the items in the cart.

   _totalPrice: A ValueNotifier holding a double. It represents the total price of all items in the cart.

3. Getters:

   Provide access to the ValueNotifiers, allowing other parts of the app to listen to changes in the cart items and total price.

4. addItem method:

   • Checks if the product already exists in the cart.

   • If it doesn't exist or has quantity 0, adds it to the cart.

   • Increments the quantity of the item.

   • Updates the total price.

5. removeItem method:

   • Removes an item from the cart based on the product ID.

   • Updates the total price.

6. _updateTotalPrice method:

   • Calculates the total price of all items in the cart.

   • Uses the fold method to sum up the prices of all items, considering their quantities.

7. dispose method:

   • Cleans up resources by disposing of all ValueNotifiers, including those in individual CartItems.

This class encapsulates all the logic for managing the shopping cart state. By using ValueNotifiers, it can notify listeners (like UI widgets) whenever the cart items or total price changes, allowing for reactive updates to the user interface.

4. UI Implementation

Now, let's implement the UI for our product list page:

class ProductListPage extends StatefulWidget {
  @override
  _ProductListPageState createState() => _ProductListPageState();
}

class _ProductListPageState extends State<ProductListPage> {
  late final ProductCatalogNotifier _productCatalog;
  late final CartNotifier _cart;

  @override
  void initState() {
    super.initState();
    _productCatalog = ProductCatalogNotifier(ApiService());
    _cart = CartNotifier();
    WidgetsBinding.instance.addPostFrameCallback((_) {
      _productCatalog.fetchProducts();
    });
  }

  @override
  void dispose() {
    _productCatalog.dispose();
    _cart.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Product Catalog')),
      body: MultiValueListenableBuilder(
        valueListenables: [
          _productCatalog.isLoading,
          _productCatalog.error,
          _productCatalog.products,
        ],
        builder: (context, (bool isLoading, String? error, List<Product> products), _) {
          return switch ((isLoading, error, products)) {
            (true, _, _) => Center(child: CircularProgressIndicator()),
            (_, String error, _) => _buildErrorWidget(error),
            (_, _, []) => Center(child: Text('No products available')),
            (_, _, List<Product> products) => _buildProductList(products),
          };
        },
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => Navigator.push(
          context,
          MaterialPageRoute(builder: (_) => CartPage(_cart)),
        ),
        child: Icon(Icons.shopping_cart),
      ),
    );
  }

  Widget _buildErrorWidget(String error) {
    return Center(
      child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: [
          Text(error),
          ElevatedButton(
            onPressed: () => _productCatalog.fetchProducts(),
            child: Text('Retry'),
          ),
        ],
      ),
    );
  }

  Widget _buildProductList(List<Product> products) {
    return RefreshIndicator(
      onRefresh: () => _productCatalog.fetchProducts(),
      child: ListView.builder(
        itemCount: products.length,
        itemBuilder: (context, index) {
          final product = products[index];
          return ListTile(
            title: Text(product.name),
            subtitle: Text('\$${product.price.toStringAsFixed(2)}'),
            trailing: IconButton(
              icon: Icon(Icons.add_shopping_cart),
              onPressed: () => _cart.addItem(product),
            ),
          );
        },
      ),
    );
  }
}

Let's break down this implementation:

1. We use a StatefulWidget to manage the lifecycle of our notifiers.

2. In initState, we initialize our notifiers and fetch products after the widget is built.

3. In dispose, we make sure to dispose of our notifiers to prevent memory leaks.

4. We use MultiValueListenableBuilder to listen to multiple ValueNotifiers simultaneously.

5. We use Dart's pattern matching feature to handle different states elegantly: Remember that this pattern matching syntax requires Dart 3.0 or later. If you're using an earlier version of Dart, you'll need to stick with the if-else approach or update your Dart SDK.

   • (true, , ) matches when loading.

   • (_, String error, _) matches when there's an error.

   • (_, _, []) matches when the product list is empty.

   • (_, _, List<Product> products) matches when we have products to display.

6. We extract the error widget and product list widget into separate methods for better organization.

7. We use a RefreshIndicator to allow users to manually refresh the product list.

Using Listenable.merge constructor:

ListenableBuilder(
        listenable: Listenable.merge([
          _productCatalog.loadingStatus,
          _productCatalog.errorMessage,
          _productCatalog.products,
        ]),
        builder: (context, _) {
          final status = _productCatalog.loadingStatus.value;
          final errorMessage = _productCatalog.errorMessage.value;
          final products = _productCatalog.products.value;

          return switch ((status, errorMessage, products)) {
            (LoadingStatus.loading, _, _) => 
              Center(child: CircularProgressIndicator()),
            (LoadingStatus.error, String error, _) => 
              Center(child: Text(error)),
            (_, _, List<Product> products) => ListView.builder(
              itemCount: products.length,
              itemBuilder: (context, index) {
                final product = products[index];
                return ListTile(
                  title: Text(product.name),
                  subtitle: Text('\$${product.price.toStringAsFixed(2)}'),
                );
              },
            ),
            _ => Center(child: Text('Unexpected state')),
          };
        },
      )

Now for the CartPage which will show our shopping cart.

class CartPage extends StatelessWidget {
  final CartNotifier cart;

  const CartPage({Key? key, required this.cart}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Shopping Cart'),
      ),
      body: ValueListenableBuilder<List<CartItem>>(
        valueListenable: cart.items,
        builder: (context, items, child) {
          if (items.isEmpty) {
            return Center(child: Text('Your cart is empty'));
          }
          return ListView.builder(
            itemCount: items.length,
            itemBuilder: (context, index) {
              final item = items[index];
              return ListTile(
                title: Text(item.product.name),
                subtitle: Text('\$${item.product.price.toStringAsFixed(2)}'),
                trailing: Row(
                  mainAxisSize: MainAxisSize.min,
                  children: [
                    IconButton(
                      icon: Icon(Icons.remove),
                      onPressed: () => cart.decreaseQuantity(item.product),
                    ),
                    ValueListenableBuilder<int>(
                      valueListenable: item.quantity,
                      builder: (context, quantity, child) {
                        return Text('$quantity');
                      },
                    ),
                    IconButton(
                      icon: Icon(Icons.add),
                      onPressed: () => cart.addItem(item.product),
                    ),
                  ],
                ),
              );
            },
          );
        },
      ),
      bottomNavigationBar: ValueListenableBuilder<double>(
        valueListenable: cart.totalPrice,
        builder: (context, totalPrice, child) {
          return Padding(
            padding: const EdgeInsets.all(8.0),
            child: Text(
              'Total: \$${totalPrice.toStringAsFixed(2)}',
              style: Theme.of(context).textTheme.headline6,
              textAlign: TextAlign.center,
            ),
          );
        },
      ),
    );
  }
}

5. Unit Tests

You might be wondering how to test your ValueNotifier.

Let’s test the ProductCatalogNotifier.

Our tests should cover:

• Initial state of the product catalog

• Successful fetching of products

• Handling of errors during fetching

• Loading state during fetching

• Clearing of previous errors on new fetch

• Replacement of previous products on new fetch

To write our test, we will use Mockito. Mockito is a popular mocking framework for Dart and Flutter. It allows you to create mock objects for your tests, which is particularly useful when you want to test classes that depend on other classes or services.

1. Add Mockito and build_runner to your pubspec.yaml file under dev_dependencies to your project:

dev_dependencies:
  flutter_test:
    sdk: flutter
  mockito: ^5.0.0
  build_runner: ^2.0.0

Then run flutter pub get to install these packages.

2. Create a test file:

Create a new file for your tests, e.g., test/product_catalog_notifier_test.dart.
We’ll use GenerateNiceMocks to generate mocks for our ApiService class. GenerateNiceMocks is a newer and often more convenient way to generate mocks using Mockito. It creates "nice" mocks by default, which means they return null for unexpected method calls instead of throwing exceptions. This can be helpful in many testing scenarios.

@GenerateNiceMocks([MockSpec<ApiService>()])
import 'product_catalog_notifier_test.mocks.dart';

void main() {
  late ProductCatalogNotifier productCatalog;
  late MockApiService mockApiService;

  setUp(() {
    mockApiService = MockApiService();
    productCatalog = ProductCatalogNotifier(mockApiService);
  });

  tearDown(() {
    productCatalog.dispose();
  });

  group('ProductCatalogNotifier', () {
    test('initial state is empty', () {
      expect(productCatalog.products.value, isEmpty);
      expect(productCatalog.isLoading.value, false);
      expect(productCatalog.error.value, isNull);
    });

    test('fetchProducts updates products on success', () async {
      final mockProducts = [
        Product(id: 1, name: 'Test Product 1', price: 10.0, imageUrl: 'test1.jpg'),
        Product(id: 2, name: 'Test Product 2', price: 20.0, imageUrl: 'test2.jpg'),
      ];

      when(mockApiService.fetchProducts()).thenAnswer((_) async => mockProducts);

      await productCatalog.fetchProducts();

      expect(productCatalog.products.value, equals(mockProducts));
      expect(productCatalog.isLoading.value, false);
      expect(productCatalog.error.value, isNull);
    });

    test('fetchProducts updates error on failure', () async {
      when(mockApiService.fetchProducts()).thenThrow(Exception('API error'));

      await productCatalog.fetchProducts();

      expect(productCatalog.products.value, isEmpty);
      expect(productCatalog.isLoading.value, false);
      expect(productCatalog.error.value, contains('Failed to fetch products'));
    });

    test('isLoading is true while fetching products', () async {
      when(mockApiService.fetchProducts()).thenAnswer((_) async {
        await Future.delayed(Duration(milliseconds: 100));
        return [];
      });

      final future = productCatalog.fetchProducts();

      expect(productCatalog.isLoading.value, true);

      await future;

      expect(productCatalog.isLoading.value, false);
    });

    test('fetchProducts clears previous error', () async {
      // First, simulate an error
      when(mockApiService.fetchProducts()).thenThrow(Exception('API error'));
      await productCatalog.fetchProducts();
      expect(productCatalog.error.value, isNotNull);

      // Then, simulate a successful fetch
      when(mockApiService.fetchProducts()).thenAnswer((_) async => []);
      await productCatalog.fetchProducts();
      expect(productCatalog.error.value, isNull);
    });

    test('fetchProducts replaces previous products', () async {
      final mockProducts1 = [
        Product(id: 1, name: 'Test Product 1', price: 10.0, imageUrl: 'test1.jpg'),
      ];
      final mockProducts2 = [
        Product(id: 2, name: 'Test Product 2', price: 20.0, imageUrl: 'test2.jpg'),
      ];

      when(mockApiService.fetchProducts()).thenAnswer((_) async => mockProducts1);
      await productCatalog.fetchProducts();
      expect(productCatalog.products.value, equals(mockProducts1));

      when(mockApiService.fetchProducts()).thenAnswer((_) async => mockProducts2);
      await productCatalog.fetchProducts();
      expect(productCatalog.products.value, equals(mockProducts2));
    });
  });
}

Remember to run flutter pub run build_runner build

Let’s test our CartNotifier.
We’ll have a test suite that covers

• Initial state of the cart

• Adding a new item to an empty cart

• Increasing quantity of an existing item

• Adding different items separately

• Removing an item from the cart

• Attempting to remove a non-existent item

• Updating total price with multiple operations

• Edge case of adding an item with quantity 0 and then incrementing

• Removing the last item and ensuring total price is 0

• Handling high-priced items without precision errors

void main() {
  late CartNotifier cartNotifier;
  late Product product1;
  late Product product2;

  setUp(() {
    cartNotifier = CartNotifier();
    product1 = Product(id: 1, name: 'Test Product 1', price: 10.0, imageUrl: 'test1.jpg');
    product2 = Product(id: 2, name: 'Test Product 2', price: 20.0, imageUrl: 'test2.jpg');
  });

  tearDown(() {
    cartNotifier.dispose();
  });

  group('CartNotifier', () {
    test('initial state is empty', () {
      expect(cartNotifier.items.value, isEmpty);
      expect(cartNotifier.totalPrice.value, 0.0);
    });

    test('addItem adds new item to empty cart', () {
      cartNotifier.addItem(product1);
      expect(cartNotifier.items.value.length, 1);
      expect(cartNotifier.items.value[0].product, product1);
      expect(cartNotifier.items.value[0].quantity.value, 1);
      expect(cartNotifier.totalPrice.value, 10.0);
    });

    test('addItem increases quantity for existing item', () {
      cartNotifier.addItem(product1);
      cartNotifier.addItem(product1);
      expect(cartNotifier.items.value.length, 1);
      expect(cartNotifier.items.value[0].quantity.value, 2);
      expect(cartNotifier.totalPrice.value, 20.0);
    });

    test('addItem adds different items separately', () {
      cartNotifier.addItem(product1);
      cartNotifier.addItem(product2);
      expect(cartNotifier.items.value.length, 2);
      expect(cartNotifier.totalPrice.value, 30.0);
    });

    test('removeItem removes the item from the cart', () {
      cartNotifier.addItem(product1);
      cartNotifier.addItem(product2);
      cartNotifier.removeItem(product1);
      expect(cartNotifier.items.value.length, 1);
      expect(cartNotifier.items.value[0].product, product2);
      expect(cartNotifier.totalPrice.value, 20.0);
    });

    test('removeItem does nothing if item not in cart', () {
      cartNotifier.addItem(product1);
      cartNotifier.removeItem(product2);
      expect(cartNotifier.items.value.length, 1);
      expect(cartNotifier.items.value[0].product, product1);
      expect(cartNotifier.totalPrice.value, 10.0);
    });

    test('totalPrice updates correctly with multiple operations', () {
      cartNotifier.addItem(product1);
      cartNotifier.addItem(product2);
      cartNotifier.addItem(product1);
      expect(cartNotifier.totalPrice.value, 40.0);
      cartNotifier.removeItem(product2);
      expect(cartNotifier.totalPrice.value, 20.0);
    });

    test('adding item with quantity 0 and then incrementing works correctly', () {
      cartNotifier.addItem(product1);
      cartNotifier.items.value[0].quantity.value = 0;
      cartNotifier.addItem(product1);
      expect(cartNotifier.items.value.length, 1);
      expect(cartNotifier.items.value[0].quantity.value, 1);
      expect(cartNotifier.totalPrice.value, 10.0);
    });

    test('removing last item sets total price to 0', () {
      cartNotifier.addItem(product1);
      cartNotifier.removeItem(product1);
      expect(cartNotifier.items.value, isEmpty);
      expect(cartNotifier.totalPrice.value, 0.0);
    });

    test('adding item with very high price doesn\'t cause precision errors', () {
      final expensiveProduct = Product(id: 3, name: 'Expensive', price: 1000000.01, imageUrl: 'expensive.jpg');
      cartNotifier.addItem(expensiveProduct);
      expect(cartNotifier.totalPrice.value, 1000000.01);
    });
  });
}

Next, let’s add a widget test our ProductListPage. We are testing several scenarios:

• Loading state when fetching products

• Error state when fetching fails

• Successful display of products

• Adding a product to the cart

• Navigating to the cart page

@GenerateNiceMocks([MockSpec<ApiService>(), MockSpec<CartNotifier>()])
import 'product_list_page_test.mocks.dart';

void main() {
  late MockApiService mockApiService;
  late MockCartNotifier mockCartNotifier;
  late ProductCatalogNotifier productCatalogNotifier;

  setUp(() {
    mockApiService = MockApiService();
    mockCartNotifier = MockCartNotifier();
    productCatalogNotifier = ProductCatalogNotifier(mockApiService);
  });

  Widget createWidgetUnderTest() {
    return MaterialApp(
      home: ProductListPage(
        productCatalog: productCatalogNotifier,
        cart: mockCartNotifier,
      ),
    );
  }

  group('ProductListPage', () {
    testWidgets('displays loading indicator when fetching products', (WidgetTester tester) async {
      when(mockApiService.fetchProducts()).thenAnswer((_) async {
        await Future.delayed(Duration(seconds: 1));
        return [];
      });

      await tester.pumpWidget(createWidgetUnderTest());

      expect(find.byType(CircularProgressIndicator), findsOneWidget);
    });

    testWidgets('displays error message when fetch fails', (WidgetTester tester) async {
      when(mockApiService.fetchProducts()).thenThrow(Exception('Failed to fetch products'));

      await tester.pumpWidget(createWidgetUnderTest());
      await tester.pumpAndSettle();

      expect(find.text('Error: Failed to fetch products'), findsOneWidget);
    });

    testWidgets('displays list of products when fetch succeeds', (WidgetTester tester) async {
      final mockProducts = [
        Product(id: 1, name: 'Test Product 1', price: 10.0, imageUrl: 'test1.jpg'),
        Product(id: 2, name: 'Test Product 2', price: 20.0, imageUrl: 'test2.jpg'),
      ];

      when(mockApiService.fetchProducts()).thenAnswer((_) async => mockProducts);

      await tester.pumpWidget(createWidgetUnderTest());
      await tester.pumpAndSettle();

      expect(find.text('Test Product 1'), findsOneWidget);
      expect(find.text('Test Product 2'), findsOneWidget);
      expect(find.text('\$10.00'), findsOneWidget);
      expect(find.text('\$20.00'), findsOneWidget);
    });

    testWidgets('adds product to cart when add button is tapped', (WidgetTester tester) async {
      final mockProducts = [
        Product(id: 1, name: 'Test Product', price: 10.0, imageUrl: 'test.jpg'),
      ];

      when(mockApiService.fetchProducts()).thenAnswer((_) async => mockProducts);

      await tester.pumpWidget(createWidgetUnderTest());
      await tester.pumpAndSettle();

      await tester.tap(find.byIcon(Icons.add_shopping_cart));
      await tester.pump();

      verify(mockCartNotifier.addItem(mockProducts[0])).called(1);
    });

    testWidgets('navigates to cart page when cart icon is tapped', (WidgetTester tester) async {
      when(mockApiService.fetchProducts()).thenAnswer((_) async => []);

      await tester.pumpWidget(createWidgetUnderTest());
      await tester.pumpAndSettle();

      await tester.tap(find.byIcon(Icons.shopping_cart));
      await tester.pumpAndSettle();

      // Verify navigation to CartPage
      // This depends on how you've set up navigation. You might need to adjust this.
      expect(find.byType(CartPage), findsOneWidget);
    });
  });
}

We're using tester.pumpAndSettle() to wait for all animations to complete and the widget tree to settle. These tests cover the main functionality of the ProductListPage, including loading states, error handling, displaying products, adding to cart, and navigation. They help ensure that your UI behaves correctly under various conditions and that user interactions produce the expected results.

Remember to update these tests as you add new features or change the behavior of your ProductListPage. Widget tests are a powerful tool for maintaining the quality and reliability of your Flutter application's UI.

Finally, let’s add a widget test for our CartPage

@GenerateNiceMocks([MockSpec<CartNotifier>()])
import 'cart_page_test.mocks.dart';

void main() {
  late MockCartNotifier mockCartNotifier;

  setUp(() {
    mockCartNotifier = MockCartNotifier();
  });

  Widget createWidgetUnderTest() {
    return MaterialApp(
      home: CartPage(cart: mockCartNotifier),
    );
  }

  group('CartPage', () {
    testWidgets('displays empty cart message when cart is empty', (WidgetTester tester) async {
      when(mockCartNotifier.items).thenReturn(ValueNotifier([]));
      when(mockCartNotifier.totalPrice).thenReturn(ValueNotifier(0.0));

      await tester.pumpWidget(createWidgetUnderTest());

      expect(find.text('Your cart is empty'), findsOneWidget);
    });

    testWidgets('displays cart items when cart is not empty', (WidgetTester tester) async {
      final product = Product(id: 1, name: 'Test Product', price: 10.0, imageUrl: 'test.jpg');
      final cartItem = CartItem(product: product, quantity: ValueNotifier(2));

      when(mockCartNotifier.items).thenReturn(ValueNotifier([cartItem]));
      when(mockCartNotifier.totalPrice).thenReturn(ValueNotifier(20.0));

      await tester.pumpWidget(createWidgetUnderTest());

      expect(find.text('Test Product'), findsOneWidget);
      expect(find.text('\$10.00'), findsOneWidget);
      expect(find.text('2'), findsOneWidget);
      expect(find.text('Total: \$20.00'), findsOneWidget);
    });

    testWidgets('increases quantity when add button is tapped', (WidgetTester tester) async {
      final product = Product(id: 1, name: 'Test Product', price: 10.0, imageUrl: 'test.jpg');
      final cartItem = CartItem(product: product, quantity: ValueNotifier(1));

      when(mockCartNotifier.items).thenReturn(ValueNotifier([cartItem]));
      when(mockCartNotifier.totalPrice).thenReturn(ValueNotifier(10.0));

      await tester.pumpWidget(createWidgetUnderTest());

      await tester.tap(find.byIcon(Icons.add));
      await tester.pump();

      verify(mockCartNotifier.addItem(product)).called(1);
    });

    testWidgets('decreases quantity when remove button is tapped', (WidgetTester tester) async {
      final product = Product(id: 1, name: 'Test Product', price: 10.0, imageUrl: 'test.jpg');
      final cartItem = CartItem(product: product, quantity: ValueNotifier(2));

      when(mockCartNotifier.items).thenReturn(ValueNotifier([cartItem]));
      when(mockCartNotifier.totalPrice).thenReturn(ValueNotifier(20.0));

      await tester.pumpWidget(createWidgetUnderTest());

      await tester.tap(find.byIcon(Icons.remove));
      await tester.pump();

      verify(mockCartNotifier.decreaseQuantity(product)).called(1);
    });
  });
}

These tests cover the main functionality of the CartPage, including displaying cart items, showing the total price, and handling quantity changes.

Remember to run flutter pub run build_runner build to generate the mock classes before running the tests.

Let’s Wrap Up

ValueNotifier and ValueListenableBuilder provide a powerful yet simple way to manage state in Flutter applications. By using these tools along with custom widgets like MultiValueListenableBuilder and Dart's pattern matching feature, we can create responsive, efficient, and easy-to-maintain applications.

Remember to always dispose of your ValueNotifiers when they're no longer needed, and consider breaking down complex widgets into smaller, more manageable pieces. With these techniques, you can handle even complex state management scenarios with ease in your Flutter applications.

NOTE:
There are scenarios where ChangeNotifier might be more appropriate:

• Complex State: When your state becomes more complex with multiple interdependent properties, ChangeNotifier can provide a more organized way to manage and update this state.

• Multiple Listeners: If you need to notify multiple widgets about state changes and these changes might affect multiple properties at once, ChangeNotifier can be more efficient.

• Business Logic: When you have significant business logic associated with your state updates, ChangeNotifier allows you to encapsulate this logic within the notifier class.

• Computed Properties: If you need computed properties that depend on multiple pieces of state, ChangeNotifier can handle this more elegantly.

• State Persistence: For cases where you need to persist state across app restarts or sync with external storage, ChangeNotifier can provide a centralized place to manage this.

• Larger Applications: In larger applications with more complex state management needs, ChangeNotifier (often used with Provider) can offer a more scalable solution.

That said, it's important to note that you don't always need to jump to ChangeNotifier. For many cases, especially in smaller widgets or components, ValueNotifier and ValueListenableBuilder (or MultiValueListenableBuilder) can provide a simpler and more focused solution. The key is to choose the right tool for the job based on the complexity of your state management needs.

Riverpod is a reactive Caching and Data-binding Framework which can be used as powerful state management library for Flutter and Dart applications, created by Remi Rousselet, the author of the popular Provider package. It addresses several limitations of Provider and offers significant advantages:

1. Compile-time safety: Riverpod catches many errors at compile-time rather than runtime.

2. Testability: It provides excellent support for unit testing and widget testing.

3. Flexibility: Riverpod allows for easy creation and combination of providers.

4. Improved performance: It optimizes rebuilds and allows for more granular control over state updates.

Riverpod is designed to work seamlessly with the Flutter framework but can also be used in pure Dart applications. It provides a set of tools to manage application state, from simple values to complex asynchronous data flows.

ProviderContainer and Testing Utilities

Before diving into specific provider types, it's crucial to understand the tools Riverpod offers for testing.

ProviderContainer

ProviderContainer is a fundamental class in Riverpod for testing purposes. It allows you to create an isolated environment for your providers, separate from the widget tree. This isolation is essential for unit testing providers without the need for a full widget test setup.

Key points about ProviderContainer:

1. It holds the state of all providers created within it.

2. It allows you to read and interact with providers outside of a widget context.

3. It supports overrides, enabling you to replace providers with mocks or different implementations for testing.

createContainer Utility

To streamline the creation of ProviderContainer instances in tests, you can use a utility function like createContainer:

ProviderContainer createContainer({
  ProviderContainer? parent,
  List<Override> overrides = const [],
  List<ProviderObserver>? observers,
}) {
  final container = ProviderContainer(
    parent: parent,
    overrides: overrides,
    observers: observers,
  );

  addTearDown(container.dispose);

  return container;
}

This utility function:

1. Creates a new ProviderContainer with optional parameters for parent, overrides, and observers.

2. Automatically adds a teardown step to dispose of the container after the test, preventing memory leaks.

3. Provides a consistent way to create containers across your test suite.

Overrides in Riverpod Testing

Overrides are a powerful feature in Riverpod that allow you to replace the implementation of a provider for testing purposes. This is particularly useful for:

• Mocking dependencies

• Testing different scenarios by providing different initial values

• Isolating parts of your application for focused testing

Types of Riverpod Providers and How to Test Them

1. Provider

What is it?

Provider is the most basic type of provider in Riverpod. It creates a value that doesn't change over time.

When to use it?

Use Provider for:

• Dependency injection

• Computed values that don't change

• Singleton instances

Testing Provider

final apiClientProvider = Provider<ApiClient>((ref) => ApiClient());

void main() {
  test('apiClientProvider returns a singleton instance', () {
    final container = createContainer();

    final instance1 = container.read(apiClientProvider);
    final instance2 = container.read(apiClientProvider);

    expect(instance1, isA<ApiClient>());
    expect(identical(instance1, instance2), true);
  });
}

Why test this way?

• We use createContainer to isolate the provider from the rest of the app.

• We verify that the provider returns the correct type of object.

• We check that multiple reads return the same instance, ensuring it's a singleton.

2. StateProvider

What is it?

StateProvider is used for simple state that can change over time.

When to use it?

Use StateProvider for:

• Simple state that can be represented by a single value

• State that doesn't require complex logic to update

Testing StateProvider

final counterStateProvider = StateProvider<int>((ref) => 0);

void main() {
  test('counterStateProvider can be incremented and reset', () {
    final container = createContainer();

    expect(container.read(counterStateProvider), 0);

    container.read(counterStateProvider.notifier).state++;
    expect(container.read(counterStateProvider), 1);

    container.read(counterStateProvider.notifier).state = 0;
    expect(container.read(counterStateProvider), 0);
  });
}

Why test this way?

• We test the initial state to ensure correct initialization.

• We modify the state and verify it changes correctly.

• We test resetting the state to ensure all state changes work as expected.

3. StateNotifierProvider

What is it?

StateNotifierProvider is used for more complex state management, allowing you to define methods to change the state.

When to use it?

Use StateNotifierProvider for:

• Complex state that requires custom logic to update

• State that needs to be modified through specific methods

Testing StateNotifierProvider

class Counter extends StateNotifier<int> {
  Counter() : super(0);
  void increment() => state++;
  void decrement() => state--;
}

final counterNotifierProvider = StateNotifierProvider<Counter, int>((ref) => Counter());

void main() {
  test('counterNotifierProvider handles state changes correctly', () {
    final container = createContainer();

    expect(container.read(counterNotifierProvider), 0);

    container.read(counterNotifierProvider.notifier).increment();
    expect(container.read(counterNotifierProvider), 1);

    container.read(counterNotifierProvider.notifier).decrement();
    expect(container.read(counterNotifierProvider), 0);
  });
}

Why test this way?

• We test the initial state.

• We test each method of the StateNotifier to ensure they modify the state correctly.

• We verify that the state is accessible both through the provider and its notifier.

4. NotifierProvider

What is it?

NotifierProvider is a more recent addition to Riverpod, introduced as an alternative to StateNotifierProvider. It offers a simpler API and better type inference.

When to use it?

Use NotifierProvider for:

• Complex state management where you need custom methods to update the state

• Situations where you want to avoid the boilerplate of extending StateNotifier

Testing NotifierProvider

class CounterNotifier extends Notifier<int> {
  @override
  int build() => 0;

  void increment() => state++;
  void decrement() => state--;
}

final counterNotifierProvider = NotifierProvider<CounterNotifier, int>(() => CounterNotifier());

void main() {
  test('counterNotifierProvider handles state changes correctly', () {
    final container = createContainer();

    expect(container.read(counterNotifierProvider), 0);

    container.read(counterNotifierProvider.notifier).increment();
    expect(container.read(counterNotifierProvider), 1);

    container.read(counterNotifierProvider.notifier).decrement();
    expect(container.read(counterNotifierProvider), 0);
  });
}

Why test this way?

• We test the initial state provided by the build method.

• We test each method of the Notifier to ensure they modify the state correctly.

• We verify that the state is accessible both through the provider and its notifier.

5. AsyncNotifierProvider

What is it?

AsyncNotifierProvider is used for managing asynchronous state with more complex logic. It's similar to NotifierProvider but designed specifically for asynchronous operations.

When to use it?

Use AsyncNotifierProvider for:

• Complex asynchronous state management

• Scenarios where you need to handle loading, error, and data states

• Operations that involve API calls or other asynchronous tasks

Testing AsyncNotifierProvider

Let's create an example AsyncNotifier and then test it:

class UserAsyncNotifier extends AsyncNotifier<User> {
  @override
  Future<User> build() async {
    // Simulating an API call
    await Future.delayed(Duration(seconds: 1));
    return User('Initial User');
  }

  Future<void> updateUser(String newName) async {
    state = const AsyncValue.loading();
    try {
      // Simulating an API call
      await Future.delayed(Duration(seconds: 1));
      state = AsyncValue.data(User(newName));
    } catch (e, st) {
      state = AsyncValue.error(e, st);
    }
  }
}

final userAsyncNotifierProvider = AsyncNotifierProvider<UserAsyncNotifier, User>(() => UserAsyncNotifier());

class User {
  final String name;
  User(this.name);
}

// Test
import 'package:flutter_test/flutter_test.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';

void main() {
  test('UserAsyncNotifier initializes and updates correctly', () async {
    final container = createContainer();

    // Test initial state
    expect(container.read(userAsyncNotifierProvider), const AsyncValue<User>.loading());

    // Wait for the build method to complete
    await container.read(userAsyncNotifierProvider.future);

    // Check the initial user
    final initialUser = container.read(userAsyncNotifierProvider).value;
    expect(initialUser?.name, 'Initial User');

    // Update the user
    final notifier = container.read(userAsyncNotifierProvider.notifier);
    notifier.updateUser('New User');

    // Check loading state
    expect(container.read(userAsyncNotifierProvider), const AsyncValue<User>.loading());

    // Wait for the update to complete
    await Future.delayed(Duration(seconds: 2));

    // Check the updated user
    final updatedUser = container.read(userAsyncNotifierProvider).value;
    expect(updatedUser?.name, 'New User');
  });

  test('UserAsyncNotifier handles errors', () async {
    final container = createContainer();

    // Override the provider to simulate an error
    final errorProvider = AsyncNotifierProvider<UserAsyncNotifier, User>(() {
      return UserAsyncNotifier()
        ..updateUser = (String newName) async {
          throw Exception('Update failed');
        };
    });

    // Wait for the initial build
    await container.read(errorProvider.future);

    // Attempt to update, which should cause an error
    final notifier = container.read(errorProvider.notifier);
    await notifier.updateUser('Error User');

    // Check that the state is an error
    final errorState = container.read(errorProvider);
    expect(errorState, isA<AsyncError>());
    expect(errorState.error, isA<Exception>());
    expect((errorState.error as Exception).toString(), 'Exception: Update failed');
  });
}

Why test this way?

• We test the initial loading state and the result of the build method.

• We verify that the updateUser method correctly transitions through loading and data states.

• We test error handling by overriding the provider to simulate an error condition.

• We check all possible states: loading, data, and error.

Key Points for Testing AsyncNotifierProvider

• Initial State: Always check the initial loading state before the build method completes.

• State Transitions: Verify that the state correctly transitions through loading, data, and error states.

• Error Handling: Test error scenarios by simulating failures in your async operations.

• Timing: Use Future.delayed or similar methods to allow for asynchronous operations to complete.

• State Access: Access the current state using container.read(provider) and the notifier using container.read(provider.notifier).

Testing AsyncNotifierProvider thoroughly ensures that your application can handle complex asynchronous workflows correctly, including proper error management and state transitions.

6. FutureProvider

What is it?

FutureProvider is used for asynchronous operations that don't need to be refreshed frequently.

When to use it?

Use FutureProvider for:

• API calls that don't need real-time updates

• Loading data that's fetched once and then cached

Testing FutureProvider

final userProvider = FutureProvider<User>((ref) async {
  await Future.delayed(Duration(seconds: 1)); // Simulating network delay
  return User('John Doe');
});

void main() {
  test('userProvider loads data correctly', () async {
    final container = createContainer();

    expect(container.read(userProvider), const AsyncValue<User>.loading());

    await container.read(userProvider.future);

    final value = container.read(userProvider);
    expect(value, isA<AsyncData<User>>());
    expect(value.value?.name, 'John Doe');
  });
}

Why test this way?

• We check the initial loading state.

• We await the future to complete.

• We verify the loaded data is correct and in the expected AsyncValue wrapper.

7. StreamProvider

What is it?

StreamProvider is used for asynchronous data that changes over time.

When to use it?

Use StreamProvider for:

• Real-time data updates (e.g., WebSocket connections)

• Observing changes in databases or other data sources

Testing StreamProvider

final countStreamProvider = StreamProvider<int>((ref) {
  return Stream.periodic(Duration(seconds: 1), (i) => i).take(3);
});

void main() {
  test('countStreamProvider emits values correctly', () async {
    final container = createContainer();

    expect(container.read(countStreamProvider), const AsyncValue<int>.loading());

    await expectLater(
      container.stream(countStreamProvider.future),
      emitsInOrder([0, 1, 2]),
    );

    final finalValue = container.read(countStreamProvider);
    expect(finalValue, isA<AsyncData<int>>());
    expect(finalValue.value, 2);
  });
}

Why test this way?

• We check the initial loading state.

• We use expectLater to verify the stream emits the expected sequence of values.

• We check the final state to ensure it reflects the last emitted value.

8. Family Providers

What is it?

Family providers allow you to create providers that take parameters.

When to use it?

Use Family providers when:

• You need to create multiple instances of a provider with different parameters

• The provider depends on external data not available at compile-time

Testing Family Providers

final userFamilyProvider = FutureProvider.family<User, String>((ref, userId) async {
  await Future.delayed(Duration(seconds: 1)); // Simulating network delay
  return User(userId);
});

void main() {
  test('userFamilyProvider loads different users based on parameter', () async {
    final container = createContainer();

    final user1Future = container.read(userFamilyProvider('user1').future);
    final user2Future = container.read(userFamilyProvider('user2').future);

    final user1 = await user1Future;
    final user2 = await user2Future;

    expect(user1.id, 'user1');
    expect(user2.id, 'user2');
  });
}

Why test this way?

• We test multiple instances of the family provider with different parameters.

• We ensure that each instance returns the correct data based on its parameter.

• We verify that family providers can be used concurrently without interference.

Advanced Testing Techniques

Using Overrides for Mocking

Overrides are particularly useful when you need to mock dependencies or test different scenarios. Here's an example:

final apiClientProvider = Provider<ApiClient>((ref) => RealApiClient());

final userProvider = FutureProvider<User>((ref) async {
  final client = ref.watch(apiClientProvider);
  return client.fetchUser();
});

test('userProvider fetches user correctly', () async {
  final mockClient = MockApiClient();
  when(mockClient.fetchUser()).thenAnswer((_) async => User('Test User'));

  final container = createContainer(
    overrides: [
      apiClientProvider.overrideWithValue(mockClient),
    ],
  );

  final user = await container.read(userProvider.future);
  expect(user.name, 'Test User');
});

In this example, we're overriding the apiClientProvider with a mock implementation, allowing us to test the userProvider in isolation without making real API calls.

Widget Testing with Riverpod

Widget testing is crucial for ensuring that your UI components behave correctly when integrated with Riverpod providers. Let's explore how to effectively test widgets that use Riverpod, utilizing some helpful extensions from your testing utilities.

WidgetTester Extensions

First, let's look at the useful extensions you've defined for WidgetTester:

extension WidgetTesterX on WidgetTester {
  /// Calls [pumpWidget] with the [widget] wrapped in a [MaterialApp].
  Future<void> pumpMaterialWidget(
    Widget widget, [
    Duration? duration,
    EnginePhase phase = EnginePhase.sendSemanticsUpdate,
  ]) =>
      pumpWidget(MaterialApp(home: widget));

  /// Calls [pumpWidget] with the [widget] wrapped in a [MaterialApp] and scoped
  /// with a [ProviderScope].
  ///
  /// The [overrides] and [observers] values will be passed to
  /// the [ProviderScope].
  Future<void> pumpMaterialWidgetScoped(
    Widget widget, {
    Duration? duration,
    EnginePhase phase = EnginePhase.sendSemanticsUpdate,
    List<Override> overrides = const [],
    List<ProviderObserver>? observers,
  }) =>
      pumpWidget(
        ProviderScope(
          overrides: overrides,
          observers: observers,
          child: MaterialApp(home: widget),
        ),
      );
}

These extensions provide convenient methods for pumping widgets wrapped in a MaterialApp and ProviderScope, which is essential for testing Riverpod-dependent widgets.

Testing a Widget with Riverpod

Let's create an example widget that uses a Riverpod provider and then test it:

// counter_widget.dart
import 'package:flutter/material.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';

final counterProvider = StateProvider((ref) => 0);

class CounterWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider);
    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: [
        Text('Count: $count'),
        ElevatedButton(
          onPressed: () => ref.read(counterProvider.notifier).state++,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

Now, let's write a test for this widget:

// counter_widget_test.dart
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';
import 'package:your_app/counter_widget.dart';
import 'package:your_app/test/utils/testing_utils.dart';

void main() {
  testWidgets('CounterWidget displays count and increments', (WidgetTester tester) async {
    await tester.pumpMaterialWidgetScoped(CounterWidget());

    // Check initial state
    expect(find.text('Count: 0'), findsOneWidget);

    // Tap the increment button
    await tester.tap(find.byType(ElevatedButton));
    await tester.pump();

    // Check updated state
    expect(find.text('Count: 1'), findsOneWidget);
  });

  testWidgets('CounterWidget with initial value override', (WidgetTester tester) async {
    await tester.pumpMaterialWidgetScoped(
      CounterWidget(),
      overrides: [
        counterProvider.overrideWith((ref) => 10),
      ],
    );

    // Check initial state with override
    expect(find.text('Count: 10'), findsOneWidget);
  });
}

Key Points for Widget Testing with Riverpod

1. Use pumpMaterialWidgetScoped: This extension method wraps your widget in both a MaterialApp and a ProviderScope, which is necessary for most Riverpod-based widgets.

• Overrides for Testing: You can pass overrides to pumpMaterialWidgetScoped to replace providers with test-specific values or mocks.

• Interacting with Widgets: Use tester.tap(), tester.enterText(), etc., to interact with your widgets, then use tester.pump() or tester.pumpAndSettle() to rebuild the widget tree.

• Verifying UI Updates: After interactions, check that the UI has updated correctly using expect() and finder methods.

• Testing Different Scenarios: Create multiple test cases to cover different initial states, user interactions, and edge cases.

Testing Asynchronous Widgets

For widgets that depend on asynchronous providers (like FutureProvider or StreamProvider), you may need to use tester.pumpAndSettle() or manually pump with a duration to allow for asynchronous operations to complete:

testWidgets('AsyncCounterWidget displays loading and then value', (WidgetTester tester) async {
  final asyncCounterProvider = FutureProvider((ref) async {
    await Future.delayed(Duration(seconds: 1));
    return 42;
  });

  await tester.pumpMaterialWidgetScoped(
    Consumer(builder: (context, ref, _) {
      final asyncValue = ref.watch(asyncCounterProvider);
      return asyncValue.when(
        data: (value) => Text('Count: $value'),
        loading: () => CircularProgressIndicator(),
        error: (_, __) => Text('Error'),
      );
    }),
  );

  // Initially, we should see a loading indicator
  expect(find.byType(CircularProgressIndicator), findsOneWidget);

  // Wait for the future to complete
  await tester.pumpAndSettle(Duration(seconds: 2));

  // Now we should see the value
  expect(find.text('Count: 42'), findsOneWidget);
});

By incorporating these widget testing techniques with Riverpod, you can ensure that your UI components interact correctly with your state management logic, leading to more robust and reliable Flutter applications.

Best Practices for Riverpod Testing

1. Isolation: Always use createContainer to isolate providers during testing.

2. Disposal: The createContainer utility automatically handles disposal, but ensure you're not keeping references that prevent garbage collection.

3. Async Handling: For async providers, use expectLater or await appropriately.

4. State Changes: Test both initial states and state transitions.

5. Mocking and Overrides: Use overrides in createContainer to mock dependencies or provide test-specific implementations. This allows you to isolate the component under test and control its environment.

6. Comprehensive Coverage: Test edge cases and error scenarios, not just the happy path.

7. Readability: Structure tests in a "Arrange-Act-Assert" pattern for clarity.

Conclusion

By understanding Riverpod's core concepts, including ProviderContainer, overrides, and the various provider types, you can create a comprehensive and robust test suite. The createContainer utility and judicious use of overrides allow you to precisely control the testing environment, focusing on specific behaviors without unnecessary dependencies.

This approach leads to more reliable, maintainable, and performant Flutter applications. As Riverpod continues to evolve, always refer to the official documentation for the most up-to-date information and advanced usage patterns.

Trust me, I've been there. Forms can be a real pain, but they're also the bread and butter of most apps. So, let's roll up our sleeves and dive into the world of Flutter forms together. By the end of this, you'll be creating forms so smooth, users might actually enjoy filling them out.

Setting the Stage

First things first, we need to invite some friends to our form-building party.

Open up your pubspec.yaml file and add these cool cats:

dependencies:
  flutter:
    sdk: flutter
  flutter_hooks: ^0.20.5
  hooks_riverpod: ^2.5.2
  riverpod_annotation: ^2.3.5
  freezed_annotation: ^2.4.4 
  json_annotation: ^4.9.0

dev_dependencies:
  flutter_test:
    sdk: flutter
  build_runner: ^2.4.9
  riverpod_generator: ^2.4.0
  freezed: ^2.5.2
  json_serializable: ^6.8.0

Now, run flutter pub get to fetch these packages. It's like ordering pizza for your project – essential for a good time!

But why these specific packages, you ask?

Well, flutter_hooks is like a Swiss Army knife for state management in widgets. hooks_riverpod combines the power of Riverpod (our state management superhero) with Flutter Hooks. And riverpod_annotation with riverpod_generator? They're the dynamic duo that'll help us write less boilerplate code.

The VIP: UserProfile Class

Let's create our star player, the UserProfile class. Think of it as the VIP of our app – it's got all the important info:

class UserProfile {
  final String username;
  final String email;
  final int age;
  final bool notificationsEnabled;

  UserProfile({
    required this.username,
    required this.email,
    required this.age,
    required this.notificationsEnabled,
  });

  UserProfile copyWith({
    String? username,
    String? email,
    int? age,
    bool? notificationsEnabled,
  }) {
    return UserProfile(
      username: username ?? this.username,
      email: email ?? this.email,
      age: age ?? this.age,
      notificationsEnabled: notificationsEnabled ?? this.notificationsEnabled,
    );
  }
}

See that copyWith method? It's like a clone machine for our UserProfile. Super handy when we want to update just one or two fields!

Do we really need to write this by hand?

Now, let's rewrite our UserProfile class using Freezed:

import 'package:freezed_annotation/freezed_annotation.dart';

part 'user_profile.freezed.dart';
part 'user_profile.g.dart';

@freezed
class UserProfile with _$UserProfile {
  const factory UserProfile({
    required String username,
    required String email,
    required int age,
    @Default(true) bool notificationsEnabled,
  }) = _UserProfile;

  factory UserProfile.fromJson(Map<String, dynamic> json) => _$UserProfileFromJson(json);
}

Whoa, what just happened? We've turned our UserProfile into a Freezed class. It's like giving it superpowers:

1. Immutability: This class is now as unchangeable as your grandma's secret recipe.

2. Auto-generated copyWith: No more hand-writing clone methods!

3. Equality comparisons: Two profiles with the same data are now considered equal. Identity crisis averted!

4. JSON superpowers: Serialization and deserialization come built-in. API integration just got a whole lot easier!

5. Pattern matching: For when you want to get fancy with your data handling.

The Personal Assistant: UserProfileNotifier

Now, we need someone to manage our VIP. Enter the UserProfileNotifier:

import 'package:riverpod_annotation/riverpod_annotation.dart';
import '../models/user_profile.dart';

part 'user_profile_provider.g.dart';
@riverpod
class UserProfileNotifier extends _$UserProfileNotifier {
  @override
  UserProfile build() {
    return const UserProfile(
      username: 'JohnDoe',
      email: 'john@example.com',
      age: 30,
      notificationsEnabled: true,
    );
  }

  void updateProfile({
    String? username,
    String? email,
    int? age,
    bool? notificationsEnabled,
  }) {
    state = state.copyWith(
      username: username ?? state.username,
      email: email ?? state.email,
      age: age ?? state.age,
      notificationsEnabled: notificationsEnabled ?? state.notificationsEnabled,
    );
  }
}

This notifier is like a personal assistant for our UserProfile. It keeps track of changes and updates the profile when needed. The @riverpod annotation is telling our code generator, "Hey, make some cool stuff for this class!"

After creating this file, don't forget to run:

It's like telling your assistant, "Hey, organize all this stuff for me!"

flutter pub run build_runner build --delete-conflicting-outputs

The Main Event: ProfileSettingsForm

Alright, now for the main event – the form itself. We'll create a ProfileSettingsForm widget. This is where users can tweak their profile info:

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';
import '../providers/user_profile_provider.dart';

class ProfileSettingsForm extends HookConsumerWidget {
  const ProfileSettingsForm({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final userProfile = ref.watch(userProfileNotifierProvider);
    final notifier = ref.read(userProfileNotifierProvider.notifier);

    final usernameController = useTextEditingController(text: userProfile.username);
    final emailController = useTextEditingController(text: userProfile.email);
    final ageController = useTextEditingController(text: userProfile.age.toString());
    final notificationsEnabled = useState(userProfile.notificationsEnabled);

    // We'll add more code here soon!

    return Scaffold(
      appBar: AppBar(title: Text('Profile Settings')),
      body: Padding(
        padding: EdgeInsets.all(16.0),
        child: Column(
          children: [
            TextFormField(
              controller: usernameController,
              decoration: InputDecoration(labelText: 'Username'),
            ),
            TextFormField(
              controller: emailController,
              decoration: InputDecoration(labelText: 'Email'),
            ),
            TextFormField(
              controller: ageController,
              decoration: InputDecoration(labelText: 'Age'),
              keyboardType: TextInputType.number,
            ),
            SwitchListTile(
              title: Text('Enable Notifications'),
              value: notificationsEnabled.value,
              onChanged: (value) => notificationsEnabled.value = value,
            ),
            // We'll add a save button here soon!
          ],
        ),
      ),
    );
  }
}

Notice how we're using copyWith in the saveProfile method? That's our Freezed magic making profile updates a breeze!

The Freezed Cherry on Top

After making all these cool changes, don't forget to tell your project to generate all the magical code:

flutter pub run build_runner build --delete-conflicting-outputs

This form is like a backstage pass to the user's profile. We're using HookConsumerWidget because it's the cool kid that lets us use both Riverpod and Hooks in the same widget.

The Watchful Eye: Tracking Form Changes

We want to know when the user makes changes, right? Let's set up a little spy system:

final isFormChanged = useState(false);

useEffect(() {
  void listener() {
    isFormChanged.value = usernameController.text != userProfile.username ||
        emailController.text != userProfile.email ||
        ageController.text != userProfile.age.toString() ||
        notificationsEnabled.value != userProfile.notificationsEnabled;
  }

  usernameController.addListener(listener);
  emailController.addListener(listener);
  ageController.addListener(listener);

  return () {
    usernameController.removeListener(listener);
    emailController.removeListener(listener);
    ageController.removeListener(listener);
  };
}, [userProfile]);

This useEffect hook is like a vigilant guard, always watching for changes in the form. It's comparing the current values to the original ones, and if anything's different, it raises the isFormChanged flag.

The Bouncer: Input Validation

We can't just let any old data through, can we? Time for some validation:

bool validateInputs() {
  final isValidEmail = RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$').hasMatch(emailController.text);
  final isValidAge = int.tryParse(ageController.text) != null && int.parse(ageController.text) > 0;
  return usernameController.text.isNotEmpty && isValidEmail && isValidAge;
}

This function is like the bouncer at an exclusive club. It's checking if the email looks legit, the age is a positive number, and the username isn't empty. Only the cool kids (valid inputs) get through!

The Grand Finale: Saving the Profile

When the user hits that save button, we want to make sure everything's shipshape:

void saveProfile() {
  if (!validateInputs()) return;

  notifier.updateProfile(
    username: usernameController.text,
    email: emailController.text,
    age: int.parse(ageController.text),
    notificationsEnabled: notificationsEnabled.value,
  );

  ScaffoldMessenger.of(context).showSnackBar(
    SnackBar(content: Text('Profile updated successfully')),
  );

  isFormChanged.value = false;
}

This function is like a careful librarian, making sure all the info is filed away correctly. If everything checks out, it updates the profile, shows a snazzy success message, and resets our change tracker.

Now, let's add that save button to our form:

ElevatedButton(
  onPressed: isFormChanged.value && validateInputs() ? saveProfile : null,
  child: Text('Save Profile'),
)

This button is smart - it only lights up when there are changes and all inputs are valid. No premature saving here!

Everything Together

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';
import '../providers/user_profile_provider.dart';

class ProfileSettingsForm extends HookConsumerWidget {
  const ProfileSettingsForm({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final userProfile = ref.watch(userProfileNotifierProvider);
    final notifier = ref.read(userProfileNotifierProvider.notifier);

    final usernameController = useTextEditingController(text: userProfile.username);
    final emailController = useTextEditingController(text: userProfile.email);
    final ageController = useTextEditingController(text: userProfile.age.toString());
    final notificationsEnabled = useState(userProfile.notificationsEnabled);

    final isFormChanged = useState(false);

    useEffect(() {
      void listener() {
        isFormChanged.value = usernameController.text != userProfile.username ||
            emailController.text != userProfile.email ||
            ageController.text != userProfile.age.toString() ||
            notificationsEnabled.value != userProfile.notificationsEnabled;
      }

      usernameController.addListener(listener);
      emailController.addListener(listener);
      ageController.addListener(listener);

      return () {
        usernameController.removeListener(listener);
        emailController.removeListener(listener);
        ageController.removeListener(listener);
      };
    }, [userProfile]);

    bool validateInputs() {
      final isValidEmail = RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$').hasMatch(emailController.text);
      final isValidAge = int.tryParse(ageController.text) != null && int.parse(ageController.text) > 0;
      return usernameController.text.isNotEmpty && isValidEmail && isValidAge;
    }

    void saveProfile() {
      if (!validateInputs()) return;

      final updatedProfile = userProfile.copyWith(
        username: usernameController.text,
        email: emailController.text,
        age: int.parse(ageController.text),
        notificationsEnabled: notificationsEnabled.value,
      );

      notifier.updateProfile(
        username: updatedProfile.username,
        email: updatedProfile.email,
        age: updatedProfile.age,
        notificationsEnabled: updatedProfile.notificationsEnabled,
      );

      ScaffoldMessenger.of(context).showSnackBar(
        SnackBar(content: Text('Profile updated successfully')),
      );

      isFormChanged.value = false;
    }

    return Scaffold(
      appBar: AppBar(title: Text('Profile Settings')),
      body: Padding(
        padding: EdgeInsets.all(16.0),
        child: Column(
          children: [
            TextFormField(
              controller: usernameController,
              decoration: InputDecoration(labelText: 'Username'),
            ),
            TextFormField(
              controller: emailController,
              decoration: InputDecoration(labelText: 'Email'),
            ),
            TextFormField(
              controller: ageController,
              decoration: InputDecoration(labelText: 'Age'),
              keyboardType: TextInputType.number,
            ),
            SwitchListTile(
              title: Text('Enable Notifications'),
              value: notificationsEnabled.value,
              onChanged: (value) => notificationsEnabled.value = value,
            ),
            ElevatedButton(
              onPressed: isFormChanged.value && validateInputs() ? saveProfile : null,
              child: Text('Save Profile'),
            ),
          ],
        ),
      ),
    );
  }
}

Pro Tips for Form Mastery

1. Debounce like a Pro: If you're doing something heavy (like API calls) on every keystroke, use debouncing. It's like giving your app a chill pill:

       final debouncedUsername = useDebounce(usernameController.text, const Duration(milliseconds: 300));
   
       useEffect(() {
         print('Checking availability for username: $debouncedUsername');
         // Perform API call here
         return null;
       }, [debouncedUsername]);
   

2. Error Messages with Attitude: Don't just say "Invalid input". Get creative!

       TextFormField(
         controller: emailController,
         decoration: InputDecoration(
           labelText: 'Email',
           errorText: !RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$').hasMatch(emailController.text)
               ? 'That email looks about as real as a three-dollar bill'
               : null,
         ),
       )
   

3. Accessibility is Key: Make your forms accessible. It's not just nice, it's necessary:

       TextFormField(
         controller: usernameController,
         decoration: InputDecoration(labelText: 'Username'),
         autofocus: true, // Focus on this field when the form loads
         textInputAction: TextInputAction.next, // Move to next field on submit
       )
   

4. Form Keys: For more complex forms, use a GlobalKey<FormState>:

    final formKey = GlobalKey<FormState>();
   
    // In your build method:
    Form(
      key: formKey,
      child: Column(
        children: [
          // Your form fields here
        ],
      ),
    )
   
    // Validate the entire form:
    if (formKey.currentState!.validate()) {
      // Form is valid, proceed with saving
    }
   

5. Separation of Concerns: Use Riverpod providers to handle business logic:

    @riverpod
    Future<bool> checkUsernameAvailability(CheckUsernameAvailabilityRef ref, String username) async {
      // Implement API call to check username availability
      await Future.delayed(Duration(seconds: 1)); // Simulating API call
      return username != 'takenUsername';
    }
   

6. Test, Test, Test: Write tests for your forms. It's like proofreading your work – boring but essential:

       testWidgets('ProfileSettingsForm shows validation errors', (WidgetTester tester) async {
         await tester.pumpWidget(ProviderScope(child: MaterialApp(home: ProfileSettingsForm())));
   
         await tester.enterText(find.byType(TextFormField).at(1), 'invalid-email');
         await tester.pump();
   
         expect(find.text('That email looks about as real as a three-dollar bill'), findsOneWidget);
       });
   

   Wrapping Up

   And there you have it, folks! We've taken the scary beast that is form handling in Flutter and tamed it into a purring kitten. With Riverpod for state management and hooks for local widget state, you've got a powerful combo that'll make your forms sing.

   Remember, practice makes perfect. The more forms you build, the easier it gets. So go forth and create forms that are so good, users might actually enjoy filling them out. (Okay, maybe that's a stretch, but we can dream, right?)

   Happy coding, and may your forms always validate on the first try!

This article will guide you through the process of testing a permission service class, using a PermissionHandlerAppPermissionsService as an example.

Understanding the Permission Service

First, let's look at a simplified version of our PermissionHandlerAppPermissionsService:

import 'package:permission_handler/permission_handler.dart';
import '../domain/app_permissions_service.dart';
import '../domain/model/permission_type.dart';
import '../domain/model/permission_status.dart' as domain;

class PermissionHandlerAppPermissionsService extends AppPermissionsService {
  @override
  Future<Result<AppException<PermissionErrorCode>, domain.PermissionStatus>>
      requestPermission(PermissionType type) async {
    try {
      final permission = type.toPermission();
      final status = await permission.request();
      return Success(status.toDomain());
    } catch (e) {
      return Failure(AppException(PermissionErrorCode.unknown));
    }
  }
}

This service uses the permission_handler package to request permissions and handles the results.

Setting Up the Test Environment

To test this service effectively, we'll use a custom MethodChannelMock class.

This class allows us to simulate method channel calls without relying on the actual platform implementation. Here's the implementation:

import 'package:flutter/services.dart';
import 'package:flutter_test/flutter_test.dart';

class MethodChannelMock {
  MethodChannelMock({
    required String channelName,
    required this.method,
    this.result,
    this.delay = Duration.zero,
  }) : methodChannel = MethodChannel(channelName) {
    TestDefaultBinaryMessengerBinding.instance.defaultBinaryMessenger
        .setMockMethodCallHandler(methodChannel, _handler);
  }
  final MethodChannel methodChannel;
  final String method;
  final dynamic result;
  final Duration delay;

  Future _handler(MethodCall methodCall) async {
    if (methodCall.method != method) {
      throw MissingPluginException('No implementation found for method '
          '$method on channel ${methodChannel.name}');
    }

    return Future.delayed(delay, () {
      if (result is Exception) {
        throw result;
      }

      return Future.value(result);
    });
  }
}

This custom mock class allows us to easily set up method channel mocks with specific results and delays.

This custom mock class is designed to simulate method channel calls in Flutter tests. Here's a breakdown of its key components:

1. Constructor:

   1. Takes channelName, method, result, and an optional delay.

   2. Creates a MethodChannel with the given channelName.

   3. Sets up a mock method call handler using TestDefaultBinaryMessengerBinding.

2. Properties:

   1. methodChannel: The MethodChannel being mocked.

   2. method: The specific method name to mock.

   3. result: The result to return when the method is called.

   4. delay: An optional delay before returning the result.

3. _handler method:

   1. This is the core of the mock. It's called when the mocked method is invoked.

   2. It checks if the called method matches the expected method name.

   3. If there's a mismatch, it throws a MissingPluginException.

   4. If the method matches, it returns the result after the specified delay.

   5. If the result is an Exception, it throws the exception instead.

The class provides a flexible way to mock method channel calls by:

• Allowing specification of the exact method to mock.

• Providing custom results or exceptions.

• Simulating delays in responses.

This approach allows for precise control over the behavior of platform channel interactions in tests, enabling thorough testing of various scenarios without relying on actual platform implementations.

Writing the Tests

Now, let's write some tests for our PermissionHandlerAppPermissionsService using the MethodChannelMock:

import 'package:flutter_test/flutter_test.dart';
import 'package:flutter/services.dart';
import 'package:your_app/modules/permissions/data/permission_handler_app_permissions_service.dart';
import 'package:your_app/modules/permissions/domain/model/permission_type.dart';
import 'package:your_app/modules/permissions/domain/model/permission_status.dart' as domain;
import '../../../common/method_channel_mock.dart';

void main() {
  late PermissionHandlerAppPermissionsService service;
  late MethodChannelMock methodChannelMock;

  setUp(() {
    service = PermissionHandlerAppPermissionsService();
    methodChannelMock = MethodChannelMock(
      channelName: 'flutter.baseflow.com/permissions/methods',
      method: 'requestPermissions',
      result: {0: 1}, // This represents PermissionStatus.granted
    );
  });

  test('requestPermission returns Success with granted status', () async {
    final result = await service.requestPermission(PermissionType.camera);

    expect(result, isA<Success>());
    expect((result as Success).value, equals(domain.PermissionStatus.granted));
  });

  test('requestPermission returns Success with denied status', () async {
    methodChannelMock = MethodChannelMock(
      channelName: 'flutter.baseflow.com/permissions/methods',
      method: 'requestPermissions',
      result: {0: 0}, // This represents PermissionStatus.denied
    );

    final result = await service.requestPermission(PermissionType.camera);

    expect(result, isA<Success>());
    expect((result as Success).value, equals(domain.PermissionStatus.denied));
  });

  test('requestPermission returns Failure on exception', () async {
    methodChannelMock = MethodChannelMock(
      channelName: 'flutter.baseflow.com/permissions/methods',
      method: 'requestPermissions',
      result: PlatformException(code: 'TEST_ERROR'),
    );

    final result = await service.requestPermission(PermissionType.camera);

    expect(result, isA<Failure>());
    expect((result as Failure).error.code, equals(PermissionErrorCode.unknown));
  });
}

In these tests, we're using the MethodChannelMock to simulate different responses from the platform channel. Here's what's happening:

1. We create a new MethodChannelMock in the setUp function with a default "granted" response.

2. In each test, we can create a new MethodChannelMock with different results to test various scenarios.

3. We test for granted permissions, denied permissions, and exceptions.

Advantages of Using MethodChannelMock

The MethodChannelMock class provides several benefits:

• Simplicity: It's easy to set up and use in tests, requiring minimal boilerplate code.

• Flexibility: You can easily change the result for different test scenarios.

• Realism: It closely mimics the actual method channel behavior, including the ability to simulate delays and exceptions.

Testing Different Permission Statuses

To thoroughly test your permission service, create tests for all possible permission statuses.

The MethodChannelMock makes it easy to simulate these different outcomes:

test('requestPermission returns Success with restricted status', () async {
  methodChannelMock = MethodChannelMock(
    channelName: 'flutter.baseflow.com/permissions/methods',
    method: 'requestPermissions',
    result: {0: 1}, // This represents PermissionStatus.restricted
  );

  final result = await service.requestPermission(PermissionType.camera);

  expect(result, isA<Success>());
  expect((result as Success).value, equals(domain.PermissionStatus.granted));
});

Conclusion

Testing permission-handling classes in Flutter becomes more straightforward and reliable with a custom MethodChannelMock class. This approach allows you to:

• Simulate various permission statuses and error conditions.

• Test your code's behavior without relying on actual device permissions.

• Ensure your permission handling logic works correctly across different scenarios.

By following this testing strategy, you can create comprehensive tests that cover various permission-related scenarios, leading to a more robust and reliable application.

Remember to test for all possible permission statuses, error conditions, and edge cases. This thorough testing will help you catch and fix issues early in the development process, ensuring your app handles permissions correctly in all situations.

Recommended

Listen to the Podcast version of this. I gave more detail on getting a Job as a Flutter Developer

https://open.spotify.com/episode/2YujGK0GdaE1S9EAaCyCRC

About Me

My name is Temitope and I am a Flutter Developer. I have been building mobile apps in the last 3 years using Flutter. Prior to that, I have been a Web developer building perhaps one of Nigeria's largest loan lending platforms. I eventually got tired of the web and decided to go head-on into mobile app development.

Was this a good decision? You will find out in a bit.

I have made a lot of progress as a developer and a major highlight of this is getting a job as a Flutter developer.

A Timeline

Started the year with a plan - Learn as many Data Structures and Algorithms as possible - so I can confidently apply for Flutter jobs. I do not like to go to an interview unprepared and look like a fool. So January, I started learning and by the end of January, I was a little confident. I knew some C# and JavaScript so I used these two languages to practice some DS and Algo exercises.

The following month, February, I started applying to jobs on LinkedIn.

Applying to jobs on LinkedIn turned out to be a huge time waster. I am not sure how people get jobs from just applying to jobs on LinkedIn. Recruiters never got back to me on LinkedIn.

I think one would have a better chance by sending a message to recruiters directly on LinkedIn rather than wasting time using the job board. Another strategy that could work is to "Show workings".

Show Workings

"Rather than applying for jobs, why not get recruiters to notice you instead"? This was my thought after sending over 50+ applications on LinkedIn. But, how do I get them to notice me?

Show workings.

I believe that no matter how talented/genius you might be, hiding under the bed would make you go hungry and people won't see how good you really are. Or at most, you become underpaid.

I had worked at Sterling at the time and seen a lot of wasted talents in the banking industry getting underpaid because they did not show the world what they can do.

I had an idea. I will build pockets of Demos and POCs in Flutter and post them on Twitter and LinkedIn. The first week I did that on LinkedIn, I had recruiters and CEOs in my Inbox.

It should be noted that you can see a better response from recruiters on Indeed than on LinkedIn when applying for jobs - my opinion.

A city that is set on a hill cannot be hidden - Matt. 5:14

A Stream of "Unfortunately"

Yeah! Typical. You apply for a job, go through some series of interviews and bam, you get those emails. Rough. It can mess with your self-esteem.

I was fortunate, I didn't take those emails seriously because I had a job at Sterling. If I didn't, it would have been really hard when those emails came in.

It was a learning process for me and the first thing I learnt was that recruitment for a Flutter role was quite different from what I was used to. I was expecting algorithm questions and the likes.

Imagine preparing a whole week solving challenges on Codility but then you get asked "What is the difference between a Stateless widget and Stateful widget". Hold up. I froze. An interview for another company, same series of questions. confused

I was given a lot of take-home assessments too.

Then I figured, If I am going to land a job, I need to go learn the basics of Flutter in-depth. It was not like I didn't know how to write Flutter, I just never really paid attention to explaining what some concepts are. Some of those things are just big words - "immutability and mutability". Huh? It's simple right? Yes, but that is such a big word. Things that change and things that do not change. Simple.

This is a thread on Twitter that helped me know which questions to expect in Flutter interviews.

Not that I'd advise it, I kept a folder for all the rejection emails. This helped me to reminisce and prepare for the next interview.

A Job Finally

Looks like it's usually the interview you thought you didn't do well in that you'd actually get a job with.

Got a job in October. Yay!

I had wanted to leave banking and fintech and so it's a dream come through. I remember getting an offer from a company in the UK. I turned down the offer because it is Fintech(shhh.. na because of money sha. How I go dey work for company for UK dey collect local rate.).

Key Takeaway(Party Jollof inside)

I am not sure there is a key takeaway from what I have written so far, however, if this article was written by someone else and I was reading, my key takeaways would be:

• Applying for jobs on LinkedIn may be useless. You'd have more success with Indeed.
• Showcase what you are capable of on LinkedIn and Twitter. They are powerful tools to gain exposure.
• Job hunting is a game of numbers.

Is learning Flutter worth it? Yes, it is. Apart from the joy I get to showcase the demos and POCs I built on Twitter and LinkedIn, I get paid as a Flutter Developer.

Will it be worth it if you learn Flutter? Definitely, yes.

In retrospect, I should have started applying for jobs earlier than I did. I thought I really needed DS and Algo in the interviews.

Other than career

Moving away from career update, earlier this year, the Code Clan Nigeria Community, which I founded, moved to Discord. Since then we have grown to over 600+ members learning together. You can join us here.

By the way, if you are interested in volunteering for the community, please send me a DM on Twitter.

Earlier in the year, I also took on 3 Flutter Mentees. Next year, I will do the same.

Life Update

Got engaged to the most beautiful woman in the world. This is the highlight of my 2021.

She loves her ring y'all.

What next?

• Next year, I will keep applying for jobs. I believe the time to apply for jobs is when you currently have a job. You'll be able to confidently do interviews and negotiate your pay.
• Resume Podcasting.
• Upload more videos to my YouTube channel.
• Launch a beginner's Flutter course.
• Organize a meetup for Code Clan Nigeria.
• Write more articles this year.

Is this article long? Is this an article? Well, I hope it was a good read.

Your friend,

Temi(not Timi) Ajiboye