DEV Community: Biplab Dutta 🇳🇵📱🧑‍💻

A deep dive into unit testing in Flutter 🧪

Biplab Dutta 🇳🇵📱🧑‍💻 — Sat, 20 Aug 2022 03:39:11 +0000

Testing code is an important task for a developer that helps us in ensuring that our code works as expected. Testing is an important task that should not be given the least priority or be neglected. Many companies seeking for a software developer candidate look for those who can perform testing effectively. Many open-source projects don't prefer to merge contributions for which tests are not included. So, it is clear that testing is a must-have skill for a developer and in this blog, we will go in depth about unit testing in Flutter. 😎
Testing doesn't help in locating bugs. It only helps in making sure that our code works as expected. It gives us the confidence that our code works even after refactoring the codebase.
In Flutter, there are mainly three types of test but not limiting to. They are:

In this article, we will see what unit testing is and how we can perform unit testing with some examples.

NOTE
I am publishing all of my blogs on my own blogging site. You can read this blog on my site by visiting this link.
https://biplabdutta.com.np/posts/unit-test/

An info on my upcoming blogs

Biplab Dutta 🇳🇵📱🧑‍💻 — Thu, 18 Aug 2022 03:36:00 +0000

Hi all. 👋
I have been writing blogs ✍️ for sometime now and I've decided 🤔 to use my own blogging site to host my blogs. I hope the community would be supportive enough to visit my site. 🤗
I will keep uploading posts with their title and links to my blogging site here on Dev though. 👀
I've already migrated my existing blogs on my site. You can check the site my visiting this link. 👇️
https://biplabdutta.com.np/

Theme Switching & Persisting in Flutter using cubits and Stream

Biplab Dutta 🇳🇵📱🧑‍💻 — Wed, 08 Jun 2022 12:04:36 +0000

Every mobile app user prefers having an option to choose between multiple themes. Having decent themes available is also very crucial in enhancing the user experience. So, how can we do it effectively in Flutter? How can we have different configs set for each theme? This article ensures that you get a proper understanding of it and I’ll also talk a bit regarding Stream in Dart.

Demo

Let’s take a look at our final app.

As we can see in the GIF, our app allows us to switch between dark theme and light theme. Also, the icon on the floating action button changes dynamically. And the chosen theme is persisted which can be witnessed in every app launch.

Dependencies

Before we begin working on the code, let’s first include some external packages that we will need. Include flutter_bloc, shared_preferences, and equatable as your dependencies in pubspec.yaml file.

Let’s Code 👨‍💻

Since this is a very simple app, I won’t be concerned about app architecture in this article. You can check my other articles if you want to learn about app architecture.

Theme Configurations

First, start a new flutter project and get rid of the default counter app. Then inside the lib folder, create a file app_theme.dart.



import 'package:flutter/material.dart';

abstract class AppTheme {
  static ThemeData get lightTheme => ThemeData(
        scaffoldBackgroundColor: Colors.white,
        textTheme: ThemeData.light().textTheme.copyWith(
              bodyText1: const TextStyle(
                fontSize: 25,
                color: Colors.black,
              ),
              caption: const TextStyle(
                fontStyle: FontStyle.italic,
                fontSize: 15,
                color: Colors.black,
              ),
            ),
      );

  static ThemeData get darkTheme => ThemeData(
        scaffoldBackgroundColor: Colors.blueGrey.shade800,
        textTheme: ThemeData.dark().textTheme.copyWith(
              bodyText1: const TextStyle(
                fontSize: 25,
                color: Colors.white,
              ),
              caption: const TextStyle(
                fontStyle: FontStyle.italic,
                fontSize: 15,
                color: Colors.white,
              ),
            ),
      );
}

Data Layer/Theme Repository

Then create a theme_repository.dart file inside the lib directory and paste the following code.



import 'package:shared_preferences/shared_preferences.dart';

abstract class ThemePersistence {
  Stream<CustomTheme> getTheme();
  Future<void> saveTheme(CustomTheme theme);
  void dispose();
}

enum CustomTheme { light, dark }

class ThemeRepository implements ThemePersistence {
  ThemeRepository({
    required SharedPreferences sharedPreferences,
  }) : _sharedPreferences = sharedPreferences;

  final SharedPreferences _sharedPreferences;

  @override
  Stream<CustomTheme> getTheme() {}

  @override
  Future<void> saveTheme(CustomTheme theme) {}

  @override
  void dispose() {}
}

As you can see, we created an abstract class ThemePersistence, and another class ThemeRepository that implements the abstract class. Also, we created an enum CustomTheme that has two values — light and dark because these are the themes that our app will have. The ThemeRepository class depends on the SharedPreferences instance that we will use for theme persistence.

Also, we can see that getTheme() returns a Stream and not a Future. The main reason behind using Stream is that listeners of this Stream can immediately be notified of the theme change and we needn’t call the getTheme() method again and again.

If we had a Future implementation for getTheme(), after every theme update, we’d have to invoke the getTheme() method which is not ideal.

getTheme() is a one-time delivery of data meaning that it should be called only once and any changes should be yielded in the form of a stream which the listeners will listen to.

Now, we will add code to our getTheme() and saveTheme() methods.



import 'package:shared_preferences/shared_preferences.dart';

abstract class ThemePersistence {
  Stream<CustomTheme> getTheme();
  Future<void> saveTheme(CustomTheme theme);
  void dispose();
}

enum CustomTheme { light, dark }

class ThemeRepository implements ThemePersistence {
  ThemeRepository({
    required SharedPreferences sharedPreferences,
  }) : _sharedPreferences = sharedPreferences;

  final SharedPreferences _sharedPreferences;

  static const _kThemePersistenceKey = '__theme_persistence_key__';

  final _controller = StreamController<CustomTheme>();

  Future<void> _setValue(String key, String value) =>
      _sharedPreferences.setString(key, value);

  @override
  Stream<CustomTheme> getTheme() => _controller.stream;

  @override
  Future<void> saveTheme(CustomTheme theme) {
    _controller.add(theme);
    return _setValue(_kThemePersistenceKey, theme.name);
  }

  @override
  void dispose() => _controller.close();
}

We initialized a StreamController which will act as a manager for our Stream<CustomTheme>. The saveTheme() method is straightforward. First, it adds the theme that we want to save to the stream and then calls _setValue() which will persist the theme. The _setValue() method uses API from SharedPreferences to persist the chosen theme.

Everything looks fine. But if you see it carefully, the method getTheme() yields the stream from the controller. But initially, as the app is launched, there would be no stream in the controller. Then how do we deal with it?

The solution is simple. We can add a constructor body that would be executed as soon as the ThemeRepository class is instantiated. Also, getTheme() is a method that would be called in the very early stage. So, we need to make sure that before the getTheme() method is called, there is some stream value in the controller. So, add a _init() method in the constructor body and instantiate the ThemeRepository in the main.dart file later. Then, the final version of our theme_repository.dart file would look like this:



import 'dart:async';

import 'package:shared_preferences/shared_preferences.dart';

abstract class ThemePersistence {
  Stream<CustomTheme> getTheme();
  Future<void> saveTheme(CustomTheme theme);
  void dispose();
}

enum CustomTheme { light, dark }

class ThemeRepository implements ThemePersistence {
  ThemeRepository({
    required SharedPreferences sharedPreferences,
  }) : _sharedPreferences = sharedPreferences {
    _init();
  }

  final SharedPreferences _sharedPreferences;

