Category: Development

In this post, you’ll learn more about Layering the Flutter Application Architecture.

Structuring code is crucial for building large-scale applications that are maintainable and extendable. Poorly structured code can make it difficult to add new features or make changes to existing functionality, leading to bugs and technical debt that can accumulate over time.

What is app architecture?

The architecture of an application determines how its components interact with each other, how data is stored and retrieved, and how the application responds to user input. A well-structured architecture should be modular, with clear separation of concerns between different parts of the codebase. This allows developers to work on different parts of the codebase independently, without fear of breaking other parts of the application. 

There are several popular architectural patterns that can be used to structure code, such as Model-View-Controller (MVC), Model-View-ViewModel (MVVM), and Clean Architecture. Each pattern has its own strengths and weaknesses, and the choice of pattern will depend on the specific needs of the application.

 Some common components of an application architecture include:

• User interface (UI). The interface that users interact with to use the application.
• Data storage. The technology used to store data, such as a database or file system.
• Backend. The server-side components that handle business logic and data processing.
• Networking. The protocols and technologies used to communicate between the frontend and backend of the application.
• Security. The mechanisms used to protect the application from unauthorized access and attacks.

A few words about layers

Layers refer to different levels of abstraction or responsibility in a system. Each layer has a specific function and interacts with the layers above and below it to provide a cohesive and functional system.

The layers typically include:

• Presentation Layer: This layer is responsible for presenting the data to the user in a way that is easy to understand and interact with. It includes user interface components such as screens, forms, and dialogs.
• Business Layer: This layer contains the application logic and business rules that process and manipulate data. It handles data validation, workflows, and business logic rules that govern how data is processed.
• Data Access Layer: This layer is responsible for accessing data from a database or other data storage mechanism. It includes data access components such as data mappers, repositories, and data contexts.
• Infrastructure Layer: This layer contains the technical infrastructure components that support the application. It includes components such as logging, configuration, and security.

By separating an application into layers, each layer can be developed and tested independently, making the application more maintainable and scalable. It also allows for more flexibility in the development process, as changes can be made to one layer without affecting the others.

The layered architecture pattern is just one example of how layers can be used in software development. Other examples include the OSI model for networking and the protocol stack used in communications.

The Single Responsibility Principle

The Single Responsibility Principle (SRP) is a software development principle when each class or module should have only one responsibility or job to perform.

The SRP is one of the SOLID principles;it helps to ensure that code is easy to understand, modify, and test.

When a class or module has only one responsibility, it is easier to understand its purpose and to modify it without affecting other parts of the codebase. This also helps to reduce the likelihood of introducing bugs or errors when making changes.

For example, a class that handles user authentication should not also be responsible for managing user profiles. Instead, these responsibilities should be separated into two separate classes, each with its own responsibility. 
Here are some examples of responsibilities that software components may have:

• User interface (UI) components are responsible for displaying information to the user and capturing user input.
• Business logic components are responsible for implementing the business rules and processes that govern the behavior of an application.
• Data access components are responsible for accessing and manipulating data in a database or other data storage mechanism.
• Networking components are responsible for managing communication between different parts of an application or between different applications.
• Security components are responsible for ensuring that an application is secure and protected from unauthorized access or attacks.

Architectural patterns

Some common architectural choices include:

• Monolithic architecture involves building a single, self-contained application that handles all aspects of the system’s functionality. This can be easier to develop and deploy, but may become unwieldy as the system grows larger and more complex.
• Microservices architecture implies breaking the system down into small, independent services that communicate with each other over a network. This can make the system more scalable and easier to maintain, but may introduce additional complexity in terms of service discovery, communication protocols, and deployment.
• Event-driven architecture is about building the system around a set of events or triggers, such as user input or external messages. This can make the system more responsive and adaptable to changing conditions, but may require additional overhead in terms of event management and processing.
• Service-oriented architecture (SOA) is for building the system around a set of loosely-coupled, reusable services that can be easily combined and composed to create more complex functionality. This can make the system more flexible and adaptable, but may require additional effort in terms of service design and coordination.

When making architectural choices, consider a variety of factors, including the requirements of the system, the available technology stack, the skills and experience of the development team, and the expected future growth and evolution of the system. 

Define your layers

You can create different layers in your application to perform the three main duties. Layers need to be defined carefully so that they guarantee convenient operation and without compromising work.

Good architecture: what is it?

