When moving from an imperative approach to a more declarative way of doing things, you must reconsider how your app exchanges data between different app layers, especially when transitioning information from the business logic layer to the presentation layer and vice-versa.

Also, event-driven programming leads to asynchronous programming. This means you are writing methods that take data as input, and return futures or streams of something else as output most of the time.

Futures versus Streams

Before trying to understand what the Command-Query Separation is and how this pattern could help us write better data-driven Flutter Apps, let’s focus on both the definition of Futures and Streams.

According to the official Flutter documentation:

A Future represents a computation that doesn’t complete immediately. Where a normal function returns the result, an asynchronous function returns a Future, which will eventually contain the result. The future will tell you when the result is ready.

A stream is a sequence of asynchronous events. It is like an asynchronous Iterable — where, instead of getting the next event when you ask for it, the stream tells you that there is an event when it is ready.

Let’s focus on this sentence:

instead of getting the next event when you ask for it, the stream tells you that there is an event when it is ready

Reading between the lines looks like the future could be represented by a voluntary action while the stream might be something we undergo.

Let me explain…

Memo App

Imagine you want to develop a Memo App. What you need are two user interfaces: the first one is where you can show the saved memos sorted by the creation date, and the second one is used to gather information like a title or a description of the memo to be saved.

The best place to save the memos is in a database. We don’t need to do rocket science, then a SQLite database would do the job. We’re going to create a table that contains an auto-increment primary key, two columns representing the title and the description of the memo, and two more columns to store the creation date and the deletion date of the memo itself.

In our memo app, we need to perform three different operations:

• gathering data from the database: basically, we need to query our SQLite database to get all the non-deleted memos
• saving a memo to the database: creating a new row entry by providing a title and a description
• removing a memo from the database: removing a row by a memo ID

In our first interface, all we have to do is call a function that gathers data from the database. But what happens after we create or delete a memo? We have to query our database once again to update our list accordingly.

Is there a way to decouple the operations that read from the database to the ones who write to the database? Yes, we can, using the Command-Query Separation pattern.

Command-Query Separation

Command-Query Separation (or CQS) is a design pattern that separates data requests from data modifications.

A Command represents a request change of stored data through operations like Insert, Update, or Delete. The sole responsibility of a command is to update data, which means no data should be returned.

Future<void> save({required String title, required String description}) =>
    into(memosTable).insert(
      MemosTableCompanion(
        title: Value(title),
        description: Value(description),
      ),
      mode: InsertMode.insertOrReplace,
    );

Future<void> remove(int id) async {
  final query = update(memosTable);

  query.where((tbl) => tbl.id.equals(id));

  await query.write(MemosTableCompanion(deletedAt: Value(DateTime.now())));
}

On the other hand, a Query is a request to a data source to obtain information about an Entity. Query operations return Data Transfer Objects (DTOs) instead.

Stream<List<MemoEntity>> fetch() {
  final query = select(memosTable);

  query.where((tbl) => tbl.deletedAt.isNull());
  query.orderBy([
    (t) => OrderingTerm(expression: t.createdAt, mode: OrderingMode.desc),
  ]);

  return query.watch();
}

Advantages of CQS in Flutter

Command-Query Separation pattern is extremely helpful in event-driven applications, and Flutter extensively relies on event-driven programming.

By declaring all our command methods as functions that return nothing (void) and our query methods as streams that return a DTO or a collection of DTOs, we can easily apply the CQS pattern.

Using the CQS pattern, all we have to do is focus on queries and commands:

• With a stream that constantly listens for changes coming from our data source, we don’t need to take care of refreshing our memos list when a new memo is created or deleted, the query is already in charge of updating the UI every time something changes.
• When we create a new memo or delete an existing one, we don’t need to update that specific entry in our result set, the command’s sole responsibility is to update the data.

Memo App: Practical Approach

To better showcase an example of how to use the Command-Query Separation design pattern in our Flutter App, let’s create a new Flutter project using Drift as a reactive persistence library, built on top of SQLite.

After adding Drift dependencies, we need to define our Memo entity to be saved in our database.

import 'package:drift/drift.dart';

@DataClassName('MemoEntity')
class MemosTable extends Table {
  Column<int> get id => integer().autoIncrement()();

  Column<String> get title => text()();

  Column<String> get description => text()();

  Column<DateTime> get createdAt =>
      dateTime().named('created_at').withDefault(currentDateAndTime)();

  Column<DateTime> get deletedAt => dateTime().named('deleted_at').nullable()();

  @override
  String get tableName => 'memos';
}

Then a Data Access Object class is needed to perform our command and query operations on our SQLite database. Let’s keep in mind that command methods must always return void, and query methods must return the DTOs, in this case represented by the MemoEntity. Usually, it’s better to separate the commands DAO class from the query DAO class, but for the sake of simplicity, we’ll keep everything in a single class.

import 'package:drift/drift.dart';
import 'package:memo_app/features/database/dao/memo/memo_dao.drift.dart';
import 'package:memo_app/features/database/memo_database.dart';
import 'package:memo_app/features/database/tables/memo/memos_table.dart';
import 'package:memo_app/features/database/tables/memo/memos_table.drift.dart';

@DriftAccessor(tables: [MemosTable])
class MemoDAO extends DatabaseAccessor<MemoDatabase> with $MemoDAOMixin {
  MemoDAO(super.attachedDatabase);

  Future<void> save({required String title, required String description}) =>
      into(memosTable).insert(
        MemosTableCompanion(
          title: Value(title),
          description: Value(description),
        ),
        mode: InsertMode.insertOrReplace,
      );

  Future<void> remove(int id) async {
    final query = update(memosTable);

    query.where((tbl) => tbl.id.equals(id));

    await query.write(MemosTableCompanion(deletedAt: Value(DateTime.now())));
  }

  Stream<List<MemoEntity>> fetch() {
    final query = select(memosTable);

    query.where((tbl) => tbl.deletedAt.isNull());
    query.orderBy([
      (t) => OrderingTerm(expression: t.createdAt, mode: OrderingMode.desc),
    ]);

    return query.watch();
  }
}

Let’s move on by creating our MemoRepository, our single source of truth capable of interacting with our data source. Nothing special here, we can spot the very same methods under a different name and with different types: here’s where the DTOs are translated into business logic models.

import 'package:memo_app/features/database/dao/memo/memo_dao.dart';
import 'package:memo_app/models/memo/memo.dart';
import 'package:memo_app/repositories/mappers/memo_mapper.dart';
import 'package:memo_app/repositories/repository.dart';

/// Abstract class of MemoRepository
abstract interface class MemoRepository {
  Future<void> create({required String title, required String description});

  Stream<List<Memo>> fetch();

  Future<void> remove(int id);
}

/// Implementation of the base interface MemoRepository
class MemoRepositoryImpl extends Repository implements MemoRepository {
  final MemoDAO memoDAO;
  final MemoMapper memoMapper;

  const MemoRepositoryImpl({
    required this.memoDAO,
    required this.memoMapper,
    required super.logger,
  });

  @override
  Future<void> create({required String title, required String description}) =>
      safeCode(() async {
        try {
          logger.info('[$MemoRepository] Creating memo with title: $title');

          await memoDAO.save(title: title, description: description);

          logger.info('[$MemoRepository] Memo created!');
        } catch (error, stackTrace) {
          logger.error(
            '[$MemoRepository] Error creating memo',
            error,
            stackTrace,
          );
          rethrow;
        }
      });

  @override
  Stream<List<Memo>> fetch() {
    logger.info('[$MemoRepository] Fetching memos from database');

    final entities = memoDAO.fetch();

    return entities.map((entity) {
      logger.info('[$MemoRepository] Mapping entities to models');

      return memoMapper.toModels(entity);
    }).safeCode();
  }

  @override
  Future<void> remove(int id) => safeCode(() async {
    try {
      logger.info('[$MemoRepository] Removing memo with id: $id');

      await memoDAO.remove(id);

      logger.info('[$MemoRepository] Memo removed!');
    } catch (error, stackTrace) {
      logger.error('[$MemoRepository] Error removing memo', error, stackTrace);
      rethrow;
    }
  });
}

And here’s where the magic happens! One layer before the presentation layer, we can spot our state management pattern in charge of translating business logic data into events. In this particular example, I decided to use both BLoC and Cubit, but you can use your favorite state management pattern as well.

In my humble opinion, I believe BLoC and Cubits are well suited to implement the CQS pattern: BLoC is a Cubit with events, and we can associate events with commands! On the other hand, Cubit is pretty simple and we can use it to subscribe to incoming events using a stream subscription.

import 'dart:async';

import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:flutter_essentials_kit/flutter_essentials_kit.dart';
import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:memo_app/errors/generic_error.dart';
import 'package:memo_app/repositories/memo_repository.dart';

part 'memo_bloc.freezed.dart';
part 'memo_event.dart';
part 'memo_state.dart';

/// The MemoBloc
class MemoBloc extends Bloc<MemoEvent, MemoState> {
  final MemoRepository memoRepository;

  /// Create a new instance of [MemoBloc].
  MemoBloc({required this.memoRepository}) : super(const MemoState.initial()) {
    on<CreateMemoEvent>(_onCreate);
    on<RemoveMemoEvent>(_onRemove);
  }

  /// Method used to add the [CreateMemoEvent] event
  void create({required String title, required String description}) =>
      add(MemoEvent.create(title: title, description: description));

  /// Method used to add the [RemoveMemoEvent] event
  void remove(int id) => add(MemoEvent.remove(id));

  FutureOr<void> _onCreate(
    CreateMemoEvent event,
    Emitter<MemoState> emit,
  ) async {
    emit(const MemoState.creating());

    try {
      await memoRepository.create(
        title: event.title,
        description: event.description,
      );

      emit(const MemoState.created());
    } on LocalizedError catch (error) {
      emit(MemoState.errorCreating(error));
    } catch (_) {
      emit(MemoState.errorCreating(GenericError()));
    }
  }

  FutureOr<void> _onRemove(
    RemoveMemoEvent event,
    Emitter<MemoState> emit,
  ) async {
    emit(const MemoState.removing());

    try {
      await memoRepository.remove(event.id);

      emit(const MemoState.removed());
    } on LocalizedError catch (error) {
      emit(MemoState.errorRemoving(error));
    } catch (_) {
      emit(MemoState.errorRemoving(GenericError()));
    }
  }
}

extension MemoBlocExtension on BuildContext {
  /// Extension method used to get the [MemoBloc] instance
  MemoBloc get memoBloc => read<MemoBloc>();
}

import 'dart:async';

import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:flutter_essentials_kit/flutter_essentials_kit.dart';
import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:memo_app/errors/generic_error.dart';
import 'package:memo_app/models/memo/memo.dart';
import 'package:memo_app/repositories/memo_repository.dart';

part 'memo_cubit.freezed.dart';
part 'memo_state.dart';

/// The MemoCubit
class MemoCubit extends Cubit<MemoState> {
  final MemoRepository memoRepository;

  StreamSubscription<List<Memo>>? _subscription;

  /// Create a new instance of [MemoCubit].
  MemoCubit({required this.memoRepository}) : super(const MemoState.fetching());

  /// Method used to perform the [fetch] action
  void fetch() {
    _subscription = memoRepository.fetch().listen(
      (memos) {
        emit(
          memos.isNotEmpty ? MemoState.fetched(memos) : const MemoState.empty(),
        );
      },
      onError: (error) {
        if (error is LocalizedError) {
          emit(MemoState.errorFetching(error));
        } else {
          emit(MemoState.errorFetching(GenericError()));
        }
      },
    );
  }

  @override
  Future<void> close() {
    _subscription?.cancel();

    return super.close();
  }
}

extension MemoCubitExtension on BuildContext {
  /// Extension method used to get the [MemoCubit] instance
  MemoCubit get memoCubit => read<MemoCubit>();
}

Now let’s move to the presentation layer to better understand how things (do not) interact with each other, making the CQS pattern concrete.

As we can see, the only thing MainPage class is doing is subscribing for upcoming state changes from MemoCubit, nothing less, nothing more. Even though there are two buttons in charge of navigating to the creation page, we’re not telling anyone to reload our data once deletion or creation is done.

import 'package:auto_route/auto_route.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:memo_app/blocs/memo/memo_bloc.dart';
import 'package:memo_app/cubits/memo/memo_cubit.dart' as cubit;
import 'package:memo_app/features/localization/extensions/build_context.dart';
import 'package:memo_app/features/routing/app_router.dart';
import 'package:memo_app/models/memo/memo.dart';
import 'package:memo_app/pages/main/widgets/add_fab.dart';
import 'package:memo_app/pages/main/widgets/empty_memo_courtesy.dart';
import 'package:memo_app/pages/main/widgets/error_memo_courtesy.dart';
import 'package:memo_app/pages/main/widgets/memo_card.dart';
import 'package:memo_app/widgets/loading_widget.dart';

