Flutter at 10 years

It all began with Eric Seidel's keynote, reflecting on the first 10 years of Flutter. The keynote was a journey through Flutter's evolution, broken down into three key sections:

1. Getting Flutter to Work

The first part of the presentation revisited the humble beginnings of Flutter, with Eric recalling one of the early “Sky” demos, which would later evolve into Flutter. You can check out that original demo here: Sky: An Experiment Writing Dart for Mobile (Dart Developer Summit 2015). It was a powerful reminder of the engineering challenges and achievements that led to what we now recognize as Flutter today. Once those initial demos were up and running, the focus shifted toward building something stable and reliable that developers could use in production.

2. Flutter in production

Next, Eric shared how companies began taking a leap of faith with Flutter, with Hamilton being the first commercial app developed using the framework, this set the stage for Flutter’s suitability in large-scale production environments. This started a wave of adoption by businesses—big and small—leading to discussions on how to best leverage the framework: from UI and animations to state management and architecture. This laid the foundation for the stable Flutter we know today.

3. Flutter Everywhere

Today, Flutter has over 1 million published apps, and it has been embraced by countless businesses. However, Eric pointed out that there’s still a barrier preventing some large enterprises and legacy businesses from fully adopting Flutter. The need now is for more organic success stories—companies demonstrating Flutter’s power not because of Google partnerships, but because they’ve achieved real success with the framework.

In conclusion, the keynote made it clear that Flutter is ready. As Eric put it, it has become the "safe choice" for multi-platform development. However, there’s still progress to be made on the business front. We now have a stable and reliable framework, but it’s up to both developers and businesses to drive a large adoption of Flutter. And as a final thought, it’s evident that Flutter is here to stay, leading multi-platform development for at least another 10 years.

Going offline first with Flutter by Gianfranco Papa and Elian Ortega

It was an amazing opportunity to share the stage with Gianfranco Papa at FlutterCon USA for this talk. We wanted to set the foundation for future discussions about offline-first approaches within the Flutter community, a topic we believe is crucial but not widely covered.

The idea behind our talk was to introduce the key concepts of offline-first development, especially in the context of Flutter, where there isn't as much documentation available compared to native Android or iOS. We started by explaining why this approach is essential for modern apps, discussing everything from optimistic UI updates to delta updates and synchronization strategies. We also got into conflict resolution techniques like First Write Wins (FWW), Last Write Wins (LWW), and more advanced strategies like Conflict-Free Replicated Data Types (CRDTs).

Offline-first development isn't trivial. It involves working with local databases, synchronizing data with the server when it's available, and resolving conflicts that arise from multiple devices trying to update the same data. We highlighted how this impacts user experience, making apps feel faster and more responsive while reducing server loads and potentially improving costs. We also stressed that these considerations should be factored into the app's architecture from the start to avoid complications down the line.

We touched on some tools and packages that can help developers implement offline-first functionality in Flutter, including popular local database options like Sqflite, Isar, Hive, and Drift, as well as CRDT solutions for handling more complex synchronization challenges.

Our goal was to set the groundwork for more in-depth talks in the future and encourage developers to consider offline-first strategies early in their projects for a smoother, more efficient development process.

Background Processing With Flutter and Native Platforms by Dominik Roszkowski

I was particularly interested in this talk, as background processing plays a crucial role in creating offline-first applications.

Dominik kicked off the session by highlighting a common Google search: “How to do background processing in Flutter?” The top result typically suggests, “In Flutter, you can just use isolates.” But, as he explained, this is merely the tip of the iceberg.

He then discussed some key considerations when using isolates, such as the fact that they require the Flutter engine and can be invoked either from the main engine or a new engine created in the native code. Dominik also presented a demo showing how to create a new engine and perform background processing using Kotlin for Android.

This led to a bold takeaway: “Maybe write your code natively?” He emphasized that background processing behaviors and APIs vary significantly between iOS and Android. His demo focused on Kotlin and Android, where the environment is more controlled, making it easier to ensure consistent behavior.

Some existing background processing plugins were highlighted, including:

• background_fetch by Transistor Software

• workmanager by Flutter Community

• flutter_background_service by ekasetiawans

• flutter_downloader, background_downloader, and flutter_uploader

It was an excellent talk, and I highly recommend watching it if you’re planning to work on any background processing tasks. You can catch the talk recorded during FlutterCon Europe here.

Stop centralizing! A humble approach to Flutter app architecture by Matt Carroll

I’m a big fan of architecture, and I always find it valuable to explore new approaches.

Matt kicked off by discussing the pros and cons of centralizing app components and features—things like UI themes and internationalization. But the real focus came when he addressed navigation through the example of a multistep form for buying movie tickets.

In this example, Matt demonstrated how a centralized navigation approach could introduce unnecessary complexity for a relatively simple feature. Instead, he proposed disconnecting the multistep form from centralized navigation and managing the flow using a StatefulWidget and a switch statement to display different widgets based on the current step which was handled with an enum. Naturally, this raised concerns like, “What if I need to go back?” and “What about navigation transitions?” The solution was simple: add an onBackRequested callback to each view for handling back navigation, and use a custom widget (I believe it was called StackNavigation) to preserve state and animate between steps.

While this approach might be controversial for some developers, the key takeaway was clear: in many cases, opting for a simpler architecture can lead to the same results, but with faster development and less complexity.

The power of Macros in Dart by Gianfranco Papa

Macros are one of the most anticipated features in Dart, offering the potential to introduce powerful metaprogramming into the language. Gianfranco's talk was all about breaking down what macros are, how they can be used in day-to-day coding, and how developers can create their own macros to make life easier.

He also went into the technical side of things, talking about the different stages of a macro’s lifecycle and explaining how the order of execution works behind the scenes. This gave everyone a better understanding of how macros will function in practice.

Gianfranco wrapped up by highlighting how macros could change the way we write Dart code—especially by reducing the need for code generation tools, like those used for JSON serialization. This shift could lead to cleaner, more efficient codebases with fewer workarounds. It’s clear that macros are going to make a big impact when they officially land in Dart.

From frontend to backend with Serverpod by Viktor Lidholt

I was particularly interested in this talk because I’ve been working with Dart on the server almost daily for the past few months. Naturally, I’d heard of Serverpod but hadn’t taken the time to dive deeper into it.

