Build maintainable Flutter apps with these 3 concepts

Introduction

Most Flutter developers don’t struggle with writing code. They struggle with reading it’s specially six months later. In this post, we will explore three concepts that will help you build maintainable apps and make your future self happier.

Concept 1: State Management

Let’s start with principle one, which is state and how you would go about managing it.

setState

State management typically begins with setState and then progresses into using a state management package.

Provider, Riverpod or even bloc

That package can be Provider, Riverpod, bloc, or any other general state management package.

These all come with their own different recommended approaches on how you should handle state. But we have everything we need already.

ValueNotifier and ChangeNotifier exists

For state within a widget, we have setState. For state within a wider architecture, you can use ChangeNotifier or ValueNotifier. Both of these notify the view whenever the data changes.

1
// setState example
2
setState(() { count++; });
3

4
// ChangeNotifier example
5
class CountingModel extends ChangeNotifier {
6
  int value = 0;
7
  void increment() { value++; notifyListeners(); }
8
}
9

10
// ValueNotifier example
11
ValueNotifier<int> countNotifier = ValueNotifier(0);

Within the view, we can listen to these notifications with a ListenableBuilder or ValueListenableBuilder. This would then cause the builder to rebuild the child widgets.

1
// Listen to ChangeNotifier
2
ListenableBuilder(
3
  listenable: countingModel,
4
  builder: (_, __) => Text('${model.value}')
5
);
6

7
// Listen to ValueNotifier
8
ValueListenableBuilder<int>(
9
  valueListenable: countNotifier,
10
  builder: (_, count, __) => Text('$count')
11
);

State management doesn’t have to be hard. The difficult part with state is how you would go about the architecture around it, and that leads us into the second concept.

Concept 2: Architecture

The architecture drives the flow of your application. Flutter recommends MVVM, which is what we cover in our course. We teach a similar architecture with some quality of life improvements.

MVVM

Remember, an architecture should be able to scale from a simple hobby project to an enterprise situation without introducing lots of layers initially to support it.

In reality, most projects don’t make it to the enterprise step, so don’t overcomplicate your life.

You should think of the architecture as a guideline on how you structure your code, not rules. It should be able to be done with the minimal amount of code and be able to scale in complexity and support as you need it.

If you have a view such as a page, you would put the business logic in a class referred to as a view model. This class would contain ValueNotifiers around the state you want to have.

You then instantiate the view model within the view and use a ValueListenableBuilder to react to those state changes.

1
class ViewModel {
2
  final countNotifier = ValueNotifier(0);
3
  void update() => count.value++;
4
}
5

6
class _State extends State<MyPage> {
7
  final vm = ViewModel();
8

9
  @override
10
  Widget build(BuildContext c) => ValueListenableBuilder(
11
    valueListenable: vm.countNotifier,
12
    builder: (_, count, __) => Text('$count'),
13
  );
14
}

This architecture allows you to scale up the layers if wanted. This could be a repository layer. A repository is a class that interacts with outside sources. A repository can be added to this architecture without affecting the rest of the code. The repository can then be used throughout the application using a service locator.

If you want to manage state in an app-wide approach, which we call a service, you can create a class, add the state, and expose it to your different view models. There you have a simple and effective way for app-wide state.

1
class CountService {
2
  final countNotifier = ValueNotifier(0);
3
  void update() => count.value++;
4
}
5

6
class _State extends State<MyPage> {
7
  final vm = ViewModel(countService: locator<CountService>());
8

9
  @override
10
  Widget build(BuildContext c) => ValueListenableBuilder(
11
    valueListenable: vm.countNotifier, // exposed through a getter
12
    builder: (_, count, __) => Text('$count'),
13
  );
14
}

Concept 3: Automatic Tests

Now for concept three, we have automatic tests. Here you want to cover the widest range possible first.

Have you ever written lots of unit tests only to realize they break on every refactor? This is because the tests are tied to the implementation rather than the input and output. This is also called coupling.

Input and Output

Think of the concept of input and output; that is when you use unit tests.

Action and Result

If you think about action and result, this is when you use widget or integration tests.

For example, instead of writing unit tests for all your view model methods, you can instead write widget tests that verify the interaction between what your user sees and the business logic behind those actions.

1
void main() {
2
  testWidgets('test counter business logic', (WidgetTester tester) async {
3
    await tester.pumpWidget(MyApp());
4

5
    expect(find.text('0'), findsOneWidget);
6
    expect(find.text('1'), findsNothing);
7

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

11
    expect(find.text('0'), findsNothing);
12
    expect(find.text('1'), findsOneWidget);
13
  });
14
}

This approach will allow you to write simple tests that are easy to maintain, give you good confidence, and let you refactor without breaking tests.

Think of your tests as a way to verify your code while reducing the coupling of your test code to your implementation code.

”The goal of testing is to separate the wheat from the chaff, not to tie the two together.” - Kent Beck

Conclusion

In summary, avoid state management packages and use what is included in Flutter. We use a simple and expandable architecture; we use a modified MVVM architecture. Finally, write tests that give you confidence in the code you write.

• Minimize packages
• Use a good architecture
• Tests that do not break

If you want to learn more about testing, read our article on widget vs unit testing.