  static const _kThemePersistenceKey = '__theme_persistence_key__';

  final _controller = StreamController<CustomTheme>();

  String? _getValue(String key) {
    try {
      return _sharedPreferences.getString(key);
    } catch (_) {
      return null;
    }
  }

  Future<void> _setValue(String key, String value) =>
      _sharedPreferences.setString(key, value);

  void _init() {
    final themeString = _getValue(_kThemePersistenceKey);
    if (themeString != null) {
      if (themeString == CustomTheme.light.name) {
        _controller.add(CustomTheme.light);
      } else {
        _controller.add(CustomTheme.dark);
      }
    } else {
      _controller.add(CustomTheme.light);
    }
  }

  @override
  Stream<CustomTheme> getTheme() async* {
    yield* _controller.stream;
  }

  @override
  Future<void> saveTheme(CustomTheme theme) {
    _controller.add(theme);
    return _setValue(_kThemePersistenceKey, theme.name);
  }

  @override
  void dispose() => _controller.close();
}

Also, you may have noticed I used a CustomTheme enum that I created in this file instead of using ThemeMode which is available in Flutter. The reason is simply to avoid including the material package in the data layer of our project as ThemeMode comes from the material package. In my opinion, the components of the material package are associated with the presentation layer and not the data layer.

Cubits/ViewModel/State Management

Now, we will create a ThemeCubit and ThemeClass class that will be responsible for our state handling. Create a folder in the lib directory and name it them_cubit. Inside theme_cubit, create two dart files — theme_cubit.dart and theme_state.dart.

theme_state.dart



part of 'theme_cubit.dart';

class ThemeState extends Equatable {
  const ThemeState({this.themeMode = ThemeMode.light}); // Default theme = light theme

  final ThemeMode themeMode;

  // `copyWith()` method allows us to emit brand new instance of ThemeState
  ThemeState copyWith({ThemeMode? themeMode}) => ThemeState(
        themeMode: themeMode ?? this.themeMode,
      );

  @override
  List<Object?> get props => [themeMode];
}

theme_cubit.dart



import 'dart:async';

import 'package:equatable/equatable.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'package:theme_switching_demo/theme_repository.dart';

part 'theme_state.dart';

class ThemeCubit extends Cubit<ThemeState> {
  ThemeCubit({
    required ThemePersistence themeRepository,
  })  : _themeRepository = themeRepository,
        super(const ThemeState());

  final ThemePersistence _themeRepository;
  late StreamSubscription<CustomTheme> _themeSubscription;
  static late bool _isDarkTheme;  // used to determine if the current theme is dark

  void getCurrentTheme() {
    // Since `getTheme()` returns a stream, we listen to the output
    _themeSubscription = _themeRepository.getTheme().listen(
      (customTheme) {
        if (customTheme.name == CustomTheme.light.name) {
          // Since, `customTheme` is light, we set `_isDarkTheme` to false
          _isDarkTheme = false;
          emit(state.copyWith(themeMode: ThemeMode.light));
        } else {
          // Since, `customTheme` is dark, we set `_isDarkTheme` to true
          _isDarkTheme = true;
          emit(state.copyWith(themeMode: ThemeMode.dark));
        }
      },
    );
  }

  void switchTheme() {
    if (_isDarkTheme) {
      // Since, currentTheme is dark, after switching we want light theme to
      // be persisted.
      _themeRepository.saveTheme(CustomTheme.light);
    } else {
      // Since, currentTheme is light, after switching we want dark theme to
      // be persisted.
      _themeRepository.saveTheme(CustomTheme.dark);
    }
  }

  @override
  Future<void> close() {
    _themeSubscription.cancel();
    _themeRepository.dispose();
    return super.close();
  }
}

The code is self-explanatory and I have added all the necessary explanations through comments in the above code. Be sure to go through them.

main.dart

Let’s add some code to the main.dart file.



import 'package:flutter/material.dart';

import 'package:shared_preferences/shared_preferences.dart';

import 'package:theme_switching_demo/app.dart';

import 'package:theme_switching_demo/theme_repository.dart';

Future<void> main() async {

  // required when using any plugin. In our case, it's shared_preferences

  WidgetsFlutterBinding.ensureInitialized();

// Creating an instance of ThemeRepository that will invoke the _init() method

  // and populate the stream controller in the repository.

  final themeRepository = ThemeRepository(

    sharedPreferences: await SharedPreferences.getInstance(),

  );

runApp(App(themeRepository: themeRepository));

}

App Widget

Next, create a app.dart file in the lib directory and paste the following code.



import 'package:flutter/material.dart';

import 'package:flutter_bloc/flutter_bloc.dart';

import 'package:theme_switching_demo/home_page.dart';

import 'package:theme_switching_demo/theme_cubit/theme_cubit.dart';

import 'package:theme_switching_demo/theme_repository.dart';

import 'package:theme_switching_demo/themes.dart';

class App extends StatelessWidget {

  const App({required this.themeRepository, super.key});

final ThemeRepository themeRepository;

@override

  Widget build(BuildContext context) {

    return RepositoryProvider.value(

      value: themeRepository,

      child: BlocProvider(

        create: (context) => ThemeCubit(

          themeRepository: context.read<ThemeRepository>(),

        )..getCurrentTheme(),

        child: const AppView(),

      ),

    );

  }

}

class AppView extends StatelessWidget {

  const AppView({super.key});

@override

  Widget build(BuildContext context) {

    return BlocBuilder<ThemeCubit, ThemeState>(

      builder: (context, state) {

        return MaterialApp(

          debugShowCheckedModeBanner: false,

          title: 'Flutter Demo',

          theme: AppTheme.lightTheme, // If ThemeMode is ThemeMode.light, this is selected as app's theme

          darkTheme: AppTheme.darkTheme, // If ThemeMode is ThemeMode.dark, this is selected as app's theme

      <span class="c1">// The themeMode is the most important property in showing</span>
      <span class="c1">// proper theme. The value comes from ThemeState class.</span>
      <span class="nl">themeMode:</span> <span class="n">state</span><span class="o">.</span><span class="na">themeMode</span><span class="p">,</span>
      <span class="nl">home:</span> <span class="kd">const</span> <span class="n">HomePage</span><span class="p">(),</span>
    <span class="p">);</span>
  <span class="p">},</span>
<span class="p">);</span>



}

}

HomePage

Create a file home_page.dart and add the following code.



import 'package:flutter/material.dart';

import 'package:flutter_bloc/flutter_bloc.dart';

import 'package:theme_switching_demo/theme_cubit/theme_cubit.dart';

class HomePage extends StatelessWidget {

  const HomePage({super.key});

@override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: const Text('Theme Switching Demo'),

      ),

      body: Center(

        child: Column(

          mainAxisAlignment: MainAxisAlignment.center,

          children: [

            Text(

              'Follow me on my socials',

              style: Theme.of(context).textTheme.bodyText1,

              // Depending on the current theme, the text is also rendered properly

              // If the theme is dark, text is white in color else black

            ),

            const SizedBox(height: 10),

            Text(

              'https://github.com/Biplab-Dutta',

              style: Theme.of(context).textTheme.caption,

            ),

            const SizedBox(height: 10),

            Text(

              'https://twitter.com/b_plab98',

              style: Theme.of(context).textTheme.caption,

            ),

          ],

        ),

      ),

      floatingActionButton: FloatingActionButton(

        onPressed: () => context.read<ThemeCubit>().switchTheme(),

        tooltip: 'Switch Theme',

        child: context.read<ThemeCubit>().state.themeMode == ThemeMode.light

            ? const Icon(Icons.dark_mode)

            : const Icon(Icons.light_mode),

      ),

    );

  }

}