With my current Dart-on-the-server setup, I’ve faced several challenges. For instance, logging has been tricky to implement, especially when trying to make the logs look good in GCP. I’ve also had issues with health checks to ensure the API is running smoothly, and I ended up handling authentication in the mobile app using Firebase for simplicity. Since I’m keen to explore more of the backend world (I’ve worked with NestJS for some projects), I had this feeling that my current setup was missing a lot.

That’s why, when I saw the second slide of the talk listing features Serverpod has built-in, I was immediately intrigued. The list included:

• Logging (with a companion app to view logs)

• File uploads

• Authentication with major providers (Email, Google, Apple, Firebase)

• Data streaming

• Task scheduling

• Health checks

• Easy deployment

• Data migrations

Knowing that Serverpod is so feature-rich and backed by a team of 8 developers dedicated to its growth gave me a lot of confidence in its potential for long-term support and new features.

Viktor then went on to demo how to create models, run migrations, and build an endpoint. The process felt very similar to my current workflow, but with a lot more built-in functionality and benefits.

I’m genuinely excited to try Serverpod myself and might even write a blog post about my experience. If you're curious to learn more, check out their excellent documentation at serverpod.dev.

Building a package with assets by Moritz Sümmermann and Daco Harkes

This talk grabbed my attention because it featured two Googlers from the Dart compiler team. In my view, the more Dart advances as a language, the more Flutter will benefit as a framework for cross-platform development.

The session began with a disclaimer: some of the demos shown were only available on the Flutter master channel behind experimental flags, and a few only worked on their laptops (which was very funny 😂). Moritz and Daco then showcased an add and subtract function written in C, which was built and bundled as part of a Dart package asset. They also demonstrated how tree-shaking applies to native code—if the subtract function wasn’t used in the Dart code, it was excluded from the final native build. This technique worked for other assets too, such as JSON files.

As they walked through the process, they explained the hooks involved in building and linking these native code assets. They emphasized that their implementation followed protocols that would allow support for other programming languages, such as Rust, Kotlin, and Swift, in the future.

The end goal of the "Asset" feature in Dart and Flutter is to facilitate the use of pre-existing code from other languages, allowing developers to integrate it seamlessly within their Dart projects.

Future of Dart Panel

This panel was one of my favorite events at FlutterCon, offering valuable insights while engaging with questions directly from the community. The open format allowed attendees to hear the thoughts and opinions of the Dart team, and there were some particularly interesting discussions.

One recurring question, reflecting concerns within the developer community, was: “Is Google going to kill Dart and Flutter?” Michael Thomsen’s response was clear—this question has been asked repeatedly since the begining of the language, and Dart is still going strong. His response gave a sense of confidence for the future of both Dart and Flutter. They also mentioned appreciation for community contributions to the Dart ecosystem.

Other questions ranged from thoughts on WebAssembly (WASM) for Flutter Web to things the team might have done differently. For example, there was once an intention to remove semicolons from the language, but this was ultimately scrapped due to the enormous impact it would have had on the framework's core—simply too disruptive to consider.

The main takeaway for me was the reiterated message that Dart and Flutter are here to stay, with the team’s main focus now on highly anticipated features like WASM and macros—features that the community has been asking for quite a bit.

Flutter and Dart Package Ecosystem Summit

The "Flutter and Dart Package Ecosystem Summit" was another great session I attended, focusing on the current state and future of the package ecosystem in Flutter and Dart. This session aimed to address some of the key issues and challenges developers face, such as abandoned packages and finding ways to encourage ongoing maintenance through potential compensation models for package maintainers.

The discussion was led by Ander Dobo and Rody Davis, with members of the Dart team, package creators, and community members actively participating. It was great to see that everyone involved is committed to avoiding the pitfalls that have impacted other open-source ecosystems in the past.

Some of the key takeaways for me were:

• Support for Package Maintainers: There’s clear interest from the community in finding ways to support package maintainers, possibly through a compensation model. While nothing has been stablished, starting this conversation is a step in the right direction to ensure long-term package maintenance.

• Flutter Community GitHub: If you can no longer maintain your package and want to prevent it from becoming obsolete, you can transfer it to the FlutterCommunity GitHub, where it will continue to be maintained by the community. You will still lead the package development but it will be backed up by the Flutter Community team.

• Pub.dev Package Name Recovery: In cases where a package has been abandoned for a significant period, developers can reach out to pub.dev to request that the package name be made available again.

• Namespace Discussions: There’s growing interest in introducing namespaces for packages to avoid conflicts where two packages share the same name. This could be an important change to ensure smoother package management as the ecosystem continues to grow.

This session highlighted how much thought is being put into ensuring that the Flutter and Dart package ecosystem remains sustainable and avoids common issues seen in other communities.

Final Thoughts

There were so many other amazing talks and sessions I couldn’t attend live, but I’m definitely looking forward to watching the recordings once they’re available. If possible, I might even write another post to highlight some of my favorite sessions that I couldn't catch.

All in all, FlutterCon USA was an incredible experience! It was amazing to meet so many talented people from the Flutter community in person, share knowledge, and be part of such a supportive network. Huge thanks to my team at Somnio Software, especially Mauricio Pastorini and Gianfranco Papa, for all their support and collaboration. I'm already excited for the next FlutterCon and to continue being part of this fantastic community.

What a great experience! See you all at the next one!

💡 Note: This article is part of the Cleaner Flutter series by my friend Marcos Sevilla to which I contribute. You can find the complete series here.

Hello and welcome to the last volume where we will talk about the domain layer of our Clean Architecture proposal. Last time we talked about a fundamental part: the repositories, which allow us to create the communication of our software with the outside world.

On this occasion, with the use cases we are going to achieve independence from the specific interactions of the user with the system, using use cases and thus obtain maintainable, reusable code that truly meets the needs of the business.

But before we get into technical matters, we must remember that there are 2 perspectives: a developer's and a business perspective of the product. This differentiation is a very important topic since by being clear about the objectives of the product we can develop software in a better way.

Remember that all software products should first go through a process where their requirements and the interactions of a user with the software product are defined, whether this is a login, addToShoppingCart, or processPayment.

Ok, let's get into it.

What are use cases?

In Uncle Bob's words...

The software in this layer contains the application-specific business rules. These encapsulate and implement all the use cases of the system.