/// Enter the Main documentation here
@RoutePage()
class MainPage extends StatelessWidget implements AutoRouteWrapper {
  /// The constructor of the page.
  const MainPage({super.key});

  @override
  Widget wrappedRoute(BuildContext context) => MultiBlocProvider(
    providers: [
      BlocProvider<MemoBloc>(
        create: (context) => MemoBloc(memoRepository: context.read()),
      ),
      BlocProvider<cubit.MemoCubit>(
        create:
            (context) =>
                cubit.MemoCubit(memoRepository: context.read())..fetch(),
      ),
    ],
    child: this,
  );

  @override
  Widget build(BuildContext context) => Scaffold(
    appBar: AppBar(title: Text(context.l10n?.appName ?? 'appName')),
    body: BlocBuilder<cubit.MemoCubit, cubit.MemoState>(
      builder:
          (context, state) => switch (state) {
            cubit.FetchingMemoState() => const LoadingWidget(),
            cubit.FetchedMemoState(:final memos) => ListView.separated(
              padding: const EdgeInsets.symmetric(vertical: 16.0),
              physics: const BouncingScrollPhysics(),
              separatorBuilder: (_, __ )=> const SizedBox(height: 8.0),
              itemBuilder: (context, index) {
                final memo = memos[index];

                return MemoCard(
                  memo,
                  onDismissed: () => _removeMemo(context, memo),
                );
              },
              itemCount: memos.length,
            ),
            cubit.EmptyMemoState() => EmptyMemoCourtesy(
              onTap: () => context.router.push(const CreateMemoRoute()),
            ),
            cubit.ErrorFetchingMemoState() => const ErrorMemoCourtesy(),
          },
    ),
    floatingActionButton: BlocSelector<cubit.MemoCubit, cubit.MemoState, bool>(
      selector:
          (state) => switch (state) {
            cubit.FetchedMemoState() => true,
            _ => false,
          },
      builder:
          (context, showButton) => switch (showButton) {
            true => AddFab(
              onPressed: () => context.router.push(const CreateMemoRoute()),
            ),
            false => const SizedBox.shrink(),
          },
    ),
  );

  void _removeMemo(BuildContext context, Memo memo) {
    context.memoBloc.remove(memo.id);
  }
}

Of course, we can see there’s another bloc on this page, but its only purpose is to trigger our deletion command, which will propagate down the layers until MemoDAO’s remove function which will set deletedAt value to DateTime.now().

import 'package:auto_route/auto_route.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:memo_app/blocs/memo/memo_bloc.dart';
import 'package:memo_app/features/localization/extensions/build_context.dart';
import 'package:memo_app/pages/create_memo/widgets/create_button.dart';
import 'package:memo_app/pages/create_memo/widgets/reactive_description_field.dart';
import 'package:memo_app/pages/create_memo/widgets/reactive_title_field.dart';
import 'package:memo_app/widgets/loading_widget.dart';
import 'package:reactive_forms/reactive_forms.dart';

/// Enter the CreateMemo documentation here
@RoutePage()
class CreateMemoPage extends StatefulWidget implements AutoRouteWrapper {
  static const _kFormTitle = 'title';
  static const _kFormDescription = 'description';

  /// The constructor of the page.
  const CreateMemoPage({super.key});

  @override
  Widget wrappedRoute(BuildContext context) => MultiBlocProvider(
    providers: [
      BlocProvider<MemoBloc>(
        create: (context) => MemoBloc(memoRepository: context.read()),
      ),
    ],
    child: this,
  );

  @override
  State<CreateMemoPage> createState() => _CreateMemoState();
}

class _CreateMemoState extends State<CreateMemoPage> {
  final _form = FormGroup({
    CreateMemoPage._kFormTitle: FormControl<String>(
      validators: [Validators.required],
    ),
    CreateMemoPage._kFormDescription: FormControl<String>(
      validators: [Validators.required],
    ),
  });

  @override
  Widget build(BuildContext context) => BlocListener<MemoBloc, MemoState>(
    listener:
        (context, state) => switch (state) {
          CreatingMemoState() => _onCreating(context),
          CreatedMemoState() => _onCreated(context),
          ErrorCreatingMemoState() => _onErrorCreating(context),
          _ => null,
        },
    child: Scaffold(
      appBar: AppBar(
        title: Text(context.l10n?.titleCreateMemo ?? 'titleCreateMemo'),
      ),
      body: ReactiveForm(
        formGroup: _form,
        child: ListView(
          padding: const EdgeInsets.symmetric(horizontal: 16.0),
          physics: const BouncingScrollPhysics(),
          children: [
            const ReactiveTitleField(
              formControlName: CreateMemoPage._kFormTitle,
            ),
            const ReactiveDescriptionField(
              formControlName: CreateMemoPage._kFormDescription,
            ),
            BlocBuilder<MemoBloc, MemoState>(
              builder:
                  (context, state) => switch (state) {
                    CreatingMemoState() => const LoadingWidget(),
                    _ => CreateButton(onPressed: () => _createMemo(context)),
                  },
            ),
          ],
        ),
      ),
    ),
  );

  void _createMemo(BuildContext context) {
    final title = _form.control(CreateMemoPage._kFormTitle).value;
    final description = _form.control(CreateMemoPage._kFormDescription).value;

    context.memoBloc.create(title: title, description: description);
  }

  void _onCreating(BuildContext context) {
    _form.markAsDisabled();
  }

  void _onCreated(BuildContext context) {
    _form.markAsEnabled();

    context.maybePop();
  }

  void _onErrorCreating(BuildContext context) {
    _form.markAsEnabled();

    ScaffoldMessenger.of(context).showSnackBar(
      SnackBar(
        content: Text(
          context.l10n?.snackbarErrorCreatingMemo ??
              'snackbarErrorCreatingMemo',
        ),
      ),
    );
  }
}

The same approach applies to the CreateMemoPage, a single cubit injected in the tree, capable of creating a new memo entry in our SQLite database.

Third-party project libraries

Many different third-party dependencies have been used to support this project like auto_route, dart_mapper, freezed, pine, and reactive_forms. If you want to better understand how this project works, here you can find the official repository on GitHub.

Conclusion

In this article, we delved into how to apply the Command-Query Separation pattern to write better data-driven Flutter Apps. CQS pattern could be really helpful when developing applications that rely on a lot of CRUD operations, especially when using a database like SQLite. Libraries like Drift help us write better CQS-driven applications focusing on what matters: data gathering and modifications.

But let’s start from the beginning, what are Pine Bricks and Copilot?

Pine Bricks

Pine bricks are bricks based on the Pine scaffolding. If you never heard about Pine Architecture, here you can find more details about it.

I prefer defining it as an architecture because there’s a bit of software engineering stuff in it, but is a set of tools that helps you use Bloc for state management and Provider as a Dependency Injector/Service Locator following a predefined hierarchy while defining business logic in your app.

Bricks

But what are bricks? A brick is a template that helps you generate a boilerplate through Mason, a wonderful tool developed by Felix Angelov.

Don’t you feel bored writing the same code over and over? If you’re capable of finding some sort of pattern in your files, you can create your brick using mason_cli and share it with the community through brickhub.dev

Copilot

Do we need to introduce it? I’ll just stick with the GitHub definition.

GitHub Copilot suggests code completions as developers type and turns natural language prompts into coding suggestions based on the project’s context and style conventions.

Why these tools?

By combining these two tools, for some particular tasks, we can raise our productivity by over 300% and now I’ll explain why.

If you ever created a well-structured application, most of the time you’re going to write the same pieces over and over. Think about a repository or a service: you create an abstraction for the signature, you extend the abstraction with a concrete class, and then you put the logic inside of it. The same story applies when you want to create a Bloc: a bunch of events and states, a list of event subscriptions in the constructor, and the business logic inside of it.

Even copy-pasting the same code becomes time-consuming because you’re more prone to mistakes. A former professor of mine used to say that 50% of errors come from copying stuff.

To maximize our efficiency in writing boilerplate code we’re going to use bricks. Since I prefer using the Pine Architecture, I created a set of bricks for its scaffolding. With these bricks, you can create services, repositories, blocs, pages, models, DTOs, and so on.

Some of these bricks come with a set of fixtures to generate objects using fakers and they also generate boilerplate code to write unit tests.

Ok, now that we understood how to spend less time writing boilerplate code using Pine Bricks, what about GitHub Copilot?

Copilot is a wonderful tool when it comes to writing repetitive patterns in your code. I don’t like it when he tries to generate code when it doesn’t have enough context, that’s why I’m not using the prompt but the suggestion instead.

Where can you find repetitive patterns? Most of the time when you write CRUDs or tests. You’ll only need to write the first method of the class or the first test in the file and then Copilot will have enough context to understand what’s gonna change in the next iterations. With Copilot you can reduce your time writing tests by 60%, and the only thing you need to do is double-check that everything has been generated properly as Copilot is not always perfect.

Enough with the theory, let’s go writing our first application to see how to use Pine Bricks and Copilot to speed up our development.

Crypto App

Crypto App is one of the most developed applications you can find on GitHub or YouTube. It’s simple: you only need to perform some HTTP requests to an API to retrieve data you’re gonna show on your app.

Let’s create our Flutter Application with the following dependencies inside the pubspec.yaml. Some of these dependencies are mandatory if you want to use Pine Bricks, but I promise once you start using them, you’ll never come back.

dependencies:
  auto_route: ^7.8.4
  cached_network_image: ^3.3.1
  dio: ^5.4.0
  dio_smart_retry: ^6.0.0
  flutter:
    sdk: flutter
  flutter_bloc: ^8.1.3
  flutter_essentials_kit: ^2.5.0
  freezed_annotation: ^2.4.1
  intl: ^0.18.1
  json_annotation: ^4.8.1
  pine: ^1.0.3
  provider: ^6.1.1
  retrofit: ^4.1.0
  talker: ^4.0.1
  talker_bloc_logger: ^4.0.1
  talker_dio_logger: ^4.0.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  auto_route_generator: ^7.3.2
  bloc_test: ^9.1.5
  build_runner: ^2.4.8
  data_fixture_dart: ^2.2.0
  flutter_lints: ^3.0.1
  freezed: ^2.4.7
  http_mock_adapter: ^0.6.1
  json_serializable: ^6.7.1
  mockito: ^5.4.4
  retrofit_generator: ^8.1.0

After getting these dependencies using flutter pub get, we must install mason_cli and our Pine Bricks. Let’s create a file in the root of the project named mason.yaml with the following content:

bricks:
  pine: ^0.1.0+2
  pine_bloc: ^0.2.0
  pine_cubit: ^0.2.0
  pine_dto_mapper: ^0.1.0+2
  pine_model: ^0.1.0+2
  pine_network_jto: ^0.1.0+2
  pine_network_request: ^0.1.0+2
  pine_network_response: ^0.1.0+2
  pine_page: ^0.2.1
  pine_repository: ^0.1.0+2
  pine_retrofit: ^0.1.0+2
  pine_service: ^0.1.0+2

We’re not gonna use them all in this project, but I suggest you install all of them when writing more complex applications. Now let’s run mason get in our prompt to retrieve the pine bricks. We can spot the mason-lock.json.

Setup the Dependency Injection

By following the Pine documentation, we need a class to define our global providers, repositories, mappers and blocs to be injected into the tree. Under lib/ we create a folder named di, and then a file named dependency_injector.dart.

import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:pine/pine.dart';
import 'package:provider/provider.dart';

class DependencyInjector extends StatelessWidget {
  final Widget child;

  const DependencyInjector({
    super.key,
    required this.child,
  });

  @override
  Widget build(BuildContext context) => DependencyInjectorHelper(
        providers: [],
        mappers: [],
        repositories: [],
        child: child,
      );
}

Let’s inject these items into the tree by adding the DependencyInjector widget on top of our application. We can create a file named app.dart which contains the following:

import 'package:crypto_app/di/dependency_injector.dart';
import 'package:crypto_app/features/routing/app_router.dart';
import 'package:crypto_app/features/theme/extensions/color_extension.dart';
import 'package:flutter/material.dart';

class App extends StatelessWidget {
  final _router = AppRouter();

  App({super.key});

  @override
  Widget build(BuildContext context) => DependencyInjector(
        child: MaterialApp.router(
          title: 'Crypto App',
          debugShowCheckedModeBanner: false,
          routeInformationParser: _router.defaultRouteParser(),
          routerDelegate: _router.delegate(),
          theme: ThemeData(
            colorScheme: ColorScheme.fromSeed(seedColor: Colors.orange),
            useMaterial3: true,
            extensions: [
              ColorExtension(
                rising: Colors.green[800],
                falling: Colors.red[800],
                neutral: Colors.grey,
              ),
            ],
            appBarTheme: const AppBarTheme(
              centerTitle: true,
              toolbarHeight: 80.0,
            ),
            dividerTheme: const DividerThemeData(
              thickness: 1.0,
              indent: 16.0,
              endIndent: 16.0,
            ),
          ),
        ),
      );
}