Conclusion

This article showed how we can include theme switching and persisting feature in our Flutter app using the best practices. I hope you all got to learn from my article and if there’s any feedback for me, drop a comment. I’ll be sure to upload another article in a few days again.

If you wish to see some Flutter projects with proper architecture, follow me on GitHub. I am also active on Twitter @b_plab.

Source Code for the project in this article

Credit:
raywenderlich.com for the cover image.

My Socials:

Until next time, happy coding!!! 👨‍💻

— Biplab Dutta

Product Flavors in Flutter—Create admin and non-admin apps with distinct UI with a single codebase

Biplab Dutta 🇳🇵📱🧑‍💻 — Sat, 21 May 2022 14:05:12 +0000

Have you ever wondered how some mobile applications have admin and non-admin variants? The admin app has different UIs than the non-admin ones. Or have you seen some apps on the Play Store or App Store with premium and freemium versions? So, how do developers actually do it? How do they create multiple variants of the same project? Do they manage multiple codebases? Is there one team responsible for developing one variant and another team developing the other variant with 2 different codebases? And a clear and short answer to that is NO.

It would be costly for companies to hire two different teams to create two different app variants. So, how is it possible? And unsurprisingly, the answer to that is using Product Flavor.

As the name suggests, a product flavor (or a product variant) is a way to create multiple variants of your app from a single codebase. We can deploy these different apps independently in the relevant stores as well.

Implementation

Now, we will begin creating our flavors. We will have an admin flavor and a non-admin flavor. I will keep the apps very simple and have them display a text saying This is the admin UI and This is the non-admin UI. In a real-world application, you can follow the same techniques that I will show you and have UIs accordingly the way you want.

First, we will add a configuration in the app-level build.gradle file inside the android block.

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }

    // Specifies one flavor dimension.
    flavorDimensions "userTypes"
    productFlavors {
        admin {
            dimension "userTypes"
            resValue "string", "app_name", "Admin App"
            applicationIdSuffix ".admin"
        }
        non_admin {
            dimension "userTypes"
            resValue "string", "app_name", "Non-Admin App"
            applicationIdSuffix ".nonAdmin"
        }
    }
}

Because we will have two different apps created, we want two different names for each of our applications. To do so, we will have to navigate to /android/app/src/main/AndroidManifest.xml file and edit android:label.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.product_flavor_demo">
   <application
        android:label="@string/app_name"      // Edit this line
        android:name="${applicationName}"
        android:icon="@mipmap/ic_launcher">
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTop"
            android:theme="@style/LaunchTheme"
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"
            android:hardwareAccelerated="true"
            android:windowSoftInputMode="adjustResize">
            <!-- Specifies an Android theme to apply to this Activity as soon as
                 the Android process has started. This theme is visible to the user
                 while the Flutter UI initializes. After that, this theme continues
                 to determine the Window background behind the Flutter UI. -->
            <meta-data
              android:name="io.flutter.embedding.android.NormalTheme"
              android:resource="@style/NormalTheme"
              />
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
        <!-- Don't delete the meta-data below.
             This is used by the Flutter tool to generate GeneratedPluginRegistrant.java -->
        <meta-data
            android:name="flutterEmbedding"
            android:value="2" />
    </application>
</manifest>

Now, we need to create two main.dart files in our lib directory. We shall name them main_admin.dart and main_non_admin.dart.

main_admin.dart

// Add necessary imports

void main() {
  runApp(const MyApp());
}

main_non_admin.dart

// Add necessary imports

void main() {
  runApp(const MyApp());
}

We will create our MyApp() widget in a moment but let’s first take care of some other things.

For VS Code Users

If you are a VS Code user, then you need to follow some of the steps that I’ll show you now.

First, create a .vscode folder in the root project directory. Then create a file launch.json inside it and add the following snippet.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "admin_app",
            "request": "launch",
            "type": "dart",
            "program": "lib/main_admin.dart",
            "args": [
                "--flavor",
                "admin",
                "--target",
                "lib/main_admin.dart",
                "--dart-define=appType=admin"
            ]
        },
        {
            "name": "non_admin_app",
            "request": "launch",
            "type": "dart",
            "program": "lib/main_non_admin.dart",
            "args": [
                "--flavor",
                "non_admin",
                "--target",
                "lib/main_non_admin.dart",
                "--dart-define=appType=nonAdmin"
            ]
        }
    ]
}

Now, if you go to the Run and Debug option in your VS Code or hold Ctrl+Shift+D, you will see a drop-down menu. On clicking it, you should see an option to debug your two different app variants.

For Android Studio Users

If you use Android Studio then you need to follow some of the steps that I’ll show you now.

Navigate to Edit Configurations option under the Run tab. It should open up a new window. Then you need to add configurations for each flavor.

In the Dart entrypoint option, add the path to main_admin.dart file using the browse option on the right-hand side. In the Additional run args option, add

--flavor admin --dart-define=appType=admin

Now, add another configuration for the non-admin app.

Follow the same steps as mentioned above and in the Additional run args option, add

--flavor non_admin --dart-define=appType=nonAdmin

Now, we can select the proper configurations that we want to run and debug.

The dart-define option that we have attached in our command is important to find out the app type on run time. We will see how we can use it to identify the app types.

Create a new file app_config.dart inside the lib directory.

abstract class AppConfig {
  static const isAdminApp = String.fromEnvironment('appType') == 'admin';
}

The value of String.fromEnvironment() comes from the dart-define option that we set earlier for each app variant. Now, using the isAdminApp boolean value, we can easily check if the app running currently is the admin app or the non-admin app and render UIs accordingly.

Now create a new file my_app.dart inside the lib directory which will contain code for our MyApp() class. I am keeping it very simple to display different UI for each app variant. You can however take the idea and create as complex UI as you want for each app variant.

// Add the necessary imports

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: AppConfig.isAdminApp ? 'Admin App' : 'Non-admin App',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(),
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: AppConfig.isAdminApp ? _AdminBody(key: key) : _NonAdminBody(key: key),
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return const Center(
      child: Text(
        'This is the admin UI.',
        style: TextStyle(fontSize: 22),
      ),
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return const Center(
      child: Text(
        'This is the non-admin UI.',
        style: TextStyle(fontSize: 22),
      ),
    );
  }
}

As you can see, we have _AdminBody() class and _NonAdminBody() class which will help us render UIs depending on the app we are running.

On running both app flavors, we will have two different apps created with a single codebase.

Conclusion

We learned how we can have two different apps created with different UIs using a single codebase. I hope this blog post will be helpful for some of you reading if you ever encounter a situation where you’d have to create a similar project.

If you wish to see some Flutter projects with proper architecture, follow me on GitHub. I am also active on Twitter @b_plab.

Source Code

My Socials:

Until next time, happy coding!!! 👨‍💻

— Biplab Dutta

Form Validation in Flutter using flutter_bloc and Functional Programming (Either)—A Proper Way

Biplab Dutta 🇳🇵📱🧑‍💻 — Sun, 15 May 2022 13:28:00 +0000

Image Source: morioh
Dealing with forms is a very common task that we encounter as mobile application developers. With forms come form validation. It is necessary to show relevant warnings to the users when they don’t fill-up the form as they were supposed to. In order to do so, we need to write certain validation logic. However, the declarative UI approach in flutter results in many developers writing their validation logic right in the UI code which is BAD, VERY BAD.

