DEV Community: Elian Ortega

🔁 asdf Flutter version manager (MacOS/ Linux)

Elian Ortega — Fri, 08 Oct 2021 21:47:07 +0000

Without a doubt, Flutter is a framework that is constantly changing. And as developers, we need to be ready and have more than one version installed at the same time.

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

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

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

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

How to use asdf with flutter?

Official docs: here

Install asdf



# MacOS with Homebrew
brew install asdf

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

ASDF Flutter plugin

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



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

Github Repo: asdf flutter plugin

install/uninstall a version



# List all available flutter versions
asdf list all flutter

Preview:



# Install a version 
asdf install flutter <VERSION_NUMBER>

# Example:
asdf install flutter 2.5.2-stable

# to uninstall
asdf uninstall flutter <VERSION_NUMBER>

Local and global version



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

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

Export to $PATH

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



export PATH="$(asdf where flutter)/bin":"$PATH"

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

... and dart?

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



# Install asdf-dart

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

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

As always...

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

There's a Spanish version of this article on Medium. You're welcome. 🇪🇸

Also, if you liked this content, you can find even more and keep in contact with me on my socials:

dev.to - where you're reading this article.
GitHub - where are my code repositories in case you like the examples.
GitHub NoScope - donde están los repositorios de código en conjunto del canal de YouTube y directos de Twitch con Marcos.
LinkedIn - where I connect professionally.
Twitter - where I express my short thoughts and share my content.
Twitch - where I do informal live shows from which I take clips with specific information.
YouTube - where I publish the clips that come out of my lives.

🇪🇸 Versión en español de este articulo aquí

How to start using Riverpod, StateNotifier and Freezed in your Flutter applications.

Elian Ortega — Wed, 14 Apr 2021 15:55:27 +0000

How to use the 3 tools together to manage the state of your application.

Haz clic aquí para la versión en español

More and more we hear of Riverpod as the new state management solution in Flutter. The big problem is that people trying to use it do not even know where to start.

In this article I am going to focus on how a project can be structured using Riverpod,StateNotifer and Freezed together to create the complete flow of state management.

What are we going to build?

We are going to build a jokes application, it's going to use the Jokes API to get a new programming joke and then show it in the screen. The result will look something like this:

Basics

I could make an explanation of each of these tools, but there is no need to reinvent the wheel. My friend Marcos Sevilla has some excellent articles explaining these tools.

Riverpod article
- A tool that allows us to inject dependencies and encapsulate a state and then listen to this state.
StateNotifier article
- It is a “re-implementation” of ValueNotifier, with the difference that it does not depend on Flutter.
Freezed article
- It is a code generator for immutable classes.

Now that you know what each of these tools are and how they work, let's see how we can use them together as a state management solution.

⚠️ Before continuing it is important that you know the basics concepts of the tools so read the documentation!

Now let's get started!

Folder Structure

In order to maintain a clean code base, the folder structure is key, so let's start with the idea of separating our application by features. If you have used flutter_bloc, you have seen that it is very common to create a bloc folder with its respective states, events and a views folder for the UI part of our feature, something like this:

Carpeta generada con la extensión de VS Code de bloc v5.6.0

As you can see we have a feature called jokes in this you will find the logic and views of the jokes app. This structure may be familiar to many who have already used flutter_bloc.

But before looking at the code let's see the structure we want to achieve using Riverpod, StateNotifier and Freezed:

You can see that it is a very similar structure to the one proposed by flutter_bloc. But in this case, because of how riverpod works we have the following files:

jokes_state.dart
- This file is where we define the possible states that the StateNotifier can emit. Commonly they are: initial, loading, data and error.
jokes_state.freezed.dart
- This is a file that is generated with all the information of the classes that we define in jokes_state.dart, we shouldn't worry that much about its content, since it is generated code.
jokes_state_notifier.dart
- This file contains the definition of the JokesNotifier, which is an implementation of StateNotifier. This will be the core of our state management, since in this class is where we define the methods that will be in charge of changing and emitting the new states when necessary.
jokes_provider.dart
- This file is where we define the different types of Providers that we are going to use in this feature. In this case we will need 2, the first is a common Provider for the repository from where we will obtain a new joke and the second a StateNotifierProvider that is a special provider for StateNotifiers objects. Or in other words, we could say that this file is where the feature's dependency injection is done.