I remind you that the use cases mentioned in the definition do not refer coding part or module, but to the use cases that came from de planning phase of the project.

Each event is an interaction of the user with the system and we can call this a use case. As this is also a business concept the most common way of displaying the use cases of the system is by the use case graph, which looks like this:

Taken from Use Case Tutorial for Dummies.

Here we have objects like:

• Actor: Users who interact with the system (might be another software too).
• UseCase: How the actor uses the system to fulfill some functionality.
• Relationship: The relationship between the actors and the use cases.

The example shows some use cases for a passenger at an airport. Which, as I mentioned before, is the user's interactions with the system, in this case, the logic of an airport.

In code

In my experience, I have noticed that the use case layer is usually bypassed and replaced using methods directly in the software's business logic. But when we implement it we achieve better decoupling and other advantages.

By adding the use cases layer the folder structure for the domain layer would look like this:

Complying with the principles

They end up being simpler repositories. When we create the use cases, we manage to facilitate communication with the repositories and we make sure to have better abstractions that meet the specific objective of that use case, and as we saw in previous articles, with this we comply with the single responsibility principle.

We use interfaces, not implementations. In use cases we are normally going to depend on a repository, which rather must be an interface, this way we would be complying with the Liskov substitution principle, since we could replace the repository with any other that implements the same interface and this will not affect the base logic of our use case.

Implementing in Dart

Like any of the components we've talked about throughout the series, each can be implemented in many ways. This time with the use cases we are going to use one of Dart's not very well-known features.

In Dart, there is something called callable classes. This allows us to use the instance of a class as if it were a function. To achieve this, all we have to do is implement the call method inside the class.

We get something like this:

class CallableClass {
  String call() => 'Thanks for calling!';
}

void main() {
  final callable = CallableClass();
  print(callable()); // Thanks for calling!
}

Using this Dart feature, we can create a class for each of our use cases and implement the call method with the respective functionality.

Putting the pieces together

With all the information we have, we can already see an example with all the pieces that we have carried so far: entities, repositories, and use cases.

The code is simplified to facilitate the example. I also remind you that to understand the examples you must read the previous articles. Here's the previous one.

Let's imagine a very simple case of a signIn, for this, we are going to have a user entity and a repository interface that contains a method to make thesignIn using an email and password.

class User {
  const User({
    required this.email,
    required this.password,
  });

  final String email;
  final String password;
}

abstract class AuthRepositoryInterface {
  Future<User> signIn({
    required String email,
    required String password,
  });
}

This is where many developers decide not to implement the use case layer, so they call the repositories directly from the application's business logic.

But since we are using use cases, we create a SignInUser class which will be our use case. This will have a dependency on the AuthRepositoryInterface, then we implement the call method and call signIn. And so we have a use case with sole responsibility and decouple the repositories from the business logic (state manager).

class UserSignIn {
  const UserSignIn({
    required AuthRepositoryInterface authRepository,
  }) : _authRepository = authRepository;

  final AuthRepositoryInterface _authRepository;

  Future<User> call({
    required String email,
    required String password,
  }) async {
    return await _authRepository.signIn(
      email: email,
      password: password,
    );
  }
}

It doesn't matter who wins the endless battle of which is the best state management tool, since it does not matter which one we select. If we even decide to change, this does not affect our implementation at all.

This example is quite simple, but for the moment what we are trying to do is understand each of the components that are part of this Clean Architecture proposal. Later we will make examples and videos applying all the theories with production code.

Continue with the Cleaner Flutter Series

You can go back to the series list here.

Of course, just as I have mentioned in other articles, in my opinion, package:riverpod is more of a dependency injection tool than a state management solution. It does include APIs like StateNotifier which can be used as a state management solution but that is a topic for another article.

Today I want to focus on one of the tools that are included inside the package:riverpod. The FutureProvider.

The problem

Almost every app has one feature that makes a single asynchronous operation to get some data that later on will be displayed to the user using some widgets.

As a good developer, you create a new feature folder with the view/ and your selected state management solution call it bloc/, cubit/, state_notifier/, provider/ or whatever you want.

But while writing every single line of code you are thinking:

It's kind of non-sense to write this amount of code for an extremely simple feature.

Enters FutureProvider

Straight from the docs:

A FutureProvider can be considered as a combination of Provider and FutureBuilder. By using FutureProvider, the UI will be able to read the state of the future synchronously, handle the loading/error states, and rebuild when the future completes.

We get access to data, loading, and error states based on a Future operation that is usually an http request.

It's important to understand that we get access to these states thanks to AsyncValue that is another API included in the package:riverpod.

The code

Nothing is better than the code itself to understand how a FutureProvider works.

You are going to build the following app:

It's a simple app that fetches a new programming joke after pressing a button. It uses the following jokes API sv443.

Folder/File structure

To start, we are going to create the following folder/file structure.

.
└── lib/
    ├── app/
    │   └── app.dart
    └── jokes/
        ├── logic/
        │   └── jokes_provider.dart
        ├── model/
        │   ├── joke.dart
        │   └── models.dart (barrel file)
        ├── view/
        │   └── jokes_page.dart
        └── jokes.dart (barrel file)

The app can be generated with the default flutter create command. It is going to have a single feature jokes/, separated into 3 parts. First, the logic of the feature in the /logic folder, which is going to contain the FutureProvider inside jokes_provider.dart. Then the user interfaces in the /view folder, which is going to contain the JokesPage inside jokes_page.dart. Finally, we need a model to serialize the response from the API so we are going to create a Joke model in themodel/ folder inside joke.dart.

Joke Model

import 'package:equatable/equatable.dart';

class Joke extends Equatable {
  const Joke({
    required this.error,
    required this.category,
    required this.type,
    required this.setup,
    required this.delivery,
    required this.id,
    required this.safe,
    required this.lang,
  });

  factory Joke.fromJson(Map<String, dynamic> json) => Joke(
        error: json['error'] as bool? ?? false,
        category: json['category'] as String? ?? '',
        type: json['type'] as String? ?? '',
        setup: json['setup'] as String? ?? '',
        delivery: json['delivery'] as String? ?? '',
        id: (json['id'] as num?)?.toInt() ?? 0,
        safe: json['safe'] as bool? ?? false,
        lang: json['lang'] as String? ?? '',
      );