At TBR Group, we follow an architecture pattern that has four layers.

1. Data Layer. This layer is responsible for interacting with the API.
2. Domain Layer. This is the one responsible for transforming the data coming from the data layer.
3. Business logic layer manages the state (usually using flutter_bloc).
4. Finally, the presentation layer. It renders UI components based on the state.

Each layer contains multiple neurons, or nodes, which perform mathematical operations on the input data and pass the output to the next layer. The first layer, the input layer, receives the raw input data and passes it to the first hidden layer. The output layer produces the final output of the network, which could be a prediction or classification based on the input.

The layer responsible for domain-specific data modeling is known as the domain layer, which transforms unprocessed data into models specific to the domain that are then used by the business logic layer. The business logic layer maintains an unalterable state of the domain models supplied by the repository. Furthermore, this layer responds to user inputs from the UI and interacts with the repository when modifications are required based on the current state.

Say NO to mixed responsibilities

Very often, mixed responsibilities cause chaos in various projects. Without a clear division of duties and priorities, it is very easy to get confused and make a lot of mistakes that are then difficult to find and correct. 

import 'package:firebase_auth/firebase_auth.dart';

class StartPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StreamBuilder<User?>(
      stream: FirebaseAuth.instance.userChanges(),
      builder: (context, snapshot) {
        if (snapshot.hasData) {
          return const ProfilePage();
        }

        return const SignInPage();
      },
    );
  }
}

Be consistent (always)

When working according to a specific template for projects, we advise you not to use labels with layers. Each layer should have a chain of relationships that will prevent interaction between layers that are not directly related. For example, the presentation layer should not call or interact in any way directly with the data-tier APIs.
Establish a consistent naming convention and adhere to it throughout the development process.  In the case of a project with a data layer that is a dependency of the domain layer, it would be beneficial to name the data layer accordingly, such as “data” or “repository”.  

├── lib
| ├── posts
│ │ ├── bloc
│ │ │ └── post_bloc.dart
| | | └── post_event.dart
| | | └── post_state.dart
| | └── models
| | | └── models.dart
| | | └── post.dart
│ │ └── view
│ │ | ├── posts_page.dart
│ │ | └── posts_list.dart
| | | └── view.dart
| | └── widgets
| | | └── bottom_loader.dart
| | | └── post_list_item.dart
| | | └── widgets.dart
│ │ ├── posts.dart
│ ├── app.dart
│ ├── simple_bloc_observer.dart
│ └── main.dart
├── pubspec.lock
├── pubspec.yaml

Reusability in mind

The abstract declaration and concrete implementation approach used in the flutter_todos example from the bloc library is a good way to implement this type of solution. The abstract declaration provides a blueprint for the functionality needed, while the concrete implementation provides the specific details for how it is implemented. This allows for flexibility in adapting the functionality to different use cases while maintaining a consistent API interface.

Balance abstraction

Choosing between creating a repository with a direct dependency or creating an API wrapper for an external package will depend on various factors, including the complexity of the external package’s API, the number of dependencies it requires, and how well it meets the specific needs of the project.

If the external package has a clean and simple API that meets the needs of the project without requiring too many dependencies or configuration, then creating a repository with the package as a direct dependency may be the best approach. This can simplify the codebase and make it easier to maintain, as well as potentially provide better performance.

The chat_location  application provides a good example of how to use this package with a repository, demonstrating how the package can be integrated into the app’s architecture while keeping the repository code clean and maintainable.

In cases where an external package’s API is more complex, creating an API package with a class that wraps that dependency can be a better approach. This can provide a more streamlined interface for the specific needs of the project and abstract away some of the implementation details.

The spacex_demo application is a good example of how to create a custom API package, providing a wrapper for the SpaceX API. This approach allows for a more tailored interface for the project’s specific needs, while also providing flexibility and isolation from any potential issues with the external API.

Don’t over-engineer

Over-abstracting can increase complexity and development time without providing any real benefit.

If the project primarily uses JSON as its data format, then abstracting the base properties of the model to accommodate other formats may not be necessary. In this case, it may be more efficient to simply create the serialization/deserialization functionality for JSON and avoid over-abstracting the model.

However, if there is a possibility of the data format changing in the future, or if there are other reasons for needing a more abstracted model, then it may be worthwhile to invest the time and effort into creating a more flexible model architecture.

Packages: yes or no?