But with this last point, what happens if we have 2 different features that use the same provider?

Very simple, we can create a file where we are going to define global providers that may be used by several features at the same time. Something like this:

And if you've already read the documentation, you know it, but just in case I remind you that combining providers with riverpod is very simple.

For example, let's imagine the scenario of a store where we define a Provider for the payment methods (PaymentMethods) and another provider for the Checkout, in this case the Checkout provider needs the PaymentMethods provider to be able to work and thanks to the ProviderReference parameter available when creating a new provider with riverpod, creating the relationship It is very simple:



///PaymentMethods Provider
final _paymentMethodsProvider = Provider<PaymentMethods>(
  (ProviderReference _) => PaymentMethods(),
);

///CheckOut Provider
final checkoutProvider = Provider<Checkout>(
  (ProviderReference ref) => Checkout(
    paymentMethodsProvider: ref.watch(_paymentMethodsProvider),
  ),
);

📖 If you still do not understand this last part very well, I recommend you reading the articles of the tools that I left at the beginning, here.

Let's see the code 🔥

Project setup

You may laugh at this step, but you would be amazed at how many times it is forgotten. To use riverpod you have to add a ProviderScope widget as the root of our application, this allows the communication of providers and is required to use riverpod.



///main.dart
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:riverpod_jokes_basic/src/app.dart';

void main() {
  runApp(
    ProviderScope(
      child: RiverpodJokesApp(),
    ),
  );
}

Personally, I like to separate the main.dart from the rest of the application and create an app.dart file that contains the root of the application and any extra configuration that is needed.



///app.dart

import 'package:flutter/material.dart';
import 'package:riverpod_jokes_basic/src/features/jokes/views/jokes_page.dart';

class RiverpodJokesApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: JokesPage(),
    );
  }
}

And just like that, we are ready to start using riverpod. Remember to include the dependencies in the pubspec.yaml file*,* as of the moment I write this article they are:



# pubspec.yaml

name: riverpod_jokes_basic
description: A new Flutter project.

publish_to: 'none'

version: 1.0.0+1

environment:
  sdk: ">=2.12.0 <3.0.0"

dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.2
  dio: ^4.0.0
  equatable: ^2.0.0
  flutter_riverpod: ^0.14.0+1
  freezed_annotation: ^0.14.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  build_runner: ^1.12.2
  freezed: ^0.14.1+2
  json_serializable: ^4.1.0

flutter:

  uses-material-design: true

Models

Before we can code the logic side of the application, we need to create the models that represent the objects from the API. In this case, we are going to be guided by the documentation provided by Jokes API, where they tell us that the response format looks like this:



/// JOKES API Response
{
    "error": false,
    "category": "Programming",
    "type": "twopart",
    "setup": "How many programmers does it take to screw in a light bulb?",
    "delivery": "None. It's a hardware problem.",
    "flags": {
        "nsfw": false,
        "religious": false,
        "political": false,
        "racist": false,
        "sexist": false,
        "explicit": false
    },
    "id": 1,
    "safe": true,
    "lang": "en"
}

Just by looking at the response format, we can identify the 2 models that we are going to use. The first one is a model for the possible flags of the joke, we will call it FlagsModel and another model for the whole joke that we will call JokesModel.

These objects use equatable and json_serializable to generate the fromJson() and toJson() methods.



// flags_model.dart

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

part 'flags_model.g.dart';

@JsonSerializable()
class FlagsModel extends Equatable {
  FlagsModel({
    this.explicit,
    this.nsfw,
    this.political,
    this.racist,
    this.religious,
    this.sexist,
  });