And since we moved the App definition inside the above file, we can now simplify the main.dart as follows:

import 'package:crypto_app/app.dart';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:talker_bloc_logger/talker_bloc_logger.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  SystemChrome.setEnabledSystemUIMode(SystemUiMode.leanBack);
  SystemChrome.setPreferredOrientations([
    DeviceOrientation.portraitUp,
    DeviceOrientation.portraitDown,
  ]);

  Bloc.observer = TalkerBlocObserver();

  runApp(App());
}

Be careful! I’m not gonna cover all the aspects of the Crypto App development process but I’ll focus on the Bricks and Copilot stuff only. I.e: if you don’t know where the class ColorExtension comes from, I encourage you to take a look at the project repository on GitHub.

CoinJTO to carry data from the API

In software engineering, to carry data across different layers you use a special model called DTO which stands for Data Transfer Object. In our Crypto App we need to get data from an API that answers to our HTTP requests with a JSON payload.

Most of the time our DTO carries JSON data, that’s why I decided to call it JTO which stands for JSON Transfer Object.

For our Crypto App we’re gonna use the Coingecko APIs to request a list of coins with EUR currency sorted descendingly by market capitalization:

https://api.coingecko.com/api/v3/coins/markets?vs_currency=EUR&order=market_cap_desc&per_page=250&page=1&parkline=false

{
"id": "bitcoin",
"symbol": "btc",
"name": "Bitcoin",
"image": "https://assets.coingecko.com/coins/images/1/large/bitcoin.png?1696501400",
"current_price": 43177,
"market_cap": 849325665337,
"market_cap_rank": 1,
"fully_diluted_valuation": 908936212551,
"total_volume": 29370790007,
"high_24h": 43377,
"low_24h": 41403,
"price_change_24h": 1767.14,
"price_change_percentage_24h": 4.26748,
"market_cap_change_24h": 34932151048,
"market_cap_change_percentage_24h": 4.28935,
"circulating_supply": 19622762,
"total_supply": 21000000,
"max_supply": 21000000,
"ath": 59717,
"ath_change_percentage": -27.55324,
"ath_date": "2021-11-10T14:24:11.849Z",
"atl": 51.3,
"atl_change_percentage": 84235.76945,
"atl_date": "2013-07-05T00:00:00.000Z",
"roi": null,
"last_updated": "2024-02-09T09:19:18.204Z"
},

Now that we have a deep understanding of what kind of data the JTO will have, it’s time to generate it, let’s type the following in the command prompt:

mason make pine_network_jto --name "Coin"

We can spot two different files, the JTO under lib/services/network/jto/coin/coin_jto.dart and the Fixture of the JTO under test/fixtures/jto/coin_jto_fixture_factory.dart. It’s time to define the attributes of our JTO and how its fixture can generate one. The JTO relies on the freezed dependency, so keep in mind we’re gonna need it in our project. Don’t forget to run the build_runner in watch mode as freezed classes depend on code generation.

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

Under lib/services/network/jto/coin/coin_jto.dart let’s define our JTO as follows:

import 'package:pine/pine.dart';
import 'package:freezed_annotation/freezed_annotation.dart';

part 'coin_jto.g.dart';

part 'coin_jto.freezed.dart';

@Freezed(toJson: false, copyWith: false)
class CoinJTO extends DTO with _$CoinJTO {
  const factory CoinJTO({
    @JsonKey(name: 'id') required String id,
    @JsonKey(name: 'symbol') required String symbol,
    @JsonKey(name: 'name') required String name,
    @JsonKey(name: 'image') String? image,
    @JsonKey(name: 'current_price') required num currentPrice,
    @JsonKey(name: 'market_cap') required num marketCap,
    @JsonKey(name: 'market_cap_rank') num? marketCapRank,
    @JsonKey(name: 'fully_diluted_valuation') num? fullyDilutedValuation,
    @JsonKey(name: 'total_volume') num? totalVolume,
    @JsonKey(name: 'high_24h') num? high24h,
    @JsonKey(name: 'low_24h') num? low24h,
    @JsonKey(name: 'price_change_24h') num? priceChange24h,
    @JsonKey(name: 'price_change_percentage_24h') required num priceChangePercentage24h,
    @JsonKey(name: 'market_cap_change_24h') num? marketCapChange24h,
    @JsonKey(name: 'market_cap_change_percentage_24h') num? marketCapChangePercentage24h,
    @JsonKey(name: 'circulating_supply') num? circulatingSupply,
    @JsonKey(name: 'total_supply') num? totalSupply,
    @JsonKey(name: 'max_supply') num? maxSupply,
    @JsonKey(name: 'ath') num? ath,
    @JsonKey(name: 'ath_change_percentage') num? athChangePercentage,
    @JsonKey(name: 'ath_date') String? athDate,
    @JsonKey(name: 'atl') num? atl,
    @JsonKey(name: 'atl_change_percentage') num? atlChangePercentage,
    @JsonKey(name: 'atl_date') String? atlDate,
    @JsonKey(name: 'last_updated') String? lastUpdated,
}) = _CoinJTO;

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

Under test/fixtures/jto/coin_jto_fixture_factory.dart let’s define the CoinJTO Fixture taking advantage of Copilot. To generate our fixtures we can use the library data_fixture_dart.

import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:data_fixture_dart/data_fixture_dart.dart';

extension CoinJTOFixture on CoinJTO {
  static CoinJTOFixtureFactory factory() => CoinJTOFixtureFactory();
}

class CoinJTOFixtureFactory extends JsonFixtureFactory<CoinJTO> {
  @override
  FixtureDefinition<CoinJTO> definition() => define(
        (faker) => CoinJTO(
          id: faker.randomGenerator.string(10),
          symbol: faker.currency.code(),
          name: faker.currency.name(),
          image: faker.internet.httpsUrl(),
          currentPrice: faker.randomGenerator.decimal(),
          marketCap: faker.randomGenerator.integer(1000),
          marketCapRank: faker.randomGenerator.integer(10),
          fullyDilutedValuation: faker.randomGenerator.integer(1000),
          totalVolume: faker.randomGenerator.integer(1000),
          high24h: faker.randomGenerator.decimal(),
          low24h: faker.randomGenerator.decimal(),
          priceChange24h: faker.randomGenerator.decimal(),
          priceChangePercentage24h: faker.randomGenerator.decimal(),
          marketCapChange24h: faker.randomGenerator.integer(1000),
          marketCapChangePercentage24h: faker.randomGenerator.decimal(),
          circulatingSupply: faker.randomGenerator.integer(1000),
          totalSupply: faker.randomGenerator.integer(1000),
          maxSupply: faker.randomGenerator.integer(1000),
          ath: faker.randomGenerator.decimal(),
          athChangePercentage: faker.randomGenerator.decimal(),
          athDate: faker.date.dateTime().toIso8601String(),
          atl: faker.randomGenerator.decimal(),
          atlChangePercentage: faker.randomGenerator.decimal(),
          atlDate: faker.date.dateTime().toIso8601String(),
          lastUpdated: faker.date.dateTime().toIso8601String(),
        ),
      );

  @override
  JsonFixtureDefinition<CoinJTO> jsonDefinition() => defineJson(
        (object) => {
          'id': object.id,
          'symbol': object.symbol,
          'name': object.name,
          'image': object.image,
          'current_price': object.currentPrice,
          'market_cap': object.marketCap,
          'market_cap_rank': object.marketCapRank,
          'fully_diluted_valuation': object.fullyDilutedValuation,
          'total_volume': object.totalVolume,
          'high_24h': object.high24h,
          'low_24h': object.low24h,
          'price_change_24h': object.priceChange24h,
          'price_change_percentage_24h': object.priceChangePercentage24h,
          'market_cap_change_24h': object.marketCapChange24h,
          'market_cap_change_percentage_24h':
              object.marketCapChangePercentage24h,
          'circulating_supply': object.circulatingSupply,
          'total_supply': object.totalSupply,
          'max_supply': object.maxSupply,
          'ath': object.ath,
          'ath_change_percentage': object.athChangePercentage,
          'ath_date': object.athDate,
          'atl': object.atl,
          'atl_change_percentage': object.atlChangePercentage,
          'atl_date': object.atlDate,
          'last_updated': object.lastUpdated,
        },
      );
}

We can place our cursor next to the open curly bracket and Copilot will start generating suggestions. Sometimes it’s less accurate but it’s a good starting point to save some time writing this huge Fixture by hand.

Now that we have our JTO, it’s time to call the API

CoinService with Retrofit

Retrofit is one of my favorite Flutter libraries. It’s a Dio wrapper that simplifies the process of defining REST APIs in our projects. I created a brick to generate a Retrofit service, let’s run the following to create our CoinService:

mason make pine_retrofit --name "Coin"

We can spot two different files, the service under lib/services/network/coin/coin_service.dart and the test of the service under test/services/network/coin/coin_service_test.dart.

In the CoinService class we need to define our endpoints as follows:

import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:dio/dio.dart';
import 'package:retrofit/retrofit.dart';

part 'coin_service.g.dart';

/// Abstract class of CoinService
@RestApi()
abstract class CoinService {
  factory CoinService(Dio dio, {String baseUrl}) = _CoinService;

  @GET('/coins/markets')
  Future<List<CoinJTO>> coins({
    @Query('vs_currency') String currency = 'EUR',
    @Query('order') String order = 'market_cap_desc',
    @Query('per_page') int items = 250,
    @Query('page') int page = 1,
    @Query('parkline') bool parkLine = false,
  });
}

Don’t forget to inject this service in the widget tree through our DependencyInjector widget.

Now that we have defined our service, we can create a bunch of tests. To mock my endpoints I like to use the http_mock_adapter library. We’re gonna use our fixtures to generate fake data for the library and to also make assertions on the output.

Here we can also take advantage of Copilot after it gains a bit of context. When you start defining these behaviors multiple times, you will only need to write the first test and then Copilot will suggest the other test cases:

import 'package:crypto_app/services/network/coin/coin_service.dart';
import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:data_fixture_dart/misc/fixture_tuple.dart';
import 'package:dio/dio.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:http_mock_adapter/http_mock_adapter.dart';

import '../../../fixtures/jto/coin_jto_fixture_factory.dart';

/// Test case for the class CoinService
void main() {
  late Dio dio;
  late DioAdapter dioAdapter;

  late CoinService service;

  setUp(() {
    dio = Dio(BaseOptions());
    dioAdapter = DioAdapter(dio: dio);

    service = CoinService(dio);
  });

  group('Testing coins endpoint', () {
    late List<FixtureTuple<CoinJTO>> coins;

    setUp(() {
      coins = CoinJTOFixture.factory().makeManyWithJsonArray(5);
    });

    test('when /coins/markets answers 200 OK successfully', () async {
      dioAdapter.onGet(
        '/coins/markets',
        (server) => server.reply(
          200,
          coins.map((coin) => coin.json).toList(),
        ),
      );

      final actual = coins.map((coin) => coin.object).toList();
      expect(await service.coins(), actual);
    });

    test('when /coins/markets answers 422 Unprocessable Entity', () async {
      dioAdapter.onGet(
        '/coins/markets',
        (server) => server.reply(422, null),
      );

      expect(
        () async => await service.coins(),
        throwsA(isA<DioException>()),
      );
    });
  });
}

Now we can inject the service into the tree.

The Coin Model

What kind of information should we show in our application? This is the typical question we should ask ourselves to understand what attributes we need to extract from our JTOs to display data. Some of you may already be thinking why should we have all these layers of information when it’s way more simple to have a single model instead?

Well, the answer to our question comes from software engineering. Our data source may change over time, so it’s way simpler to change the behavior of a single mapper despite changing the whole business logic instead.

In our particular case, we’re not gonna show all the information we added in our JTO, it’s for the sake of this article to have all of them there. That’s why our Coin model will be slim.

Alright, it’s time to generate our model, we have a brick for it:

mason make pine_model --name "Coin"

Since the Coin shares some attributes with the CoinJTO class, it’s possible that Copilot will suggest something if we try to put our cursor next to the Coin constructor. If Copilot acts like a shy person, let’s do it on our own.

Under lib/models/coin/coin.dart:

import 'package:freezed_annotation/freezed_annotation.dart';

part 'coin.freezed.dart';

@freezed
class Coin with _$Coin {
  const Coin._();

  const factory Coin({
    required String id,
    required String symbol,
    required String name,
    String? image,
    required num currentPrice,
    required num marketCap,
    required num priceChangePercentage24h,
  }) = _Coin;

  String get formattedName => '$name (${symbol.toUpperCase()})';

  bool get priceRising => priceChangePercentage24h > 0;