  final bool error;
  final String category;
  final String type;
  final String setup;
  final String delivery;
  final int id;
  final bool safe;
  final String lang;

  @override
  List<Object?> get props => [
        error,
        category,
        type,
        setup,
        delivery,
        id,
        safe,
        lang,
      ];
}

This class will be in charge of serializing the JSON response from the API. You can check a sample response here.

Jokes Logic

Now, the reason we are here the FutureProvider that will make the HTTP request and handle the states changes of the joke query.

For this example, I'm using Dio as the http client.

Dio Client Provider

final dioClientProvider = Provider<Dio>(
  (ref) => Dio(
    BaseOptions(baseUrl: 'https://v2.jokeapi.dev/joke'),
  ),
);

It's important to create an independent Provider for the http client so that later we can mock it for testing purposes of the FutureProvider.

Jokes Future Provider

final jokesFutureProvider = FutureProvider<Joke>((ref) async {
  final result = await ref.read(dioClientProvider).get<Map<String, dynamic>>(
        '/Programming?type=twopart',
      );

  return Joke.fromJson(result.data!);
});

Yes... that's it.

With these lines of code, we're able to handle the loading, data, and error states of the request.

When called, the jokesFutureProvider will make the http request. On success, it will update its state to AsyncValue.data(Joke). If any errors occur during the request or serialization, the error will be automatically caught and the state will be updated to AsyncValue.error(ErrorObject). And while loading the jokesFutureProvider state will be AsyncValue.loading.

Jokes Page

Now we just need to create a User Interface to see the jokesFutureProvider in action.

JokeWidget

First, we can subscribe to state changes of the jokesFutureProvider doing:

final jokeState = ref.watch(jokesFutureProvider);

🚀 calling refwatch on the jokesFutureProvider will trigger the asynchronous operation of the FutureProvider.

The jokeState variable will give you access to the AsyncValue object and with its built-in when method we can easily handle the different states of the FutureProvider.

class JokeWidget extends ConsumerWidget {
  const JokeWidget({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final jokeState = ref.watch(jokesFutureProvider);

    return jokeState.when(
      loading: () => const Center(child: CircularProgressIndicator()),
      error: (error, _) => const Text(
        'Ups an error occurred. Try again later.',
        key: const Key('jokesPage_jokeWidget_errorText'),
      ),
      data: (joke) => Container(
        key: const Key('jokesPage_jokeWidget_jokeContainer'),
        padding: const EdgeInsets.all(20),
        decoration: BoxDecoration(
          borderRadius: BorderRadius.circular(20),
          color: Theme.of(context).secondaryHeaderColor,
        ),
        child: Column(
          children: [
            Text(joke.setup),
            Text(joke.delivery),
          ],
        ),
      ),
    );
  }
}

Get Joke Button

We have a widget that shows the joke, but we need a button to be able to refresh this joke and get a new one.

Calling ref.refresh(jokesFutureProvider) will refresh the provider and repeat the asynchronous operation.

Consumer(
  builder: (context, ref, _) {
    return Align(
      child: ElevatedButton(
        onPressed: () {
          ref.refresh(jokesFutureProvider);
        },
        child: const Text('Get new joke'),
      ),
    );
  },
),

Finally, we can put all of it together in the JokesPage:

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:future_provider_jokes_app/jokes/jokes.dart';

class JokesPage extends StatelessWidget {
  const JokesPage({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const JokesView();
  }
}

class JokesView extends StatelessWidget {
  const JokesView({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('JokesApp')),
      body: Padding(
        padding: const EdgeInsets.symmetric(horizontal: 20),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.stretch,
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            const JokeWidget(),
            const SizedBox(height: 10),
            Consumer(
              builder: (context, ref, _) {
                return Align(
                  child: ElevatedButton(
                    onPressed: () {
                      ref.refresh(jokesFutureProvider);
                    },
                    child: const Text('Get new joke'),
                  ),
                );
              },
            ),
          ],
        ),
      ),
    );
  }
}

With this, we have a fully implemented feature that gets us funny programming jokes 🎉.

Just in case you need it, here you have the other files needed to run the app.

Other files

app.dart

import 'package:flutter/material.dart';
import 'package:future_provider_jokes_app/jokes/jokes.dart';

class JokesApp extends StatelessWidget {
  const JokesApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark(),
      home: const JokesPage(),
    );
  }
}

With this we have

main.dart

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:future_provider_jokes_app/app/app.dart';

void main() {
  runApp(const ProviderScope(child: JokesApp()));
}

Testing 🧪

We cannot call ourselves good developers if we do not test our code. In this channel we test everything.

Tests folder structure:

test/
└── jokes/
    ├── logic/
    │   └── jokes_provider_test.dart
    └── view/
        └── jokes_page_test.dart

Let's start with the logic of our app.

For the tests I'll assume you have some extra knowledge of how package:riverpod works. If you would like a more in detailed article on Override and ProviderContainer please let me know in the comments.

DioProvider Test

We can add a test to validate that the Dio client has the correct url.

void main() {
  group('dioClientProvider', () {
    test('is a Dio with https://v2.jokeapi.dev/joke base url', () {
      final container = ProviderContainer();

      final dio = container.read(dioClientProvider);

      expect(dio, isA<Dio>());
      expect(dio.options.baseUrl, 'https://v2.jokeapi.dev/joke');
    });
  });
}

ℹ️ From de docs: ProviderContainer An object that stores the state of the providers and allows overriding the behavior of a specific provider. If you are using Flutter, you do not need to care about this object (outside of testing), as it is implicitly created for you by ProviderScope.

FutureProvider Test

Hopefully you remember how earlier in the article I mention the importance of creating a n independent dioProvider so that we were able to mock it for testing purposes. Well we've reached that point.

We'll use mocktail to create mocks of the Dio http client and the Response object.

class MockDio extends Mock implements Dio {}

class MockDioResponse<T> extends Mock implements Response<T> {}

Before start writing the tests let's create a group for the jokesFutureProvider so we can keep our test file organized.

 group('jokesFutureProvider', () {
    late Dio client;

    setUp(() {
      client = MockDio();
    });
  });

To start, we can test the happy path of the jokesFutureProvider. We can test that the FutureProvider state first changes to AsyncValue.loading and if the http request success the state will change to AsyncValue.data. We can also validate that the http request is made to the correct url.