  //Json Serializable
  factory FlagsModel.fromJson(Map<String, dynamic> json) =>
      _$FlagsModelFromJson(json);

  Map<String, dynamic> toJson() => _$FlagsModelToJson(this);

  final bool? explicit;
  final bool? nsfw;
  final bool? political;
  final bool? racist;
  final bool? religious;
  final bool? sexist;

  @override
  List<Object?> get props => [
        explicit,
        nsfw,
        political,
        racist,
        religious,
        sexist,
      ];
}



// jokes_model.dart

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

import './flags_model.dart';

part 'joke_model.g.dart';

@JsonSerializable()
class JokeModel extends Equatable {
  JokeModel({
    required this.safe,
    this.category,
    this.delivery,
    this.flags,
    this.id,
    this.lang,
    this.setup,
    this.type,
  });

  //Json Serializable
  factory JokeModel.fromJson(Map<String, dynamic> json) =>
      _$JokeModelFromJson(json);

  Map<String, dynamic> toJson() => _$JokeModelToJson(this);

  final String? category;
  final String? delivery;
  final FlagsModel? flags;
  final int? id;
  final String? lang;
  final bool safe;
  final String? setup;
  final String? type;

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

Once these 2 classes are created, it is necessary to run the build_runner commands since json_serializable must generate the parsing methods of the classes.

We run the following commands:



# When the project depends on Flutter

flutter pub run build_runner build

# In project is pure dart

pub run build_runner build

With this all syntax errors should disappear, and we can get to the next step.

Repository

On this occasion I am not going to focus much on this step or any clean architecture layer/component, since it is not the main goal. If you want to see more examples or documentation of clean architecture and its components you can check my networks where I have other articles, code repositories and videos talking about these concepts.

The reason for creating the repository with an interface, of course good coding practices, but also that you can see how the dependency injection with interfaces can be done when we create the providers.

The jokes_repository.dart contains the IJokesRepository interface and JokesRepository which is the implementation. These only have a Future<JokeModel> getJoke(); method that makes an API call to get a new joke. If the response is successful it returns the joke, otherwise an exception is thrown.



/// jokes_repository.dart

import 'package:dio/dio.dart';
import 'package:riverpod_jokes_basic/src/features/jokes/data/models/joke_model.dart';

abstract class IJokesRepository {
  Future<JokeModel> getJoke();
}

class JokesRepository implements IJokesRepository {
  final _dioClient = Dio();
  final url = 'https://v2.jokeapi.dev/joke/Programming?type=twopart';

  @override
  Future<JokeModel> getJoke() async {
    try {
      final result = await _dioClient.get(url);
      if (result.statusCode == 200) {
        return JokeModel.fromJson(result.data);
      } else {
        throw Exception();
      }
    } catch (_) {
      throw Exception();
    }
  }
}

States using Freezed

In this case, our feature of generating random numbers is not very complex, the objective is to simulate the call to an API, and react to the different states in the UI. So, we are going to have 4 states: initial, loading (loading), data when we already have the new joke and error to give feedback to the user about what is happening.



/// jokes_state.dart

import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:riverpod_jokes_basic/src/features/jokes/data/models/joke_model.dart';

part 'jokes_state.freezed.dart';

///Extension Method for easy comparison
extension JokesGetters on JokesState {
  bool get isLoading => this is _JokesStateLoading;
}

@freezed
abstract class JokesState with _$JokesState {
  ///Initial
  const factory JokesState.initial() = _JokesStateInitial;

  ///Loading
  const factory JokesState.loading() = _JokesStateLoading;

  ///Data
  const factory JokesState.data({required JokeModel joke}) = _JokesStateData;