  bool get priceFalling => priceChangePercentage24h < 0;
}

Don’t forget to define the Fixture of this model, it will be useful when we will mock data in our repository or bloc. Under test/fixtures/models/coin_fixture_factory.dart:

import 'package:crypto_app/models/coin/coin.dart';
import 'package:data_fixture_dart/data_fixture_dart.dart';

extension CoinFixture on Coin {
  static CoinFixtureFactory factory() => CoinFixtureFactory();
}

class CoinFixtureFactory extends FixtureFactory<Coin> {
  @override
  FixtureDefinition<Coin> definition() => define(
        (faker) => Coin(
          id: faker.randomGenerator.string(10),
          symbol: faker.currency.code(),
          name: faker.currency.name(),
          image: faker.internet.httpsUrl(),
          currentPrice: faker.randomGenerator.decimal(),
          marketCap: faker.randomGenerator.integer(1000),
          priceChangePercentage24h: faker.randomGenerator.decimal(),
        ),
      );
}

The CoinMapper

Now that we have our model, we‘ll take advantage of the mapper pattern to translate data from a JTO to a model and vice-versa. Of course, we have a brick for that:

mason make pine_dto_mapper --name "CoinMapper" --model_name "Coin" --dto_name "Coin" --type "jto"

After running our brick, we can spot two files, the mapper and its test. Let’s start defining the mapper behavior under lib/repositories/mappers/coin_mapper.dart. Since this is a monodirectional mapper (we use it only to transform our JTO to a model), we can ignore the toDTO method, but I’ll write it anyway for the sake of this article:

import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:pine/pine.dart';

class CoinMapper extends DTOMapper<CoinJTO, Coin> {
  const CoinMapper();

  @override
  Coin fromDTO(CoinJTO dto) => Coin(
        id: dto.id,
        symbol: dto.symbol,
        name: dto.name,
        image: dto.image,
        currentPrice: dto.currentPrice,
        marketCap: dto.marketCap,
        priceChangePercentage24h: dto.priceChangePercentage24h,
      );

  @override
  CoinJTO toDTO(Coin model) => CoinJTO(
        id: model.id,
        symbol: model.symbol,
        name: model.name,
        image: model.image,
        currentPrice: model.currentPrice,
        marketCap: model.marketCap,
        priceChangePercentage24h: model.priceChangePercentage24h,
      );
}

We can also take advantage of the Copilot suggestions to speed up our process:

The mapper test is already there, we simply need to create a Model and a JTO instance. Since the model has fewer attributes than our JTO, we cannot use the Fixtures to generate it. Under test/repositories/mappers/coin_mapper_test.dart:

import 'package:data_fixture_dart/data_fixture_dart.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/repositories/mappers/coin_mapper.dart';
import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';

void main() {
  late CoinMapper mapper;
  late CoinJTO dto;
  late Coin model;

  setUp(() {
    dto = CoinJTO(
      id: faker.randomGenerator.string(10),
      symbol: faker.currency.code(),
      name: faker.currency.name(),
      image: faker.internet.httpsUrl(),
      currentPrice: faker.randomGenerator.decimal(),
      marketCap: faker.randomGenerator.integer(1000),
      priceChangePercentage24h: faker.randomGenerator.decimal(),
    );

    model = Coin(
      id: dto.id,
      symbol: dto.symbol,
      name: dto.name,
      image: dto.image,
      currentPrice: dto.currentPrice,
      marketCap: dto.marketCap,
      priceChangePercentage24h: dto.priceChangePercentage24h,
    );
    mapper = const CoinMapper();
  });

  test('mapping Coin object from CoinJTO', () {
    expect(mapper.fromDTO(dto), equals(model));
  });

  test('mapping Coin to CoinJTO', () {
    expect(mapper.toDTO(model), equals(dto));
  });
}

Now we can inject the mapper into the tree.

Data abstraction: the CoinRepository

It’s time to go back to our command prompt and type the following instructions:

mason make pine_repository --name "Coin"

The brick will generate two files, the repository and its test. The coin_repository.dart file now contains an abstraction called CoinRepository and a concrete implementation that implements the aforementioned class. Our goal now is to define the repository behaviors in the abstraction and implement them in the concrete class.

By defining our repositories in our project multiple times, Copilot will learn the context and will be able to make suggestions speeding up our development.

Under lib/repositories/coin_repository.dart:

import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/services/network/coin/coin_service.dart';
import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:pine/pine.dart';
import 'package:talker/talker.dart';

/// Abstract class of CoinRepository
abstract class CoinRepository {
  Future<List<Coin>> get coins;
}

/// Implementation of the base interface CoinRepository
class CoinRepositoryImpl implements CoinRepository {
  final CoinService coinService;
  final DTOMapper<CoinJTO, Coin> coinMapper;
  final Talker logger;

  const CoinRepositoryImpl({
    required this.coinService,
    required this.coinMapper,
    required this.logger,
  });