test('returns AsyncValue.data when joke request success', () async {
  const jsonMap = <String, dynamic>{
    'error': false,
    'category': 'Programming',
    'type': 'twopart',
    'setup': 'Why are modern programming languages so materialistic?',
    'delivery': 'Because they are object-oriented.',
    'id': 21,
    'safe': true,
    'lang': 'en',
  };

  final response = MockDioResponse<Map<String, dynamic>>();
  when(() => response.data).thenReturn(jsonMap);

  // Use the mock response to answer any GET request made with the
  // mocked Dio client.
  when(() => client.get<Map<String, dynamic>>(any()))
      .thenAnswer((_) async => response);

  final container = ProviderContainer(
    overrides: [
      dioClientProvider.overrideWithValue(client),
    ],
  );

  // Expect the first state to be AsyncValue.loading.
  expect(container.read(jokesFutureProvider), AsyncValue<Joke>.loading());

  // Read the value of `jokesFutureProvider` which will trigger the
  // Asynchronous operation.
  await container.read(jokesFutureProvider.future);

  // Expect AsyncValue.data after the future completes.
  expect(
    container.read(jokesFutureProvider),
    AsyncValue<Joke>.data(
      Joke.fromJson(jsonMap),
    ),
  );

  // Verify the GET request was made to the correct URL.
  verify(
    () => client.get<Map<String, dynamic>>('/Programming?type=twopart'),
  ).called(1);
});

Now we can test the the opposite scenario. What happens when an error occurs during the asynchronous operation of the FutureProvider?. We would expect to have an AsyncValue.error. Let's test that:

test('returns AsyncValue.error when joke request throws', () async {
  final exception = Exception();

  // Use the mocked Dio client to throw when any get request is made
  when(() => client.get<Map<String, dynamic>>(any())).thenThrow(exception);

  final container = ProviderContainer(
    overrides: [
      dioClientProvider.overrideWithValue(client),
    ],
  );

  // Expect the first state to be AsyncValue.loading.
  expect(container.read(jokesFutureProvider), AsyncValue<Joke>.loading());

  // Read the value of `jokesFutureProvider` which will trigger the
  // Asynchronous operation.
  await expectLater(
    container.read(jokesFutureProvider.future),
    throwsA(isA<Exception>()),
  );

  // Expect AsyncValue.error after the future completes.
  expect(
    container.read(jokesFutureProvider),
    isA<AsyncError<Joke>>().having((e) => e.error, 'error', exception),
  );

  // Verify the GET request was made to the correct URL.
  verify(
    () => client.get<Map<String, dynamic>>('/Programming?type=twopart'),
  ).called(1);
});

UI Tests

After testing the logic/state_management part of our application we can proceed to test the UI. So that we can ensure that the app renders the correct widgets for the correct states.

Helper

Inside the test/ directory let's add a helper that will make the UI testing process easy.

test/
└── helpers/
    ├── helpers.dart (barrel file)
    └── pump_app.dart

And inside the pump_app.dart file let's add the following extension method.

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:flutter_test/flutter_test.dart';

extension PumpApp on WidgetTester {
  Future<void> pumpApp(
    Widget widget, {
    List<Override> overrides = const [],
  }) {
    return pumpWidget(
      ProviderScope(
        overrides: overrides,
        child: MaterialApp(
          home: widget,
        ),
      ),
    );
  }
}

With this extension method we can add the ProviderScope and pass in some overrides for every test.

Now we can go to the jokes_page_test.dart file and write our tests.

JokesPage Test

Let's start creating the group for the JokesPage tests:

void main() {
  group('JokesPage', () {
      // We'll use this later
      const tJoke = Joke(
          error: false,
          category: 'category',
          type: 'type',
          setup: 'setup',
          delivery: 'delivery',
          id: 1,
          safe: true,
          lang: 'lang',
    );

    // tests go here ...
  });
}

To mock the state of the FutureProvider during any test, we just need override the value of the jokesFutureProvider like this:

await tester.pumpApp(
  // any Widget ...
  overrides: [
    jokesFutureProvider.overrideWithValue(AsyncValue.loading()),
  ],
);

Knowing this, we can create the first test that simply validates if the JokesPage renders all the expected widgets.

testWidgets('renders JokeWidget and ElevatedButton', (tester) async {
  await tester.pumpApp(
    JokesPage(),
    overrides: [
      jokesFutureProvider.overrideWithValue(AsyncValue.loading()),
    ],
  );

  expect(find.byType(JokesPage), findsOneWidget);
  expect(find.byType(JokeWidget), findsOneWidget);
  expect(find.byType(ElevatedButton), findsOneWidget);
});

Now that you get how to the overrides let's test the loading, data and error cases for the JokeWidget:

group('JokeWidget', () {
  final errorTextFinder = find.byKey(Key('jokesPage_jokeWidget_errorText'));
  final jokeContainerFinder =
      find.byKey(Key('jokesPage_jokeWidget_jokeContainer'));

  testWidgets('renders CircularProgressIndicator for AsyncValue.loading',
      (tester) async {
    await tester.pumpApp(
      JokesPage(),
      overrides: [
        jokesFutureProvider.overrideWithValue(AsyncValue.loading()),
      ],
    );

    expect(find.byType(CircularProgressIndicator), findsOneWidget);
    expect(jokeContainerFinder, findsNothing);
    expect(errorTextFinder, findsNothing);
  });

  testWidgets('renders error text for AsyncValue.error', (tester) async {
    await tester.pumpApp(
      JokesPage(),
      overrides: [
        jokesFutureProvider.overrideWithValue(AsyncValue.error('')),
      ],
    );

    expect(errorTextFinder, findsOneWidget);
    expect(jokeContainerFinder, findsNothing);
    expect(find.byType(CircularProgressIndicator), findsNothing);
  });

  testWidgets('renders jokes container for AsyncValue.data',
      (tester) async {
    await tester.pumpApp(
      JokesPage(),
      overrides: [
        jokesFutureProvider.overrideWithValue(AsyncValue.data(tJoke)),
      ],
    );

    expect(errorTextFinder, findsNothing);
    expect(find.byType(CircularProgressIndicator), findsNothing);
    expect(jokeContainerFinder, findsOneWidget);
  });
});