  ///Error
  const factory JokesState.error([String? error]) = _JokesStateError;
}

Also, we added an extension method to simplify the comparison made to know if the current state is loading.

Once we have defined the structure of the states with the respective Freezed annotations, we must run a command to create the jokes_state.freezed.dart file with generated code.

In the terminal:



# In this case our project depend on flutter
# so we run

flutter pub run build_runner build

# If the project was pure dart we run

pub run build_runner build

With this the new file will be generated resolving the syntax error from the states file.

⚠️ The jokes_state.freezed.dart code is generated so don't be stressed or intimidated if you don't understand it, it shouldn't be modified.

Implementing the StateNotifier

As I mentioned earlier, this is the core of our state management.

In this class is where we will make the calls to the repository, and we will assign the states so that they are notified to the components in the UI.



/// jokes_state_notifier.dart

part of 'jokes_provider.dart';

class JokesNotifier extends StateNotifier<JokesState> {
  JokesNotifier({
    required IJokesRepository jokesRepository,
  })   : _jokesRepository = jokesRepository,
        super(const JokesState.initial());

  final IJokesRepository _jokesRepository;

  Future<void> getJoke() async {
    state = const JokesState.loading();

    try {
      final joke = await _jokesRepository.getJoke();
      state = JokesState.data(joke: joke);
    } catch (_) {
      state = JokesState.error('Error!');
    }
  }
}

You can see that the first thing we do is in the super() method of the class we assign the first state to JokesState.initial(). Then, we only have a getJoke() method that makes a call to the repository within a try {} catch {} because as we saw previously, in some scenarios we are going to throw an exception. Based on this we will assign the new state to either state = JokesState.data(joke: joke); when the API call is successfull or state = JokesState.error('Error!'); when an exception is thrown and caught by the catch().

Exposing providers and injecting dependencies

Up to this point we have already created all the necessary components for the application logic to work. Now we must create 2 providers, first the Providers that inject the dependencies in this case of the JokesRepository with their respective interface and second the Provider that expose the StateNotifier in this case a StateNotifierProvider that exposes the JokesNotifier so that we can react to changes in states in the UI.



/// jokes_provider.dart

import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:riverpod_jokes_basic/src/features/jokes/data/repositories/jokes_repository.dart';
import 'jokes_state.dart';
export 'jokes_state.dart';

part 'jokes_state_notifier.dart';

///Dependency Injection

//* Logic / StateNotifier
final jokesNotifierProvider = StateNotifierProvider<JokesNotifier, JokesState>(
  (ref) => JokesNotifier(
    jokesRepository: ref.watch(_jokesRepositoryProvider),
  ),
);

//* Repository
final _jokesRepositoryProvider = Provider<IJokesRepository>(
  (ref) => JokesRepository(),
);

You can see that as I showed you previously in the PaymentMethods/Checkout example, combining the providers is very simple, in this case we use the ProviderReference (ref) to inject the dependency that the JokesNotifier has of the repository.

Some might wonder why I declare _jokesRepositoryProvider as a private variable? This is simply for good practices, with this you avoid making the mistake of making calls directly to the repository from the UI.

With this we have concluded the implementation of all the necessary logic components for this application. Now we only have to implement the UI and react to the states.

Reacting to states in the UI

In this case, to simplify the example we only have one page in the UI. But before, I show you the code I want to emphasize 2 important points.

Obviously remember to read the documentation, but just to remind you:

How to call a method on the StateNotifierProvider

If you only want to call one method, in this case we need to call the getJoke() method of the StateNotifier:



/// To call a method 
context.read(providerVariable.notifier).methodToCall();

/// In our case to call the state notifier
context.read(jokesNotifierProvider.notifier).getJoke();

How to listen to changes in states

If you want to listen to the state changes emitted by a StateNotifier there are different ways, but the simplest is to use a ConsumerWidget this gives us access to a property called watch of type ScopedReader with this we can listen to the different state changes of the wanted provider.



/// Using a ConsumerWidget
class NewWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, ScopedReader watch) {
    final state = watch(randomNumberNotifierProvider);
    return ///Here you can do whatever you want with the state
  }
}

In our case it is even simpler because when we use freezed to create states we have access to the when () method, this allows us to react to each of the states more easily avoiding the problem of many if - else conditions in the code .