  @override
  Future<List<Coin>> get coins async {
    try {
      logger.info('Fetching coins');
      final jtos = await coinService.coins();
      logger.info('Coins fetched');
      return jtos.map(coinMapper.fromDTO).toList(growable: false);
    } catch (error, stackTrace) {
      logger.error('Failed to fetch coins', error, stackTrace);
      rethrow;
    }
  }
}

After defining the repository behaviors, it’s time to test them. Head back to test/repositories/coin/coin_repository_test.dart to create our test suites. We’ll take advantage of the mockito library to mock our service and our mapper, and we’ll use the Fixture to fake the data. After writing the happy path test case, Copilot should be smart enough to create the other ones on its own, helping us save more time.

import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/repositories/coin_repository.dart';
import 'package:crypto_app/repositories/mappers/coin_mapper.dart';
import 'package:crypto_app/services/network/coin/coin_service.dart';
import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mockito/annotations.dart';
import 'package:mockito/mockito.dart';
import 'package:talker/talker.dart';

import '../../fixtures/models/coin_fixture_factory.dart';
import 'coin_repository_test.mocks.dart';

/// Test case for the class CoinRepositoryImpl
@GenerateMocks([
  CoinService,
  CoinMapper,
], customMocks: [
  MockSpec<Talker>(unsupportedMembers: {#configure})
])
void main() {
  late MockCoinService service;
  late MockCoinMapper mapper;
  late MockTalker logger;

  late CoinRepository repository;

  setUp(() {
    service = MockCoinService();
    mapper = MockCoinMapper();
    logger = MockTalker();

    repository = CoinRepositoryImpl(
      coinService: service,
      coinMapper: mapper,
      logger: logger,
    );
  });

  group('Testing the coins getter', () {
    late List<Coin> coins;
    late List<CoinJTO> jtos;

    setUp(() {
      coins = CoinFixture.factory().makeMany(5);
      jtos = coins
          .map((coin) => CoinJTO(
                id: coin.id,
                symbol: coin.symbol,
                name: coin.name,
                image: coin.image,
                currentPrice: coin.currentPrice,
                marketCap: coin.marketCap,
                priceChangePercentage24h: coin.priceChangePercentage24h,
              ))
          .toList(growable: false);
    });

    test('get coins successfully', () async {
      when(service.coins()).thenAnswer((_) async => jtos);
      for (var i = 0; i < coins.length; i++) {
        when(mapper.fromDTO(jtos[i])).thenReturn(coins[i]);
      }

      expect(await repository.coins, coins);

      verify(service.coins()).called(1);
      for (var i = 0; i < coins.length; i++) {
        verify(mapper.fromDTO(jtos[i])).called(1);
      }
    });

    test('get coins with an unexpected error', () async {
      when(service.coins()).thenThrow(Exception());

      expect(() async => await repository.coins, throwsException);

      verify(service.coins()).called(1);
    });
  });
}

Now we can inject the repository into the tree.

Logic: The BLoC

Here come my two favorite bricks pine_bloc and pine_cubit. They are fabulous: by defining a comma-separated set of events and states I can generate the whole bloc/cubit boilerplate with a single instruction. Let’s do it for our CoinBloc as follows:

mason make pine_bloc --name "Coin" --events "fetch" --states "initial,fetching,fetched,none,errorFetching"

Under lib/blocs/coin/coin_state.dart we need to fill the attributes for our states, the fetch event doesn’t need anything:

part of 'coin_bloc.dart';

@freezed
class CoinState with _$CoinState {
  const factory CoinState.initial() = InitialCoinState;

  const factory CoinState.fetching() = FetchingCoinState;

  const factory CoinState.fetched(List<Coin> coins) = FetchedCoinState;

  const factory CoinState.none() = NoneCoinState;

  const factory CoinState.errorFetching(dynamic error) = ErrorFetchingCoinState;
}

Under lib/blocs/coin/coin_bloc.dart let’s wrap up:

import 'dart:async';

import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/repositories/coin_repository.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:freezed_annotation/freezed_annotation.dart';

part 'coin_bloc.freezed.dart';

part 'coin_event.dart';

part 'coin_state.dart';

/// The CoinBloc
class CoinBloc extends Bloc<CoinEvent, CoinState> {
  final CoinRepository coinRepository;

  /// Create a new instance of [CoinBloc].
  CoinBloc({
    required this.coinRepository,
  }) : super(const CoinState.initial()) {
    on<FetchCoinEvent>(_onFetch);
  }

  /// Method used to add the [FetchCoinEvent] event
  void fetch() => add(const CoinEvent.fetch());

  FutureOr<void> _onFetch(
    FetchCoinEvent event,
    Emitter<CoinState> emit,
  ) async {
    try {
      emit(const CoinState.fetching());
      final coins = await coinRepository.coins;
      emit(
        coins.isNotEmpty ? CoinState.fetched(coins) : const CoinState.none(),
      );
    } catch (error) {
      emit(CoinState.errorFetching(error));
    }
  }
}

And now it’s time for the test. This brick is magical, after you define the first test case, when you put your cursor on the next line, Copilot gains so much context it can enumerate the missing states to suggest the missing scenarios. Of course, it’s not as accurate as it should be, but with literally zero effort we can fix the errors in a few seconds.

Under test/blocs/coin/coin_bloc_test.dart let’s complete the file as follows:

import 'package:bloc_test/bloc_test.dart';
import 'package:crypto_app/blocs/coin/coin_bloc.dart';
import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/repositories/coin_repository.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mockito/annotations.dart';
import 'package:mockito/mockito.dart';

import '../../fixtures/models/coin_fixture_factory.dart';
import 'coin_bloc_test.mocks.dart';

@GenerateMocks([CoinRepository])
void main() {
  late MockCoinRepository coinRepository;
  late CoinBloc bloc;

  setUp(() {
    coinRepository = MockCoinRepository();
    bloc = CoinBloc(coinRepository: coinRepository);
  });

  /// Testing the event [FetchCoinEvent]
  group('when the event FetchCoinEvent is added to the BLoC', () {
    late List<Coin> coins;
    late dynamic exception;

    setUp(() {
      coins = CoinFixture.factory().makeMany(3);
      exception = Exception();
    });

    blocTest<CoinBloc, CoinState>(
      'test that CoinBloc emits CoinState.fetched when fetch is called',
      setUp: () {
        when(coinRepository.coins).thenAnswer((_) async => coins);
      },
      build: () => bloc,
      act: (bloc) {
        bloc.fetch();
      },
      expect: () => <CoinState>[
        const CoinState.fetching(),
        CoinState.fetched(coins),
      ],
      verify: (_) {
        verify(coinRepository.coins).called(1);
      },
    );

    blocTest<CoinBloc, CoinState>(
      'test that CoinBloc emits CoinState.errorFetching when fetch is called and an error occurs',
      setUp: () {
        when(coinRepository.coins).thenThrow(exception);
      },
      build: () => bloc,
      act: (bloc) {
        bloc.fetch();
      },
      expect: () => <CoinState>[
        const CoinState.fetching(),
        CoinState.errorFetching(exception),
      ],
      verify: (_) {
        verify(coinRepository.coins).called(1);
      },
    );

    blocTest<CoinBloc, CoinState>(
      'test that CoinBloc emits CoinState.none when fetch is called',
      setUp: () {
        when(coinRepository.coins).thenAnswer((_) async => []);
      },
      build: () => bloc,
      act: (bloc) {
        bloc.fetch();
      },
      expect: () => <CoinState>[
        const CoinState.fetching(),
        const CoinState.none(),
      ],
      verify: (_) {
        verify(coinRepository.coins).called(1);
      },
    );
  });
}

Dependency Injection

We’re not gonna inject the Bloc on the tree since this is a scoped Bloc, this is how the DependencyInjector class should look at the end of the project:

import 'package:crypto_app/misc/constants.dart';
import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/repositories/coin_repository.dart';
import 'package:crypto_app/repositories/mappers/coin_mapper.dart';
import 'package:crypto_app/services/network/coin/coin_service.dart';
import 'package:crypto_app/services/network/jto/coin/coin_jto.dart';
import 'package:dio/dio.dart';
import 'package:dio_smart_retry/dio_smart_retry.dart';
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:pine/pine.dart';
import 'package:provider/provider.dart';
import 'package:talker/talker.dart';
import 'package:talker_dio_logger/talker_dio_logger.dart';

class DependencyInjector extends StatelessWidget {
  final Widget child;

  const DependencyInjector({
    super.key,
    required this.child,
  });

  @override
  Widget build(BuildContext context) => DependencyInjectorHelper(
        providers: [
          Provider<Dio>(
            create: (_) {
              final dio = Dio(BaseOptions(
                connectTimeout: K.networkTimeout,
                sendTimeout: K.networkTimeout,
                receiveTimeout: K.networkTimeout,
              ));

              dio.interceptors.addAll([
                RetryInterceptor(
                  dio: dio,
                  retries: 3,
                  retryDelays: const [
                    Duration(seconds: 1),
                    Duration(seconds: 2),
                    Duration(seconds: 3),
                  ],
                ),
                if (kDebugMode)
                  TalkerDioLogger(
                    settings: const TalkerDioLoggerSettings(
                      printRequestHeaders: true,
                      printResponseHeaders: true,
                      printResponseMessage: true,
                    ),
                  ),
              ]);

              return dio;
            },
          ),
          Provider<Talker>(
            create: (_) => Talker(),
          ),
          Provider<CoinService>(
            create: (context) => CoinService(
              context.read(),
              baseUrl: K.baseUrl,
            ),
          ),
        ],
        mappers: [
          Provider<DTOMapper<CoinJTO, Coin>>(
            create: (_) => const CoinMapper(),
          ),
        ],
        repositories: [
          RepositoryProvider<CoinRepository>(
            create: (context) => CoinRepositoryImpl(
              coinService: context.read(),
              coinMapper: context.read(),
              logger: context.read(),
            ),
          ),
        ],
        child: child,
      );
}

The UI: CoinsPage

Yes, I also have a brick for that. Of course, I rely on auto_route to manage routing in my Flutter apps, so if you want to use this brick you have to use it too. When running the following command I’m setting the state to false since I need a stateless page but the auto_route is set to true as I’m gonna take advantage of a special mixin to inject the CoinBloc locally.

mason make pine_page --name "Coins" --state false --auto_route true

What does the CoinsPage look like? Under lib/pages/coins_page.dart we have the following:

import 'package:auto_route/auto_route.dart';
import 'package:crypto_app/blocs/coin/coin_bloc.dart';
import 'package:crypto_app/widgets/coin_tile.dart';
import 'package:crypto_app/widgets/loading_widget.dart';
import 'package:crypto_app/widgets/no_coins_widget.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';

/// Enter the Coins documentation here
@RoutePage()
class CoinsPage extends StatelessWidget implements AutoRouteWrapper {
  /// The constructor of the page.
  const CoinsPage({super.key});

  @override
  Widget wrappedRoute(BuildContext context) => MultiBlocProvider(
        providers: [
          BlocProvider<CoinBloc>(
            create: (context) => CoinBloc(
              coinRepository: context.read(),
            )..fetch(),
          ),
        ],
        child: this,
      );

  @override
  Widget build(BuildContext context) => Scaffold(
        appBar: AppBar(title: const Text('Crypto App')),
        body: BlocBuilder<CoinBloc, CoinState>(
          builder: (context, state) => switch (state) {
            FetchingCoinState() => const LoadingWidget(),
            FetchedCoinState(:final coins) => ListView.separated(
                physics: const BouncingScrollPhysics(),
                itemBuilder: (context, index) {
                  final coin = coins[index];

                  return CoinTile(coin);
                },
                separatorBuilder: (_, __) => const Divider(),
                itemCount: coins.length,
              ),
            NoneCoinState() => NoCoinsWidget(
                onPressed: () => context.read<CoinBloc>().fetch(),
              ),
            ErrorFetchingCoinState() => NoCoinsWidget(
                onPressed: () => context.read<CoinBloc>().fetch(),
              ),
            _ => const SizedBox.shrink(),
          },
        ),
      );
}

Can you tell I’m obsessed with tests? No? Here’s the test for the CoinsPage class under test/pages/coins/coins_page_test.dart

import 'dart:io';

import 'package:bloc_test/bloc_test.dart';
import 'package:crypto_app/blocs/coin/coin_bloc.dart';
import 'package:crypto_app/models/coin/coin.dart';
import 'package:crypto_app/pages/coins_page.dart';
import 'package:crypto_app/widgets/coin_tile.dart';
import 'package:crypto_app/widgets/no_coins_widget.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:pine/pine.dart';

import '../../fixtures/models/coin_fixture_factory.dart';

/// Test case for the page Coins
void main() {
  late MockCoinBloc coinBloc;
  late List<BlocProvider> blocs;

  late List<Coin> coins;

  setUpAll(() => HttpOverrides.global = null);

  setUp(() {
    coinBloc = MockCoinBloc();
    blocs = [
      BlocProvider<CoinBloc>.value(value: coinBloc),
    ];

    coins = CoinFixture.factory().makeMany(3);
  });

  testWidgets(
      'Testing that CoinsPage with a list of coins is rendered properly',
      (tester) async {
    whenListen(
      coinBloc,
      Stream.fromIterable([
        const FetchingCoinState(),
        FetchedCoinState(coins),
      ]),
      initialState: const FetchingCoinState(),
    );

    await tester.pumpWidget(
      DependencyInjectorHelper(
        blocs: blocs,
        child: const MaterialApp(
          home: CoinsPage(),
        ),
      ),
    );

    expect(find.text('Crypto App'), findsOneWidget);

    expect(find.byType(CircularProgressIndicator), findsOneWidget);
    expect(find.byType(ListView), findsNothing);
    expect(find.byType(NoCoinsWidget), findsNothing);
    expect(find.byType(CoinTile), findsNothing);

    await tester.pumpAndSettle();

    expect(find.byType(CircularProgressIndicator), findsNothing);
    expect(find.byType(ListView), findsOneWidget);
    expect(find.byType(NoCoinsWidget), findsNothing);
    expect(find.byType(CoinTile), findsNWidgets(coins.length));
  });

  testWidgets('Testing that CoinsPage with no coins is rendered properly',
      (tester) async {
    whenListen(
      coinBloc,
      Stream.fromIterable([
        const FetchingCoinState(),
        const NoneCoinState(),
      ]),
      initialState: const FetchingCoinState(),
    );

    await tester.pumpWidget(
      DependencyInjectorHelper(
        blocs: blocs,
        child: const MaterialApp(
          home: CoinsPage(),
        ),
      ),
    );

    expect(find.text('Crypto App'), findsOneWidget);

    expect(find.byType(CircularProgressIndicator), findsOneWidget);
    expect(find.byType(ListView), findsNothing);
    expect(find.byType(NoCoinsWidget), findsNothing);
    expect(find.byType(CoinTile), findsNothing);

    await tester.pumpAndSettle();

    expect(find.byType(CircularProgressIndicator), findsNothing);
    expect(find.byType(ListView), findsNothing);
    expect(find.byType(NoCoinsWidget), findsOneWidget);
    expect(find.byType(CoinTile), findsNothing);
  });

  testWidgets('Testing that CoinsPage with an error is rendered properly',
      (tester) async {
    whenListen(
      coinBloc,
      Stream.fromIterable([
        const FetchingCoinState(),
        ErrorFetchingCoinState(Exception()),
      ]),
      initialState: const FetchingCoinState(),
    );

    await tester.pumpWidget(
      DependencyInjectorHelper(
        blocs: blocs,
        child: const MaterialApp(
          home: CoinsPage(),
        ),
      ),
    );

    expect(find.text('Crypto App'), findsOneWidget);

    expect(find.byType(CircularProgressIndicator), findsOneWidget);
    expect(find.byType(ListView), findsNothing);
    expect(find.byType(NoCoinsWidget), findsNothing);
    expect(find.byType(CoinTile), findsNothing);

    await tester.pumpAndSettle();

    expect(find.byType(CircularProgressIndicator), findsNothing);
    expect(find.byType(ListView), findsNothing);
    expect(find.byType(NoCoinsWidget), findsOneWidget);
    expect(find.byType(CoinTile), findsNothing);
  });
}

class MockCoinBloc extends MockBloc<CoinEvent, CoinState> implements CoinBloc {}

Copilot is so helpful in these particular scenarios, it can suggest different use cases and it modulates the assertions accordingly

Final thoughts

Looks like we finished our application. It took me more time to write this article than to create this simple project with good architecture and unit testing 😂.

Are you curious about it? Do you want to take a look at the full source code? Here’s the repository on GitHub: https://github.com/AngeloAvv/crypto_app

Thank you for reading 👋

I hope you enjoyed this article. If you have any questions or suggestions please let me know in the comments down below.

Passing data to a screen

Let’s analyze the following example (a custom snippet from the official Flutter docs) to understand what we need to do to pass data from one screen to another:

class FirstScreen extends StatelessWidget {
  const FirstScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('First Screen'),
      ),
      body: Center(
        child: ElevatedButton(
          child: const Text('Open screen'),
          onPressed: () {
            Navigator.push(
                context,
                MaterialPageRoute(builder: (context) => SecondScreen(title: 'title')),
              );
          },
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  final String title;

  const SecondScreen({required this.title, super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(title),
      ),
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            // Navigate back to first route when tapped.
          },
          child: const Text('Go back!'),
        ),
      ),
    );
  }
}

When we tap on the ElevatedButton in the FirstScreen class, we’re navigating to another route named SecondScreen and we’re passing custom data, in this case, the title of the screen. SecondScreen has a strong contract definition because we exactly know what kind of data we want to send. If someone else in the future changes the definition of the SecondScreen constructor, a syntactic error will occur.

Return data from a screen

Let’s keep adding features to our snippet so we can return data back:

class FirstScreen extends StatelessWidget {
  const FirstScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('First Screen'),
      ),
      body: Center(
        child: ElevatedButton(
          child: const Text('Open screen'),
          onPressed: () async {
            final result = await Navigator.push(
                context,
                MaterialPageRoute(builder: (context) => SecondScreen(title: 'title')),
              );

            ScaffoldMessenger.of(context)
              ..removeCurrentSnackBar()
              ..showSnackBar(SnackBar(content: Text('$result')));
          },
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  final String title;

  const SecondScreen({required this.title, super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(title),
      ),
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            Navigator.pop(context, 'Let\'s go back!');
          },
          child: const Text('Go back!'),
        ),
      ),
    );
  }
}

In the aforementioned snipped code I changed the behavior of both screens a little bit: in the SecondScreen, I added a Navigator.pop which navigates back to FirstScreen and returns data, in this case, a String, which will be shown as a Snackbar in the FirstScreen.

If we inspect the definition of Navigator.push, we can see there’s a custom generic type we can take advantage of to declare the type that will be returned if we decide to wait for the future. If we choose to not declare a type, then our result variable will be dynamic.

final result = await Navigator.push(
    context,
    MaterialPageRoute(builder: (context) => SecondScreen(title: 'title')),
  );

ScaffoldMessenger.of(context)
  ..removeCurrentSnackBar()
  ..showSnackBar(SnackBar(content: Text('$result')));

In this particular case, we’re able to show the SnackBar because the type of result implicitly inherits toString(), but if we want to explicitly use result as a String, we need to declare the generic type when using Navigator.push:

final result = await Navigator.push<String>(
    context,
    MaterialPageRoute(builder: (context) => SecondScreen(title: 'title')),
  );

ScaffoldMessenger.of(context)
  ..removeCurrentSnackBar()
  ..showSnackBar(SnackBar(content: Text(result)));

But what happens if someone in the future changes the type of the returned data? We have no control over the returned data in terms of a contract or type. In the first scenario, the type will always be dynamic, in the second one it will be String, but if someone returns data that is not a String and we declare the generic type as String, we won’t face any kind of syntactic error, the code will compile the same way as before, but as soon as our user will tap on the ElevatedButton in SecondScreen, our app will miserably crash.

Take advantage of contracts

If we don’t want to make mistakes when it comes to returning data from a screen, we need to define contracts across screens to exchange data. Let’s customize the snippet code to see how to introduce it:

typedef SecondScreenCallback = void Function(String result);

class FirstScreen extends StatelessWidget {
  const FirstScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('First Screen'),
      ),
      body: Center(
        child: ElevatedButton(
          child: const Text('Open screen'),
          onPressed: () {
            Navigator.push(
                context,
                MaterialPageRoute(builder: (context) => SecondScreen(
                  title: 'title',
                  onResult: (result) {
                    ScaffoldMessenger.of(context)
                      ..removeCurrentSnackBar()
                      ..showSnackBar(SnackBar(content: Text('$result')));
                  }
                )),
              );
          },
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  final String title;
  final SecondScreenCallback onResult;

  const SecondScreen({required this.title, required this.onResult, super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(title),
      ),
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            Navigator.pop(context);

            onResult.call('Let\'s go back!');
          },
          child: const Text('Go back!'),
        ),
      ),
    );
  }
}