FutureProvider.refresh

We are about to test the last part of our UI but this one can be tricky for some new developers. We need to test that the jokesFutureProvider is refreshed (it calls the asynchronous operation again) when the button in the JokesPage is pressed.

To do this you could think of trying to mock the FutureProvider, but this can be tricky and confusing. But we can mock the asynchronous operation that the FutureProvider executes and verify that it is called after pressing the button.

To do this we first need a function that can be mocked, to do this we could use a callable class:

class MockFunction extends Mock {
  Future<Joke> call();
}

and the test will end up looking like this:

testWidgets('refresh jokesFutureProvider when ElevatedButton is tapped',
    (tester) async {
  final mockFunction = MockFunction();

  when(mockFunction.call).thenAnswer((_) => Future.value(tJoke));

  await tester.pumpApp(
    JokesPage(),
    overrides: [
      jokesFutureProvider.overrideWithProvider(
        FutureProvider((_) => mockFunction.call()),
      ),
    ],
  );

  expect(find.byType(ElevatedButton), findsOneWidget);

  await tester.tap(find.byType(ElevatedButton));

  verify(
    mockFunction.call,
  ).called(2);
});

and just like that we are able to achieve 100% test coverage in our jokes application 🧪🎉.

Final thoughts

Before ending is my responsibility to remind you two things:

1. Remember to test your code as you are making a favor to your future self.
2. Use FutureProvider in a responsible way, it is a great tool for some simple logic flows but always think through so that you can decide the best solution.

Thanks for reading all the way! I hope this article was helpful.

If you would like to have any similar article covering another tool or state management solution, let me know in the comments.

If you got any questions feel free to contact me through any of my socials.

💡 Note: This article is part of the Cleaner Flutter series by my friend Marcos Sevilla to which I contribute. You can find the complete series here.

After starting in the world of programming we all reach a point where we have to look back on the road and review some of the lines of code that we have written, either 1 day ago to remember an idea or years ago to review the implementation of any module of our software.

Many times in these glances at the code of the past we come across a list of problems such as:

• Having to search among many files for the answer to what we are looking for.
• Not understanding the code we wrote.
• Not understanding why we wrote the code the way we did.

These problems start when we start a project because we do not spend enough time to have a clear idea not only of what we are going to do but also of how we are going to do it.

We have to develop code imagining what would happen if I return in 2 years to review it, this ability to program clean and understandable code is essential to facilitate development, especially if you work in a team.

What are the SOLID principles?

SOLID is the acronym for a set of principles that help us develop more maintainable code that also allows easy extension without compromising code already developed.

In other words...

Write more code without damaging what already works.

We can even see them as a set of guidelines to follow.

Now we are going to explore each of the principles, which can be applied to any programming language, but I am going to cover them using Dart language since it is the language used by the Flutter framework.

Before continuing it is important to note that these were first introduced by Uncle Bob. You can see his explanation SOLID Principles by Uncle Bob.

S stands for Single Responsibility

A class must have one, and only one, a reason to change.

To explain this principle we can imagine a messy room, as we have all had it at some point, perhaps even now that you are reading this.

But the truth is that within this, everything has its place and everything should be in its designated place. To put the analogy aside, this principle tells us more specifically:

• A class must have a unique responsibility (applies to methods, variables, entities, etc).
• There is a place for everything and everything should be in its place.
• All the variables and methods of the class must be aligned with the objective of the class.

By following these principles, we achieve smaller and simpler classes that have unique objectives. Also, we avoid giant classes with generic properties and methods that can be redundant in development.

Let's see an example:

Let's take a look at this signUp function. This could be the method we call from our UI layer to perform the user sign-up process.

Future<User> signUp({
  required String name,
  required String email,
  required String password,
}) async {
  final isValid = name.isNotEmpty && email.isNotEmpty && password.isNotEmpty;

  if (isValid) {
    final newUser = User(
      name: name,
      email: email,
      password: password,
    );

    final userMap = newUser.toMap();

    await saveToDb(json.encode(userMap));
  }
}

In the code, we see that there is the functionality of creation, conversion to JSON, and even the call to the database that is normally an API call, so we are not fulfilling the principle.

This is one of the most common mistakes, especially in Flutter, since developers easily make the mistake of combining different things within the same class or methods.

⚠️ In other articles we will see how this applies to Clean Architecture...

Done, I got it, now... how do I apply it?

To follow the single responsibility principle correctly, we could create methods and classes with simple and unique functionalities.

In the example method signUp many things are done with different objectives, each of these functionalities could be separated into an individual class with a single objective.

Extracting logic

We could implement a class that is responsible for performing the validation, there are many ways to do this. One of them can be to use package:formz which is a Dart package that allows us to create classes for a data type and perform validations.

import 'package:formz/formz.dart';

/// Define input validation errors
enum NameInputError { empty }

/// Extend FormzInput and provide the input type and error type.
class NameInput extends FormzInput<String, NameInputError> {
  /// Call super.pure to represent an unmodified form input.
  const NameInput.pure() : super.pure('');

  /// Call super.dirty to represent a modified form input.
  const NameInput.dirty({String value = ''}) : super.dirty(value);

  /// Override validator to handle validating a given input value.
  @override
  NameInputError? validator(String value) {
    return value.isNotEmpty == true ? null : NameInputError.empty;
  }
}

Do not focus too much on the logic of the code, the important thing is to understand that now the validation is decoupled from the rest of the logic with the validator method.

Connecting dependencies

The other error is to call an API from the business logic or user interface, this would not fulfill the principle since the connection with the API is a complex functionality by itself, so it would be best to implement a class as Repository to which we pass the parameters that we are going to send and delegate the rest of the process to it.

/// Repository that handles the relationship
/// between app logic and data source or API.
class AuthRepository {
  AuthRepository({
    http.Client? client,
  }) : _client = client ?? http.Client();

  final http.Client _client;

  /// Method that makes the API call to sign-up a user.
  Future<void> signUpUser(User user) async {
    try {
      await _client.post(
        Uri.parse('https://noscope.dev/user/create'),
        body: user.toMap(),
      );
    } catch (e) {
      throw NetworkException();
    }
  }
}

This repository concept is key to meeting clean architecture standards but we can see that the principle of single responsibility is behind this whole idea.

By implementing these classes applying the principle we would achieve a simpler method compared to how we started with:

Future<void> signUp({
  required String name,
  required String password,
  required String email,
}) async {
  final newUser = User(
    email: email,
    password: password,
    name: name,
  );
  await _authRepository.signUpUser(newUser);
}

Simpler, testable, more maintainable, and decoupled.

O stands for Open/Closed

An entity must be open to extending but closed to modify.

This principle tells us that we must extend our classes to add new code, instead of modifying the existing one.

The first time we read this it can be a bit confusing but it just is:

Don't modify what already works, just extend and add new code.

In this way, we can develop without damaging the previously tested code. To understand this principle we can see an example given by Katerina Trjchevska at LaraconEU 2018.

Let's imagine that our app has a payment module that currently only accepts debit/credit cards and PayPal as payment methods.

Future<void> pay(String paymentType) async {
  if (paymentType == 'card') {
    await _paymentRepository.payWithCard();
  } else if (paymentType == 'paypal') {
    await _paymentRepository.payWithPaypal();
  }
}

At a first glance at the code, we may think that everything is fine, but when we analyze its long-term scalability, we realize the problem.

Let's imagine that our client asks us to add a new payment method such as Alipay, gift cards, and others.

Each new payment method implies a new function and a new conditional in the pay method, and we could say that this is not an issue, but if we keep adding code within the same class, we would never achieve a stable, ready for production code.

By applying the open/closed principle, we can create an abstract class PayableInterface that serves as a payment interface. In this way, each of our payment methods extends this abstract class, and it can be a separate class that is not affected by modifications made to another.

abstract class PayableInterface {
  Future<void> pay();
}

class CardPayment implements PayableInterface {
  @override
  Future<void> pay() async {
    // Card payment logic.
  }
}

class PaypalPayment implements PayableInterface {
  @override
  Future<void> pay() async {
    // Paypal payment logic.
  }
}

class AliPayPayment implements PayableInterface {
  @override
  Future<void> pay() async {
    // AliPay payment logic.
  }
}

After having our payment logic implemented, we can receive a parameter with the paymentType that allows us to select the PayableInterface indicated for the transaction, and in this way we do not have to worry about how the pay method makes the payment, only to make a type of filtering so that the correct instance of the interface is used; be it Card, PayPal or Alipay.

enum PaymentType { card, payPal, aliPay }

class PaymentFactory {
  const PaymentFactory();

  PayableInterface initializePayment(PaymentType paymentType) {
    // Filter by `paymentType` and return the correct [PayableInterface].
    switch (paymentType) {
      case PaymentType.card:
        return CardPayment();
      case PaymentType.payPal:
        return PayPalPayment();
      case PaymentType.aliPay:
        return AliPayPayment();
    }
  }
}

class PaymentRepository {
  PaymentRepository({
    required PaymentFactory paymentFactory,
  }) : _paymentFactory = paymentFactory;

  final PaymentFactory _paymentFactory;

  Future<void> pay(PaymentType paymentType) async {
    // Get the respective payableInterface based on the `paymentType`.
    PayableInterface payment = _paymentFactory.initializePayment(paymentType);

    // Make payment.
    payment.pay();
  }
}

In the end, we would have a method like this where we can see that the code was reduced to only 3 lines and it is much easier to read.

It is also more scalable since if we wanted to add a new type of payment method we would only have to extend from PayableInterface and add it as an option in the filtering method.

👆 These concepts of abstractions and instances are confusing at first but throughout this series of articles and by practice they'll become simple concepts.

L stands for Liskov Substitution

We can change any concrete instance of a class with any class that implements the same interface.

The main objective of this principle is that we should always obtain the expected behavior of the code regardless of the class instance that is being used.

To be able to fulfill this principle correctly, there are 2 important parts:

• Implementation.
• Abstraction.

The first we can see in the previous example of open/closed principle when we have PayableInterface and the payment methods that implement it as CardPayment and PaypalPayment

In the implementation of the code we see that it doesn't matter with the implementation we choose, our code should continue to work correctly, this is because both make correct implementation of the PayableInterface interface.

With this example, the idea is easy to understand but in practice, there are many times that we perform the abstraction process wrong, so we cannot truly make great use of the principle.

If you are not very familiar with concepts such as interface, implementation, and abstraction this may sound a bit complex but let's see it with a simple example..

This is one of the iconic images of the principle as it makes it easy to understand.

Let's imagine that in our code we have a class called DuckInterface.

This gives us the basic functionality of a duck: fly, swim, and quack. And we would have the RubberDuck class that implements the interface.

abstract class DuckInterface {
  void fly();
  String swim();
  String quack();
}

class RubberDuck implements DuckInterface {
  @override
  void fly() {
    throw Exception('Rubber duck cannot fly');
  }

  @override
  String quack() {
    return "Quack!!!";
  }

  @override
  String swim() {
    return "Duck Swimming";
  }
}

At a first glance, we could say that our abstraction is fine since we are using an interface that gives us the functionality we need, but the fly method does not apply to a rubber duck, imagine that our program is going to have different Animals with shared functionality such as flying and swimming, so it would not make sense to leave this method on the DuckInterface interface.

To solve this and comply with the Liskov principle, we can create more specific interfaces that allow us to reuse code, which also makes our code more maintainable.

abstract class QuackInterface {
  String quack();
}

abstract class FlyInterface {
  String fly();
}

abstract class SwimInterface {
  String swim();
}

class RubberDuck implements QuackInterface, SwimInterface {
  @override
  String quack() {
    return "Quack!!!";
  }

  @override
  String swim() {
    return "Duck Swimming";
  }
}

With this implementation, our RubberDuck class only implements the methods it needs and now, for example, if we need an animal that fulfills a specific function such as swimming, we could use any class that implements the SwimInterface interface. This is because by fulfilling the Liskov principle we can switch any declaration of an abstract class by any class that implements it.

I stands for Interface Segregation

The code should not depend on methods that it does not use.

At first, this could seem to be the simplest principle but for this very reason, in the beginning, it can even confuse us.

In the previous principles, we have seen the importance of interfaces to decouple our code.

This principle ensures that our abstractions for creating interfaces are correct since we cannot create a new instance of an interface without implementing one of the methods defined by them. The above would be violating the principle