Are you writing your validation logic in the UI? If yes, then this article is for you. I will be talking about a proper way how can deal with form validation that doesn’t just work but is architecturally clean and reasonable.

The approach that I will be sharing and which I often use in my personal projects is inspired by Reso Coder’s tutorial on Domain-driven design.

Form Validation in the UI (Bad Approach)

Let’s take a look at a snippet that validates a form with the validation logic in the UI.



class MyCustomForm extends StatefulWidget {
  const MyCustomForm({super.key});

  @override
  MyCustomFormState createState() {
    return MyCustomFormState();
  }
}

class MyCustomFormState extends State<MyCustomForm> {

  final _formKey = GlobalKey<FormState>();

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        crossAxisAlignment: CrossAxisAlignment.start,
        children: [
          TextFormField(
            validator: (value) {
              if (value == null || value.isEmpty) {   // Validation Logic
                return 'Please enter some text';
              }
              return null;
            },
          ),
          Padding(
            padding: const EdgeInsets.symmetric(vertical: 16.0),
            child: ElevatedButton(
              onPressed: () {
                if (_formKey.currentState!.validate()) {
                  ScaffoldMessenger.of(context).showSnackBar(
                    const SnackBar(content: Text('Processing Data')),
                  );
                }
              },
              child: const Text('Submit'),
            ),
          ),
        ],
      ),
    );
  }
}

As you can see, this is how someone would perform form validation with all validation logic right in the UI. It definitely works as intended but it is bad from an architectural point of view.

Many might argue that for something as simple as this is, it is not necessary to be concerned about architecture and do it as shown above but as developers, we should have developer ethics and we should do things in the right way. There should never be room for a simple workaround.

Now, if you are further reading this article, I assume you agree with me. Now let’s take a look at how to perform form validation — the right way.

Before anything, let’s add some dependencies and dev-dependencies that we will require for this project. You will be needing dartz, equatable, flutter_bloc, and freezed_annotation as your dependencies. Also, build_runner and freezed as your dev-dependencies.

Domain Layer

Let’s have a look at what we often see in simple projects where a login() method is implemented.



Future<void> login({
   required String email,
   required String password,
}) async {}

This is generally the method signature for login() method. While we can definitely do something with the method shown above, it won’t prevent some developers in the future from messing up.
For example, one can call the method as



await login(
   email: "email123", 
   password: "pw",
);

Syntactically, it is fine. There’s nothing wrong with what we have done here. But logically, the email can’t just be email123 and the password shouldn’t just be two characters long. So, how can we deal with issues as such, enforcing us to pass only email-like input to email and the same for password?

And the answer to that is creating EmailAddress and Password class. Having a class for each attribute will allow us to write some custom logic as well which we will see in a moment.



class EmailAddress {
  const EmailAddress(this.value);
  final String value;
}

Now, we have a EmailAddress class with a value property of String type. But this is no different from what I showed earlier because the property value is still a String and any string can be passed to it. If we think about the property value , then it can either be a legitimate String value or an illegitimate String. For example, if the property value for EmailAddress class is ‘abc@gmail.com’ then, this is a legitimate string value for email. But if the property value is something like ‘abc’ then, it is an illegitimate string value.

Now, what data type can we use for the property value so as to tell that it can have either a legitimate value or an illegitimate value? And the answer to that will be using Either type from package dartz.

Either is an entity whose value can be of two different types, called left and right. By convention, Right is for the success case and Left is for the error one. It’s a common pattern in the functional community.



class EmailAddress {
  const EmailAddress(this.value);
  final Either<ValueFailure, String> value;
}

Now, using Either type, we can tell the compiler that value can possibly have one out of two types. In this case, the property value can either be of a ValueFailure type or a String type.

Now, what is a ValueFailure? ValueFailure is simply a union to represent an invalid email string. We can create unions using freezed package.



part 'value_failure.freezed.dart';

@freezed
class ValueFailure with _$ValueFailure {
  const factory ValueFailure.invalidEmail({
    required String failedValue,
  }) = _InvalidEmail;
}

Now, run the command



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

This should generate a bunch of code and all the errors should be gone.

Now, if we take a look at our EmailAddress class, everything looks fine except for the validation logic. We somehow need to add the validation logic while we are in the domain layer. It would be great if we could run the validation as soon as EmailAddress class was instantiated.
Fortunately, we can do so with the help of a factory constructor. First, we will create a private constructor so that it can’t be used to create an instance of EmailAddress class. And then add a factory constructor which will act as a default constructor. The factory constructor will take in a string as an input which will undergo validation.

We shall be using Regex to perform email validation.



class EmailAddress extends Equatable {
  factory EmailAddress(String input) =>
      EmailAddress._(_validateEmailAddress(input));

  const EmailAddress._(this.value);

  final Either<ValueFailure, String> value;

  @override
  List<Object?> get props => [value];
}

Either<ValueFailure, String> _validateEmailAddress(String input) {
  const emailRegex =
      r"""^[a-zA-Z0-9.a-zA-Z0-9.!#$%&'*+-/=?^_`{|}~]+@[a-zA-Z0-9]+\.[a-zA-Z]+""";
  if (RegExp(emailRegex).hasMatch(input)) {
    return right(input);
  } else {
    return left(
      ValueFailure.invalidEmail(failedValue: input),
    );
  }
}
```
We can see that if we try to do something like

```dart
var email = EmailAddress('abc@gmail.com');
```
then immediately, the passed in string will go through our validation logic and either return `ValueFailure` or `String`. Also, notice that we are extending our `EmailAddress` class with [Equatable](https://pub.dev/packages/equatable) to enforce value equality over reference equality which requires us to override the `props` getter.

And this is it.

Now, we do the same thing for the `Password` class too. The validation logic will only differ and the rest remains the same. Also, we will need to add another redirecting constructor in our `ValueFailure` union class. Therefore, our `value_failure.dart` and `password.dart` would look like this:
```dart
import 'package:freezed_annotation/freezed_annotation.dart';

part 'value_failure.freezed.dart';

@freezed
class ValueFailure with _$ValueFailure {
  const factory ValueFailure.invalidEmail({
    required String failedValue,
  }) = _InvalidEmail;

  const factory ValueFailure.shortPassword({
    required String failedValue,
  }) = _Password;
}
```

```dart
class Password extends Equatable {
  factory Password(String input) => Password._(_validatePassword(input));

  const Password._(this.value);

  final Either<ValueFailure, String> value;

  @override
  List<Object?> get props => [value];
}

Either<ValueFailure, String> _validatePassword(String input) {
  if (input.length >= 5) {
    return right(input);
  } else {
    return left(
      ValueFailure.shortPassword(failedValue: input),
    );
  }
}
```
## Presentation Layer
Now, we will begin working with our presentation layer. Let me show you the final result of our application.

![flutter form validation demo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/796f898wzkv7fxxde3bz.gif)

We will begin with creating our bloc.
### Event class
Considering the events or actions that users can perform to interact with the UI, the events can be

- EmailChanged (when the user adds an input character to the email text field)

- PasswordChanged (when the user adds an input character to the password text field)

- ObscurePasswordToggled (when the user taps on the show password or hide password option in the password text field)

- LoginSubmitted (when the user taps on the login button)

We will be creating a union class to represent events in our project.

```dart
part of 'login_form_bloc.dart';