The decision to use packages should be based on the specific needs and constraints of the project. For a small project with a small team, the added complexity of using packages may not be worth the benefits. In this case, it may be more efficient to handle migrations and updates manually.

However, as the project grows and the team expands, the benefits of using packages become more apparent. Component isolation becomes more important as the project becomes more complex, and having different team members working on different parts of the project simultaneously becomes more common.

You can have one teammate migrating the accounting repository to Very Good Analysis 2.4.0 and another migrating the retail API to dio 4.0.0 at the same time, so you can tackle fixing lints and null safety refactors without stepping on each other’s toes.

Choose right tools

When choosing packages or tools, it’s important to have a set of criteria to evaluate them against:

• Activity on the GitHub repository: a package that is actively being developed and maintained is more likely to be reliable and up-to-date.
• pub.dev  metrics: pub.dev provides useful information such as the number of downloads, the number of dependent packages, and the percentage of code coverage. This information can help you evaluate a package’s popularity and usefulness.
• Test coverage: packages with high test coverage are more likely to be reliable and less prone to bugs.
• Who’s maintaining it: knowing who is responsible for maintaining a package can give you an idea of its reliability and longevity.
• Other factors that are important to you and your team: this could include factors such as documentation, community support, or compatibility with other tools or packages you’re already using.

Follow best practices

Studying other developers’ repositories is an excellent way to learn and improve. Many open-source projects have an active community of contributors who can help you with any questions or issues you may encounter. 

Refactor

Refactoring is a natural part of the development process, and it’s important to recognize when something needs to be improved and not be afraid to make changes. Additionally, it’s important to maintain a positive attitude towards mistakes and failures, as they provide valuable learning experiences that can lead to growth and improvement. As the saying goes, “fail fast, fail often, fail forward.”

Welcome to our team!

If you are reading this article, then you are interested in the topic of structuring code. If you are ambitious, not afraid of difficulties, you have a lot of ideas, but a little lack of confidence and experience in your business – come to our team! 

1. Template Generation in Flutter.

Code generation allows you to speed up and make the development more convenient by generating ready-made pieces of a code.

This can be used to preset the architecture of an application, for example. If you want to use the wedge architecture pattern, then you will have to spend a lot of time creating all the folders and files.

Template generation will save you this time and enable you to jump right into the development with a quick start.

Also, template generation helps not only with the architecture setup, but also speeds up the development itself.

For example, we used template generation to automatically create repositories to save time and make developers create unit tests for their code, since our template, together with the repository, creates a template with tests for this repository in the test directory.

There are a large number of approaches to generating templates in Flutter, we chose Mason package, because it is the most popular, constantly developing and improving package, which also has its own hub containing bricks (templates) that can be used with this package.

2. About Mason package

Mason is a Flutter code generation tool that helps developers create reusable code blocks, called “bricks”, for their Flutter projects.

These bricks can contain any type of code, from UI elements to business logic, and can be easily imported into any Flutter project using the Mason command line interface (CLI).

One of the main benefits of using Mason is that it allows developers to easily share their code with others, making it easier for teams to collaborate and reuse the code.

Additionally, Mason makes it easy to create and manage code templates, which can save developers a lot of time and effort when starting new projects or adding new features to existing ones.

Using Mason and the Brickhub can provide a number of benefits for Flutter developers, including:

• Time saving: By using reusable bricks, developers can save a lot of time and effort when starting new projects or adding new features to existing ones.
• Improved collaboration: Mason makes it easy to share bricks with others, which can improve collaboration within a team and make it easier to reuse code.
• Consistency: Using a common set of bricks can help to ensure that projects have a consistent look and feel, which can be especially useful for larger projects or teams.
• Increased efficiency: By using Mason, developers can focus on more important aspects of their projects, rather than spending time writing a boilerplate code.

Overall, Mason and the Brickhub provide a powerful tool for Flutter developers looking to save time and improve their workflow. Whether you’re a seasoned developer or just starting out, Mason can help you create high-quality, reusable code for your Flutter projects.

3. How to install Mason

Official documentation recommend installing mason_cli from pub.dev

# 🎯 Activate from https://pub.dev
dart pub global activate mason_cli

Alternatively, mason_cli can be installed via homebrew

# 🍺 Install from https://brew.sh
brew tap felangel/mason
brew install mason

Once you have successfully installed the mason_cli you can verify your setup by running the mason command in your terminal. If mason_cli was installed correctly, you should see something similar to the following output:

🧱 mason • lay the foundation!
Usage: mason <command> [arguments]
Global options:
-h, --help Print this usage information.
--version Print the current version.
Available commands: ...

4. How to install Mason

We will describe how to create your own break using as example our simple_repository brick.

Use this command to create the new brick:

mason new simple_repositoty

It will create a new, custom brick template in the current working directory.

5. Detail

It should generate such file structure:

├── CHANGELOG.md
├── LICENSE
├── README.md
├── __brick__
└── brick.yaml

The brick.yaml file is a manifest which contains metadata for the current brick. The newly generated brick.yaml should look something like:

name: simple_repository
description: Brick for the simple creating repositories and tests for them.
repository: https://github.com/TBR-Group-software/simple_bricks/tree/main/bricks/simple_repository
version: 0.1.0+2
environment:
mason: ">=0.1.0-dev.26 <0.1.0"
vars:
repository_name:
type: string
description: Repository Name
default: Dash
prompt: What is your repository name?

The __brick__ directory contains the template for your brick. Any files, directories within the __brick__ will be generated when the brick is used via mason make.

In the example brick, our __brick__ directory contains a such files structure:

├── __brick__
│ ├── lib
│ │ ├── {{repository_name.snakeCase()}}
│ │ │ ├── {{repository_name.snakeCase()}}_repository
│ │ │ │ └──{{repository_name.snakeCase()}}
_repository.dart
│ │ │ └──api_{{repository_name.snakeCase()}}
_repository
│ │ │ └── api_{{repository_name.snakeCase()}}
_repository
│ │ └── {{repository_name.snakeCase()}}.dart
│ ├── test
│ │ └── repositories
│ │ └── {{repository_name.snakeCase()}}
_repository_test.dart
└── └──

Templates currently support only Mustache syntax, we will create our template using it.

Mason supports a handful of built-in lambdas that can help with customizing generated code:

{{repository_name.snakeCase()}}_repository.dart file:

abstract class {{repository_name.pascalCase()}}Repository {}

{{repository_name.snakeCase()}}_repository.dart file:

/// {@template api_{{repository_name.snakeCase()}}repository} /// [{{repository_name.pascalCase()}}Repository] /// {@endtemplate} 
class Api{{repository_name.pascalCase()}}Repository extends {{repository_name.pascalCase()}}Repository { /// {@macro api{{repository_name.snakeCase()}}_repository} 
}

{{repository_name.snakeCase()}}.dart file:

export 
'api_{{repository_name.snakeCase()}}_repository/api_{{repository_name.snakeCase()}}_repository.dart';
export
'{{repository_name.snakeCase()}}_repository/{{repository_name.snakeCase()}}_repository.dart';

{{repository_name.snakeCase()}}_repository_test.dart file:

import 'package:flutter_test/flutter_test.dart';

void main() {
group("Testing {{repository_name.pascalCase()}} Repository", () {
//TODO: implement the tests

setUp(() {});
test("Test method", () {});
});
}

6. How to publish brick to the Brickhub

To publish a brick to the Brickhub using Mason, you will first need to sign up for an account on the Brickhub website.

To do this, you will need to request access to the site, and then follow the instructions in the email invite to sign up and verify your email.

Once you have an account, you can log in to the Brickhub using the mason login command.

This will prompt you to enter your email and password, and once you have successfully logged in, you will be ready to publish your brick. To publish a brick, you will use the mason publish command, followed by the –directory option and the path to your brick’s directory.

For example:

mason publish --directory ./my_brick

This will start the process of publishing your brick to the Brickhub.
You will be prompted to confirm that you want to publish the brick, and once you confirm, the brick will be bundled and published to the Brickhub.

It’s important to note that you will need to be logged in to an account in order to publish a brick to the Brickhub.

Overall, publishing a brick to the Brickhub is a straightforward process that can be accomplished quickly and easily using the Mason CLI.
By making your bricks available on the Brickhub, you can share them with other Flutter developers and save time and effort when working on your projects.

7. Hooks

Mason supports Custom Script Execution so called hooks.

These hooks are defined in the application’s configuration and can be executed before or after certain events occur, such as the generation of code or the rendering of templates.

Currently, Mason only supports hooks written in the Dart programming language.

These hooks are defined in the hooks directory at the root of the brick and must contain a run method that accepts a HookContext from the package:mason/mason.dart library