For this implementation we could have something like this:



class _JokeConsumer extends ConsumerWidget {
  @override
  Widget build(BuildContext context, ScopedReader watch) {
    final state = watch(jokesNotifierProvider);

    return state.when(
      initial: () => Text('Press the button to start'),
      loading: () => Center(child: CircularProgressIndicator()),
      data: (joke) => Text('${joke.setup}\n${joke.delivery}'),
      error: (error) => Text('Error Occured!'),
    );
  }
}

This ConsumerWidget return a different widget for each of the different states.

With this we are ready to create the page for our application:



/// jokes_page.dart

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:riverpod_jokes_basic/src/features/jokes/logic/jokes_provider.dart';

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

  ///JokesPage [routeName]
  static const routeName = 'JokesPage';

  ///Router for JokesPage
  static Route route() {
    return MaterialPageRoute<void>(builder: (_) => const JokesPage());
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Riverpod Jokes'),
      ),
      body: Padding(
        padding: EdgeInsets.symmetric(horizontal: 20.0),
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          crossAxisAlignment: CrossAxisAlignment.stretch,
          children: [
            _JokeConsumer(),
            const SizedBox(height: 50),
            _ButtonConsumer(),
          ],
        ),
      ),
    );
  }
}

class _JokeConsumer extends ConsumerWidget {
  @override
  Widget build(BuildContext context, ScopedReader watch) {
    final state = watch(jokesNotifierProvider);

    return state.when(
      initial: () => Text(
        'Press the button to start',
        textAlign: TextAlign.center,
      ),
      loading: () => Center(
        child: CircularProgressIndicator(),
      ),
      data: (joke) => Text('${joke.setup}\n${joke.delivery}'),
      error: (error) => Text('Error Occured!'),
    );
  }
}

class _ButtonConsumer extends ConsumerWidget {
  @override
  Widget build(BuildContext context, ScopedReader watch) {
    final state = watch(jokesNotifierProvider);
    return ElevatedButton(
      child: Text('Press me to get a joke'),
      onPressed: !state.isLoading
          ? () {
              context.read(jokesNotifierProvider.notifier).getJoke();
            }
          : null,
    );
  }
}

And this would be the result:

It's not the prettiest UI in the world, but that wasn't the goal, it was learning how to use riverpod, freezed, and statenotifier together as a state manager.

This is a fairly basic example if you want to see an example with a complete clean architecture setup I leave you these links:

Jokes application created with riverpod following clean architecture principles

App with COVID 19 API and minimal architecture

Qr generator application with testing flutter_bloc and riverpod implementations + clean architecture

For the future I plan to share an article on how to do the testing and other things.

As always...

Thanks to my friend Marcos Sevilla for this outro 😂, he also shares great content so here is his Twitter if you want to stay tuned of the content.

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

There's a Spanish version of this article on Medium. Click here. You're welcome. 🇪🇸

Also, if you liked this content, you can find even more and keep in contact with me on my socials:

dev.to - where you're reading this article.
GitHub - where are my code repositories in case you like the examples.
GitHub NoScope - where you can find the code repositories used in the YouTube and Twitch channels.
LinkedIn - where I connect professionally.
Medium - where I publish my Spanish articles.
Twitter - where I express my short thoughts and share my content.
Twitch - where I do informal live shows from which I take clips with specific information.
YouTube - where I publish the clips that come out of my lives.

Cleaner Flutter Vol. 5: Establishing Use Cases

Elian Ortega — Sun, 31 Jan 2021 17:18:38 +0000

Before starting: Previous Volume Cleaner Flutter Vol. 4: Hiring Repositories

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

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

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

Remember that all software products should first go through a process where their requirements and the interactions of a user with the software product are defined, whether this is a login,add an object to a shopping cart, or process a payment.

Ok, let's get into it.

What are use cases?

In uncle Bobs words ...

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

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

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