@freezed
class LoginFormEvent with _$LoginFormEvent {
  const factory LoginFormEvent.emailChanged(String emailString) = _EmailChanged;

  const factory LoginFormEvent.passwordChanged(String passwordString) =
      _PasswordChanged;

  const factory LoginFormEvent.obscurePasswordToggled() =
      _ObscurePasswordToggled;

  const factory LoginFormEvent.loginSubmitted() = _LoginSubmitted;
}
```
### State class
What field should be present in the state class? We need to pass back the validated email and password to our UI.
Also, on pressing the login button, a loading indicator appears until a response is received from the backend. So, we will need a `isSubmitting` `boolean` field that will be false by default.
We don’t want the validation logic to kick in as soon as our app starts. Only once the login button is pressed, and if the email and password combination is invalid then we want the warnings to begin getting displayed. So, we also need a `showErrorMessage` `boolean` field that will be false by default.
We also have a **_show/hide password_** option and the password will remain hidden (obscured) by default. So, we need an `obscurePassword` `boolean` field which will be true by default.
After tapping on login, we will either succeed or fail. In this demo, we will show a snack bar if we log in when having a valid email and password. In a real-world application, you would show a snack bar with a proper message if the user is unable to log in or navigate to the home screen if login is successful. Since we will either succeed or fail the login process, we will need an `authSuccessOrFailure` `Either<AuthFailure, Unit>?` field. It is a nullable field because as the app starts we can’t tell if the login process is successful or not. So, if the `authSuccessOrFailure` is null that means we haven’t tried logging in yet.
`Unit` is a data type that comes from [dartz](https://pub.dev/packages/dartz) package and is equivalent to `void`.

```dart
part of 'login_form_bloc.dart';

@freezed
class LoginFormState with _$LoginFormState {
  const factory LoginFormState({
    required EmailAddress emailAddress,
    required Password password,
    @Default(false) bool isSubmitting,
    @Default(false) bool showErrorMessage,
    @Default(true) bool obscurePassword,
    Either<AuthFailure, Unit>? authFailureOrSuccess,
    // Unit comes from Dartz package and is equivalent to void.
  }) = _LoginFormState;

  factory LoginFormState.initial() => LoginFormState(
        emailAddress: EmailAddress(''),
        password: Password(''),
      );
}
```
`AuthFailure` is also a union class to represent authentication failure and because the authentication process might fail because of several reasons, we are using a union class.
```dart
part 'auth_failure.freezed.dart';

@freezed
class AuthFailure with _$AuthFailure {
  const factory AuthFailure.invalidEmailAndPasswordCombination() =
      _InvalidEmailAndPasswordCombination;
  const factory AuthFailure.serverError() = _ServerError;
}
```

> _Since we ran the **build_runner watch** command earlier, we needn’t run the build command again. For some reason, if the build_runner watch command has stopped running, you will need to re-run the command._

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

### Bloc
This is where the presentation logic is located.

```dart
part 'login_form_bloc.freezed.dart';
part 'login_form_event.dart';
part 'login_form_state.dart';

class LoginFormBloc extends Bloc<LoginFormEvent, LoginFormState> {
  LoginFormBloc() : super(LoginFormState.initial()) {
    on<LoginFormEvent>(
      (event, emit) async {
        await event.when<FutureOr<void>>(
          emailChanged: (emailString) => _onEmailChanged(emit, emailString),
          passwordChanged: (passwordString) =>
              _onPasswordChanged(emit, passwordString),
          obscurePasswordToggled: () => _onObscurePasswordToggled(emit),
          loginSubmitted: () => _onLoginSubmitted(emit),
        );
      },
    );
  }

  void _onEmailChanged(Emitter<LoginFormState> emit, String emailString) {
    emit(
      state.copyWith(
        emailAddress: EmailAddress(emailString),
        authFailureOrSuccess: null,
      ),
    );
  }

  void _onPasswordChanged(Emitter<LoginFormState> emit, String passwordString) {
    emit(
      state.copyWith(
        password: Password(passwordString),
        authFailureOrSuccess: null,
      ),
    );
  }

  void _onObscurePasswordToggled(Emitter<LoginFormState> emit) {
    emit(state.copyWith(obscurePassword: !state.obscurePassword));
  }