SecondScreenCallback is our contract: we defined a custom callback, a simple function that returns void with a single parameter, the message that will be shown in our SnackBar as soon as SecondScreen is popped.

Instead of waiting for the future when we push SecondScreen, we declare an anonymous function that will be triggered on the screen where we want to send back data. This function contains our Data Transfer Object, in this case, a simple String that will be used later.

Pros and Cons

Of course, the two solutions aren’t 100% perfect, they both share pros and cons, but I prefer the second one as it gives me a bit more control over the data I’m returning.

If you decide to go with the contractless implementation, you don’t need to create a contract and declare custom callbacks that can be easily forgotten when you call Navigator.pop. On the other hand, you have no control over the types of data you’re returning.

With the contract implementation, of course, you have more control over the data but bear in mind you should invoke the callback every time you want to navigate back using Navigator.pop.

In the past few years, I created my custom logging systems by combining multiple different tools to log information in Flutter such as logger and Firebase Crashlytics. The main drawback of using it was strictly related to the hard coupling between the implementation and Firebase Crashlytics: if my application, for any reason, wasn’t meant to include Firebase, I had to change the implementation of the logging system.

Looking for something different

Logger is a fantastic library, but I find it a little bit oldish and tricky when it comes to plugging things. For instance, if I want to intercept network calls and use Logger as a pipe, strings are not printed out in a fancy way and it becomes difficult to understand what’s going on.

I started looking for new libraries on pub.dev and I found Talker, which by the way integrates pretty well with my Flutter stack: it supports a custom logger for Bloc and Dio, and adding Firebase crashlytics is easy peasy. To be honest, I’m really surprised by how this library is not so well known in the Flutter community.

How to integrate it

Let’s get to the point: first of all, we need to add Talker as a flutter dependency:

flutter pub add talker

If you’re following the Pine architecture as I do, we should inject the Talker instance in the widget tree, let’s open the providers.dart file and let’s inject it:

Provider<Talker>(
  create: (context) => Talker(),
),

Now that we’ve properly injected the Talker instance in the tree, we can use it in our services, repositories, blocs, and so on. For instance, I created this repository to obtain news from an RSS feed:

class NewsRepository {
  final RSSFeed feed;
  final Talker logger;

  const NewsRepository({
    required this.feed,
    required this.logger,
  });

  Future<AtomFeed> get news async {
    String response;
    try {
      logger.info(
        '[NewsRepository] Getting news from API',
      );

      response = await feed.rss();

      logger.good(
        '[NewsRepository] Got news from API',
      );
    } catch (error, stackTrace) {
      logger.error(
        'Thrown exception during news request',
        error,
        stackTrace,
      );
      throw RepositoryError(error: error);
    }

    return AtomFeed.parse(response);
  }
}

As you can see, this repository has two dependencies: an RSSFeed instance named feed, which is a service, and a Talker instance known as logger. This class contains a single method that calls the RSS method from the feed service and logs the information of what’s going on.

Before invoking feed.rss() we can spot

logger.info(
  '[NewsRepository] Getting news from API',
);

this allows us to log information at the info level. We’re basically telling “Okay, I’m about to call the RSS service”.

If you don’t know what logging levels are, please take a look at this very well-explained document.

Everything is embraced into a try/catch block: if everything went well, we can use the .good() method from the Talker library to express success, this will print out a green text surrounded by a frame.

logger.good(
  '[NewsRepository] Got news from API',
);

If something goes south, the code execution will enter the catch block and before handling the exception, we can log the error using of course the .error() method: this will print out a red text surrounded by a frame. We can provide more information when logging the error by passing both the error and the stack trace variables.

logger.error(
  'Thrown exception during news request',
  error,
  stackTrace,
);

We can also use many different methods to log the behavior of our application. In the following image, we can spot the .debug() and the .warning() outputs which respectively print out a white text and an orange text surrounded by a box.

Send the information to Crashlytics

To send the information to Firebase Crashlytics, we need to create and register an observer. We can register a single observer and I hope the maintainers of the library will find a way to allow us to register multiple ones, but as for now, let’s create a new class to log events to crashlytics.

import 'package:firebase_crashlytics/firebase_crashlytics.dart';
import 'package:talker/talker.dart';

class CrashlitycsTalkerObserver extends TalkerObserver {

  final FirebaseCrashlytics crashlytics;

  const CrashlitycsTalkerObserver({required this.crashlytics,});

  @override
  void onLog(TalkerDataInterface log) {
    crashlytics.log(log.generateTextMessage());
  }

  @override
  void onError(err) {
    crashlytics.recordError(
      err.error,
      err.stackTrace,
      reason: err.message,
    );
  }

  @override
  void onException(err) {
    crashlytics.recordError(
      err.exception,
      err.stackTrace,
      reason: err.message,
    );
  }
}

First of all, we should create a class that extends a TalkerObserver. It’s not mandatory to override all the methods in the abstract class, we can decide what kind of error we want to send to crashlytics. In my case, I prefer to send everything to better understand what’s happening during the app’s execution flow.

The onLog method will be triggered every time we call .warning(), .debug(), .info(), and .good(). In case of an error or an exception, onError and onException will be called instead.

Now that we have our observer, we need to register it, so let’s go back to the providers.dart file and let’s add it when creating our Talker instance.

Provider<Talker>(
  create: (context) => Talker(
    observer: CrashlitycsTalkerObserver(
      crashlytics: context.read(),
    ),
  ),
),

Do not forget to also inject a FirebaseCrashlytics instance in the tree, otherwise, Provider won’t be able to locate the crashlytics service needed by the Observer.

And that’s it, every time we’ll log something with Talker, everything will be also sent to our Firebase Crashlytics console.

Talker third-party integrations

If you also want to integrate a Dio logger and a Bloc logger, simply run

flutter pub add talker_dio_logger
flutter pub add talker_bloc_logger

To add a Dio logger to our Dio instance, simply add a TalkerDioLogger instance in the Dio interceptors. If you’re following the Pine architecture, you can do it in the providers.dart file as follows:

Provider<Dio>(
  create: (_) {
    final dio = Dio(BaseOptions());
    if (kDebugMode) {
      dio.interceptors.add(
        TalkerDioLogger(
          settings: const TalkerDioLoggerSettings(
            printRequestHeaders: true,
            printResponseHeaders: true,
            printResponseMessage: true,
          ),
        ),
      );
    }

    return dio;
  },
),

In this case, I’m registering the interceptor when we’re running the application in debug mode. For security reasons, I don’t want to log Dio calls when the app is in production.

To register a Bloc logger, simply add this instruction in your main.dart file before executing runApp():

Bloc.observer = TalkerBlocObserver();

And we’re good to go. We finally have control of what’s happening in our application when a user interacts with it.

My experience as a developer started almost fourteen years ago: I wasn’t a good programmer because I was a lazy person, I didn’t want to study algorithms and data structures from books and the only thing I kept doing was copy-pasting stuff or doing things without knowledge of the facts.

Why am I telling you that? Because of that attitude, I decided to stick with a simple programming language like Visual Basic .NET to start developing my first desktop apps.

In the following years, as many of you know, I abandoned desktop app development in favor of mobile app development. In the meantime, I had the chance to test some other desktop frameworks or technologies like Electron or GTK, but nothing has surprised me like Flutter desktop: for instance, Electron apps are generally heavy-resources consuming due to the Chromium instances.

The disks desktop library

After this boring introduction, let’s stick back to the point of this article. Even though Flutter desktop moved to stable a few months ago, it still lacks some things like interaction with its native operative system.

In my case, I needed to develop a desktop app able to burn ISO or IMG images to external disk drives. When I started diving into the internet looking for libraries or code to do that I found literally nothing.

I mean, you can do very high-level things like gathering paths with some well-known libraries like path provider, but I wasn’t able to enumerate the available disk drives in my system or understand whether that drive is a system drive, is removable, and so on.

And that’s why I decided to develop disks_desktop, a Flutter desktop library able to retrieve installed disk drives information. disks_desktop is available for Windows, macOS and Linux.

With Disks Desktop you can get access to disks’ information like:

• block size
• bus type
• bus version
• description
• device name
• device path
• logical block size
• available mountpoints
• disk size
• partition table type
• is in error
• is a card
• is read only
• is removable
• is scsi
• is system
• is uas
• is usb
• is virtual
• is raw

Setup

In general, put it under dependencies, in your pubspec.yaml:

dependencies:
  disks_desktop: ^1.0.1

You can install packages from the command line:

flutter pub get

or simply add it through the command line:

flutter pub add disks_desktop

Usage

To get the list of the available drives with their details, simply create an instance of a Disk Repository and invoke the query getter.

Example:

final repository = DiskRepository();
final disks = await repository.query;

You can also use it with a FutureBuilder:

FutureBuilder<List<Disk>>(
  future: DisksRepository().query,
  builder: (context, snapshot) => [...]
),

Links and Examples

The disks_desktop library is available under pub.dev and on GitHub. Please check the example project to better understand how to create a desktop app.

Thank you for reading 👋

I hope you enjoyed this article. If you have any queries or suggestions please let me know in the comments down below.

When we speak about the architecture of a Flutter project, every single component resides in the widget tree. It could be a visible widget or something less tangible that has to do with the business logic like a repository or a service, but at the end of the day, everything is there.

Since the beginning, Dependency Injection has been the common design pattern used in Flutter to inject elements into the widget tree. Flutter’s early adopters will easily remember about InheritedWidgets, a particular type of widget mainly used to inject non-tangible elements into the widget tree. InheritedWidget is really easy to understand and pretty straightforward when it comes to its use. The main downside is the boilerplate code around its definition.

The revolution started with Provider, a library that simplified the injection of different types of elements into the widget tree. Provider has been widely adopted by the Flutter community and works pretty well in combination with ChangeNotifier. Provider aims to remove the boilerplate code from the definition of an InheritedWidget. In fact, in terms of the number of lines of code, injecting an element in the widget tree with Provider takes only a single line:

Provider<Service>(create: (context) => Service());

Even the most used state management system decided to rely on Provider to inject its component in the widget tree: we are talking about BLoC.

The flutter_bloc library created by Felix Angelov is using a custom provider to inject the blocs into the widget tree.

BlocProvider<Bloc>(create: (context) => Bloc());

The problem

Flutter is a relatively easy framework that gives everyone the ability to create applications. Most people out there can to create a product that works, but I strongly believe that as developers we should focus more on how things work.

Software engineering comes in help: if you ever attended a lesson in computer science at the University, one of the first things that will teach you is about software architectures.

When it comes to Flutter architecture, I love to apply a customized version of the Flutter Clean Code Architecture. Generally speaking, my projects are organized into four different layers as follows:

UI Layer

The UI layer is composed of screens, pages, and widgets. Here you can create a combination of widgets that reside in Stateful and Stateless widgets. Those widgets typically interact with the second layer which is the state manager, in my case I like to use BLoC.

Business Logic Component Layer

The business logic component (or BLoC) layer, is the layer that is typically a middleware and aims to translate the user interaction with the UI into a set of instructions for the repository layer.

Repository Layer

The repository layer is an abstraction layer, a single source/point of truth, that queries the lower level, the service layer, translates this information into app-readable data using a set of mappers to convert DTOs into models, and delivers back this data, typically to the upper layers like a BLoC.

Service Layer

The service layer is the bottom layer in this kind of architecture. Here it’s easy to find different services like a REST Client that queries a REST API to get data from a server, or access to a database as a DAO.

The solution

During these years I used a combination of MultiProvider, MultiRepositoryProvider, and MultiBlocProvider to inject items into the widget tree. But as soon as your project starts growing and your app becomes more complex, it’s easier to have tons of injections in your app widget.

To avoid an always-growing app widget, I decided to split these providers into different files referenced by a single widget that I decided to name DependencyInjector.

class DependencyInjector extends StatelessWidget {
  final Widget child;

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

  @override
  Widget build(BuildContext context) => _Providers(
        child: _Repositories(
          child: _Blocs(
            child: child,
          ),
        ),
      );
}

Each nested element contained in the DependencyInjector widget is also a private Widget that wraps a MultiProvider, MultiRepositoryProvider, and MultiBlocProvider according to its reference layer.

This implementation sooner became a blocker when I wanted to start testing a single component coming from a particular layer. That’s why I decided to rewrite the dependency injector widget to simplify the process of injecting components into the widget tree.

Since all these widgets were continuously copied to newer projects, I decided to create a library for myself and for everyone who wants to simplify the injection process, and whose projects rely on Provider and BLoC as a state manager.

Pine