From: https://warren2lynch.medium.com/use-case-tutorial-for-dummies-8cf426043710

In this we have objects like:

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

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

If you want to read more into these diagrams and their components, here is an article for you*: Use cases for dummies.*

In the code…

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

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

The principles (SOLID)...

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

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

Implementation in Dart

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

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

We get something like this:

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

Let's put the pieces together

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

The code is simplified to facilitate the example. I also remind you that in order to understand the examples it is important that you have read the previous articles. I leave the previous one: Vol 4: Contratando Repositorios.

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

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

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

Note that it does not matter who wins the endless battle of which is the best state manager, since it does not matter which one we select, or if we even decide to change, this does not affect our implementation at all.

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

As always ...

If you learned something new, remember to leave your feedback and share with your fellow developers friends so that we continue to improve as a community and develop quality applications using Flutter.

For any questions and more content you can contact me through my social media:

GitHub, LinkedIn, Twitter, YouTube.

Cleaner Flutter Vol. 2: SOLID Principles

Elian Ortega — Sun, 17 Jan 2021 15:02:01 +0000

💡 Recommendation: Return to this article as many times as necessary to clarify the following volumes, as there are concepts that complement these.

Previous Volume: Cleaner Flutter Vol. 1: Intro to CLEAN

Next Volume: Cleaner Flutter Vol. 3: Dominating Entities

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

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

Having to search among many files for the answer to what we are looking for.
Not understanding the code we wrote.
Not understanding the code we write.

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

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

What is SOLID?

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

In other words ...

Write more code without damaging what already works.

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

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

Before continuing it is important to note that these were first introduced by Uncle Bob, I leave you a link in case you want to see his explanation: SOLID Principles Uncle Bob.

S: Single Responsibility Principle

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

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

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

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

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

Let's see an example:

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

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

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

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

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

To follow the Single Responsibility Principle correctly, we could create methods and classes with simple and unique functionalities.

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

The validation

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

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

Here is the link to formz in pub.dev.

The connection to the data source

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

This repository concept is key to meeting the Clean Architecture standards but we can see that the principle of Single Responsibility is behind this whole idea.

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

Simpler, more maintainable and decoupled.

O: Opened/Closed Principle

An entity must be open to extend, but closed to modify.

Este principio nos dice, en resumen, que debemos extender de la entidad para agregar nuevo código en vez de modificar el existente.

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

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

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

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

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

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

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

Each new payment method implies a new function and a new else if in thepay ()method and we could say that this is not a problem, but if we keep adding code within the same class, we would never achieve a stable, ready for production code.

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

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

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

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

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

L: Liskov Substitution Principle

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

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

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

Implementation
Abstraction

The first we can see in the previous example of Open / Closed Principle when we have PayableInterface and the payment methods that implements it asCardPayment and PaypalPayment.

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

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

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

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

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

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

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

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

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

I: Interface Segregation Principle

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

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

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

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

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

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

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

We have an abstract class Animal that is our interface, it has 3 methods defined eat (),sleep (), andfly ().

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

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

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

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

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

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

🔥 Almost there! Last SOLID principle ...

D: Dependency Inversion Principle

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

In my opinion, this should be the first principle that every developer should understand.

This principle tells us:

You never have to depend on a concrete implementation of a class, only on its abstractions (interfaces).
Same as the image presented in Volume 1 of this series of A Cleaner Flutter we follow the rule that modules High-level modules should not strictly rely on low-level modules.

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

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

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

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

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

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

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

And this, ladies and gentlemen, is what allows us to fulfill the magic word of Clean Architecture: Decoupling!

Wrap up ...

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

I hope now you have a better idea of what the SOLID principles are and how to apply them. For any questions or comments you can contact me through my social media accounts and if you learned something do not hesitate to share it with your fellow developers and friends, so that as a community we continue to improve and develop high quality and scalable projects.

Also, if you liked this content, you can find even more and keep in touch with me on my social networks:

GitHub, LinkedIn, Twitter, YouTube.