There are two types of hooks available in Mason: pre_gen and post_gen, which are executed immediately before and after the generation step, respectively.

These hooks can be used to perform tasks such as logging, modifying the brick variables, or interacting with the logger.

For example, hooks for running dart formatting.

Future<void> _runDartFormat(HookContext context) async {
final formatProgress = 
context.logger.progress('Running "dart format ."');
await Process.run('dart', ['format', '.']);
formatProgress.complete();
}

Future<void> _runDartFix(HookContext context) async {
final formatProgress = 
context.logger.progress('Running "dart fix --apply"');
await Process.run('dart', ['fix', '--apply']);
formatProgress.complete();
}

8. What benefits we have got

Using Mason templates has provided a number of benefits for our development process, including:

• Faster development: By generating ready-made pieces of code, we were able to speed up development and jump right into creating new features or working on existing ones. This saved us a lot of time and allowed us to focus on more important tasks.
• More structured code: Using Mason templates helped us create a more structured and organized codebase, which made it easier to maintain and scale our projects. We were able to create a consistent structure for our code, which made it easier for new developers to understand and work with.
• Forced developers to write unit tests: One of the benefits of using Mason templates is that they can be customized to include certain requirements or best practices. In our case, we used templates to force developers to write unit tests for their code, which helped us to ensure that our code was well-tested and of high quality.

Overall, using Mason templates has helped us to improve the efficiency and quality of our development process, and has made it easier for us to create and maintain high-quality code for our Flutter projects.

MVC, MVP, MVVM, Vanilla, Scoped Model, and BLoC Flutter… These are the architectural patterns, the models, which appear to be rather popular among software engineers nowadays.

But what type of mobile app structural organization to choose and which approach to the architecture should be applied?

This article will be centered around the practical approach of BLoC pattern implementation to the mobile crypto app niche.

The ABC of Flutter BLoC pattern

Being a declarative framework, Flutter implies using one of the state management approaches to build the UI and therefore reflect the current state of the application.

Flutter BLoC can be specified as a state management system belonging to the family of stream/observable-based patterns.

The main advantage of state management: it helps the developer to separate business logic from the presentation layer. It makes the codebase more clear, reusable and indepenend.

Key pros of BLoC over other state management models:

1. It’s a very popular state management system, and, as a result, there is big amount of live projects and a big dev community who is willing to share their experience.

2. It comes with easy-to-understand and well-detailed documentation. It contains lot’s of examples helpful to kick-start with BLoC.

3. Frequent updates and regular support from the authors.

4. It has the extension for Android Studion and VSCode that speed up the development process

We’re going to expand the topic, by articulating more practical aspects of this technology.

Using Flutter BloC for developing mobile apps: TBR Group’s case study

You can freely find the bitty official documentation and tons of info concerning the topic on the web.

But alongside such a diversity of information, there’s a lack of real case studies and Flutter BLoC examples.

We are going to demonstrate the BLoC pattern in action on the example of a single use case — a Crypto Aggregator mobile app.

Crypto Aggregator is a mobile app designed to browse through cryptocurrencies and market data.

The users can check how the data is changing with the help of the line and pie charts.

The Crypto Aggregator’s settings screen provides its users with a set of features allowing them to switch:

• the fiat currency;
• between the night and day mode;
• the language of the application.

The Crypto Aggregator mobile app: the “Settings” page.

While implementing the BLoC pattern, the first step is to determine the states and events classes.

State implies the output data. Actually, the state class will represent what a user will see on the screen.

Event is the input data for the BLoC. It can act either as a trigger to start loading data. Or it can represent any actions performed by the user, such as pressing a button, a text input, a page scrolling, and so on.

The “state” class describes such finals as status, fiatCurrency, themeType, and error.

The “state” class describes such finals as status, fiatCurrency, themeType, and error.

@immutable
class SettingsState {
 final BlocStatus status;
 final String? fiatCurrency;
 final ThemeType? themeType;
 final Object? error;
 const SettingsState(
   this.status, {
   this.fiatCurrency,
   this.themeType,
   this.error,
 });
}
 
enum ThemeType {
 day,
 night,
}

Respectively:

• status can be in a “Loading”, “Loaded” or “Error” state in order to show the loader, the loaded data, or an error message on the screen.
• fiatCurrency is the currency selected by users from the dialog. The monetary value of the cryptocurrencies is shown according to that parameter.
• themeType is the enum presented with 2 values: “day” and “night”. Changing this parameter updates the dark/light mode of the app.
• error implies the data used to show the error message on the screen. Typically, it is merely a string and in case no errors occur, the field remains null.

As the language change with BLoC is covered by the “easy_localization” package, we have not handled it in the current implementation.

The “event” is shown in the picture below.

@immutable
@freezed
abstract class SettingsEvent with _$SettingsEvent {
 const SettingsEvent._();
 
 const factory SettingsEvent.getFiatCurrency() = GetFiatCurrencyEvent;
 
 const factory SettingsEvent.selectFiatCurrency(String fiatCurrency) =
     SelectFiatCurrencyEvent;
 const factory SettingsEvent.getTheme() = GetThemeEvent;
 
 const factory SettingsEvent.selectTheme(ThemeType themeType) = SelectThemeEvent;
}

The event is built with help of the “freezed” package. There are:

• getFiatCurrency renders an event to load the currently selected currency.
• selectFiatCurrency stands for an event that is called when a user selects a particular currency.
• getTheme indicates an event to load the currently selected theme.
• selectTheme refers to the event called when a user selects a particular theme.

As soon as the event and state are completed, we continue with the Settings BLoC class implementation as displayed on the screenshot.

class SettingsBloc extends Bloc<SettingsEvent, SettingsState> {
 final GetFiatCurrencyUseCase _getFiatCurrencyUseCase;
 final SelectFiatCurrencyUseCase _selectFiatCurrencyUseCase;
 final GetThemeUseCase _getThemeUseCase;
 final SelectThemeUseCase _selectThemeUseCase;

As the project is built with Clean Architecture, BLoC contains four use cases for each action.

 SettingsBloc(this._getFiatCurrencyUseCase, this._selectFiatCurrencyUseCase,
     this._getThemeUseCase, this._selectThemeUseCase)
     : super(
         const SettingsState(
           BlocStatus.Loading,
         ),
       ) {
   on<GetFiatCurrencyEvent>(_getFiatCurrency);
   on<SelectFiatCurrencyEvent>(_selectFiatCurrency);
   on<GetThemeEvent>(_getTheme);
   on<SelectThemeEvent>(_selectTheme);
 }

The BLoC constructor contains the initialization of the use cases and the initial state. The initial state can work as loading, which is the first state the users encounter, and the event handlers, which are extracted in separate methods.

Future<void> _getFiatCurrency(
   GetFiatCurrencyEvent event,
   Emitter<SettingsState> emit,

 ) async {
   emit(_loadingState());
   emit(await _getFiatCurrencyUseCase()
       .then(
         (String fiatCurrency) => SettingsState(
           BlocStatus.Loaded,

           fiatCurrency: fiatCurrency,

           themeType: state.themeType,

         ),

       )
       .catchError(_onError));
 }

Let’s take a look at the callback triggered on the GetFiatCurrency event. Initially, we emit the loading state to show the loader indicator. Just after the data is loaded, the new state appears. It contains the newly loaded fiat currency as well as the current theme type. To handle the errors, we catch them by means of using the _onError method.

Future<void> _selectFiatCurrency(
   SelectFiatCurrencyEvent event,
   Emitter<SettingsState> emit,
 ) async {
   emit(_loadingState());
   emit(await _selectFiatCurrencyUseCase(event.fiatCurrency)
       .then(
         (String fiatCurrency) => SettingsState(
           BlocStatus.Loaded,
           fiatCurrency: event.fiatCurrency,
           themeType: state.themeType,
         ),
       )
       .catchError(_onError));
 }

Now, let’s explore the callback triggered by the SelectFiatCurrency event. The algorithm is mostly the same as the on “_getFiatCurrency” method. The only difference lies in the fact that the fiat currency on the loaded state is received from the event.

SettingsState _loadingState() => SettingsState(BlocStatus.Loading,
     fiatCurrency: state.fiatCurrency, themeType: state.themeType);
 
 Future<SettingsState> _onError(Object error) async => SettingsState(
       BlocStatus.Error,
       fiatCurrency: state.fiatCurrency,
       themeType: state.themeType,
       error: error,
     );

_loadingState and _onError methods help to simply create the error and respectively loading states.

The last step is to integrate the SettingsBloc into the app screen. To meet such a purpose, flutter_bloc provides a particular list of widgets.

The default widget is BlocBuilder. However, we use BlocSelector on this screen, since it allows us to focus on particular fields. Thus, if a user updates the fiat currency, there is no reason to rebuild the Day/Night mode switcher.

At first, comes the BLoC initialization.