To add this library to your Flutter project, simply type this instruction in your command line:

flutter pub add pine

Once you’ve done this, you can start injecting your elements into the widget tree with Pine.

The Architecture

Elements are injected from top to bottom.

1. The first elements added in the widget tree are mappers, particularly useful to convert data coming from data layers to something that should be used in the presentation layer.
2. The second elements are providers: here you can inject services that manipulate data or access it like REST clients or DAOs interfaces.
3. The third layer is used to inject the repositories that access the data layer using an abstraction layer.
4. The last layer is used to inject the logic: Pine relies on BLoC as a state manager, that’s why we’ll inject global scoped BLoCs.

Each element might rely on the top level ones and are generally accessed from the bottom level ones: for instance, a repository may need access to a REST client service to gather data, save it into a database, and return it to a BLoC. To access top-level items, you can use the read and watch functions exposed by Provider.

The Interactions

How to use it

A pine architecture can be achieved by using the DependencyInjectorHelper widget, which helps you to inject different types of elements into the widget tree. If you are working on a simple project, you should use the DependencyInjectorHelper straight into your main app widget.

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

  @override
  Widget build(BuildContext context) => DependencyInjectorHelper(
    blocs: [
      BlocProvider<Bloc>(
        create: (context) => Bloc(
          repository: context.read(),
        )..action(),
      ),
    ],
    mappers: [
      Provider<DTOMapper<DTO, Model>>(
        create: (_) => Mapper(),
      ),
    ],
    providers: [
      Provider<Service>(
        create: (context) => Service(),
      ),
    ],
    repositories: [
      RepositoryProvider<Repository>(
        create: (context) => RepositoryImpl(
          service: context.read(),
          mapper: context.read(),
        ),
      ),
    ],
    child: MaterialApp(
      title: 'App',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: const HomePage(),
    ),
  );
}

As the project grows, it’s better to create a new widget that wraps all of these items in different files. We can name this widget DependencyInjector.

dependency_injector.dart

part 'blocs.dart';
part 'mappers.dart';
part 'providers.dart';
part 'repositories.dart';

class DependencyInjector extends StatelessWidget {
  final Widget child;

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

  @override
  Widget build(BuildContext context) => DependencyInjectorHelper(
    blocs: _blocs,
    providers: _providers,
    mappers: _mappers,
    repositories: _repositories,
    child: child,
  );
}

In this widget, we need to define all the dependencies that are required in our project. I prefer splitting these elements into different files according to their type. In our example, we will create four different files because we inject blocs, mappers, providers, and repositories.

blocs.dart

part of 'dependency_injector.dart';

final List<BlocProvider> _blocs = [
  BlocProvider<Bloc>(
    create: (context) => Bloc(
      repository: context.read(),
    )..action(),
  ),
];

mappers.dart

part of 'dependency_injector.dart';

final List<SingleChildWidget> _mappers = [
  Provider<DTOMapper<DTO, Model>>(
    create: (_) => Mapper(),
  ),
];

providers.dart

part of 'dependency_injector.dart';

final List<SingleChildWidget> _providers = [
  Provider<Service>(
    create: (context) => Service(),
  ),
];

repositories.dart

part of 'dependency_injector.dart';

final List<RepositoryProvider> _repositories = [
  RepositoryProvider<Repository>(
    create: (context) => RepositoryImpl(
      service: context.read(),
      mapper: context.read(),
    ),
  ),
];

Once we finished defining the global dependencies to inject into the widget tree, we need to wrap our MaterialApp/CupertinoApp with the DependencyInjector widget as follows:

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

  @override
  Widget build(BuildContext context) => DependencyInjector(
    child: MaterialApp(
      title: 'App',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: const HomePage(),
    ),
  );
}

Testing

With the DependencyInjectorHelper it’s easy to inject dependencies into the widget tree. Simply wrap the widget you need to test with the DependencyInjectorHelper class and inject the dependencies you need.

In the following example, we will test the HomePage widget which relies on a Bloc. Before pumping the MaterialApp containing the HomePage, we will wrap it as follows:

await tester.pumpWidget(
  DependencyInjectorHelper(
    blocs: [
      BlocProvider<Bloc>.value(value: bloc),
    ],
    child: const MaterialApp(
      home: HomePage(),
    ),
  ),
);

Of course, since we are testing the HomePage, we are injecting a mocked bloc.

Links and Examples

The Pine library is available under pub.dev and on GitHub. Please check the example project News App to better understand how to model a Pine based Flutter Architecture.

Thank you for reading 👋

I hope you enjoyed this article. If you have any queries or suggestions please let me know in the comments down below.

I always wanted to live an experience as a developer for a company that wasn’t speaking my mother tongue, so I decided to raise the bar by attending interviews in English.

Once I got a job offer, my former company needed to replace me so I was involved in the recruiting process of selecting a new Flutter developer. This has been an amazing experience because I had the opportunity to meet a lot of candidates and learn many things about the recruiting world as a technical interviewer.

Since January 2022, I attended a dozen of interviews with different companies as I was applying as a Senior Mobile Developer or Technical Lead, and I had the chance to better understand what companies look for in terms of knowledge and skills.

And that’s the purpose of this article: to give you a set of non-mandatory rules you can follow to master your next interviews as a Flutter developer.

Rule number one: Know what you did (and you’re doing)

One of the questions I like to ask, and many companies also like to, is to describe your journey in the company you’re working for, or you’ve worked for. The answers may vary according to the subjects involved in the interview, but if you’re speaking to a technical one, he might expect you to describe how your contribution impacted on the product.

You are allowed to speak about technologies, frameworks, and tools, and I think you must remember at least a bunch of them. One gold question could be related to your favorite set of third-party libraries that you typically use inside your Flutter project: you could mention three to five dependencies that you use in your daily routine as a Flutter developer. If you are not able to answer that question the interviewer may assume that you are not as fluent as expected.

Rule number two: State Management

Flutter has a very easy learning curve. I think this is one of the main drawbacks of this amazing framework because it allows people without any coding background to start creating apps.

Unless you’re applying for some sort of internship program, I think it’s better to master at least one state management. There are plenty of them out there, but please, please, don’t say you use setState only.

Another common mistake people do is to misunderstand the behaviors of the components involved in a state management pattern. Let me give you an example. One of the questions I like to ask the candidate is to tell me what kinds of state management patterns he uses.

I’m confident using Provider.

Let me get this straight to the point. Provider is not a state management pattern. It’s a way of realizing dependency injection in the widget tree by wrapping the InheritedWidget behavior. The component involved in the state management is ChangeNotifier, not certainly Provider!

TL;DR, the same argument is also valid for the GetIt library.

I think this confusion also comes from the official Flutter documentation that provides a list of methods to handle state management, without going deep into the definition.

Rule number three: Asynchronous programming

Flutter is a framework that relies on streams and futures: it mostly uses a reactive programming approach, so knowing how to handle streams and futures is mandatory.

Keep in mind that the interviewer may ask you how Flutter handles multitasking. All of the stuff in Flutter is done in the main thread: if you plan to draw a widget or perform a request to an API, the framework will take care of it. When you need to execute heavy background processes that may involve a lot of CPU or GPU, it’s better you spawn an Isolate. An Isolate is a process that runs separately from the main thread and can communicate with the main one using two ports.

Speaking about streams, probably you won’t be asked to explain how things work under the hood. Just remember the basic stuff like how to listen to it, how to consume it on the UI, and so on. For instance, you may need to show a CircularProgressIndicator as soon as a particular stream hasn’t emitted new events yet, to do that you can use a StreamBuilder. Also, if you need to listen for another stream to invoke other methods in your logic, you can listen to its changes by invoking the .listen() method.

Another tricky question would be to elaborate on the differences between single subscriptions and broadcast streams, or between yield and yield*.

It’s the same for futures. Most of the time you will invoke async methods that return a Future. For instance, you could request some data coming from the internet by querying a REST API. Just make sure you know the differences by invoking a future with or without the await keyword, or how to interact with them on the UI with a FutureBuilder.

Rule number four: Testing

If you’re trying to apply for a well-structured company, writing tests is one of the most important things you need to know. In Flutter there are basically three ways of writing tests:

• Unit tests: they give you the ability to test a small part of the code, typically a fragment that doesn’t interact too much with other logical layers of the application.
• UI tests: they give you the ability to test a finite widget or a screen/page. It’s a specialization of the unit test applied to the UI
• Integration tests: they give you the ability to test larger areas of your application that interacts with each other. Those kinds of tests are more complex and take more time to write, run and debug.

You also need to know how the mocking process works. When you write tests, you need to define boundaries the test doesn’t need to trespass. These boundaries allow you to test only some specific parts of the code.

Imagine you need to test a Repository. Typically a Repository is an abstraction layer that communicates with the lower ones without letting the invoker know which one it is. The lower layers invoked could be a REST API Service or a Data Access Object that reads and writes data to a database instance. In this particular case, you don’t need to test the whole tour, so you will just mock services and DAOs in order to focus on your repository.

Bonus track: Questions

I will leave here you a list of the most common questions I received during my interviewing process and some of them I like to ask candidates:

• What are the differences between Stateless and Stateful Widgets?
• Describe the StatefulWidget lifecycle
• What are LocalKeys and GlobalKeys? How would you use them?
• Can you tell me what is the purpose of the Scaffold widget?
• When would you use the SafeArea widget?
• Do you use any kind of architecture for your projects? Have you ever heard about Clean Code Architecture?
• How do you interact with the native? Do you know how to invoke Java/Kotlin or ObjectiveC/Swift code from Flutter?
• How do you deploy your applications? Have you ever used any kind of automatic tools to run tests or deploy your application like Fastlane?
• How do you manage internationalization in your application?
• How do you navigate across pages? Can you explain what kind of methods you use to navigate across them?
• Modifiers: can you tell me the differences between const, final and late?
• Animations: can you tell me what kinds of animations you can create in Flutter?
• Have you ever created flavors inside your flutter project? Do you use any kind of third-party libraries to do that?

When it comes to writing platform-specific code in Flutter, you need to create a channel to let the data pass through: this platform channel is called MethodChannel. According to the official Flutter docs:

The standard platform channels use a standard message codec that supports efficient binary serialization of simple JSON-like values, such as booleans, numbers, Strings, byte buffers, and Lists and Maps of these (see StandardMessageCodec for details). The serialization and deserialization of these values to and from messages happens automatically when you send and receive values.

The process of writing the interfaces on both Android and iOS hosts plus invoking the channels in the right way is typically error-prone, that’s why the Flutter community has introduced Pigeon, a code generator tool to make communication between Flutter and the host platform type-safe, easier and faster.

For the sole purpose of demonstrating how to invoke native code using Pigeon, I created a Flutter App that shows a list of the latest news by querying the NewsAPI APIs. Let’s deep dive into the process…

Setup the project

The first step requires you to add Pigeon as a dev dependency in your flutter project. In order to do this simply type in your terminal the following command:

flutter pub add --dev

Defining the interface in Flutter

Once we’ve added the pigeon dependency, we need to create the interface that we will use to invoke the native code. Since this is a service in a clean code architecture approach, I created a file named pigeon.dart under the lib/services folder.

Inside this file we need to create an abstract class annotated with the @HostApi annotation referenced in the package:pigeon/pigeon.dart file. It’s important that you also define your DTOs inside this file too.

Here’s my pigeon.dart file, as you can see we have the ArticleApi host API with a single method that returns a list of articles from the native and the Article DTO that carries all the information of single news.

Generating the code

The next step consists of letting Pigeon do its job by generating the code starting from our pigeon.dart file. Open your terminal and type

flutter pub run pigeon \
--input lib/services/pigeon.dart \
--dart_out lib/services/pigeon.g.dart \
--objc_header_out ios/Runner/pigeon.h \
--objc_source_out ios/Runner/pigeon.m \
--java_out ./android/app/src/main/java/it/angelocassano/news_app/Pigeon.java \
--java_package "it.angelocassano.news_app"

with this command, we are telling pigeon to generate some dart code in the pigeon.g.dart file next to the pigeon.dart file, and to generate the platform-specific code for both Android and iOS. Just make sure the folders where the files will be generated exist.

Final steps on Flutter

The NewsRepository class will take care of invoking the articles() method from the generated pigeon.g.dart file as follows.

Switching to Android

To query the NewsAPI APIs, I’ve plugged Retrofit as an Android dependency in my build.gradle file. I also created a new DTO class called EverythingResponse and a service called PigeonArticleApi. This last one will take care of gathering data from the APIs using Retrofit and send back the response to Flutter with the Pigeon autogenerated wrapper.

To let the PigeonArticleApi class be invokable by Flutter, we need to register it after spawning the Flutter Engine. Inside our MainActivity class let’s override the configureFlutterEngine method and invoke the Pigeon.ArticleApi.setup method passing the Flutter Engine’s binary messenger and a new PigeonArticleApi instance as follows.