This image shows the problem of not fulfilling this principle, we have some instances of classes that do not use all the interface methods, which lead to a dirty code and indicate bad abstraction.

It is easier to see it with the typical anima example, this is very similar to the example we saw from Liskov.

💡 At this point the examples become similar but the important thing is to see the code from another perspective.

We have an abstract class Animal that is our interface, it has 3 methods defined eat, sleep, and fly.

If we create a Bird class that implements the animal interface we don't see any problem, but what if we want to create the Dog class?

Exactly, we realize that we cannot implement the fly method because it does not apply to a dog.

We could leave it like that and avoid the time needed to restructure the code since we logically know that this would not affect our code, but this breaks the principle.

abstract class Animal {
  void eat();
  void sleep();
  void fly();
}

class Bird implements Animal {
  @override
  void eat() {}

  @override
  void sleep() {}

  @override
  void fly() {}
}

class Dog implements Animal {
  @override
  void eat() {}

  @override
  void sleep() {}

  @override
  void fly() => throw Exception('Dogs cannot fly!');
}

The mistake is made by having a bad abstraction in our class and the right thing to do is always refactor to ensure that the principles are being met.

It may take us a little longer at the moment but the results of having a clean and scalable code should always be priorities.

A solution to this could be that our Animal interface only has the methods shared by animals like eat, sleep and we create another interface for the fly method. In this way, only animals that need this method to implement its interface.

abstract class FlyInterface {
  void fly();
}

abstract class Animal {
  void eat();
  void sleep();
}

class Bird implements Animal, FlyInterface {
  @override
  void eat() {}

  @override
  void sleep() {}

  @override
  void fly() {}
}

class Dog implements Animal {
  @override
  void eat() {}

  @override
  void sleep() {}
}

D stands for Dependency Inversion

💉 High-level modules should not depend on low-level modules. Both must depend on abstractions.

This principle tells us:

• You never have to depend on a concrete implementation of a class, only on its abstractions (interfaces).

• Same as the image presented on volume 1, we follow the rule that high-level modules should not strictly rely on low-level modules.

To understand it more simply, let's look at the example.

Nowadays, every app or software that is developed needs to communicate with the outside world. Normally this is done through code repositories that we instantiate and call from the business logic in our software.

class DataRepository {
  Future<void> logInUser() async {}

  Future<void> signUpUser() async {}
}

class BusinessLogic {
  const BusinessLogic({
    required DataRepository repository,
  }) : _repository = repository;

  final DataRepository _repository;

  Future<void> logIn() async {
    await _repository.logInUser();
  }

  Future<void> signUp() async {
    await _repository.signUpUser();
  }
}

Declaring and using a concrete class, such as the DataRepository within BusinessLogic, is a very common practice and is one of the common mistakes that make our code not very scalable. By depending on a particular instance of a class we surely know it will never be stable because you are constantly adding code to it.

To solve this problem, the principle tells us to create an interface that communicates both modules. You can even develop the whole functionality of the business logic and user interface of an app by depending on an interface that hasn't been implemented.

This also allows better communication in a team of developers because when creating an interface, everyone is clear about the objectives of the module, and from that definition, it can be verified that the SOLID principles are being met.

abstract class DataRepositoryInterface {
  Future<void> logInUser();

  Future<void> signUpUser();
}

class DataRepository extends DataRepositoryInterface {
  @override
  Future<void> logInUser() async {
    // Implementation...
  }

  @override
  Future<void> signUpUser() async {
    // Implementation...
  }
}

With this implementation, we create a DataRepositoryInterface that we can then implement in DataRepository and the magic happens inside the class that uses this functionality when we do not depend on a concrete instance but instead on an interface we could pass as parameters any concrete class that implements this interface.

It could be a local or external database and that would not affect the development, I repeat it: we do not depend on a single concrete instance, we can use any class that complies with the implementation of the interface.

And this is what allows us to fulfill the magic word of clean architecture: decoupling!

Wrap-up

I remind you that these are principles, not rules, so there is no single way to follow them, their use and compliance with the code will depend on each project since for many of these the objectives of the project are key to making decisions. Just as something within the scope of a project can be considered small it may under other requirements become something large.

Continue with the Cleaner Flutter Series

You can go back to the series list here.

One of the most famous solutions for this problem is Flutter Version Manager by leofarias. I personally used this solution for several months, but I always had some problems with it.

A few weeks ago I came across asdf, which according to its documentation:

asdf is a tool version manager. All tool version definitions are contained within one file (.tool-versions) which you can check in to your project's Git repository to share with your team, ensuring everyone is using the exact same versions of tools.

In a nutshell, it allows us to handle multiple versions of different tools (which I found interesting as it could be useful for other tools like: cocoapods,ruby,node.js, etc.)

How to use asdf with flutter?

Official docs: here

Install asdf

# MacOS with Homebrew
brew install asdf

# Linux
# Check: https://asdf-vm.com/guide/getting-started.html#_1-install-dependencies

ASDF Flutter plugin

Once asdf is installed, we have to install the asdf flutter plugin

# Installs flutter-plugin for asdf
asdf plugin-add flutter

Github Repo: asdf flutter plugin

install/uninstall a version

# List all available flutter versions
asdf list all flutter

Preview:

# Install a version 
asdf install flutter <VERSION_NUMBER>

# Example:
asdf install flutter 2.5.2-stable

# to uninstall
asdf uninstall flutter <VERSION_NUMBER>

Local and global version

# Defines a global flutter version to be used 
asdf global flutter <VERSION_NUMBER>

# Defines a local flutter version to be used 
asdf local flutter <VERSION_NUMBER>

Export to $PATH

To have access to the currently selected version, you need to export asdf flutter to $PATH.In my case, I added the following line to my /.zshrc.

export PATH="$PATH:$(asdf where flutter)/bin"
export PATH="$PATH":"$HOME/.pub-cache/bin"

With this you will have access to the flutter and dart commands from any terminal 👍.

... and dart?

dart is included by default with the asdf flutter plugin. However, sometimes you need a different dart version. This can be accomplished by running the same commands mentioned above, but substituting flutter with dart.

# Install asdf-dart
asdf plugin-add dart https://github.com/patoconnor43/asdf-dart.git

# More info in: https://github.com/PatOConnor43/asdf-dart

As always...

You can share this article to help another developer to continue improving their productivity when writing applications with Flutter.