 final SettingsBloc settingsBloc = di.sl.get();

 
 @override
 void initState() {
   super.initState();
   settingsBloc.add(const SettingsEvent.getFiatCurrency());
 }

Before the page is built, we need to add SettingsEvent.getFiatCurrency to load the selected fiat currency. In the project, we use get_it for the BLoC dependency injection, but the more usual way is to use BlocProvider.

Next comes the fiat currency switcher.

GestureDetector(
   onTap: () async {
     final String? selectedCurrency =
         await showBottomSheetCurrencySelector(
             context: context);
     if (selectedCurrency != null) {
       settingsBloc.add(
           SettingsEvent.selectFiatCurrency(selectedCurrency));
     }
   },
   child: Row(
     children: <Widget>[
       BlocSelector<SettingsBloc, SettingsState, String>(
         bloc: settingsBloc,
         selector: (SettingsState state) =>
             state.fiatCurrency ?? '-',
         builder: (BuildContext context, String fiatCurrency) {
           return Text(
             fiatCurrency.toString().toUpperCase(),
             style: TextStyles.overlay3Bold14,
           );
         },
       ),
       SizedBox(width: 4.w),
       const ChevronIcon(),
     ],
   ),
 ),

As soon as a user selects the currency from the bottom sheet, we need to send it to the BLoC wrapped with the SettingEvent.selectFiatCurrency event.

On the selector method, we are able to receive the required data. If the string returned from the selector method changes, everything inside the builder method is rebuilt.

And the final is the Day/Night mode switcher.

 BlocSelector<SettingsBloc, SettingsState, ThemeType?>(
   bloc: settingsBloc,
   selector: (SettingsState state) => state.themeType,
   builder: (BuildContext context, ThemeType? themeType) {
     return GestureDetector(
       onTap: () {
         if (themeType == ThemeType.night) {
           settingsBloc.add(
               const SettingsEvent.selectTheme(ThemeType.day));
         } else {
           settingsBloc.add(
               const SettingsEvent.selectTheme(ThemeType.night));
         }
       },
       child: Row(
         mainAxisAlignment: MainAxisAlignment.spaceBetween,
         children: <Widget>[
           Text(
             themeType == ThemeType.night
                 ? 'switch_to_day_mode'.tr()
                 : 'switch_to_night_mode'.tr(),
             style: TextStyles.semiBold14
                 .copyWith(color: Theme.of(context).hintColor),
           ),
           Icon(
             themeType == ThemeType.night
                 ? CupertinoIcons.sun_max
                 : CupertinoIcons.moon,
             color: Theme.of(context).hintColor,
           )
         ],
       ),
     );
   },
 ),

It works in the same simple way as the fiat currency switcher does. On tap, BLoC updates the state with the new themeType that updates the corresponding text and icon.

The following screenshots demonstrate the UI updates. There come selecting fiat currency and updating the color mode.

The Crypto Aggregator mobile app: “Selecting fiat currency” option.

The Crypto Aggregator mobile app: “Updating the color mode” option.

The Crypto Aggregator project is based on Clean Architecture and the BLoC state management. You can check our GitHub repository, where extra details on the topic have been given out.

Flutter cross-platform has proved to be applicable for crafting mobile apps for meeting various purposes.

You can get more insights on this topic from our articles:
The fundamentals of Flutter & Dart, and Why choose Flutter for mobile app development in 2023?

TBR Group has carried out such software implementations as:
VinciLabs — a platform for providing digital medical solutions for healthcare entities;
SwishBOOM and Babymates are child care mobile apps;
pingNpay will describe the digital payment options based on blockchain technology;
Wywroty Śpiewnik — a musical mobile app — will make you privy to the Polish guitar songs’ performance.

A complete list of the designed mobile apps is presented on our Case Study page.

Summary

Operating in the sphere of platform-independent mobile app engineering, TBR Group targets Flutter app development.

Web, iOS, and Android mobile app developers are welcome to get in touch with TBR Group.

Whether you are an experienced engineer, a junior coder, or an enterprise willing to establish your presence online — feel free to contact TBR Group and articulate any concept directly with the development team.