In my case, I also had to create a Retrofit instance required as a dependency by the PigeonArticleApi class to query the NewsAPI APIs.

Switching to iOS

Before writing our code, remember to add both pigeon.h and pigeon.m inside our XCode project under the Runner group.

Since the generated code is not swift code, we also need to import the pigeon.h header file inside the Runner-Bridging-Header.h file in order to let the autogenerated objective-C code be visible by the swift classes that we will create in the next steps.

To query the NewsAPI APIs, I’ve plugged Alamofire as an iOS dependency in my Podfile file. I also created a new DTO class called EverythingResponseDTO and a service called PigeonArticleApi. This last one will take care of gathering data from the APIs using Alamofire and send back the response to Flutter with the Pigeon autogenerated wrapper.

To let the PigeonArticleApi class be invokable by Flutter, we need to register it after spawning the Flutter Engine. Inside our AppDelegate class let’s invoke the ArticleApiSetup method passing the Flutter Engine’s binary messenger and a new PigeonArticleApi instance under the didFinishLaunchingWithOptions method as follows.

Et voila!

Once we’ve done all of this stuff, we are ready to launch our application on both Android and iOS devices to see if everything works.

Thank you for reading 👋

I hope you enjoyed this article. If you have any queries or suggestions please let me know in the comments down below.

For some time I had an idea in my mind: I wanted to create a desktop application able to run on the three most known and used operative systems to simplify the process of gathering a macOS recovery image.

Since I’m fluent with Dart and Flutter, I decided to stick with it and leave Electron and Javascript on my back, moreover Flutter Desktop for Windows available on the stable channel gave me a further push to follow this path.

The App: MacRecoveryX

It took no more than a few days to develop my new app. MacRecoveryX, that’s the name I gave to it it’s a very simple tool. It allows you to choose the version of macOS you wish to download, define where to place the two recovery files (the dmg image system and its chunklist), and start the process to download these files.

Once I finished developing my app, I needed to find a way to deploy it to the world. According to the official Flutter documentation, you can distribute your Flutter apps bundling an MSIX file for Windows, Snap for Linux, and Apple Store for macOS. I thought it was too overkill for a simple tool.

The source code

As a fervent supporter of the open-source world, I decided to version the MacRecoveryX source code on GitHub.

That wasn’t enough. MacRecoveryX needs a Flutter SDK to allow users to generate artifacts and run them: I needed a way to generate artifacts after a push (a tag would be better) for each OS target, compress them into a zip file and then release them in the repository. GitHub Actions was the key to success.

GitHub Actions pipeline

To trigger a GitHub actions pipeline we need to create a .yml file under the .github/workflows folder at the root of our project.

Since we need to deploy a Flutter app, we will name it Flutter CI. We also need to build our app for the three main targets: Windows, Linux, and macOS. We will split the build flow into three different jobs. The scripts will run respectively on Windows, Ubuntu, and macOS.

name: Flutter CI

on: push

jobs:
  build-and-release-linux:
    runs-on: ubuntu-latest

  build-and-release-windows:
    runs-on: windows-latest

  build-and-release-macos:
    runs-on: macos-latest

The build process

Now let’s focus on the build process, we need to:

• Check out our source code from GitHub — with actions/checkout@v2
• Choose the right version of Flutter to build our project — with subosito/flutter-action@v1
• Install a bunch of dependencies to compile our artifacts (some of them are mentioned here)
• Retrieve the flutter project dependencies using flutter pub get
• Generate some intermediate files using build_runner
• Enable the target desktop configuration
• Build the artifact
• Compress the artifact and its files in a zip file — with thedoctor0/zip-release@master
• Deploy the zip file as a new release — with softprops/action-gh-release@v1

    steps:
      - uses: actions/checkout@v2
      - uses: subosito/flutter-action@v1
        with:
          channel: 'stable'
          flutter-version: '2.10.0'
      - name: Install project dependencies
        run: flutter pub get
      - name: Generate intermediates
        run: flutter pub run build_runner build --delete-conflicting-outputs
      - name: Enable windows build
        run: flutter config --enable-windows-desktop
      - name: Build artifacts
        run: flutter build windows --release
      - name: Archive Release
        uses: thedoctor0/zip-release@master
        with:
          type: 'zip'
          filename: MacRecoveryX-${{github.ref_name}}-windows.zip
          directory: build/windows/runner/Release
      - name: Windows Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          files: build/windows/runner/Release/MacRecoveryX-${{github.ref_name}}-windows.zip

Enabling Desktop support

To enable Windows Desktop support we will execute:

flutter config --enable-windows-desktop

To enable Linux Desktop support we will execute:

flutter config --enable-linux-desktop

To enable macOS Desktop support we will execute:

flutter config --enable-macos-desktop

Building the app

Once enabled desktop support, we need to build our app with the following instructions.

To build a Windows Desktop app we will execute:

flutter build windows --release

To build a Linux Desktop app we will execute:

flutter build linux --release

To build a macOS Desktop app we will execute:

flutter build macos --release

Zipping the artifacts

Every build will create an executable and a bunch of support files like libraries and assets. Every target will create the artifacts in a different path.

To create a zip artifact for Windows we will run the following step:

- name: Archive Release
  uses: thedoctor0/zip-release@master
  with:
    type: 'zip'
    filename: MacRecoveryX-${{github.ref_name}}-windows.zip
    directory: build/windows/runner/Release

To create a zip artifact for Linux we will run the following step:

- name: Archive Release
  uses: thedoctor0/zip-release@master
  with:
    type: 'zip'
    filename: MacRecoveryX-${{github.ref_name}}-linux.zip
    directory: build/linux/x64/release/bundle

To create a zip artifact for macOS we will run the following step:

- name: Archive Release
  uses: thedoctor0/zip-release@master
  with:
    type: 'zip'
    filename: MacRecoveryX-${{github.ref_name}}-macos.zip
    directory: build/macos/Build/Products/Release

Releasing the assets

Once done, we need to upload these assets as a set of release artifacts.

To release the Windows zip file we will run the following step:

- name: Windows Release
  uses: softprops/action-gh-release@v1
  if: startsWith(github.ref, 'refs/tags/')
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    files: build/windows/runner/Release/MacRecoveryX-${{github.ref_name}}-windows.zip

To release the Linux zip file we will run the following step:

- name: Linux Release
  uses: softprops/action-gh-release@v1
  if: startsWith(github.ref, 'refs/tags/')
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    files: build/linux/x64/release/bundle/MacRecoveryX-${{github.ref_name}}-linux.zip

To release the macOS zip file we will run the following step:

- name: macOS Release
  uses: softprops/action-gh-release@v1
  if: startsWith(github.ref, 'refs/tags/')
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    files: build/macos/Build/Products/Release/MacRecoveryX-${{github.ref_name}}-macos.zip

The completed script

In the end, the script will look like this:

name: Flutter CI

on: push

jobs:
  build-and-release-linux:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - uses: subosito/flutter-action@v1
        with:
          channel: 'stable'
          flutter-version: '2.10.0'
      - name: Install dependencies
        run: sudo apt-get install -y clang cmake ninja-build pkg-config libgtk-3-dev liblzma-dev
      - name: Install project dependencies
        run: flutter pub get
      - name: Generate intermediates
        run: flutter pub run build_runner build --delete-conflicting-outputs
      - name: Enable linux build
        run: flutter config --enable-linux-desktop
      - name: Build artifacts
        run: flutter build linux --release
      - name: Archive Release
        uses: thedoctor0/zip-release@master
        with:
          type: 'zip'
          filename: MacRecoveryX-${{github.ref_name}}-linux.zip
          directory: build/linux/x64/release/bundle
      - name: Linux Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          files: build/linux/x64/release/bundle/MacRecoveryX-${{github.ref_name}}-linux.zip

  build-and-release-windows:
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v2
      - uses: subosito/flutter-action@v1
        with:
          channel: 'stable'
          flutter-version: '2.10.0'
      - name: Install project dependencies
        run: flutter pub get
      - name: Generate intermediates
        run: flutter pub run build_runner build --delete-conflicting-outputs
      - name: Enable windows build
        run: flutter config --enable-windows-desktop
      - name: Build artifacts
        run: flutter build windows --release
      - name: Archive Release
        uses: thedoctor0/zip-release@master
        with:
          type: 'zip'
          filename: MacRecoveryX-${{github.ref_name}}-windows.zip
          directory: build/windows/runner/Release
      - name: Windows Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          files: build/windows/runner/Release/MacRecoveryX-${{github.ref_name}}-windows.zip

  build-and-release-macos:
    runs-on: macos-latest

    steps:
      - uses: actions/checkout@v2
      - uses: subosito/flutter-action@v1
        with:
          channel: 'stable'
          flutter-version: '2.10.0'
      - name: Install project dependencies
        run: flutter pub get
      - name: Generate intermediates
        run: flutter pub run build_runner build --delete-conflicting-outputs
      - name: Enable macOS build
        run: flutter config --enable-macos-desktop
      - name: Build artifacts
        run: flutter build macos --release
      - name: Archive Release
        uses: thedoctor0/zip-release@master
        with:
          type: 'zip'
          filename: MacRecoveryX-${{github.ref_name}}-macos.zip
          directory: build/macos/Build/Products/Release
      - name: macOS Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          files: build/macos/Build/Products/Release/MacRecoveryX-${{github.ref_name}}-macos.zip

The final result

Every time we will push into our repository, a new workflow will be triggered. Furthermore, if we push a tag, the pipeline will also proceed to create a release and upload a custom set of artifacts according to the OS target.

The release section will look like this:

Conclusions

It’s often unnecessary to build and deploy your Desktop application using the Windows Store, Snap, or the Apple Store. You can simply prepare a GitHub Actions pipeline to create a set of artifacts, zip the files, and release the zip files in the repository.

Taking part in a recruiting process is stimulating. Am I a masochist? Probably. From my perspective, I think everyone should take part in a recruiting process at least once or twice per year.

Why? There are three main reasons behind that:

• You get to know how other companies work
• It enhances your relational skills
• Keeps your problem-solving capabilities trained

In the last year, I applied for different roles and of course, I took part in different recruitment processes. Some of them asked me to complete a “small” take-home exercise. Let’s see how it went.

Senior Flutter developer selection process experience

I found this company on LinkedIn that was looking for a well-knowledged Flutter developer to strengthen their mobile team. I thought I was qualified for this role so I decided to apply.

I sent my updated CV and I wrote a cover letter to explain why I was suited for the job, then they contacted me a few hours later: it’s a match! They scheduled me for interview where they asked me about my career path and what were my expectations. At the end of the interview, they asked me to complete a “small” take-home exercise during the weekend.

At this point you might be wondering why I keep embracing the term small with double quotes, so let me explain. They asked me to develop a “small” application composed of two interfaces, that talk to an open-source REST API and present the data inside of it.

Let me get this straight to the point. The hardest part of this exercise is code and UX refinements. You can set up a working product in less than an hour, but it will suck aesthetically and engineeringly.

It took me two business days to complete the task: the exercise also required good UX, strong architecture choices, animations, unit, and integration tests.

Senior software engineer selection process experience

At the beginning of 2021, I decided to bring the challenge to another level. I’m a native Italian speaker, so I decided to take part in an English recruitment process.

In short, this company was looking for a senior software engineer for a particular programming language that I didn’t know, no matter what your knowledge was (in terms of programming languages of course).

I was very skeptical about that, but the recruiter who contacted me on LinkedIn reassured me, so I decided to get into it. We scheduled an interview and after some questions about my career path, he introduced me to the hard skill selection process.

Well, that exercise was not quite “small”. They told me they weren’t expecting me to deliver the task in a few days, so I thought that I would have made it in a few weeks. Long story short: I should have studied this new programming language in less than a week, and then complete the exercise, average working days? 5 to 15.

Senior Backend engineer selection process experience

In the last few weeks, I get contacted through StackOverflow for a senior backend engineer position. They asked me if I was interested in their company, so we arranged three different interviews.

Between two interviews, they asked me to develop a “small” authentication system that manages roles and some other different behaviors. They also asked me to mind about database optimizations and algorithm performance, and to provide with a bunch of papers (documentation, flow charts, entity-relationships diagrams, and so on).

Deadline? 5 days. Did I complete it? Partially. In the next interview, the examiner told me it would have required at least a month to complete it.

Do take-home exercises really work?

They do. Indisputably.

I think a take-home exercise should take no more than two or three hours. You need to understand how the developer solves a problem and how he broadly thinks, you don’t need to take him down emotionally or put it under pressure. I need to warn you about a thing, we have a life too.

And guess what, I even attended paid take-home exercises: yes, some companies really take seriously their recruiting process.

In this article, I wanted to talk to you about how to not abuse them, so if you are a recruiter, please don’t do it. You will let your candidates run far away from your company.