  Future<void> _onLoginSubmitted(Emitter<LoginFormState> emit) async {
    final isEmailValid = state.emailAddress.value.isRight();
    final isPasswordValid = state.password.value.isRight();

    if (isEmailValid && isPasswordValid) {
      emit(
        state.copyWith(
          isSubmitting: true,
          authFailureOrSuccess: null,
        ),
      );

      // Perform network request to get a token.

      await Future.delayed(const Duration(seconds: 1));
    }
    emit(
      state.copyWith(
        isSubmitting: false,
        showErrorMessage: true,

        // Depending on the response received from the server after loggin in,
        // emit proper authFailureOrSuccess.

        // For now we will just see if the email and password were valid or not
        // and accordingly set authFailureOrSuccess' value.

        authFailureOrSuccess:
            (isEmailValid && isPasswordValid) ? right(unit) : null,
      ),
    );
  }
}
```
Now all that is left is to create two TextFields and wrap them with the BlocBuilder widget.

To check the remaining UI source code, I’d suggest you take a look at this [repo](https://github.com/Biplab-Dutta/form-validation) which contains the source code for the entire project.

## Conclusion
This article demonstrated how you can perform form validation in Flutter using proper techniques and without having any business logic in the UI. There are several other ways to do the same thing. One of them happens to be [formz](https://pub.dev/packages/formz) package.

I hope after reading this article those who have been writing their validation logic in the UI, would now have such logic in the domain layer, keeping your presentation layer neat.

If you wish to see some Flutter projects with proper architecture, follow me on [GitHub](https://github.com/Biplab-Dutta). I am also active on Twitter [@b_plab](https://twitter.com/b_plab98).

**[Source Code](https://github.com/Biplab-Dutta/form-validation)**

**My Socials:**

- [GitHub](https://github.com/Biplab-Dutta)

- [LinkedIn](https://www.linkedin.com/in/biplab-dutta-43774717a/)

- [Twitter](https://twitter.com/b_plab98)

Until next time, happy coding!!! 👨‍💻

— Biplab Dutta

A Taste of Reactive Programming in Flutter with RxDart and flutter_bloc

Biplab Dutta 🇳🇵📱🧑‍💻 — Sat, 07 May 2022 16:49:30 +0000

Image Source: West Agile Labs

When it comes to reactive programming, not many developers, especially junior developers feel comfortable with it. The base for reactive programming in Dart is Stream, a type in dart used to represent an asynchronous sequence of data. In this article, we will learn about what streams are, when to use them, and how to use them by building a simple flutter application and bringing everything into practice.

Stream and StreamController

Before anything, let’s first talk about Streams as I already told you that it lays the foundation for reactive programming. Simply put, you can consider Stream as a flow of data that arrives asynchronously, meaning you don’t exactly know when a certain data is going to arrive. It is represented as Stream<T> where T is any data type.

Unlike Future, when you invoke a method returning Stream, the execution doesn’t get terminated once a result is yielded (Stream’s equivalent to return). You will manually need to close the stream to terminate its operation.

When talking about Streams, you must also be familiar with StreamController . A StreamController is basically a manager for the stream. We use it to determine what type of stream we are interested in and for some other purposes.

To understand it more easily, imagine a pipe that has two ends. One for letting the water enter the pipe and the other for letting it out of the pipe. If you think about it, water freely flows inside of the pipe. Similarly, the StreamController has two ends — one for letting the data come in, and the other to let it exit. The data enters the StreamController via Sink . The data can also be modified before it is emitted.

Stream Representation (Image By: Rajat Palankar)

Those parts of our application that are interested in our data stream need to listen to the emitted stream, also referred to as subscribing to the stream. Those who listen or subscribe to the stream are called subscribers or listeners. The stream can be listened to by one or many listeners. Depending on the number of listeners, the stream can be categorized into two parts:

Single-subscription Stream: This type of stream only allows one listener during the whole lifetime of that stream. You can’t re-listen to the stream even after closing it.
Broadcast Stream: This type of stream allows any number of listeners.

Reactive Programming

Simply put, reactive programming is programming with asynchronous data streams.

If the repository in the data layer returns data in the form of Stream (which the ViewModel(s) will listen to), you can consider that reactive programming.

But how is it going to help us anyway? If this is what you have been thinking, let me demonstrate two images.

A picture is worth a thousand words — Henrik Ibsen

Steps in performing Network Request — Future-based Approach (Image Source: Android Developers)

We can clearly understand what the above image illustrates. It shows how a developer can obtain necessary data from the server by following the shown steps:

First, the view is initialized.
Then the ViewModel (or bloc) requests the necessary data. The communication takes place with the Repository.
The Repository communicates with the relevant data sources for the required data.
The data source performs some data fetching operations and returns the data back to the Repository.
The Repository returns the data back to the ViewModel.
And finally, the data is consumed by the UI.

While there is nothing wrong with this approach to performing network requests, in larger projects, it might be an overkill. If we add some data to our database, we would immediately have to call some methods like loadData() or getUpdatedData().

loadData() is a one-time delivery of data meaning you shouldn’t be calling methods like loadData() time and again. The app must contain logic to ask for updates periodically.

What is the better way of doing the same thing then? And the answer to that would be having a reactive repository. To illustrate this, see this image.

Steps in performing Network Request — Reactive Approach (Image Source: Android Developers)

This diagram has fewer steps than what we saw earlier. But how does this work? Let’s have a look at it.

First, the view is initialized and requests ViewModel for initial data and observes it. Observes is another term for listening or subscribing.
Then the ViewModel requests Repository for the data and observes the Repository.
And the Repository requests data from the data source and observes the data source.

Now, how will the data that will be coming from the data source be ultimately consumed by the UI if the data is not being returned back?

Now, this is where the Streams and Reactive approach shines. 🤩

Because the data source is being observed (or listened to) by the Repository, which also means that the data source will return a Stream of some data, the repository will immediately be notified when new data arrives.

Again, the Repository is being observed (or listened to) by the ViewModel, the ViewModel would immediately be notified when the Repository yields some stream of data.

And finally, as the ViewModel is observed by the UI, the UI gets proper data to display on the screen.

With this approach, we needn’t call methods like loadData() again and again as new data arrives. We only add incoming data to the Stream then the relevant listener(s) will automatically get notified about the changes. This is what we call a Reactive Approach.

Now, we will begin building a simple application, that will put all of our understanding regarding Streams and the Reactive approach into practice.

Demo

We will build a very simple application that will initially display a list of names in a ListView. And we will add some more names but follow a reactive approach.

This is what our final application looks like.

First, create a new Flutter project and get rid of the default counter app.
Also, add Equatable and RxDart packages to your pubspec.yaml file.



flutter create stream_demo

I named the project stream_demo . You can name your project anything you like. Then inside your lib, create three folders and name them data, domain, and presentation. The main.dart file should also reside in the lib directory.



lib
 |__ data
 |__ domain
 |__ presentation
 |__ main.dart

We will begin with the Domain Layer first. Inside the domain folder, create a file models.dart . And paste the following code.



class User {
  final String name;

  User(this.name);
}

final allUsers = <User>[
  User('Biplab'),
  User('Aashish'),
  User('Aayam'),
  User('Saroj'),
  User('Ereema'),
  User('Manisha'),
];

Next, we will work on the Data Layer. Create two files repository.dart and remote_data_source.dart inside the data folder.

Now, add the following code to remote_data_source.dart file.



import 'package:stream_demo/domain/models.dart';

class RemoteDataSource {
  const RemoteDataSource();

  /// This class, in a real project is supposed to make network requests to
  /// the server to get the data. But here we will just return our hard-coded
  /// list of users `List<User>`.
  Future<List<User>> getUsers() async {
    // make a network request
    await Future.delayed(const Duration(seconds: 2)); // mimicking network delay
    return allUsers;
  }
}

The above code simply returns a List<User> which will be returned by the Repository. So, add the following code to repository.dart file.



import 'dart:async';

import 'package:rxdart/rxdart.dart';
import 'package:stream_demo/data/some_data_source.dart';
import 'package:stream_demo/domain/models.dart';

class UserRepository {
  final RemoteDataSource _dataSource;

  UserRepository(
    RemoteDataSource dataSource,
  ) : _dataSource = dataSource {
    _dataSource.getUsers().then(
          (users) => _userStreamController.add(users),
        );
  }

  final _userStreamController = BehaviorSubject<List<User>>();

  Stream<List<User>> getUsers() => _userStreamController.stream;

  /* If there are multiple listeners of this stream, then
     edit the `getUsers()` method as:

      Stream<List<User>> getUsers() => _userStreamController.asBroadcastStream();
  */

  void addUser(User user) {
    final users = [..._userStreamController.value, user];

    /* Don't do:
     _userStreamController.value.add(user);   ❌
     As it will add the new user to the previous List instance (which
     is also called mutating the List) due to which
     the ListView in the UI will not update properly.
     So, we should return new List instance with updated values.

     Alternatively, we can also do:

     final users = List<User>.from(_userStreamController.value)..add(user);   ✅

     */

    _userStreamController.add(users);

    /* 
      And finally the data is added to the stream as soon as this method is 
      invoked, allowing other listeners of this stream know about the new
      update immediately.
    */
  }
}

Here, the UserRepository is dependent on the RemoteDataSource. In the constructor body, we call getUsers() and the list of users is added to the StreamController.

Also, we are using BehaviorSubject instead of a StreamController. BehaviorSubject comes from RxDart package. The package is simply an extension on Stream provided by Dart. Using BehaviorSubject, any new listeners when begin listening to the stream, they immediately get the lastly emitted Stream of data.

We can think that BehaviorSubject has some kind of a caching mechanism that caches the latest emitted Stream immediately.

Also, notice how the addUser() method is implemented. We are simply adding the new user to a new List and adding the List to our StreamController. This way, whenever a new user is added, the listeners subscribed to this Stream (in the bloc) immediately get notified, and our UI updates immediately.

I have had one question in the past when I saw Stream<List<User>> being returned instead of Stream<User>. The main reasons for that are:

When a new user arrives, we can’t tell if that should be at the top of our list or at the bottom, or somewhere in the middle.

And one major principle of the BLoC Pattern is to pass those data in the UI that will be represented in the UI and avoid having any additional business logic in the UI.

Now, we can work on the Presentation Layer. It will consist of bloc, widgets, and pages. So, create three folders inside the presentation folder and name them bloc, widgets, and pages respectively.

We will begin with the bloc. Add three files — user_bloc.dart, user_event.dart, and user_state.dart.

user_event.dart



part of 'user_bloc.dart';

abstract class UserEvent extends Equatable {
  const UserEvent();

  @override
  List<Object> get props => [];
}

class UserRequested extends UserEvent {
  const UserRequested();
}

class UserAdded extends UserEvent {
  const UserAdded(this.user);

  final User user;

  @override
  List<Object> get props => [user];
}

class UserInputChanged extends UserEvent {
  const UserInputChanged(this.input);

  final String input;

  @override
  List<Object> get props => [input];
}

user_state.dart



part of 'user_bloc.dart';

enum UserStatus { initial, loading, success, failure }

class UserState extends Equatable {
  const UserState({
    this.status = UserStatus.initial,
    this.users = const [],
    this.userInput = '',
  });

  final UserStatus status;
  final List<User> users;
  final String userInput;

  UserState copyWith({
    UserStatus? status,
    List<User>? users,
    String? userInput,
  }) =>
      UserState(
        status: status ?? this.status,
        users: users ?? this.users,
        userInput: userInput ?? this.userInput,
      );

  @override
  List<Object> get props => [status, users, userInput];
}

user_bloc.dart



import 'package:bloc/bloc.dart';
import 'package:equatable/equatable.dart';
import 'package:stream_demo/data/repository.dart';
import 'package:stream_demo/domain/models.dart';

part 'user_event.dart';
part 'user_state.dart';

class UserBloc extends Bloc<UserEvent, UserState> {
  UserBloc({
    required UserRepository repository,
  })  : _repository = repository,
        super(const UserState()) {
    on<UserRequested>(_onUserRequested);
    on<UserAdded>(_onUserAdded);
    on<UserInputChanged>(_onUserInputChanged);
  }

  final UserRepository _repository;

  Future<void> _onUserRequested(
    UserRequested event,
    Emitter<UserState> emit,
  ) async {
    emit(state.copyWith(status: UserStatus.loading));

    /// We also could have used `stream.listen` however `emit.forEach()` is a
    /// newer and recommended approach when working with the flutter_bloc package.
    await emit.forEach<List<User>>(
      _repository.getUsers(),
      onData: (users) => state.copyWith(
        status: UserStatus.success,
        users: users,
      ),
      onError: (_, __) => state.copyWith(status: UserStatus.failure),
    );
  }

  void _onUserAdded(
    UserAdded event,
    Emitter<UserState> emit,
  ) {
    _repository.addUser(event.user);
    emit(state.copyWith(userInput: ''));
  }

  void _onUserInputChanged(
    UserInputChanged event,
    Emitter<UserState> emit,
  ) {
    emit(
      state.copyWith(
        userInput: event.input,
      ),
    );
  }
}

The event UserRequested is triggered as soon as the app is launched. The event UserAdded is triggered when we want to add the user to our existing list. And the UserInputChanged event exists to handle the event when we provide input to the text field.

Now to create UI, I'd suggest you check my GitHub repo as the UI code is pretty simple and I don't want to create this article very long for the readers to read.

Conclusion

This article aimed at making Streams and Reactive Programming easier to get used to. The reactive Approach can help in having a relatively small codebase, easier to manage, and most importantly having our application truly reactive.

If you have anything to tell me, please do so. I will be looking forward to all the feedback I receive. You can also follow me on Twitter at @b_plab98 where I tweet about Flutter and Android.

My Socials

Until next time, happy coding!!! 👨‍💻
— Biplab Dutta

Exception Handling in Flutter with Functional Programming (Either type)

Biplab Dutta 🇳🇵📱🧑‍💻 — Sat, 30 Apr 2022 15:25:40 +0000

Every application needs some data sources to receive the data and display it in the UI. So, it becomes very crucial how we, as developers, perform network requests. Handling API responses in an effective manner also determine the success or failure of our application.

In this post, we will see how to perform such network requests effectively using dio and a bit of functional programming using the dartz package. This will allow our overall architecture to remain consistent while making our project scalable and maintainable.

To follow along, make sure to include dio and dartz as your dependencies in the pubspec.yaml file.

Dio API Calls

First thing first, let’s take a look at how I used to make network requests in Flutter a while back 😂 when I was still a beginner.



class FeedRemoteDataSource {
  FeedRemoteDataSource(Dio dio) : _dio = dio;

  final Dio _dio;

  Future<List<Feed>> fetchFeeds() async {
    try {
      final response = await _dio.get('some url path');
      // Some other work
    } on DioError {
      // error handling
      // return empty list.
    }
  }
}

This was how I did my network request returning a List of something no matter what. It worked fine for small projects; however, it didn’t take much longer for me to realize that I had been doing it wrong. As you can see in the code snippet above, I was always returning a List, irrespective of the status code.

In real-world projects, we are likely to work in a multi-layered architecture which means our entire project could be divided into multiple layers.
The layers can be:

Presentation Layer (consisting of UI code and ViewModel)
Domain Layer (consisting of entities and use-cases (optional))
Data Layer (consisting of DTOs, a repository, and data sources)

In this article, we will work closely with the Data Layer as it is what this article is about in the first place.

Now, getting back to the previous snippet. The fetchFeeds() method always returned a List. The presentation layer will then have no idea if the returned List was because of a successful request or unsuccessful. Because a successful request can also sometimes give an empty list if the database has no data. So, it was clear that I was doing it wrong ❌.
After spending some time looking at other people’s codes and tutorials 📖, I learned the importance of software architecture. 🤯

So, keeping proper architecture in our mind, let us redo the same request but in a proper way. 😎
Since I talked about architecture, let me begin with what our architecture for the data layer should look like.

Before we proceed any further, let me tell you that this is not the best architecture or the only architecture you can go with. Different people/teams have their own ideas regarding architecture and their own ways of doing things. However, every architecture makes sure to separate UI and business logic which is why software architectures exist.

Data Layer Architecture

Data Layer (Image by Reso Coder)

So, our data layer would consist of three parts:

Data Transfer Objects (DTOs): They are the data layer representation of domain layer entities. They are also responsible for performing various data-related logic like conversion between Dart Object and JSON format and vice-versa. It also contains logic to convert domain layer entities into DTOs and vice-versa.
Data Sources: It is where we perform all of our network requests and the result is passed to the repository. All network-related exceptions that may arise are also thrown here which are then caught by the repository and converted to Failure (about which we will see in a moment).
Repository: The repository is what the view model communicates with. A repository also acts as a single gateway for data coming from several data sources. A repository is thus, essential in maintaining a single source of truth.

Data Transfer Objects (DTOs)

First, let’s see how our feed_dto.dart would look like.



part 'user_dto.freezed.dart';
part 'user_dto.g.dart';

@freezed    // Import package freezed. [https://pub.dev/packages/freezed]
class FeedDTO with _$FeedDTO {
  const factory FeedDTO({
    required String title,
  }) = _FeedDTO;

  const FeedDTO._();

  factory FeedDTO.fromJson(Map<String, dynamic> json) =>
      _$FeedDTOFromJson(json);

  factory FeedDTO.fromDomain(Feed feed) => FeedDTO(
        title: feed.title,
      );

  Feed toDomain() => Feed(title: title);
}

You will also need to have freezed included in your project as a dev-dependency along with build_runner. Also, include freezed_annotation as a dependency.

freezed is a code generator for data-classes/unions/pattern-matching/cloning.

Next, you will need to have the required code generated which freezed and build_runner will take care of. Run the following command to initialize code generation.



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

Data Sources

In this section, we will perform our network request using the dio package. Any exceptions that need to be thrown will be thrown in this section which then is handled by the Repository.



class FeedRemoteDataSource {
  FeedRemoteDataSource(
    Dio dio,
  ) : _dio = dio;

  final Dio _dio;

  Future<List<FeedDTO>> getFeeds() async {
    try {
      final response = await _dio.get<String>('some url path');
      if (response.statusCode == 200) {
        // decode json response
        // return List<FeedDTO>
      } else {
        throw RestApiException(response.statusCode);   // Custom class implementing Exception whose constructor accepts int
      }
    } on DioError catch (e) {
      if (e.isNoConnectionError) {
        // handle no connection error
      } else if (e.response != null) {
        throw RestApiException(e.response?.statusCode);
      } else {
        rethrow;
      }
    }
  }
}

extension DioErrorX on DioError {
  bool get isNoConnectionError =>
      type == DioErrorType.other && error is SocketException;   // import 'dart:io' for SocketException
}

Repository

This is the main gateway for the data coming from several data sources. Also, the ViewModel communicates with the Repository to get the data and display it in the UI. And the conversion between DTO and the domain-level entity is also performed here.

Now, how is our repository going to make it easy for us to handle exceptions so as to have a maintainable architecture? It’s simple. We use Either.

Either is an entity whose value can be of two different types, called left and right. By convention, Right is for the success case and Left is for the error one. It’s a common pattern in the functional community.

It might be difficult to get a grasp on Either just by looking at its definition. So, let’s take a look at our repository implementation which will help us understand Either easily.

The FeedRepositoryImpl class implements FeedRepository which is a simple abstract class. The FeedRepositoryImpl is dependent on our FetchRemoteDataSource.



abstract class FeedRepository {
  Future<Either<Failure, List<Feed>>> getFeeds();
}

class FeedRepositoryImpl implements FeedRepository {
  FeedRepositoryImpl({
    required this.remoteDataSource,
  });

  final FeedRemoteDataSource remoteDataSource;

  @override
  Future<Either<Failure, List<Feed>>> getFeeds() async {
    try {
      final result = await remoteDataSource.getFeeds();
      return right(result.toDomainList);
    } on RestApiException {
      return left(
        const Failure.serverError(),
      );
    }
  }
}

extension DTOListToDomainList on List<FeedDTO> {
  List<Feed> get toDomainList => map((e) => e.toDomain()).toList();
}

Now, now, now!! What is that method returning Future<Either<Failure, List<Feed>>> ??? 🤯😵‍💫 And how can a method return two different data types? 😵‍💫

If you are thinking the same, then it’s just as simple as it can get.

Either<A, B> means that a method will return either A or B depending on the situation. It won’t return both A and B.

In our case, the getFeeds() returns Future<Either<Failure, List<Feed>>> meaning either Failure or List<Feed> . And because we are dealing with asynchronous code, we also have Future.

Failure is just a simple union class that is created using freezed package.



part 'failure.freezed.dart';

@freezed
class Failure with _$Failure {
  const factory Failure.serverError() = _ServerError;
  const factory Failure.anotherFailure() = _AnotherFailure;
}

If you had run the build_runner watch command earlier, saving the above failure.dart file will automatically generate a bunch of code for you. Else run the command again.



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

So, our repository implementation is pretty straightforward now. If the remote data source returns relevant data, then the repository will return Right i.e. List<Feed> else it returns Left i.e. Failure. Notice how the exceptions that were wildly being thrown from the remote data source are now gone because the repository implementation returns the Dart object. 🤩

This way, we also reduce the risk of the error bubble.

BLoC / ViewModel

So, how exactly are we going to deal with the obtained result from the repository in the presentation layer? For that, we will need to create a bloc that will be dependent on the repository. I prefer using flutter_bloc for state management purposes.

You needn’t use flutter_bloc to follow along. Any state management solutions are fine. 👍️



part of 'timeline_bloc.dart';

@freezed
class TimelineEvent with _$TimelineEvent {
  const factory TimelineEvent.feedFetched() = _FeedFetched;
  // add some other events too as desired...
}



part of 'timeline_bloc.dart';

@freezed
class TimelineState with _$TimelineState {
  const factory TimelineState.loading() = _Loading;
  const factory TimelineState.loaded({required List<Feed> feeds}) = _Loaded;
  const factory TimelineState.failed() = _Failed;
}



class TimelineBloc extends Bloc<TimelineEvent, TimelineState> {
  TimelineBloc(
    FeedRepository repository,
  )   : _repository = repository,
        super(const TimelineState.loading()) {
    on<TimelineEvent>(
      (event, emit) async {
        await event.when<Future<void>>(
          feedFetched: () => _onFeedFetched(emit),
        );
      },
    );
  }

  final FeedRepository _repository;

  Future<void> _onFeedFetched(Emitter<TimelineState> emit) async {
    final fetchedFeed = await _repository.getFeeds();
    fetchedFeed.fold<void>(     // fetchedFeed is a Either type. We use fold to say what to do for each case i.e. for `Failure` and `Success` cases.
      (failure) => emit(const TimelineState.failed()),
      (feeds) => emit(TimelineState.loaded(feeds: feeds)),
    );
  }
}

In the _onFeedFetched() method above, the instance of the class implementing FeedRepository (the abstract class) is used to call the getFeeds() method which returns an Either type (stored in fetchedFeed). We use fold method to emit proper state depending on the result of _repository.getFeeds().
The fold accepts to functions as its argument. The first function is used to perform an action when Failure is returned, whereas the second function is used to perform an action when a Success is returned. Success in our case refers to List<Feed>.

Now, from our UI, we can use BlocBuilder to rebuild our widget on certain state changes.

Conclusion

In this article, you saw how to implement network requests in Flutter in a proper manner. We learned how we can use dio, freezed, dartz, and a few other architectural overviews that can help us in making our app more maintainable, and testable and ultimately help us in becoming a better developer.

Also, this was my very first blog on Dev. I know there is room for improvement and therefore, I seek feedback from the community.

If you wish to read this article in Bahasa Indonesia, you can find it here. Yunus Afghoni has done good work taking this article as a reference and translating it to Bahasa Indonesia, with some subtle changes.

If you wish to see some Flutter projects with proper architecture, follow me on GitHub. I am also active on Twitter @b_plab.

My Socials

Until next time, happy coding!!! 👨‍💻

— Biplab Dutta

DEV Community: Biplab Dutta 🇳🇵📱🧑‍💻

A deep dive into unit testing in Flutter 🧪

An info on my upcoming blogs

Theme Switching & Persisting in Flutter using cubits and Stream

Demo

Dependencies

Let’s Code 👨‍💻

Theme Configurations

Data Layer/Theme Repository

Cubits/ViewModel/State Management

main.dart

App Widget

HomePage

Other solutions

Conclusion

Product Flavors in Flutter—Create admin and non-admin apps with distinct UI with a single codebase

Implementation

For VS Code Users

For Android Studio Users

Conclusion

Form Validation in Flutter using flutter_bloc and Functional Programming (Either)—A Proper Way

Form Validation in the UI (Bad Approach)

Domain Layer

A Taste of Reactive Programming in Flutter with RxDart and flutter_bloc

Stream and StreamController

Reactive Programming

Demo

Conclusion

My Socials

Exception Handling in Flutter with Functional Programming (Either type)

Dio API Calls

Data Layer Architecture

Data Transfer Objects (DTOs)

Data Sources

Repository

BLoC / ViewModel

Other Solutions

Conclusion

My Socials