Here are few takeaways from the session.

Orange Data Mining

This was my first time hearing about this tool and I was like “man this is good”. This is a no code tool that you can do a lot with drag and drop interface.

I know you may have a ‘eek’ by hearing ‘no code’ but this can be a huge time saver if you are trying to find the best model for your data set.

The instructor demonstrated how you can use multiple models/strategies in the same dataset to find the optimal one for your data set. I think the demo was around 15-mins long, but we tried models like Linear Regression, Random Forest, SVM, Multi-Layer Perceptron, KNN etc, and for that dataset, the Random Forest was more accurate.

We generate the confusion matrix for all these models, tried with multiple datasets, analyzed the accuracy without any code and within 15 mins.

It was surprisingly good. Game changer stuff.

Cosine Similarity in Resume

He explained that how companies use cosine similarity to filter out potential spams resume, and how we can think through it and optimize our resume. We had a practical demonstration where we calculated how likely a resume is going to be passed to a second round for a given job description.

The working behind this is, the job description is converted into a vector ( i need to read more on how this is done, If you are familiar on this, feel free to comment) and similarly the resume is also converted into a vector. Once this is done, calculate the cosine of the angle between these vector.

The angles being closer to 0 means that the provided resume and the job description has a greater match.

Before you ask, yes we will also be taking into account all the irrelavent details in the resume, that is not the part of the job description.

Sentiment Analysis

We also got to know how sentiment analysis are being used in industries to optimize sales. We got to know about the Filpkart’s success story of a failing product turned to a top selling one by analyzing the reviews, followed by sentiment analysis on it, and then changing on the product. We briefly discussed other areas where sentiment analysis is being used like, Customer Feedback analysis, Product success prediction based on customer data, stock market trends (we did a on google data direct from yahoo finance with orange data mining) e.t.c.

Localized AI

We also discussed about current trends on LLM and what the next focus is going to be. Professor explained that the next big thing on LLMs is going to be on the regional languages, how the local government can help subsidize this, and it’s challenges to improve accessibility in the rural areas so that AI is accessible.

Neural Networks and Reinforcement Learning

We also briefly talked about the Neural Networks and machine learning method like Supervised Learning and Reinforcement Learning and its tradeoffs. He explained that reinforcement learning may not be the best for self driving car due to the accidents that may happen for the model to learn.

It was a really fruitful session and I got to learn a lot. This session left me thinking about how rapidly things are evolving and how we are surrounded with AI.

What I think is, although we are surrounded by AI and most of the repetitive tasks are being replaced by AI, we will still have edge in sophisticated problem solving.

If you’re curious about Orange, cosine analysis, or just AI in general, let’s chat in the comments. Always eager to discuss and learn from others in this space!

PS, Yes I generate this thumbnail with AI

That's it for today. If you have any questions on the topic you want me to write about, please feel free to write in comments. I will try to cover as much topics as I can.

Thank you for joining me on this journey, and happy coding! 💻👨💻

I’m starting with some topics that might sound trivial but can be confusing to many Flutter developers. These are the kind of questions that often get overlooked but are important to address for smoother development.

Let's try to answer these questions that you may have come across while using flutter and it's build_runner.

1. Is codegen secretly bloating your app size? TLDR; It's not!

2. Will static metaprogramming make tools like build_runner obsolete?

3. How are you handling generated files? Do you commit them to VCS?

4. Is build_runner getting slower as the project grows? Can you fix it? Yes? How?

What determines the flutter app size, and how to make it smaller?

Flutter provides tools to analyze the size breakdown of your app’s final build, helping you optimize the app size and make it smaller.

There is a special flag that many might not know about, which allows you to view the final contents of the release build. With this command, the Dart compiler will monitor package usage and code utilization within the app, generating a JSON report that details the build contents.

flutter build ipa --analyze-size

The --analyze-size flag lists all the components of the bundle, including the frameworks used, their sizes, and the total asset size of the final bundle. This is how it will look like.

This command also generates a JSON file that we can use to view a TreeMap with dart DevTools.

dart devtools --appSizeBase=ios-code-size-analysis_02.json

Once you run the command, you can see the TreeMap with all the details interactively. You can also click on one node and explore further.

Now it's clear that using codegen won't significantly increase the app size (it might only add a few kilobytes), so we don't need to worry about it bloating the app.

What occurs if I list multiple packages in my pubspec.yaml file but don't actually use them?

When you have specified packages/plugins to use in your flutter project, the Dart compiler will treeshake all the unused dart code optimizing the app's size. The tricky part is with the plugin (ones containing native dependencies).

If your pubspec.yaml contains unused plugins, the Dart compiler will treeshake unused Dart code, but native dependencies will remain, increasing the app size.

To prevent this, remove unused packages from pubspec.yaml and regularly check for unused dependencies.

You can use available tools to scan for your unused dependencies and assets from your codebase.

1. dependency_validator reports any missing, under-promoted, over-promoted, and unused dependencies. Any package that either provides an executable or a builder that will be auto-applied via the dart build system will be considered used even if it isn't imported.

2. Flutter: Find Unused Dart Files & Assets is a VS code extension which allows you to find unused assets, dart files & dependencies in your project.

If I list an asset in my pubspec.yaml but don't use it within the app, will it still get bundled into the application?

Yes, If you list an asset in your pubspec.yaml but don't use it within your Flutter app, it will still be bundled into the application. This applies to most assets like images, sounds, or general files. The asset bundling process in Flutter does not remove unused assets based on their use in the code. That's why all the assets listed in pubspec.yaml are bundled into the app, regardless of their use, ultimately bloating your app.

What about that message about fonts being treeshaken while I build for android?

The message about fonts being "treeshaken" refers to Flutter's font tree-shaking feature. This feature is different from how assets like images or other files are handled.

When you build your Flutter app in release mode, Flutter includes only the font glyphs (characters) that are actually used in your app.

Flutter analyzes your app's text usage and optimizes font files by including only the required characters. This is why you see the "fonts being treeshaken" message during the build.

Will static metaprogramming make tools like build_runner obsolete?

The Dart macro system has introduced support for static meta-programming to the Dart language.

This means that, when the feature is live, we could use annotations and the dart compiler will JIT compile the annotations to code on the fly. Most of the notable packages are planning to adapt this approach to mitigate the short coming of the build_runner (time consuming).

Here's Remi Rousselet talking about rewriting Freezed with macros.

How are you handling generated files? Do you commit them to VCS?

Using tools like build_runner generates a significant number of files, which can be cumbersome to manage, potentially leading to issues like merge conflicts if not handled correctly.

Committing these files to a version control system would be a matter of preference and is somewhat opinionated.

Personally, I do not check these files into VCS when working on collaborative projects to avoid merge conflicts.

If you choose not to check these files into your VCS, you may need to add an additional build step in your CI process to generate these files, which might increase your CI build time.

Is build_runner getting slower as the project grows? Can you fix it? Yes? How?

As your project expands with more files and additional build_runner generators, the overhead increases, leading to longer times for code generation.

This can be optimized by creating a build.yaml file and explicitly telling the generator which files to check for code generation. This can drastically decrease the codegen time.

Here's an example of such build.yaml file.

targets:
  $default:
    builders:
      freezed:freezed:
        generate_for:
          exclude:
            - test/**.dart
          include:
            - lib/**/*data/**/*.dart
            - lib/**/*models/**/*.dart
            - lib/**/*domain/**/*.dart
            - lib/core/error/failures/**/*_failure.dart
            - lib/features/**/*bloc/*_bloc.dart

      injectable_generator:injectable_builder:
        generate_for:
          exclude:
            - test/**.dart
          include:
            - lib/**/*_{bloc,data_source,interceptor,http_client,repository,service,plugin,viewmodel}.dart
            - lib/**/*usecases/**/*.dart
            - lib/core/di/**/*.dart
            - lib/domain/**/*_{factory,api,filters,impl}.dart
            - lib/network/**/*.dart

      json_serializable:json_serializable:
        generate_for:
          exclude:
            - test/**.dart
          include:
            - lib/**/*{data,models,domain}/**/*.dart
        options:
          create_factory: true
          create_to_json: true
          field_rename: snake
          explicit_to_json: true

      retrofit_generator:
        generate_for:
          exclude:
            - test/**.dart
          include:
            - lib/**/*{data_source,http_client}.dart

      stacked_generator:
        stackedBottomsheetGenerator:
          generate_for:
            exclude:
              - test/**.dart
            include:
              - lib/**/*_bottom_sheet.dart

        stackedDialogGenerator:
          enabled: false

        stackedLocatorGenerator:
          enabled: false

        stackedFormGenerator:
          enabled: true
          generate_for:
            exclude:
              - test/**.dart
            include:
              - lib/**/*_view.dart

        stackedLoggerGenerator:
          enabled: true
          generate_for:
            exclude:
              - test/**.dart
            include:
              - lib/**/*_view.dart
              - lib/core/setup/config/logger.dart
              - lib/core/setup/circles_app.dart

        stackedRouterGenerator:
          enabled: true
          generate_for:
            exclude:
              - test/**.dart
            include:
              - lib/**/*_{view,navigator,screen}.dart
              - lib/core/setup/config/routes.dart

Although this reduces the time it takes to run codegen, using this method without proper code architecture will be a nightmare, causing even more problem in the longer run.

That's it for today. If you have any questions on the topic you want me to write about, please feel free to write in comments. I will try to cover as much topics as I can.

Thank you for joining me on this journey, and happy coding! 💻👨💻

Facilitating content sharing via external apps boosts user engagement, improves the user experience, and helps to spread the word about our app.

In this article, we'll be taking advantage of the awesome share_handler package to make sharing from external apps to our Flutter app really easy!

We will be using a multi-flavored flutter app as our starting point for this tutorial. You can find the repo here

🥳 Sounds great, right?

Let's get started by adding share_handler as a dependency in pubspec.yaml

Android setup 🤖

We will start with the easy setup. In our android/app/src/main/AndroidManifest.xml file, we will add the intent filters and metadata for the media types we want to support.

For text-only support

<intent-filter>
    <action android:name="android.intent.action.SEND" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="text/*" />
</intent-filter>

For image-only support

<intent-filter>
    <action android:name="android.intent.action.SEND" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="image/*" />
</intent-filter>

For video-only support

<intent-filter>
    <action android:name="android.intent.action.SEND" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="video/*" />
</intent-filter>

If you want to support any type of files

<intent-filter>
    <action android:name="android.intent.action.SEND" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="**/*" />
</intent-filter>

💡 Tip: You can add SHARE_MULTIPLE action, if you want to support more than one media sharing.

<intent-filter>
    <action android:name="android.intent.action.SEND_MULTIPLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="image/*" />
</intent-filter>
<intent-filter>
    <action android:name="android.intent.action.SEND_MULTIPLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="video/*" />
</intent-filter>
<intent-filter>
    <action android:name="android.intent.action.SEND_MULTIPLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="*/*" />
</intent-filter>

💡Tip: You can change the android:mimeType accordingly for the file types.

Also, if you want to prevent the incoming shares from opening a new activity each time, you can prevent this by changing android:launchMode to singleTask

<activity
...
android:lunchMode="singleTask"
...
>
...
</activity>

For adding our app in share suggestions and shortcuts, we can create a new file share_targets.xml in android/app/src/main/res/xml/share_targets.xml

<?xml version="1.0" encoding="utf-8"?>
<shortcuts xmlns:android="http://schemas.android.com/apk/res/android">
  <share-target
    android:targetClass="@{'np.com.saileshdahal.sharing'+@strings/app_id_suffix+'.dynamic_share_target'}">
    <data android:mimeType="*/*" />
    <category
      android:name="@{'np.com.saileshdahal.sharing'+@strings/app_id_suffix+'.dynamic_share_target'}" />
  </share-target>
</shortcuts>

💡 Tip: Make sure you have app_id_suffix resource string defined for each flavor.

resValue "string", "app_id_suffix", applicationIdSuffix

If you are not using flavors, you can define this in the following format.

<?xml version="1.0" encoding="utf-8"?>
<shortcuts xmlns:android="http://schemas.android.com/apk/res/android">
    <share-target android:targetClass="{your.package.identifier}.MainActivity">
        <data android:mimeType="*/*" />
        <category android:name="{your.package.identifier}.dynamic_share_target" />
    </share-target>
</shortcuts>

Now, we will add a metadata field in the AndroidManifest.xml file.

<meta-data
    android:name="android.service.chooser.chooser_target_service"
    android:value="androidx.sharetarget.ChooserTargetServiceCompat" />
<meta-data
    android:name="android.app.shortcuts"
    android:resource="@xml/share_targets" />

Once done, if you try to share something, you should see the app icon on the share page.

iOS setup 📱

Update Runner Info.plist

For iOS, let's get started by editing our Info.plist file. We will be registering a deep link that will be launched by Share Extension.

For registering the deep link, add the following in your Info.plist

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>ShareMedia-$(PRODUCT_BUNDLE_IDENTIFIER)</string>
        </array>
    </dict>
</array>

If you already have some entries for CFBundleURLTypes, you can add a new entry like this.

<key>CFBundleURLTypes</key>
<array>
    ...
    <dict>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>ShareMedia-$(PRODUCT_BUNDLE_IDENTIFIER)</string>
        </array>
    </dict>
    ...
</array>

💡 Tip: Make sure you have a user-defined variable PRODUCT_BUNDLE_IDENTIFIER for your iOS project.

Make sure you have an entry for NSPhotoLibraryUsageDescription if you are planning to share images.

<key>NSPhotoLibraryUsageDescription</key>
<string>Photos can be shared to and used in this app</string>

If you are planning to add AirDrop support, add the following entry in Info.plist.

<key>LSSupportsOpeningDocumentsInPlace</key>
<string>No</string>
<key>CFBundleDocumentTypes</key>
<array>
    <dict>
        <key>CFBundleTypeName</key>
        <string>ShareHandler</string>
        <key>LSHandlerRank</key>
        <string>Alternate</string>
        <key>LSItemContentTypes</key>
        <array>
            <string>public.file-url</string>
            <string>public.image</string>
            <string>public.text</string>
            <string>public.movie</string>
            <string>public.url</string>
            <string>public.data</string>
        </array>
    </dict>
</array>

💡 You can modify LSItemContentTypes array based on your need.

Share Extension setup

Now for this part, we will create a share extension from Xcode.

• Open ios folder of your flutter project in Xcode.

open ios/Runner.xcworkspace

• Go to File -> New -> Target

• Search for Share Extension and hit Next

Now create the extension with ShareExtension name, and hit save. This will add a new target for your project.

🚨 Note: Make sure the name is ShareExtension

🚨 IMPORTANT: Make sure the minimum deployment version of both targets is the same.

For Target -> Runner, set minimum deployment version to 14.0.

Similarly for Target-> ShareExtension, set minimum deployment version to 14.0

Once this is done, open ios/ShareExtension/ShareViewController.swift and replace everything with following

import share_handler_ios_models

class ShareViewController: ShareHandlerIosViewController {}

🚨 Note: Make sure to run flutter pub get and pod install --repo-update

If you have multiple flavors set up then we will also have to create multiple flavors for our share extension. We will create 3 different schemes for share extension too.

Go to Manage Scheme, and then we will duplicate and create 3 different schemes for ShareExtension as ShareExtension-production, ShareExtension-development and ShareExtension-staging.

Rename ShareExtension to ShareExtension-production that will handle one scheme, and then for staging, we can duplicate ShareExtension-production and rename it to ShareExtension-staging and assign the correct configuration.

Similarly, we will create one scheme for ShareExtension-development as well.

🚨 Note: You don't have to duplicate the schemes if you are not using flavors.

Share Extension Info.plist update

Once this is done, we will make some changes to ios/ShareExtension/Info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CFBundleVersion</key>
    <string>$(FLUTTER_BUILD_NUMBER)</string>
    <key>NSExtension</key>
    <dict>
      <key>NSExtensionAttributes</key>
      <dict>
        <key>IntentsSupported</key>
        <array>
          <string>INSendMessageIntent</string>
        </array>
        <key>NSExtensionActivationRule</key>
        <dict>
          <key>NSExtensionActivationSupportsWebURLWithMaxCount</key>
          <integer>999</integer>
          <key>NSExtensionActivationSupportsWebPageWithMaxCount</key>
          <integer>999</integer>
          <key>NSExtensionActivationSupportsMovieWithMaxCount</key>
          <integer>999</integer>
          <key>NSExtensionActivationSupportsImageWithMaxCount</key>
          <integer>999</integer>
          <key>NSExtensionActivationSupportsFileWithMaxCount</key>
          <integer>999</integer>
          <key>NSExtensionActivationSupportsAttachmentsWithMaxCount</key>
          <integer>999</integer>
          <key>NSExtensionActivationSupportsText</key>
          <true />
        </dict>
        <key>PHSupportedMediaTypes</key>
        <array>
          <string>Video</string>
          <string>Image</string>
        </array>
      </dict>
      <key>NSExtensionMainStoryboard</key>
      <string>MainInterface</string>
      <key>NSExtensionPointIdentifier</key>
      <string>com.apple.share-services</string>
    </dict>
  </dict>
</plist>

Here you can make changes to the NSExtensionActivationRule field based on your requirements.

Note: Here we have set the maximum file-sharing count to 999, but you can disable or enable them based on your requirements.

Once this is done, make sure we have different bundle identifiers for each flavor and configuration for Share Extension. If you click Target -> Share Extension -> Singing & Capabilities -> All

🚨 Note: Make sure the ShareExtension bundle identifier for each config has a .ShareExtension prefix compared to the Runner.

Once done, we need to assign both targets with a group identifier. For both Runner and ShareExtension target, go to Signing & Capabilities.

Now, for each flavor, we will add an app group.

🚨 Note: Make sure to add the group id as group.<bundle identifier> for each flavor.

For Debug-production, Release-production, and Profile-production.

💡 Tip: For matching group, you can select the check box

For Debug-development, Release-development, and Profile-development.

Similarly for Debug-staging, Release-staging, and Profile-staging

If you click on Target -> Runner -> Signing & Capabilities -> All, you should see the following.

This will create entitlements files for each configuration.

Similarly for ShareExtension we can quickly create .entitlements files. In ios/ShareExtension we will create an entitlements file for each config and each flavor. We will create 9 entitlements files for each flavor (production, development, and staging), and Debug, Release, and Profile config.

For Debug, Release, and Profile configuration for development flavor, we will create three files ShareExtensionRelease-development.entitlements, ShareExtensionDebug-development.entitlements, and ShareExtensionProfile-development.entitlements, with the following contents.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.application-groups</key>
    <array>
        <string>group.np.com.saileshdahal.sharing.dev</string>
    </array>
</dict>
</plist>

Similarly, for each configuration of production and staging flavor, we will create three entitlements files.

By the end, we will have the following files

ShareExtensionDebug-development.entitlements
ShareExtensionDebug-production.entitlements
ShareExtensionDebug-staging.entitlements
ShareExtensionProfile-development.entitlements
ShareExtensionProfile-production.entitlements
ShareExtensionProfile-staging.entitlements
ShareExtensionRelease-development.entitlements
ShareExtensionRelease-production.entitlements
ShareExtensionRelease-staging.entitlements

Once this is done, link the entitlement files by clicking + button for app group capabilities for each flavor.

💡Tip: Make sure the entitlements files are correctly linked, else this may not work properly for each flavor.

Make sure, we have all the entitlements files linked up correctly. If we do everything right we will see the following.

🚨 For iOS setup without flavors

All the setup above can be taken reference for the apps without flavors as well. The only difference here is, we can have single entitlements file for each target, that is Runner.entitlements and ShareExtension.entitlements.

The bundle id for the Share Extension will be np.com.saileshdahal.sharing.ShareExtension, and the group bundle id will be group.np.com.saileshdahal.sharing

Now, for the final setup, we will make some changes in Podfile and register the dependency.

target 'Runner' do
  use_frameworks!
  use_modular_headers!

  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))

  # Add this block
  target 'ShareExtension' do
    inherit! :search_paths
    pod "share_handler_ios_models", :path => ".symlinks/plugins/share_handler_ios/ios/Models"
  end
  # End of block

end

Once this is done, run pod install --repo-update in ios directory.

🚨Note that pod install --repo-update gives an error: [!] No podspec found for share_handler_ios_models in .symlinks/plugins/share_handler_ios/ios/Modelsuntil the project has been built at least once, at which point Flutter has created the referenced symlink.

🥳 Thanks Guyren Howe for mentioning this in the comments.

🧪 Testing time

Let's check if we can see our app when we share something.

Here, we can see both flavors appear while we try to share images from photos.

Getting shared media in Flutter

Now that we have both Android and iOS working, we can start implementing our share handler service to get the shared media.

The package exposes a stream of SharedMedia. We can subscribe to this stream and do side effects based on the shared media type.

Also, the package has a method to get the initial shared media. This will be helpful if the app is in terminated state, and we open the app from the share page.

I have added the code snippet from share_handler

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

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  StreamSubscription<SharedMedia>? _streamSubscription;
  SharedMedia? media;

  @override
  void initState() {
    super.initState();
    initPlatformState();
  }

  @override
  void dispose() {
    _streamSubscription?.cancel();
    super.dispose();
  }

  Future<void> initPlatformState() async {
    final handler = ShareHandlerPlatform.instance;
    media = await handler.getInitialSharedMedia();
    _streamSubscription = handler.sharedMediaStream.listen((SharedMedia media) {
      if (!mounted) return;
      setState(() => this.media = media);
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Share Handler'),
      ),
      body: ListView(
        padding: const EdgeInsets.all(16),
        children: <Widget>[
          Text(
            'Shared to conversation identifier: ${media?.conversationIdentifier}',
          ),
          const SizedBox(height: 10),
          Text('Shared text: ${media?.content}'),
          const SizedBox(height: 10),
          Text('Shared files: ${media?.attachments?.length}'),
          ...(media?.attachments ?? []).map((attachment) {
            final path = attachment?.path;
            if (path != null &&
                attachment?.type == SharedAttachmentType.image) {
              return Column(
                children: [
                  ElevatedButton(
                    onPressed: () {
                      ShareHandlerPlatform.instance.recordSentMessage(
                        conversationIdentifier:
                            'custom-conversation-identifier',
                        conversationName: 'John Doe',
                        conversationImageFilePath: path,
                        serviceName: 'custom-service-name',
                      );
                    },
                    child: const Text('Record message'),
                  ),
                  const SizedBox(height: 10),
                  Image.file(File(path)),
                ],
              );
            }
            return Text(
              '${attachment?.type} Attachment: ${attachment?.path}',
            );
          }),
        ],
      ),
    );
  }
}

Now, if we run this code and try to share an image from Photos, we should see something like this 🥳.

🎉 Congratulations, we've reached the end of this article on how to easily share content from external apps to your Flutter app using the share_handler package! 🚀 Hopefully, you found this tutorial helpful and have learned a lot about effortless sharing in Flutter.

As always, the source code for this tutorial can be found on the GitHub repository at saileshbro/sharing_into_flutter_app. If you found this article useful, don't forget to leave a ⭐️ and share it with others.

And if you're interested in learning more about setting up flavors in Flutter, be sure to check out 🍰 Simplifying flavor setup in the existing Flutter app: A comprehensive guide to learn how to add different flavors to your app with unique configurations and build targets.

Thank you for joining me on this journey, and happy coding! 💻👨‍💻

References

• share_handler

• Flavors allow efficient management of different development environments (development, staging, production)

• Enables creation of multiple versions of the same app (free and paid versions, separate environments for feature development)

• Simplifies setting different parameters (API endpoints, API keys, app icons) for each configuration

• Makes it easier to manage different app versions

Apps created using the very_good_cli comes with three flavors - development, staging, and production.

Adding Flavors to an Existing Flutter App

When it comes to adding flavors to an existing Flutter app, there are packages available that promise to automate the process, such as flutter_flavorizr.

It's common for these solutions to encounter issues when the app has already made extensive use of native plugins and custom configurations.

As a result, manually adding flavors to an app may be the best course of action. This process requires a bit of human touch, but it provides complete control over the configuration of your app's flavors.

Setting Up Flavors 🛠️

To get a hands-on experience, we will be adding flavors to an existing app from here

We will be setting up development, staging and production flavors.

Create Target Files 💻

We will start by creating three main files for each flavor, main_<flavor>.dart and create a main function.

We can replace the outdated main.dart file with our new entry points. In the bootstrap.dart file, we'll create a new function called bootstrap which will accept the environment from each entry point and use it to launch the app.

• main_production.dart

void main() => bootstrap('production');

• main_development.dart

void main() => bootstrap('development');

• main_staging.dart

void main() => bootstrap('staging');

• bootstrap.dart

void bootstrap(String env) => runApp(MyApp(env: env));

class MyApp extends StatelessWidget {
  const MyApp({super.key, required this.env});
  final String env;

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      builder: (context, child) {
        if (env == 'production') return child!;
        return Banner(
          message: env.toUpperCase(),
          location: BannerLocation.topEnd,
          child: child,
        );
      },
      theme: ThemeData(
        fontFamily: 'Montserrat',
      ),
      home: const HomePage(),
    );
  }
}

Since setting up flavors in android is pretty straightforward, we will start with it so we can test it quickly.

Using flavors in Android 🤖

To add production, staging and development flavors, let's make some changes in the app level build.gradle in android/app/build.gradle file.

Here, let's specify a flavorDimensions and a productFlavors object.

    flavorDimensions 'default'
    productFlavors {
        production {
            dimension 'default'
            resValue "string", "app_name", "FITNESS"
        }
        development {
            dimension 'default'
            applicationIdSuffix '.dev'
            versionNameSuffix '.dev'
            resValue "string", "app_name", "FITNESS.DEV"
        }

        staging {
            dimension 'default'
            applicationIdSuffix '.stg'
            versionNameSuffix '.stg'
            resValue "string", "app_name", "FITNESS.STG"
        }
    }

The flavorDimensions line defines the name of the flavor dimension, which is default in this case. Each flavor is defined within the productFlavors block. The production flavor is the base flavor of the app.

The development and staging flavors are similar, but with some differences. The applicationIdSuffix and versionNameSuffix lines add the .dev or .stg suffix to the application ID and version name, respectively. The resValue line sets the name of the app to FITNESS.DEV or FITNESS.STG, respectively.

NOTE: Don't forget to add android:label="@string/app_name" to the application tag in AndroidManifest.xml file.

Let's Test 🧪

Now, we can run the app using the following commands.

flutter run --flavor development --target lib/main_development.dart
flutter run --flavor staging --target lib/main_staging.dart
flutter run --flavor production --target lib/production.dart

Once done, you should have three different apps with different names, versions, and bundle identifiers.

iOS Schemas

We will now be creating schemas for each flavor in Xcode. We already have a Runner schema, which is the default schema. We will rename it to production and create two new schemas, development and staging.

• Open the ios folder in Xcode.

open ios/Runner.xcworkspace

• Let's make some changes to our configuration.

• In Project Runner, rename Debug, Release, and Profile adding -production suffixes to each.

• Once done, we will now create these 3 files for each staging and development as well. You can use duplicate.

• Once done, we will have 9 configurations, 3 for each flavor.

• Select the Runner scheme and click the Manage Schemes button.

• Once, there rename Runner scheme to production, and duplicate production to two new development and staging.

• Make sure to add the correct configuration while duplicating.

Similarly, create a development scheme with the correct configuration.

Once you are done with schemes, you will have something like this.

NOTE: Make sure all three schemes have correct configuration, don't forget to recheck production scheme configuration.

• Now, let's add the bundle identifier for each configuration. In Target-> Runner, click Build Settings and search for Product Bundle Identifier.

Add the suffix as required.

Once you are done, you will have something like this.

• Finally, we will create a new User Defined Variable called APP_DISPLAY_NAME which will have a different name for each configuration.

In same Target -> Runner -> Build Settings, click on the + button, and create a new user-defined variable.

Once, you are done with the user-defined variable, you need to change the Info.plist to use this variable.

<key>CFBundleName</key>
<string>$(APP_DISPLAY_NAME)</string>
<key>CFBundleDisplayName</key>
<string>$(APP_DISPLAY_NAME)</string>

Let's Test 🧪

Similar to android, we can test iOS by running the following commands.

flutter run --flavor development --target lib/main_development.dart
flutter run --flavor staging --target lib/main_staging.dart
flutter run --flavor production --target lib/production.dart

App Icons for Android and iOS 🎨

🎆 Let's make it look pretty!

Now, let's have different icons based on the flavors. We will have 3 different icons for each flavor.

We will use flutter_launcher_icons to generate the launch icons. Install it as a dev dependency.

flutter pub add flutter_launcher_icons --dev

Once this is done, we will create flutter_launcher_icons-<flavor>.yaml files for each flavor.

• flutter_launcher_icons-development.yaml

flutter_icons:
  android: true
  ios: true
  remove_alpha_ios: true
  image_path: "assets/icons/dev-icon.png"

• flutter_launcher_icons-staging.yaml

flutter_icons:
  android: true
  ios: true
  remove_alpha_ios: true
  image_path: "assets/icons/stg-icon.png"

• flutter_launcher_icons-production.yaml

flutter_icons:
  android: true
  ios: true
  remove_alpha_ios: true
  image_path: "assets/icons/prod-icon.png"

Now to generate the launch icons we need to run

flutter pub run flutter_launcher_icons:main -f flutter_launcher_icons-*

This will generate all the icons.

Finally, we will set the icons to be dynamic in Xcode.

• In Runner -> Assets.xcassets we can see that we have all the required icons. We can remove the AppIcon , which is unused.

• Now, in Target-> Runner -> Build Settings, search for primary app icon.

• Now, set the corresponding suffix to each one.

Final Result 🎉

Now, if we run the app, for all the flavors, we will have different icons, names, versions, and bundle identifiers.

NOTE: Make sure to uninstall the previous builds before running the app.

🎊 Bonus

For easy usage, we can create some launch configs for Visual Studio Code and Android Studio.

For Visual Studio Code

Create a new file in .vscode/launch.json with the following content.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "DEV | DEBUG",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_development.dart",
      "args": [
        "--flavor",
        "development",
        "--target",
        "lib/main_development.dart"
      ],
      "flutterMode": "debug"
    },
    {
      "name": "DEV | RELEASE",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_development.dart",
      "args": [
        "--flavor",
        "development",
        "--target",
        "lib/main_development.dart"
      ],
      "flutterMode": "release"
    },
    {
      "name": "DEV | PROFILE",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_development.dart",
      "args": [
        "--flavor",
        "development",
        "--target",
        "lib/main_development.dart"
      ],
      "flutterMode": "profile"
    },
    {
      "name": "STG | DEBUG",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_staging.dart",
      "args": [
        "--flavor",
        "staging",
        "--target",
        "lib/main_staging.dart"
      ],
      "flutterMode": "debug"
    },
    {
      "name": "STG | RELEASE",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_staging.dart",
      "args": [
        "--flavor",
        "staging",
        "--target",
        "lib/main_staging.dart"
      ],
      "flutterMode": "release"
    },
    {
      "name": "STG | PROFILE",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_staging.dart",
      "args": [
        "--flavor",
        "staging",
        "--target",
        "lib/main_staging.dart"
      ],
      "flutterMode": "profile"
    },
    {
      "name": "PROD | DEBUG",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_production.dart",
      "args": [
        "--flavor",
        "production",
        "--target",
        "lib/main_production.dart"
      ],
      "flutterMode": "debug"
    },
    {
      "name": "PROD | RELEASE",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_production.dart",
      "args": [
        "--flavor",
        "production",
        "--target",
        "lib/main_production.dart"
      ],
      "flutterMode": "release"
    },
    {
      "name": "PROD | PROFILE",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_production.dart",
      "args": [
        "--flavor",
        "production",
        "--target",
        "lib/main_production.dart"
      ],
      "flutterMode": "profile"
    },
  ]
}

This will create the launch config with all the args.

For Android Studio

For Android Studio, you can get the configuration files from here, for all the configs.

🎉 Congrats! We've made it to the end of our exploration of Flutter Flavors! 🚀 We've successfully learned how to add different flavors to our flutter application, each with its own unique configurations and build targets.

It's just the tip of the iceberg when it comes to the use cases of flavors in Flutter. For instance, you can inject dependencies based on the flavor you are using, which can entirely change the behavior of your app. The possibilities are endless!

As always, you can refer back to the Github repository for this tutorial at https://github.com/saileshbro/fitness_app_clone if you need any help. Don't forget to give it a ⭐️ and help spread the word about this amazing project. If you get stuck or need assistance, feel free to submit an issue or contribute a pull request.

Thank you for joining me on this journey; let's create even more amazing applications together. Have fun coding! 💻👨‍💻

References

• Flutter Flavors, App Icons, and Firebase Tutorial - Marcus Ng

• Creating flavors for Flutter

• Android Developers - Build Variants: Flavor Dimensions

We've covered everything from bootstrapping an empty Flutter project, importing necessary dependencies, setting up the folder structure, integrating the frontend with the backend, and implementing the Todo data sources, repositories, and view models.

In this part, we'll show you how to utilize dart frog to establish user authentication with JSON Web Tokens (JWT). By the end of this article, we will be able to:

• Implement user login and register.

• Create User model.

• Create and implement UserRepository and UserDataSource.

• Handle UnauthorizedException.

• Create a new authorization middleware.

• Implement user authentication using JWT.

• Secure routes with Authorization headers.

Don't forget to check out the GitHub repo for this article if you need any assistance along the way.

Let's get started 🚀

Overview 🔍

👀 Get a sneak peek of what's to come 🔮

When we're done, we should have an app that supports the following requests:

1. /todos* - Guard all to-do routes with Authorization header.

curl -s -L -X POST 'http://localhost:8080/todos' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjY5ZWFkZTg3LWRhNWUtNDRjZC1iNTRlLTQ3NGE4NWQ4ZGVlNCIsIm5hbWUiOiJTYWlsZXNoIERhaGFsIiwiZW1haWwiOiJzYWlsZXNoYnJvQGdtYWlsLmNvbSIsImNyZWF0ZWRfYXQiOiIyMDIzLTAxLTIzVDIyOjU0OjM4Ljg2NDkxMloiLCJwYXNzd29yZCI6IiQyYSQxMCR6VjBTZlI3cUpHOHlCelJWWThtNkRlMWo0UUtHL2VRdXl6NzduQ1lBL1luZENtb1ZSbzB0RyIsImlhdCI6MTY3NDQ5Mzc3OX0.W36mHXKFrxZDhz0Hrxt0Cmrz3WNVexiAZe2KAjrWMaE' -H 'Content-Type: application/json' --data-raw '{
    "title":"this is a title asdf",
    "description":"Not so great description asdf"
}'

1. /users/login - Login user

curl -s -L -X POST 'http://localhost:8080/users/login' -H 'Content-Type: application/json' --data-raw '{
    "email":"saileshbro@gmail.com",
    "password":"6aMj@UBByu"
}'

1. /users/signup - Register new user

curl -s -L -X POST 'http://localhost:8080/users/signup' -H 'Content-Type: application/json' --data-raw '{
    "email":"saileshbro@gmail.com",
    "name":"Sailesh Dahal",
    "password":"6aMj@UBByu%7BzN^C9tMe#Te4b!4cJrXwwFi#HgKrQ&g&"
}'

Updating Database 🛠️

💾 Upgrading our database to its full potential 🚀

To begin, we will create a new table called users and add a foreign key to our current todos table. This ensures that each to-do item is associated with a single user, and that data is accessible only to that person.

Create users table

We will create a new users table with the following columns.

• id : unique uuid

• name : name of the user

• email : email of the user

• password : hashed password of the user

• created_at : timestamp of when the user was created

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE TABLE users(
    id uuid DEFAULT uuid_generate_v4() PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email TEXT NOT NULL,
      password TEXT NOT NULL,
    created_at timestamp default current_timestamp NOT NULL
);

The uuid-ossp extension is used to generate unique IDs for each user.

Updating todos table

We will update the todos table to include a foreign key to the users table.

TRUNCATE TABLE todos;
ALTER TABLE todos
    ADD COLUMN user_id uuid NOT NULL,
    ADD CONSTRAINT constraint_fk
        FOREIGN KEY (user_id)
            REFERENCES users (id)
            ON DELETE CASCADE;

The ON DELETE CASCADE clause ensures that when a user is deleted, all their to-do items will be deleted.

Once we are done with the changes, we can proceed to create a user schema in our models package.

More about CONSTRAINTS here.

Create User model

🧑‍💼 Defining our User Model 📝

We will start by creating a UserId in our typedefs package.

Create UserId type

In typedefs package, we will make some changes. We will rename the older src/typedefs.dart file to src/todo_types.dart and create a new src/user_types.dart file.

typedef UserId = String;

💡 Make sure to update the exports.

library typedefs;

export 'src/todo_types.dart';
export 'src/user_types.dart';

Update folder structure

In models package, we will create a new user.dart file. Since we are creating models for a different feature, we will mode the todo specific models to a new todo folder.

.
├── create_todo_dto
│   └── create_todo_dto.dart
├── todo.dart
└── update_todo_dto
    └── update_todo_dto.dart

Also, make sure to export create_todo_dto and update_todo_dto from todo.dart

import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:models/src/serializers/date_time_converter.dart';
import 'package:typedefs/typedefs.dart';

export './create_todo_dto/create_todo_dto.dart';
export './update_todo_dto/update_todo_dto.dart';

part 'todo.freezed.dart';
part 'todo.g.dart';

Create User model

Now, we will create a User model in src/user/user.dart file.

import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:models/src/serializers/date_time_converter.dart';
import 'package:typedefs/typedefs.dart';

part 'user.freezed.dart';
part 'user.g.dart';

@freezed
class User with _$User {
  const factory User({
    required UserId id,
    required String name,
    required String email,
    @DateTimeConverter() required DateTime createdAt,
    @Default('') @JsonKey(includeToJson: false) String password,
  }) = _User;

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

We are ignoring the password field when serializing the model to JSON. This is because we don't want to send the password to the client.

Similarly, we will create CreateUserDto and LoginUserDto for creating and logging in users.

In src/user/create_user_dto/create_user_dto.dart file,

import 'package:either_dart/either.dart';
import 'package:exceptions/exceptions.dart';
import 'package:failures/failures.dart';
import 'package:freezed_annotation/freezed_annotation.dart';

part 'create_user_dto.freezed.dart';
part 'create_user_dto.g.dart';

@freezed
class CreateUserDto with _$CreateUserDto {
  factory CreateUserDto({
    required String name,
    required String email,
    required String password,
  }) = _CreateUserDto;

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

  static Either<ValidationFailure, CreateUserDto> validated(
    Map<String, dynamic> json,
  ) {
    try {
      final errors = <String, List<String>>{};
      final name = json['name'] as String? ?? '';
      final email = json['email'] as String? ?? '';
      final password = json['password'] as String? ?? '';
      if (name.isEmpty) {
        errors['name'] = ['Name is required'];
      }
      if (email.isEmpty) {
        errors['email'] = ['Email is required'];
      }
      if (!email.contains('@')) {
        errors['email'] = ['Email is invalid'];
      }
      if (password.isEmpty) {
        errors['password'] = ['Password is required'];
      }
      if (password.length < 6) {
        errors['password'] = ['Password must be at least 6 characters'];
      }

      if (errors.isEmpty) return Right(CreateUserDto.fromJson(json));
      throw BadRequestException(
        message: 'Validation failed',
        errors: errors,
      );
    } on BadRequestException catch (e) {
      return Left(
        ValidationFailure(
          message: e.message,
          errors: e.errors,
          statusCode: e.statusCode,
        ),
      );
    }
  }
}

Similarly, we will create a new login_user_dto.

import 'package:either_dart/either.dart';
import 'package:exceptions/exceptions.dart';
import 'package:failures/failures.dart';
import 'package:freezed_annotation/freezed_annotation.dart';

part 'login_user_dto.freezed.dart';
part 'login_user_dto.g.dart';

@freezed
class LoginUserDto with _$LoginUserDto {
  factory LoginUserDto({
    required String email,
    required String password,
  }) = _LoginUserDto;

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

  static Either<ValidationFailure, LoginUserDto> validated(
    Map<String, dynamic> json,
  ) {
    try {
      final errors = <String, List<String>>{};
      final email = json['email'] as String? ?? '';
      final password = json['password'] as String? ?? '';
      if (email.isEmpty) {
        errors['email'] = ['Email is required'];
      }
      if (password.isEmpty) {
        errors['password'] = ['Password is required'];
      }
      if (errors.isEmpty) return Right(LoginUserDto.fromJson(json));
      throw BadRequestException(
        message: 'Validation failed',
        errors: errors,
      );
    } on BadRequestException catch (e) {
      return Left(
        ValidationFailure(
          message: e.message,
          errors: e.errors,
          statusCode: e.statusCode,
        ),
      );
    }
  }
}

These data transfer objects will be used to send, receive and validate data from the client in the backend.

💡 Make sure to export create_user_dto and login_user_dto from user.dart, and user.dart from models.dart

import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:models/src/serializers/date_time_converter.dart';
import 'package:typedefs/typedefs.dart';

export './create_user_dto/create_user_dto.dart';
export './login_user_dto/login_user_dto.dart';

part 'user.freezed.dart';
part 'user.g.dart';

library models;

export 'src/todo/todo.dart';
export 'src/user/user.dart';

💡 Make sure to run flutter pub run build_runner build to generate new files.

Creating UserDataSource

📊 Building the foundation for user management with UserDataSource 🛠️

In data_source package, we will create a new interface called UserDataSource in data_source/lib/src/user_data_source.dart

import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

abstract class UserDataSource {
  Future<User> getUserById(UserId id);

  Future<User> createUser(CreateUserDto user);

  Future<User> getUserByEmail(String email);
}

We will have methods to query and create users. We will do the implementation in our backend.

Creating UserRepository

🔍 Designing our User Management System with UserRepository 🛠️

We will also create an interface called UserRepository which will return either a failure or valid data making use of UserDataSource.

In repository package, we will create a new interface called UserRepository in repository/lib/src/user_repository.dart

import 'package:either_dart/either.dart';
import 'package:failures/failures.dart';
import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

abstract class UserRepository {
  Future<Either<Failure, User>> getUserById(UserId id);

  Future<Either<Failure, User>> createUser(CreateUserDto createUserDto);

  Future<Either<Failure, User>> loginUser(LoginUserDto loginUserDto);

  Future<Either<Failure, User>> getUserByEmail(String email);
}

We will have all the methods we need to create, query and login users. We will do the implementation in our backend.

💡 Make sure to export UserRepository from repository.dart

library repository;

export 'src/todo_repository.dart';
export 'src/user_repository.dart';

Implementing UserDataSource

💻 Bringing UserDataSource to life 🔧

Now, we will implement UserDataSource in our backend. In backend/lib/user/data_source/user_data_source_impl.dart, we will create a new class called UserDataSourceImpl which will implement UserDataSource.

This is how an empty implementation of UserDataSourceImpl will look like.

import 'package:data_source/data_source.dart';
import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

class UserDataSourceImpl implements UserDataSource {
  UserDataSourceImpl(this._databaseConnection);

  final DatabaseConnection _databaseConnection;
  Future<User> createUser(CreateUserDto user) {
    throw UnimplementedError();
  }

  @override
  Future<User> getUserByEmail(String email) {
    throw UnimplementedError();
  }

  @override
  Future<User> getUserById(UserId id) {
    throw UnimplementedError();
  }
}

Implementing createUser method

Now, we will implement createUser method. We will use DatabaseConnection to connect to our database and create a new user from the dto we received.

  @override
  Future<User> createUser(CreateUserDto user) async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        '''
        INSERT INTO users (name, email, password)
        VALUES (@name, @email, @password) RETURNING *
        ''',
        substitutionValues: user.toJson(),
      );
      if (result.affectedRowCount == 0) {
        throw const ServerException('Failed to create todo');
      }
      final userMap = result.first.toColumnMap();
      return User.fromJson(userMap);
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

We will validate the DTO in the repository before passing it to the data source. The database will then be queried to generate a new user. We will throw a ServerException if the user is not created, else, we will return the user that was created.

Implementing getUserByEmail method

  @override
  Future<User> getUserByEmail(String email) async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        '''
        SELECT id, name, email, password, created_at
        FROM users WHERE email = @email
        ''',
        substitutionValues: {'email': email},
      );
      if (result.isEmpty) {
        throw const NotFoundException('User not found');
      }
      return User.fromJson(result.first.toColumnMap());
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

Here, we will query the database for the user with the given email. If the user is not found, we will throw a NotFoundException. We will handle this exception in the UserController and return a 404 response.

Implementing getUserById method

@override
  Future<User> getUserById(UserId id) async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        'SELECT id, name, email, created_at FROM users WHERE id = @id',
        substitutionValues: {'id': id},
      );
      if (result.isEmpty) {
        throw const NotFoundException('User not found');
      }
      return User.fromJson(result.first.toColumnMap());
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

We will query the database for the user with the given id. If the user is not found, we will throw a NotFoundException. We will handle this exception in the UserController and return a 404 response.

Creating PasswordHasherService

🔑 Keeping user passwords safe with PasswordHasherService 🔒

We will create a new service to hash and validate hashed passwords before going on to the UserRepository implementation. The CreateUserDto with the hashed password will be passed to the UserRepository.

In backend/lib/services/password_hasher_service.dart, we will create a new class called PasswordHasherService.

We will use bcrypt package to hash and verify the password.

flutter pub add bcrypt

import 'package:bcrypt/bcrypt.dart';

class PasswordHasherService {
  const PasswordHasherService();

  String hashPassword(String password) {
    return BCrypt.hashpw(password, BCrypt.gensalt());
  }

  bool checkPassword(String password, String hashedPassword) {
    return BCrypt.checkpw(password, hashedPassword);
  }
}

Now, we can pass this service as a dependency to UserRepository when we implement our repository.

Implementing UserRepository

💻 Bringing UserRepository to life 🔧

Now, we will implement UserRepository in our backend. In backend/lib/user/repository/user_repository_impl.dart, we will create a new class called UserRepositoryImpl which will implement UserRepository.

import 'package:backend/services/password_hasher_service.dart';
import 'package:data_source/data_source.dart';
import 'package:either_dart/either.dart';
import 'package:failures/failures.dart';
import 'package:models/models.dart';
import 'package:repository/repository.dart';
import 'package:typedefs/typedefs.dart';

class UserRepositoryImpl implements UserRepository {
  UserRepositoryImpl(this.dataSource, this.passwordHasherService);

  final UserDataSource dataSource;
  final PasswordHasherService passwordHasherService;

  @override
  Future<Either<Failure, User>> createUser(CreateUserDto createUserDto) {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, User>> getUserByEmail(String email) {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, User>> getUserById(UserId id) {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, User>> loginUser(LoginUserDto loginUserDto) {
    throw UnimplementedError();
  }
}

Implementing getUserByEmail method

We will start by implementing getUserByEmail. We will use the data source's dataSource.getUserByEmail method to see if we get a User object. If we get a User object, we shall wrap it in a Right object and return it. If an error occurs, we will return a Left object along with a ServerFailure object.

  @override
  Future<Either<Failure, User>> getUserByEmail(String email) async {
    try {
      final user = await dataSource.getUserByEmail(email);
      return Right(user);
    } catch (e) {
      log(e.toString());
      return const Left(
        ServerFailure(
          message: 'User with this email does not exist',
          statusCode: HttpStatus.notFound,
        ),
      );
    }
  }

Implementing getUserById method

Similarly, we will call dataSource.getUserById method and see whether we get a User object. If we get a User object, we shall wrap it in a Right object and return it. If an error occurs, we will return a Left object along with a ServerFailure object.

  @override
  Future<Either<Failure, User>> getUserById(UserId id) async {
    try {
      final res = await dataSource.getUserById(id);
      return Right(res);
    } on NotFoundException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(
          message: e.message,
          statusCode: e.statusCode,
        ),
      );
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

Implementing loginUser method

Now, we will implement loginUser. We will check if the user with the given email exists. If the user exists, we will check the password with PasswordHasherService. If they do not match, we will return a failure, else we will return the logged in user.

This method will be used by the UserController to create an access token for the user.

  @override
  Future<Either<Failure, User>> loginUser(LoginUserDto loginUserDto) async {
    try {
      final email = loginUserDto.email;
      final userExists = await getUserByEmail(email);
      if (userExists.isLeft) {
        throw const ServerException('Invalid email or password');
      }
      final user = userExists.right;
      final password = loginUserDto.password;
      final isPasswordCorrect =
          passwordHasherService.checkPassword(password, user.password);
      if (!isPasswordCorrect) {
        throw const ServerException('Invalid email or password');
      }
      return Right(user);
    } catch (e) {
      log(e.toString());
      return const Left(
        ServerFailure(
          message: 'Invalid email or password',
          statusCode: HttpStatus.unauthorized,
        ),
      );
    }
  }

Implementing createUser method

Similarly, we will implement createUser. We will check if the user with the given email exists. If the user exists, we will return an failure, else we will create the user and return it.

  @override
  Future<Either<Failure, User>> createUser(CreateUserDto createUserDto) async {
    try {
      final userExists = await getUserByEmail(createUserDto.email);
      if (userExists.isRight) {
        throw const ServerException('Email already in use');
      }
      // dto is already validated in the controller
      // we will hash the password here
      final hashedPassword = passwordHasherService.hashPassword(
        createUserDto.password,
      );
      final user = await dataSource.createUser(
        createUserDto.copyWith(
          password: hashedPassword,
        ),
      );
      return Right(user);
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

Implementing JwtService

🔐 Securing User Login with JWT 🔒

Now, once we have all the necessary implementation of the repository and the data source, we will implement JwtService before implementing our UserController. This service will be used to create a JWT token for the user when they log in or signup.

In backend/lib/user/service/jwt_service.dart, we will create a new class called JwtService. We will use dart_jsonwebtoken package to create and verify JWT tokens.

flutter pub add dart_jsonwebtoken

Now, we will implement the JwtService class.

import 'package:dart_jsonwebtoken/dart_jsonwebtoken.dart';
import 'package:dotenv/dotenv.dart';

class JWTService {
  const JWTService(this._env);

  final DotEnv _env;

  String sign(Map<String, dynamic> payload) {
    final secret = _env['JWT_SECRET']!;
    final jwt = JWT(payload);
    return jwt.sign(SecretKey(secret));
  }

  Map<String, dynamic> verify(String token) {
    final secret = _env['JWT_SECRET']!;
    final jwt = JWT.verify(token, SecretKey(secret));
    return jwt.payload as Map<String, dynamic>;
  }
}

💡 NOTE: We are using dotenv package to get the JWT_SECRET from the .env file. 💡 Make sure you have added the JWT_SECRET to the .env file.

...
JWT_SECRET=verycomplexsupersecret

Once this is done, we will implement the UserController.

Tidy Up Time 🧹

Make Room for Improvement 🧠

Remove duplicates

We have multiple routes that are not implemented and are returning the same response. We will remove these routes and create a new Handler to handle these requests.

We will create a new Handler called notAllowedRequestHandler in backend/lib/request_handlers/not_allowed_request_handler.dart to handle these requests.

Future<Response> notAllowedRequestHandler(RequestContext context) async {
  return Response.json(
    body: {'error': '👀 Looks like you are lost 🔦'},
    statusCode: HttpStatus.methodNotAllowed,
  );
}

Then, we will replace the routes with this handler.

• backend/routes/index.dart

import 'package:backend/request_handlers/not_allowed_request_handler.dart';
import 'package:dart_frog/dart_frog.dart';

Handler onRequest = notAllowedRequestHandler;

• backend/routes/todos/index.dart

• backend/routes/todos/[id].dart

+     return notAllowedRequestHandler(context);
-     return Response.json(
-       body: {'error': '👀 Looks like you are lost 🔦'},
-       statusCode: HttpStatus.methodNotAllowed,
-     );

Refactor HttpController

Right now, if we have to implement HttpController, we will have to override all the methods. We will refactor the HttpController to make it optional to override all the methods.

we will create a new handler called unimplementedHandler in backend/lib/request_handlers/unimplemented_handler.dart to handle the unimplemented methods.

import 'dart:io';

import 'package:dart_frog/dart_frog.dart';

Future<Response> unimplementedHandler([RequestContext? context]) async {
  return Response.json(
    body: {'error': '👀 Not implemented yet'},
    statusCode: HttpStatus.notImplemented,
  );
}

Then, we will refactor the HttpController to use this handler. In backend/lib/controller/http_controller.dart, we will change the methods to call and return unimplementedHandler.

abstract class HttpController {
  FutureOr<Response> index(Request request) => unimplementedHandler();

  FutureOr<Response> store(Request request) => unimplementedHandler();

  FutureOr<Response> show(Request request, String id) => unimplementedHandler();

  FutureOr<Response> update(Request request, String id) =>
      unimplementedHandler();

  FutureOr<Response> destroy(Request request, String id) =>
      unimplementedHandler();
}

Implementing UserController

Adding magic with UserController Implementation 🧙‍♀️

Now, we will implement UserController in user/controller/user_controller.dart.

import 'dart:async';

import 'package:backend/controller/http_controller.dart';
import 'package:backend/services/jwt_service.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:repository/repository.dart';

class UserController extends HttpController {
  UserController(this._repo, this._jwtService);

  final UserRepository _repo;
  final JWTService _jwtService;

  @override
  FutureOr<Response> store(Request request) async {
    throw UnimplementedError();
  }

  FutureOr<Response> login(Request request) async {
    throw UnimplementedError();
  }
}

We will override store method, which will responsible for creating and storing the user, and then another login method, to log in the user.

Also, we will create a new private method called _signAndSendToken which will take the user, and then sign and send the user along with the JWT token.

Implement _signAndSendToken method

We will use this method once login and store method are successful and when we want to send a response to the user.

  Response _signAndSendToken(User user, [int? httpStatus]) {
    final token = _jwtService.sign(user.toJson());
    return Response.json(
      body: {
        'token': token,
        'user': user.toJson()..remove('password'),
      },
      statusCode: httpStatus ?? HttpStatus.ok,
    );
  }

Implement store method

We will parse the JSON body, and validate the body with CreateUserDto. Once validated, we will call repository.createUser which will hash the password and create a new user if not already there.

Once this is done, we will call _signAndSendToken and return with 201 status code.

  @override
  FutureOr<Response> store(Request request) async {
    final parsedBody = await parseJson(request);
    if (parsedBody.isLeft) {
      return Response.json(
        body: {'message': parsedBody.left.message},
        statusCode: parsedBody.left.statusCode,
      );
    }
    final json = parsedBody.right;
    final createTodoDto = CreateUserDto.validated(json);
    if (createTodoDto.isLeft) {
      return Response.json(
        body: {
          'message': createTodoDto.left.message,
          'errors': createTodoDto.left.errors,
        },
        statusCode: createTodoDto.left.statusCode,
      );
    }
    final res = await _repo.createUser(createTodoDto.right);
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      (right) => _signAndSendToken(right, HttpStatus.created),
    );
  }

Implement login

Similar to store, we will parse and verify LoginUserDto, and call repository.loginUser which will verify the password and return the user.

  FutureOr<Response> login(Request request) async {
    final parsedBody = await parseJson(request);
    if (parsedBody.isLeft) {
      return Response.json(
        body: {'message': parsedBody.left.message},
        statusCode: parsedBody.left.statusCode,
      );
    }
    final json = parsedBody.right;
    final loginUserDto = LoginUserDto.validated(json);
    if (loginUserDto.isLeft) {
      return Response.json(
        body: {
          'message': loginUserDto.left.message,
          'errors': loginUserDto.left.errors,
        },
        statusCode: loginUserDto.left.statusCode,
      );
    }
    final res = await _repo.loginUser(loginUserDto.right);
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      _signAndSendToken,
    );
  }

Adding Dependency Injections 🧰

Making sure our ducks are in a row 🦆

In our global middleware backend/routes/_middleware.dart, we will register the dependencies.

import 'package:backend/db/database_connection.dart';
import 'package:backend/services/jwt_service.dart';
import 'package:backend/services/password_hasher_service.dart';
import 'package:backend/user/controller/user_controller.dart';
import 'package:backend/user/data_source/user_data_source_impl.dart';
import 'package:backend/user/repositories/user_repository_impl.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:data_source/data_source.dart';
import 'package:dotenv/dotenv.dart';
import 'package:repository/repository.dart';

final env = DotEnv()..load();
final _db = DatabaseConnection(env);
final _userDs = UserDataSourceImpl(_db);
const _passwordHasher = PasswordHasherService();
final _userRepo = UserRepositoryImpl(_userDs, _passwordHasher);
final _jwtService = JWTService(env);
final _userController = UserController(_userRepo, _jwtService);

Handler middleware(Handler handler) {
  return handler
      .use(requestLogger())
      .use(provider<DatabaseConnection>((_) => _db))
      .use(provider<JWTService>((_) => _jwtService))
      .use(provider<UserDataSource>((_) => _userDs))
      .use(provider<UserRepository>((_) => _userRepo))
      .use(provider<UserController>((_) => _userController))
      .use(provider<PasswordHasherService>((_) => _passwordHasher));
}

Setting up routes

Connecting the dots 🔗️ - defining API endpoints

We will now setup the routes for UserController in backend/routes/user we will create three new files index.dart, login.dart, and signup.dart.

Doing this we will have three different routes:

• /user - index.dart

• /user/login - login.dart

• /user/signup - signup.dart

index.dart

This route does nothing. We will just return unimplementedHandler.

import 'package:backend/request_handlers/not_allowed_request_handler.dart';
import 'package:dart_frog/dart_frog.dart';

Handler onRequest = notAllowedRequestHandler;

login.dart

We will get the UserController from the RequestContext and call login method for POST requests.

import 'dart:async';

import 'package:backend/request_handlers/not_allowed_request_handler.dart';
import 'package:backend/user/controller/user_controller.dart';
import 'package:dart_frog/dart_frog.dart';

FutureOr<Response> onRequest(RequestContext context) {
  final userController = context.read<UserController>();
  if (context.request.method != HttpMethod.post) {
    return notAllowedRequestHandler(context);
  }
  return userController.login(context.request);
}

signup.dart

Similar to login.dart, we will get the UserController from the RequestContext and call store method for POST requests.

import 'dart:async';

import 'package:backend/request_handlers/not_allowed_request_handler.dart';
import 'package:backend/user/controller/user_controller.dart';
import 'package:dart_frog/dart_frog.dart';

FutureOr<Response> onRequest(RequestContext context) {
  final userController = context.read<UserController>();
  if (context.request.method != HttpMethod.post) {
    return notAllowedRequestHandler(context);
  }
  return userController.store(context.request);
}

💡 NOTE: Recheck your .env file before testing the routes.

Testing routes

Testing Time 🧪 - Verify Your Routes!

Once we have set up the routes, we can test them using curl or postman.

/users/login

When the email and password match

• REQUEST

curl -s -L -X POST 'http://localhost:8080/users/login' -H 'Content-Type: application/json' --data-raw '{
    "email":"saileshbro@gmail.com",
    "password":"6aMj@UBByu%7BzN^C9tMe#Te4b!4cJrXwwFi#HgKrQ&g&ddNN6eHQ94vd5SuJtEc%7^H6L^xews8soG@R7GnW*RvfJVMaKEuBXNtVtbP5!3^qs*n!Z%87q8eRJmKFUHg"
}'

• RESPONSE

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjQ4ODY5Yjc4LWEwMjgtNGMwNS1hN2QzLTQ5OTQ2Mzk4NDI2NSIsIm5hbWUiOiJTYWlsZXNoIERhaGFsIiwiZW1haWwiOiJzYWlsZXNoQGdtYWlsLmNvbSIsImNyZWF0ZWRfYXQiOiIyMDIzLTAxLTMwVDA5OjU3OjQ5LjExODM2MVoiLCJwYXNzd29yZCI6IiQyYSQxMCRGSDVDc2N1Y0VuLlNwWlZmSWFtRGwuZzRMaDFhd2ltbVRMS05yU2NORW1qT25lSFZHOE4wLiIsImlhdCI6MTY3NTA2MDA0MH0.qvzLWgAEphlYqZztoBf7Bvag6hO1qkp44hUwl78CMVo",
  "user": {
    "id": "48869b78-a028-4c05-a7d3-499463984265",
    "name": "Sailesh Dahal",
    "email": "saileshbro@gmail.com",
    "created_at": "2023-01-30T09:57:49.118361Z"
  }
}

When the email or password does not match.

• REQUEST

curl -s -L -X POST 'http://localhost:8080/users/login' -H 'Content-Type: application/json' --data-raw '{
    "email":"sa@gmail.com",
    "name":"Sailesh Dahal",
    "password":"6aMj@UBByu%7BzN^C9tMe#Te4b!4cJrXwwFi#HgKrQ&g&ddNN6eHQ94vd5SuJtEc%7^H6L^xews8soG@R7GnW*RvfJVMaKEuBXNtVtbP5!3^qs*n!Z%87q8eRJmKFUHg"
}'

• RESPONSE

{ "message": "Invalid email or password" }

/users/signup

When the data is not valid

• REQUEST

curl -s -L -X POST 'http://localhost:8080/users/signup' -H 'Content-Type: application/json' --data-raw '{
    "email":"sailes@gmail.com",
    "password":"6aMj@UBByu"
}'

• RESPONSE

{
  "message": "Validation failed",
  "errors": {
    "name": ["Name is required"]
  }
}

When there is no user with the given email, it will create a new user and return the same response as /users/login.

• REQUEST

curl -s -L -X POST 'http://localhost:8080/users/signup' -H 'Content-Type: application/json' --data-raw '{
    "email":"sailesh12@gmail.com",
    "name":"Sailesh Dahal",
    "password":"6aMj123"
}'

• RESPONSE

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImM1ODE2YWQ0LTNkODctNDUzZC1hZmFkLTUwMzljY2YxZjdjNyIsIm5hbWUiOiJTYWlsZXNoIERhaGFsIiwiZW1haWwiOiJzYWlsZXNoMTJAZ21haWwuY29tIiwiY3JlYXRlZF9hdCI6IjIwMjMtMDEtMzBUMDY6Mjg6MzUuMzkyMjM4WiIsInBhc3N3b3JkIjoiJDJhJDEwJHRuTllGM3FHQmlPT1dKeHVacm1MaU91SHhBMU1HQlNMcmoxYS5ndHY2TTNCMHpmRW5Dc1dLIiwiaWF0IjoxNjc1MDYwMTE0fQ.aUpo9HXTFmdmkTsfGoTp0mcK0OJ_fFuwZArqyNFpKvQ",
  "user": {
    "id": "c5816ad4-3d87-453d-afad-5039ccf1f7c7",
    "name": "Sailesh Dahal",
    "email": "sailesh12@gmail.com",
    "created_at": "2023-01-30T06:28:35.392238Z"
  }
}

When there is a user with the given email, it will return the following response.

• REQUEST

curl -s -L -X POST 'http://localhost:8080/users/signup' -H 'Content-Type: application/json' --data-raw '{
    "email":"sailesh12@gmail.com",
    "name":"Sailesh Dahal",
    "password":"6aMj123"
}'

• RESPONSE

{
  "message": "Email already in use"
}

Protecting Routes

Locking Down: Secure Your Endpoints 🔒

Now, we can protect our routes by adding middleware to the routes. We will check for the Authorization header and verify the token. We can intercept all the requests going to /todos/* and check for the token.

We can do this by creating a new authorization middleware. We will create a new file backend/lib/middlewares/authorization_middleware.dart. Before that, let's create a new exception for unauthorized requests.

Creating UnauthorizedException

When the token is not valid, we will throw an UnauthorizedException which will be handled by the ExceptionHandlerMiddleware.

In exceptions package, we will create a new exception called UnauthorizedException in exceptions/lib/src/http_exception/unauthorized_exception.dart

import 'dart:io';

import 'package:exceptions/src/http_exception/http_exception.dart';

class UnauthorizedException extends HttpException {
  const UnauthorizedException({
    String message = 'Unauthorized',
    this.errors = const {},
  }) : super(message, HttpStatus.unauthorized);

  final Map<String, List<String>> errors;
}

💡 Make sure to export the exception in http_exception.dart file.

export './bad_request_exception.dart';
export './not_found_exception.dart';
export './unauthorized_exception.dart';

💡 Make sure to run flutter pub run build_runner build to generate the code.

Creating AuthorizationMiddleware

🔒 Securing Endpoints with AuthorizationMiddleware 🛡️

Now, we can create the AuthorizationMiddleware in backend/lib/middlewares/authorization_middleware.dart.

import 'dart:io';

import 'package:backend/db/database_connection.dart';
import 'package:backend/services/jwt_service.dart';
import 'package:backend/todo/controller/todo_controller.dart';
import 'package:backend/todo/data_source/todo_data_source_impl.dart';
import 'package:backend/todo/repositories/todo_repository_impl.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:data_source/data_source.dart';
import 'package:exceptions/exceptions.dart';
import 'package:models/models.dart';
import 'package:repository/repository.dart';

Handler authorizationMiddleware(Handler handler) {
  return (context) async {
    try {
      final request = context.request;
      final authHeader = request.headers[HttpHeaders.authorizationHeader] ?? '';
      final token = authHeader.replaceFirst('Bearer ', '');
      if (token.isEmpty) throw const UnauthorizedException();
      final jwtService = context.read<JWTService>();
      final decoded = jwtService.verify(token);
      final decodedUser = User.fromJson(decoded);
      final userRepo = context.read<UserRepository>();
      final user = await userRepo.getUserById(decodedUser.id);
      if (user.isLeft) throw const UnauthorizedException();
      context = _handleAuthDependencies(context, user.right);
      return handler(context);
    } on UnauthorizedException catch (e) {
      return Response.json(
        body: {'message': e.message},
        statusCode: e.statusCode,
      );
    }
  };
}

RequestContext _handleAuthDependencies(
  RequestContext context,
  User user,
) {
  late RequestContext updatedContext;
  updatedContext = context.provide<User>(() => user);
  return updatedContext;
}

Here, we are checking for the Authorization header and verifying the token. If the token is valid, we are adding the User object to the context, so that we can get the logged-in user later from the provider.

If the token is invalid, we will return a 401 response.

Updating auth dependencies

Now, since we will have to add a user_id whenever, we will create a todo, we will have to pass the logged-in user to the TodoDataSource. We will update the TodoDataSourceImpl to accept the User object from the constructor.

class TodoDataSourceImpl implements TodoDataSource {
  /// {@macro todo_data_source_impl}
  const TodoDataSourceImpl(this._databaseConnection, this.user);
  final DatabaseConnection _databaseConnection;

  final User user;
}

Also, we will update createTodo and updateTodo methods to add the user_id.

Update createTodo method

  @override
  Future<Todo> createTodo(CreateTodoDto todo) async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        '''
-       INSERT INTO todos (title, description, completed)
+       INSERT INTO todos (title, description, completed, user_id)
-       VALUES (@title, @description, @completed) RETURNING *
+       VALUES (@title, @description, @completed, @user_id) RETURNING *
        ''',
        substitutionValues: {
          'title': todo.title,
          'description': todo.description,
          'completed': false,
+         'user_id': _user.id,
        },
      );
      if (result.affectedRowCount == 0) {
        throw const ServerException('Failed to create todo');
      }
      final todoMap = result.first.toColumnMap();
      return Todo(
        id: todoMap['id'] as int,
+       userId: todoMap['user_id'] as String,
        title: todoMap['title'] as String,
        description: todoMap['description'] as String,
        createdAt: todoMap['created_at'] as DateTime,
      );
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

Update updateTodo method

      final result = await _databaseConnection.db.query(
        '''
        UPDATE todos
        SET title = COALESCE(@new_title, title),
            description = COALESCE(@new_description, description),
            completed = COALESCE(@new_completed, completed),
            updated_at = current_timestamp
        WHERE id = @id
+       AND user_id = @user_id
        RETURNING *
        ''',
        substitutionValues: {
          'id': id,
+         'user_id': _user.id,
          'new_title': todo.title,
          'new_description': todo.description,
          'new_completed': todo.completed,
        },
      );

Update Todo model to add userId

We will also add the missing userId from Todo model.

  factory Todo({
    required TodoId id,
+   required UserId userId,
    required String title,
    @Default('') String description,
    @Default(false) bool completed,
    @DateTimeConverter() required DateTime createdAt,
    @DateTimeConverterNullable() DateTime? updatedAt,
  }) = _Todo;

Now, once this is done, we will update the _handleAuthDependencies method in authorization_middleware.dart as

RequestContext _handleAuthDependencies(
  RequestContext context,
  User user,
) {
  final db = context.read<DatabaseConnection>();
  final todoDs = TodoDataSourceImpl(db, user);
  final todoRepo = TodoRepositoryImpl(todoDs);
  final todoController = TodoController(todoRepo);
  late RequestContext updatedContext;
  updatedContext = context.provide<User>(() => user);
  updatedContext = updatedContext.provide<TodoController>(() => todoController);
  updatedContext = updatedContext.provide<TodoRepository>(() => todoRepo);
  updatedContext = updatedContext.provide<TodoDataSource>(() => todoDs);
  return updatedContext;
}

Using AuthorizationMiddleware

Applying AuthorizationMiddleware to routes

Let's create a new middleware in backend/routes/todos/_middleware.dart and add the following code.

import 'package:backend/middlewares/authorization_middleware.dart';
import 'package:dart_frog/dart_frog.dart';

Handler middleware(Handler handler) => authorizationMiddleware(handler);

Since this middleware lies inside routes/todos, all the /todos/* routes will be intercepted by this middleware. This means that all the /todos/* routes will be protected and if the user tries to access these routes without a valid token, it will return a 401 response.

Testing protected /todos/* routes

Putting updated routes to the Test 🧪

If we try to access the /todos/* routes without a valid token, it will return a 401 response. We can test this by running the following command.

GET /todos

• REQUEST

curl -s -L -X GET 'http://localhost:8080/todos'

• RESPONSE

{
  "message": "Unauthorized"
}

• REQUEST

curl -s -L -X GET 'http://localhost:8080/todos' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjY5ZWFkZTg3LWRhNWUtNDRjZC1iNTRlLTQ3NGE4NWQ4ZGVlNCIsIm5hbWUiOiJTYWlsZXNoIERhaGFsIiwiZW1haWwiOiJzYWlsZXNoYnJvQGdtYWlsLmNvbSIsImNyZWF0ZWRfYXQiOiIyMDIzLTAxLTIzVDIyOjU0OjM4Ljg2NDkxMloiLCJwYXNzd29yZCI6IiQyYSQxMCR6VjBTZlI3cUpHOHlCelJWWThtNkRlMWo0UUtHL2VRdXl6NzduQ1lBL1luZENtb1ZSbzB0RyIsImlhdCI6MTY3NDQ5Mzc3OX0.W36mHXKFrxZDhz0Hrxt0Cmrz3WNVexiAZe2KAjrWMaE'

• RESPONSE

[
  {
    "id": 76,
    "user_id": "69eade87-da5e-44cd-b54e-474a85d8dee4",
    "title": "this is a title asdf",
    "description": "Not so great description asdf",
    "completed": false,
    "created_at": "2023-01-23T22:56:31.686023Z",
    "updated_at": "2023-01-30T04:08:06.349549Z"
  }
]

POST /todos

• REQUEST

curl -s -L -X POST 'http://localhost:8080/todos' -H 'Content-Type: application/json' --data-raw '{
    "title":"this is a title asdf",
    "description":"Not so great description asdf"
}'

• RESPONSE

{
  "message": "Unauthorized"
}

• REQUEST

curl -s -L -X POST 'http://localhost:8080/todos' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjY5ZWFkZTg3LWRhNWUtNDRjZC1iNTRlLTQ3NGE4NWQ4ZGVlNCIsIm5hbWUiOiJTYWlsZXNoIERhaGFsIiwiZW1haWwiOiJzYWlsZXNoYnJvQGdtYWlsLmNvbSIsImNyZWF0ZWRfYXQiOiIyMDIzLTAxLTIzVDIyOjU0OjM4Ljg2NDkxMloiLCJwYXNzd29yZCI6IiQyYSQxMCR6VjBTZlI3cUpHOHlCelJWWThtNkRlMWo0UUtHL2VRdXl6NzduQ1lBL1luZENtb1ZSbzB0RyIsImlhdCI6MTY3NDQ5Mzc3OX0.W36mHXKFrxZDhz0Hrxt0Cmrz3WNVexiAZe2KAjrWMaE' -H 'Content-Type: application/json' --data-raw '{
    "title":"this is a title asdf",
    "description":"Not so great description asdf"
}'

• RESPONSE

{
  "id": 79,
  "user_id": "69eade87-da5e-44cd-b54e-474a85d8dee4",
  "title": "this is a title asdf",
  "description": "Not so great description asdf",
  "completed": false,
  "created_at": "2023-01-30T07:10:10.102358Z",
  "updated_at": null
}

Similarly, we can test the other routes as well 🥳

🎉 Congrats, we've made it to the end of Part 6! 🚀 We've successfully added user authentication with JWT to our dart_frog backend.

It's been an incredible adventure, and we've gone a long way since Part 1. Using Dart and Flutter, we created a full-stack to-do application. But our task does not end there. We haven't addressed testing yet in this course, but it's an important aspect of developing any program. Let us know in the comments if you'd want to learn more about testing your code in all of the modules we've written in this series.

As always, you can refer back to the GitHub repo for this tutorial at https://github.com/saileshbro/full_stack_todo_dart if you need any help. Don't forget to give it a ⭐ and help spread the word about the initiative. Also, if you get stuck or want assistance, please submit an issue or, better yet, contribute a pull request.

Thank you for joining me on this journey; let's create even more wonderful applications together. Have fun coding! 💻

• Scaffolding an empty flutter project

• Importing necessary dependencies

• Creating a folder structure

• Connecting our front end with the backend using TodosHttpClient

• Setting up dependency injection using injectable and get_it

• Implementing TodosRemoteDataSource and TodoRepository

• Handling errors as NetworkFailure

• Creating NetworkException and DioNetworkException

• Creating NetworkErrorInterceptor

• Creating ShowTodosView and ShowTodosViewModel to show the fetched todos

• Creating MaintainTodoView and MaintainTodoViewModel to maintain the todos

• Adding linting with very_good_analysis to make sure our code is clean.

We will be diving deeper into the world of flutter making use of the best practices, packages and libraries available for flutter. And by the end of this part, we will have a fully functional front end for our to-do application.

Don't forget to check the GitHub repo for this tutorial at GitHub if you need a little help along the way. Let's get started 🚀

🚀 Scaffolding Frontend

🌟 Frontend is about to shine.

We will begin by scaffolding an empty Flutter project using the command:

flutter create --project-name fullstack_todo --org np.com.saileshdahal frontend

This will create an empty flutter project in frontend directory. We will then do some initial setup, and add some dependencies.

Importing necessary dependencies 📦

Time to bring in the big guns! 💪 Let's import those dependencies

We will import the necessary dependencies in the pubspec.yaml file. The dependencies that we are using are as follows.

• dio

• either_dart

• flutter_hooks

• get_it

• injectable

• stacked

• stacked_services

• build_runner

• very_good_analysis

• retrofit

These dependencies will allow us to easily handle communication with the backend, handle state management, and implement a clean and maintainable codebase for our application.

To install you can use the following command:

flutter pub add dio either_dart flutter_hooks get_it injectable stacked stacked_services retrofit

flutter pub add --dev build_runner very_good_analysis stacked_generator injectable_generator retrofit_generator

We will also include the packages that we have built, once done pubspec.yaml should look something like this.

dependencies:
  data_source:
    path: ../data_source
  dio: ^4.0.6
  either_dart: ^0.3.0
  exceptions:
    path: ../exceptions
  failures:
    path: ../failures
  flutter:
    sdk: flutter
  flutter_hooks: ^0.18.5+1
  get_it: ^7.2.0
  injectable: ^2.1.0
  models:
    path: ../models
  repository:
    path: ../repository
  retrofit: ^3.3.1
  stacked: ^3.0.1
  stacked_services: ^0.9.9
  typedefs:
    path: ../typedefs

dev_dependencies:
  build_runner: ^2.3.3
  flutter_test:
    sdk: flutter
  injectable_generator: ^2.1.3
  integration_test:
    sdk: flutter
  mockito: ^5.3.2
  retrofit_generator: ^4.2.0
  stacked_generator: ^0.8.3
  very_good_analysis: ^3.1.0

Folder Structure 📂

This is how we will architect our folder structures.

.
├── constants
├── core
│   ├── app
│   ├── di
│   └── network
│       ├── exceptions
│       └── interceptors
├── data
│   ├── data_source
│   │   ├── todo_http_client
│   │   └── todo_remote_data_source
│   └── repositories
├── data_services
└── presentation

• constants: This folder will include all the hard-coded constants in our project, such as API endpoints or keys.

• core: This directory will include all the core functionalities of our app, which are common for all the features. This includes routing, dependency injection, and network interceptors.

• data: This directory will include all the implementations related to data sources and repositories.

• data_services: This will include the implementation of services that will be shared across different view models.

• presentation: This will include the views and view models for creating and listing

The data_source and repositories folders contain the implementation of the abstract contracts defined in the data_sources and repository packages, respectively. This allows for the separation of concerns and easier maintenance of the codebase.

Connecting with the backend 🔌

Let's get this party started 🎉

Let's start by connecting with the dart_frog backend using dio. For this, we will create a new class TodosHttpClient

Create TodosHttpClient

TodosHttpClient will be responsible for calling our backend. We will be using retrofit to generate the necessary codes to call the backend.

Retrofit allows us to define our API endpoints as interfaces with annotated methods, and it will automatically generate the necessary code to handle the network requests and convert the JSON responses to Dart objects.

We will create a new file in data/data_source/todo_http_client/todos_http_client.dart with the following code.

import 'package:dio/dio.dart';
import 'package:injectable/injectable.dart';
import 'package:models/models.dart';
import 'package:retrofit/retrofit.dart';
import 'package:typedefs/typedefs.dart';

part 'todos_http_client.g.dart';

@RestApi()
@lazySingleton
abstract class TodosHttpClient {
  @factoryMethod
  factory TodosHttpClient(Dio _dio) = _TodosHttpClient;

  @GET('/todos')
  Future<List<Todo>> getAllTodo();
  @GET('/todos/{id}')
  Future<Todo> getTodoById(@Path('id') TodoId id);
  @POST('/todos')
  Future<Todo> createTodo(@Body() CreateTodoDto todo);
  @PATCH('/todos/{id}')
  Future<Todo> updateTodo(@Path('id') TodoId id, @Body() UpdateTodoDto todo);
  @DELETE('/todos/{id}')
  Future<void> deleteTodoById(@Path('id') TodoId id);
}

After completing the steps, we will execute build_runner to generate the necessary code. This will create an implementation of TodosHttpClient and we will link the generated _TodosHttpClient to the factory method of this abstract class. The Dio object will be passed as a dependency through the constructor. Since we are using get_it and injectable, it will be necessary to manage the injection of this dependency.

Setup injectable 🔧

Injectable is a package for Dart that allows for dependency injection in our application. It provides a simple and easy-to-use API for managing dependencies and injecting them into our classes. By using Injectable, we can easily swap out dependencies for different environments, like testing, and make our code more modular and testable.

👉 Read more about injectable.

To handle how we inject the Dio instance, we will create some files to inject third-party modules. In the core directory, we will create a new directory called di, short for Dependency Injection.

Here, create a new file called locator.dart, and add the following code.

import 'package:fullstack_todo/core/di/locator.config.dart';
import 'package:get_it/get_it.dart';
import 'package:injectable/injectable.dart';

final locator = GetIt.instance;

@injectableInit
void setupLocator() => locator.init();

Now, we will create another file called third_party_modules.dart, this file will have a getter which will resolve the instance of Dio.

import 'package:dio/dio.dart';
import 'package:injectable/injectable.dart';

@module
abstract class ThirdPartyModules {
  @lazySingleton
  Dio get dio => Dio(BaseOptions(baseUrl: kBaseUrl));
}

Then, we will create the missing kBaseUrl constant in constants/constants.dart file.

const String kBaseUrl = 'http://localhost:8080';

Note: The port for you may be different, please check what port your backend will run by running dart_frog dev in the backend folder.

If you check the generated code in locator.config.dart, it creates the instance of dio and passes it to our TodosHttpClient.

Implement TodosRemoteDataSource 💻

We will now use TodosHttpClient to implement our TodosDataSource. For this, we will create data_source/todos_remote_data_source.dart file, and we will implement TodosDataSource as follows.

import 'package:data_source/data_source.dart';
import 'package:fullstack_todo/data/data_source/todos_http_client/todos_http_client.dart';
import 'package:injectable/injectable.dart';
import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

@LazySingleton(as: TodoDataSource)
class TodosRemoteDataSource implements TodoDataSource {
  const TodosRemoteDataSource(this.httpClient);

  final TodosHttpClient httpClient;

  @override
  Future<Todo> createTodo(CreateTodoDto todo) => httpClient.createTodo(todo);

  @override
  Future<void> deleteTodoById(TodoId id) => httpClient.deleteTodoById(id);

  @override
  Future<List<Todo>> getAllTodo() => httpClient.getAllTodo();

  @override
  Future<Todo> getTodoById(TodoId id) => httpClient.getTodoById(id);

  @override
  Future<Todo> updateTodo({required TodoId id, required UpdateTodoDto todo}) =>
      httpClient.updateTodo(id, todo);
}

Here, we are passing the TodosHttpClient as a dependency. This will help us to test the implementation by passing a mock implementation of HttpClient to the data source implementation.

Handling errors as NetworkFailure 🛑

We need to handle the errors that we send from the backend as failures, and other possible errors as well. One possible way to do this is, when we implement our TodoRepository, we will catch all the exceptions as NetworkException, and then resolve the exception to the Failure and handle the failures in the UI.

The way we do this is can create an interceptor, that we can plug into our dio instance, and then handle the errors from there.

By creating a new NetworkException class in our exceptions package, we will be able to effectively handle network errors that may occur while communicating with the backend. This is especially important when implementing the TodoRepository class in the front end, as it ensures that any network errors that occur are caught and handled in a consistent and efficient manner.

However, it is important to note that when working with APIs, we will encounter errors that are returned in the form of DioError. To handle these errors, we will use an ErrorInterceptorHandler to continue the Dio request-response cycle, while also rejecting any errors that occur.

To ensure that we are able to catch NetworkException in the repository, we will create a new class called DioNetworkException which extends DioError and implements NetworkException. This allows us to create a new instance of DioNetworkException and reject it from the handler.

Create NetworkException 🌐

In our exceptions package, we will create a new exception called NetworkExeption. We are doing this because we don't want any external dependencies on our packages, as much as we can. Let's create a new file exceptions/lib/src/network_exception/network_exception.dart in exceptions package with the following contents.

class NetworkException implements Exception {
  NetworkException({
    required this.message,
    required this.statusCode,
    this.errors = const {},
  });

  final String message;

  final int statusCode;

  final Map<String, List<String>> errors;
}

👉 Make sure to export this from exceptions.dart library.

library exceptions;

export 'src/http_exception/http_exception.dart';
export 'src/network_exception/network_exception.dart';
export 'src/server_exception/server_exception.dart';

Once this is done, let's come back to frontend and create a new class called DioNetworkException.

Create DioNetworkException

Let's create a new file in lib/core/network/exceptions/dio_network_exception.dart in the frontend package.

import 'package:dio/dio.dart';
import 'package:exceptions/exceptions.dart';

class DioNetworkException extends DioError implements NetworkException {
  DioNetworkException({
    required this.message,
    required this.statusCode,
    required this.errors,
    required super.requestOptions,
  });

  @override
  final int statusCode;
  @override
  final String message;
  @override
  final Map<String, List<String>> errors;
}

This exception is created to convert the DioError we get while implementing the error interceptor, to our NetworkException so that we only care about the NetworkException we implemented in our package, and catch it.

Create NetworkErrorInterceptor 🔒

We will now implement NetworkErrorInterceptor extending Interceptor from dio. Here we will have to override onError method, which will give us DioError object and a handler.

👉 Read more about interceptors from here.

Create a new file frontend/lib/core/network/interceptors/dio_error_interceptor.dart

import 'package:dio/dio.dart';
import 'package:failures/failures.dart';
import 'package:fullstack_todo/core/network/exceptions/dio_network_exception.dart';

class NetworkErrorInterceptor extends Interceptor {
  @override
  void onError(DioError err, ErrorInterceptorHandler handler) {
    const genericInternetIssue =
        'Please check your internet connection and try again';
    try {
      if (err.response == null) {
        throw DioNetworkException(
          message: genericInternetIssue,
          statusCode: 500,
          requestOptions: err.requestOptions,
          errors: {},
        );
      }
      final errorJson = err.response!.data as Map<String, dynamic>;
      final failureFromServer = NetworkFailure.fromJson(
        {
          ...errorJson,
          'status_code': err.response!.statusCode,
        },
      );
      throw DioNetworkException(
        message: failureFromServer.message,
        statusCode: err.response!.statusCode ?? failureFromServer.statusCode,
        errors: failureFromServer.errors,
        requestOptions: err.requestOptions,
      );
    } on DioNetworkException catch (e) {
      handler.reject(e);
    } catch (e) {
      handler.reject(
        DioNetworkException(
          message: genericInternetIssue,
          statusCode: 500,
          requestOptions: err.requestOptions,
          errors: {},
        ),
      );
    }
  }
}

Note: we may need to make a small change to our NetworkFailure class and run build_runner

  const factory NetworkFailure({
    required String message,
    required int statusCode,
-   @Default([]) List<String> errors,
+   @Default({}) Map<String, List<String>> errors,
  }) = _NetworkFailure;

Now once, we have implemented the NetworkErrorInterceptor, we will attach this interceptor to our dio object.

Open third_party_modules.dart and add the following line.

abstract class ThirdPartyModules {
  @lazySingleton
  Dio get dio => Dio(BaseOptions(baseUrl: kBaseUrl));
+    ..interceptors.add(NetworkErrorInterceptor());
}

Implement TodoRepository 📚

Now we will implement the todo repository at lib/data/repositories/todo_repository_impl.dart in the following way.

import 'package:data_source/data_source.dart';
import 'package:either_dart/either.dart';
import 'package:exceptions/exceptions.dart';
import 'package:failures/failures.dart';
import 'package:injectable/injectable.dart';
import 'package:models/models.dart';
import 'package:repository/repository.dart';
import 'package:typedefs/typedefs.dart';

@LazySingleton(as: TodoRepository)
class TodoRepositoryImpl implements TodoRepository {
  const TodoRepositoryImpl(this._todoDataSource);
  final TodoDataSource _todoDataSource;

  @override
  Future<Either<Failure, Todo>> createTodo(CreateTodoDto createTodoDto) =>
      handleError(() => _todoDataSource.createTodo(createTodoDto));

  @override
  Future<Either<Failure, void>> deleteTodo(TodoId id) =>
      handleError(() => _todoDataSource.deleteTodoById(id));

  @override
  Future<Either<Failure, Todo>> getTodoById(TodoId id) =>
      handleError(() => _todoDataSource.getTodoById(id));

  @override
  Future<Either<Failure, List<Todo>>> getTodos() =>
      handleError(_todoDataSource.getAllTodo);

  @override
  Future<Either<Failure, Todo>> updateTodo({
    required TodoId id,
    required UpdateTodoDto updateTodoDto,
  }) =>
      handleError(
        () => _todoDataSource.updateTodo(id: id, todo: updateTodoDto),
      );

  Future<Either<Failure, T>> handleError<T>(
    Future<T> Function() callback,
  ) async {
    try {
      final res = await callback();
      return Right(res);
    } on NetworkException catch (e) {
      return Left(
        NetworkFailure(
          message: e.message,
          statusCode: e.statusCode,
          errors: e.errors,
        ),
      );
    }
  }
}

Here, we are passing the data source as a dependency and calling methods from the data source for each implementation. In addition to that, we have created a handleError generic method, which takes a caller method, and checks if there is a NetworkException.

The NetworkException will be caught here which was thrown from the interceptor as DioNetworkException.

Now, let's do some UI, and connect our view model to the repository.

Creating ShowTodosView 📋

Next, we will move on to creating the user interface and retrieving data from our repositories. To do this, we will perform some initial setup. We will be utilizing stacked to implement a Model-View-ViewModel (MVVM) architecture. The necessary dependencies have already been imported. Let's begin by creating the views and adding them to the routes.

Create ShowTodosView and ShowTodosViewModel

In lib/presentation//show_todos we will create two new files called show_todos_view.dart and show_todos_viewmodel.dart.

We will begin by creating an empty implementation of the view and view model.

In show_todos_viewmodel.dart

import 'package:stacked/stacked.dart';
import 'package:injectable/injectable.dart';

@injectable
class ShowTodosViewModel extends BaseViewModel {}

Similarly in show_todos_view.dart.

import 'package:flutter/material.dart';
import 'package:fullstack_todo/core/di/locator.dart';
import 'package:fullstack_todo/presentation/show_todos/show_todos_viewmodel.dart';
import 'package:stacked/stacked.dart';

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

  @override
  Widget build(BuildContext context) {
    return ViewModelBuilder<ShowTodosViewModel>.nonReactive(
      viewModelBuilder: () => locator<ShowTodosViewModel>(),
      builder: (
        BuildContext context,
        ShowTodosViewModel model,
        Widget? child,
      ) {
        return Scaffold(
          body: Center(
            child: Text(
              'ShowTodosView',
            ),
          ),
        );
      },
    );
  }
}

We will also take advantage of the routing system provided by stacked. This system uses context-less routing, allowing us to easily navigate within our application from the view model.

We will create a NavigationService that can be injected as a dependency, which will enable us to handle routing in a consistent and efficient manner.

👉 Read more about NavigationService from here.

Let's create a new core/app/routes.dart file with the following contents.

import 'package:fullstack_todo/presentation/show_todos/show_todos_view.dart';
import 'package:stacked/stacked_annotations.dart';

@StackedApp(
  routes: routes,
)
const List<StackedRoute<dynamic>> routes = [
  AdaptiveRoute(page: ShowTodosView, initial: true),
];

Here, the @StackedApp decorator does the magic. Once this is done, we run build_runner to run code generation. We will get a new file routes.router.dart

👉 Read more about @StackedApp

Now, in main.dart file, let's remove all the comments and make these changes.

import 'package:flutter/material.dart';
import 'package:fullstack_todo/core/app/routes.router.dart';
import 'package:fullstack_todo/core/di/locator.dart';
import 'package:stacked_services/stacked_services.dart';

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

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Fullstack Todo App',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      navigatorKey: StackedService.navigatorKey,
      onGenerateRoute: StackedRouter().onGenerateRoute,
    );
  }
}

Before calling runApp(), we are invoking setupLocator() from locator.dart. This function will handle all the logic related to dependency injection. We are also providing navigatorKey and onGenerateRoute parameters, which come from stacked and routes.router.dart, respectively.

We also need to take an extra step, which is to manage the injection of the NavigationService. For this, we need to add a getter to the third_party_modules.dart file.

@module
abstract class ThirdPartyModules {
  @lazySingleton
  Dio get dio => Dio(BaseOptions(baseUrl: kBaseUrl))
    ..interceptors.add(NetworkErrorInterceptor());

  @lazySingleton
  NavigationService get navigationService;
}

Once this is done, if you build the app you should see the first visual output.

Implement ShowTodosViewModel

This view model will utilize the TodoRepository to retrieve data from the backend.

Similar to initState method used when working with StatefulWidgets, we can create a new method in our ViewModel called init to handle initialization logic.

Within this method, we can call the repository to fetch all the todos. We will also create a refresh method to handle pull-to-refresh functionality.

@injectable
class ShowTodosViewModel extends BaseViewModel {
  final TodoRepository _todoRepository;

  ShowTodosViewModel(this._todoRepository);

  void handleFailure(Failure failure) {
    setError(failure.message);
    log(failure.message);
  }

  void init() => runBusyFuture(refresh());

  Future<void> refresh() async {
    final response = await _todoRepository.getTodos();
    response.fold(handleFailure, print);
  }
}

Here, we have three methods, init refresh and handleFailure.

• init This method is ideally run on initState state. This will call the refresh method, but in addition to that, this will mark the ViewModel as busy before calling the method. This will be helpful when we want to show a loading indicator when we first fetch the todos.

• refresh This method will call the TodoRepository and than handle re response accordingly.

• handleFailure Ideally, this is the place where we would handle the failure and show the UI accordingly. The setError is storing the failure message in the view model, which will be accessible by modelError getter from BaseViewModel.

Now we are getting the todos from the backend. We will also be marking todos as completed and deleting the todo from this same view model.

Where should we put the todos once we fetch them?

We will also have another view called MaintainTodoView which will be responsible for creating and updating the todos. We will come across a problem, where we will have to update the state of the created and updated todo. We can do this by passing the todo down the routes once it is created or updated.

Another way to do this is by creating a data service, which will be shared across different view models. This service will be reactive, meaning if the data changes, it will rebuild all the view models listening to this data. This will help us avoid passing down the problem of the route.

Implement TodosDataService

We will create a TodosDataService which will be shared across the view models. This will have some helper methods that will be used to maintain the state of all the todos. We will create a new file lib/data_services/todos_data_service.dart

import 'package:flutter/material.dart';
import 'package:injectable/injectable.dart';
import 'package:models/models.dart';
import 'package:stacked/stacked.dart';

@lazySingleton
class TodosDataService with ReactiveServiceMixin {
  TodosDataService() {
    listenToReactiveValues([_todos]);
  }
  late final ReactiveValue<List<Todo>> _todos = ReactiveValue<List<Todo>>([]);

  List<Todo> get todos => _todos.value;

  void add(Todo todo) {
    final index = _todos.value.indexWhere((element) => element.id == todo.id);
    if (index == -1) {
      _todos.value.insert(0, todo);
    } else {
      _todos.value[index] = todo;
    }
    notifyListeners();
  }

  void addAll(List<Todo> todos) {
    _todos.value
      ..clear()
      ..insertAll(0, todos);
    notifyListeners();
  }

  void remove(Todo todo) {
    _todos.value.removeWhere((element) => element.id == todo.id);
    notifyListeners();
  }
}

Here, we are using ReactiveServiceMixin and ReactiveValue objects. When we call add method, it checks if the todo is present already, if so, it will update the existing one, or else it will add it to the top, so that we can see the latest one at the top.

Similarly, there is addAll which will clear all todos and then add them to the top.

👉 Read more about reactivity in stacked from here.

Updating ShowTodosViewModel

Now we will inject TodosDataService from the constructor and make some changes to the view model to handle reactivity.

@injectable
class ShowTodosViewModel extends ReactiveViewModel {
  ShowTodosViewModel(
    this._todoRepository,
    this._todosDataService,
  );

  final TodoRepository _todoRepository;
  final TodosDataService _todosDataService;
  List<Todo> get todos => _todosDataService.todos;

  Future<void> init() => runBusyFuture(refresh());

  void handleFailure(Failure failure) {
    setError(failure.message);
    log(failure.message);
  }

  Future<void> refresh() async {
    final response = await _todoRepository.getTodos();
    response.fold(handleFailure, _todosDataService.addAll);
  }

  @override
  List<ReactiveServiceMixin> get reactiveServices => [_todosDataService];
}

If you noticed, we are extending from ReactiveViewModel and also overriding reactiveServices. We are listening to the _todosDataService and will be reflecting the UI whenever the data is changed in the reactive service.

Update ShowTodosView to show fetched todos

Now we can update the show_todos_view.dart to show the fetched todos.

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

  @override
  Widget build(BuildContext context) {
    return ViewModelBuilder<ShowTodosViewModel>.reactive(
      viewModelBuilder: locator,
      onModelReady: (model) => model.init(),
      builder: (
        BuildContext context,
        ShowTodosViewModel model,
        Widget? child,
      ) {
        return Scaffold(
          appBar: AppBar(
            title: const Text('Todos'),
          ),
          floatingActionButton: FloatingActionButton(
            onPressed: () {},
            child: const Icon(Icons.add),
          ),
          body: Builder(
            builder: (context) {
              if (model.isBusy) {
                return const Center(child: CircularProgressIndicator());
              }
              if (model.hasError) {
                return Center(child: Text(model.modelError.toString()));
              }
              if (model.todos.isEmpty) {
                return Center(
                  child: Text(
                    'No todos found!',
                    style: Theme.of(context).textTheme.titleLarge,
                  ),
                );
              }
              return RefreshIndicator(
                onRefresh: model.refresh,
                child: ListView.builder(
                  physics: const AlwaysScrollableScrollPhysics(),
                  itemCount: model.todos.length,
                  itemBuilder: (context, index) {
                    final todo = model.todos[index];
                    return ListTile(
                      title: Text(todo.title),
                      subtitle: Text(todo.description),
                      leading: Checkbox(
                        value: todo.completed,
                        onChanged: (val) {},
                      ),
                      trailing: Row(
                        mainAxisSize: MainAxisSize.min,
                        children: [
                          IconButton(
                            icon: const Icon(
                              Icons.edit,
                              color: Colors.blue,
                            ),
                            onPressed: () {},
                          ),
                          IconButton(
                            icon: const Icon(
                              Icons.delete,
                              color: Colors.red,
                            ),
                            onPressed: () {},
                          ),
                        ],
                      ),
                    );
                  },
                ),
              );
            },
          ),
        );
      },
    );
  }
}

This view will get all the lists from the view model with init method.

Notice the onModelReady in the ViewModelBuilder where we are calling init method from the view model.

We are using the Builder to check the different states of the view model and show the UI accordingly.

We show a CircularProgressIndicator when the view model is isBusy. This value is set by runBusyFuture method in the view model.

Also if the model has an error, we can check hasError and show the error message accordingly. We will also show the todos with a ListView.builder, when there are todos, and an empty message as well.

Now let's build the app, and check out the progress.

Tip: If you are using macOS, make sure to allow network access in the entitlements file.

And, if you create one using postman, you should see something like this.

Create TodoListTile

Once this is done, let's do some refactoring. We can create a TodoListTile widget as a separate stateless widget in show_todos/widgets/todo_list_tile.dart

class TodoListTile extends ViewModelWidget<ShowTodosViewModel> {
  const TodoListTile({
    super.key,
    required this.todo,
  });

  final Todo todo;

  @override
  Widget build(BuildContext context, ShowTodosViewModel viewModel) {
    return ListTile(
      title: Text(todo.title),
      subtitle: Text(todo.description),
      leading: Checkbox(
        value: todo.completed,
        onChanged: (val) => viewModel.markCompleted(todo),
      ),
      trailing: Row(
        mainAxisSize: MainAxisSize.min,
        children: [
          IconButton(
            icon: const Icon(
              Icons.edit,
              color: Colors.blue,
            ),
            onPressed: () => viewModel.handleTodo(todo),
          ),
          IconButton(
            icon: const Icon(
              Icons.delete,
              color: Colors.red,
            ),
            onPressed: () => viewModel.deleteTodo(todo),
          ),
        ],
      ),
    );
  }
}

Here, we have missing view model methods, which we will implement later. Also, we are not using a StatelessWidget here, but it's a ViewModelWidget. This is a wrapper around StatelessWidget which will also provide us with the view model. This works with Provider under the hood.

Let's use this TodoListTile widget in ShowTodosView. We can update the ListView.builder as follows.

ListView.builder(
  physics: const AlwaysScrollableScrollPhysics(),
  itemCount: model.todos.length,
  itemBuilder: (context, index) =>
      TodoListTile(todo: model.todos[index]),
),

Implement delete and markCompleted methods.

We will now implement deleteTodo and markCompleted methods as follows.

  Future<void> deleteTodo(Todo todo) async {
    final response = await _todoRepository.deleteTodo(todo.id);
    response.fold(
      handleFailure,
      (_) => _todosDataService.remove(todo),
    );
  }

Here, we are calling the deleteTodo method from the repository, and if it's successful, we will remove the todo from the data service, that in turn will remove it from the UI.

  Future<void> markCompleted(Todo todo) async {
    if (busy('updating')) return;
    final completed = !todo.completed;
    _todosDataService.add(todo.copyWith(completed: completed));
    final updateDto = UpdateTodoDto(
      completed: !todo.completed,
    );
    final update = await runBusyFuture(
      _todoRepository.updateTodo(id: todo.id, updateTodoDto: updateDto),
      busyObject: 'updating',
    );
    update.fold(
      (failure) {
        _todosDataService.add(todo.copyWith(completed: !completed));
        handleFailure(failure);
      },
      (_) {},
    );
  }

Here, in markCompleted method, we are first negating the state, and then adding it to the data service, and then calling the API. This is to show the update in an instantaneous manner. If the update fails, we will revert the checkbox state.

We will add an empty implementation for the handleTodo method as follows.

  Future<void>? handleTodo([Todo? todo]) {
      return null;
  }

This method will take an optional Todo object, and we will pass it to MaintainTodoView, which will create or update the todo based on the value provided.

Once these methods are completed, we will have these functionalities.

Creating MaintainTodoView📝

This view will be able to create and update the todos. We will create the view and the view model. Also, we will create a route for this, and implement handleTodo method in ShowTodosViewModel.

We will create maintain_todo_view.dart and maintain_todo_viewmomdel.dart in presentstion/main_todo directory.

We will create the view model as follows.

@injectable
class MaintainTodoViewModel extends ReactiveViewModel {
  MaintainTodoViewModel(this._todosDataService);
  final TodosDataService _todosDataService;

  Todo? _todo;
  void init(Todo? todo) {
    if (todo == null) return;
    _todo = todo;
  }

  @override
  List<ReactiveServiceMixin> get reactiveServices => [_todosDataService];
}

Similarly, we will create an empty view, as follows

class MaintainTodoView extends StatelessWidget {
  const MaintainTodoView(this.todo, {super.key});
  final Todo? todo;
  @override
  Widget build(BuildContext context) {
    return ViewModelBuilder<MaintainTodoViewModel>.nonReactive(
      onModelReady: (model) => model.init(todo),
      viewModelBuilder: () => locator<MaintainTodoViewModel>(),
      builder: (
        BuildContext context,
        MaintainTodoViewModel model,
        Widget? child,
      ) {
        return Scaffold(
          body: Center(
            child: Text(
              'MaintainTodoView',
            ),
          ),
        );
      },
    );
  }
}

Now, we can add this view to the route, and handle routing from ShowTodosViewModel. In lib/core/app/routes.dart add the following route entry:

const List<StackedRoute<dynamic>> routes = [
  AdaptiveRoute(page: ShowTodosView, initial: true),
  AdaptiveRoute(page: MaintainTodoView),
];

Once you run the build_runner, open the ShowTodosViewModel, and make the following change.

We will have to register NavigationService in our third-party modules as follows.

@module
abstract class ThirdPartyModules {
  @lazySingleton
  Dio get dio => Dio(BaseOptions(baseUrl: kBaseUrl));

  @lazySingleton
  NavigationService get navigationService;
}

Now, we will inject the NavigationService from the ShowTodosViewModel constructor and implement the handleTodo as follows.

  ShowTodosViewModel(
    this._todoRepository,
    this._todosDataService,
+   this._navigationService,
  );

  final TodoRepository _todoRepository;
  final TodosDataService _todosDataService;
+ final NavigationService _navigationService;

  Future<void>? handleTodo([Todo? todo]) {
+   return _navigationService.navigateTo<void>(
+     Routes.maintainTodoView,
+     arguments: MaintainTodoViewArguments(todo: todo),
+   );
  }

Make sure to run build_runner.

Now, you should be able to navigate to MaintainTodoView.

Implementing MaintainTodoViewModel

We will create three state variables for handling title, description, and completed value. We will also expose the getters for these variables. Also, we will create onChanged methods for these variables.

We will also create an init method, which will take an optional Todo object and populate these state variables. Here if we pass this optional todo, we will be updating that todo.

@injectable
class MaintainTodoViewModel extends BaseViewModel {
  MaintainTodoViewModel(
    this._todosDataService,
    this._repository,
    this._navigationService,
  );

  final TodosDataService _todosDataService;
  final TodoRepository _repository;
  final NavigationService _navigationService;
  String _title = '';
  String get title => _title;

  String _description = '';
  String get description => _description;

  bool _completed = false;
  bool get completed => _completed;

  bool get isValidated {
    final empty = _title.isEmpty || _description.isEmpty;
    if (empty) return false;
    final errors = error('title') != null || error('description') != null;
    if (errors) return false;
    return true;
  }

  void onTitleChanged(String value) {
    _title = value;
    if (value.isEmpty) {
      setErrorForObject('title', 'Title is required');
    } else {
      setErrorForObject('title', null);
    }
    notifyListeners();
  }

  void onDescriptionChanged(String value) {
    _description = value;
    if (value.isEmpty) {
      setErrorForObject('description', 'Description is required');
    } else {
      setErrorForObject('description', null);
    }
    notifyListeners();
  }

  Todo? _todo;
  void init(Todo? todo) {
    if (todo == null) return;
    _title = todo.title;
    _description = todo.description;
    _todo = todo;
    _completed = todo.completed;
  }

  void onCompletedChanged({bool? value}) {
    _completed = value ?? false;
    notifyListeners();
  }

  void handleTodo() {}
}

In change handlers, we are also validating the values, and setting the errors for each state on change, and then we have a isValidated getter which would return if the values are validated or not.

Implementing MaintainTodoView

class MaintainTodoView extends HookWidget {
  const MaintainTodoView(this.todo, {super.key});
  final Todo? todo;

  @override
  Widget build(BuildContext context) {
    final titleController = useTextEditingController(text: todo?.title);
    final descriptionController =
        useTextEditingController(text: todo?.description);
    final titleFocusNode = useFocusNode();
    final descriptionFocusNode = useFocusNode();
    final checkBoxFocusNode = useFocusNode();
    final buttonFocusNode = useFocusNode();
    return ViewModelBuilder<MaintainTodoViewModel>.nonReactive(
      onModelReady: (model) => model.init(todo),
      viewModelBuilder: locator,
      builder: (
        BuildContext context,
        MaintainTodoViewModel model,
        Widget? child,
      ) {
        return Scaffold(
          appBar: AppBar(
            title: Text('${todo == null ? 'Create' : 'Edit'} Todo'),
          ),
          body: Padding(
            padding: const EdgeInsets.all(16),
            child: Column(
              crossAxisAlignment: CrossAxisAlignment.stretch,
              children: [
                TextFormField(
                  controller: titleController,
                  focusNode: titleFocusNode,
                  decoration: const InputDecoration(
                    hintText: 'Title',
                    border: OutlineInputBorder(),
                  ),
                  onChanged: model.onTitleChanged,
                  onEditingComplete: descriptionFocusNode.requestFocus,
                ),
                const SizedBox(height: 14),
                TextFormField(
                  controller: descriptionController,
                  focusNode: descriptionFocusNode,
                  decoration: const InputDecoration(
                    hintText: 'Description',
                    border: OutlineInputBorder(),
                  ),
                  onChanged: model.onDescriptionChanged,
                  onEditingComplete: checkBoxFocusNode.requestFocus,
                ),
                if (todo != null) const SizedBox(height: 14),
                if (todo != null)
                  SelectorViewModelBuilder<MaintainTodoViewModel, bool>(
                    selector: (model) => model.completed,
                    builder: (context, val, _) {
                      return CheckboxListTile(
                        focusNode: checkBoxFocusNode,
                        contentPadding: EdgeInsets.zero,
                        title: const Text('Mark Completed'),
                        value: val,
                        onChanged: (v) => model.onCompletedChanged(value: v),
                      );
                    },
                  ),
                const Spacer(),
                SelectorViewModelBuilder<MaintainTodoViewModel, bool>(
                  selector: (model) => model.isValidated,
                  builder: (context, validated, child) {
                    if (validated) return child!;
                    return const SizedBox.shrink();
                  },
                  child: SizedBox(
                    height: 50,
                    child: ElevatedButton(
                      focusNode: buttonFocusNode,
                      onPressed: model.handleTodo,
                      child:
                          SelectorViewModelBuilder<MaintainTodoViewModel, bool>(
                        selector: (model) => model.isBusy,
                        builder: (context, isBusy, child) {
                          if (isBusy) return child!;
                          return Row(
                            mainAxisSize: MainAxisSize.min,
                            children: const [
                              Icon(
                                Icons.save,
                                size: 30,
                              ),
                              SizedBox(width: 10),
                              Text(
                                'Save',
                                style: TextStyle(
                                  fontSize: 20,
                                ),
                              ),
                            ],
                          );
                        },
                        child: const CircularProgressIndicator(
                          valueColor:
                              AlwaysStoppedAnimation<Color>(Colors.white),
                        ),
                      ),
                    ),
                  ),
                )
              ],
            ),
          ),
        );
      },
    );
  }
}

This form includes crucial text fields for the title and description of the to-do task. The optional check box is displayed only when an existing to-do task is provided for updating. If a to-do task is provided, the form will be populated with the previous values and the check box will be visible for updating.

To handle the form's input, we utilize the flutter_hooks library for managing TextEditingControllers and FocusNodes. The ElevatedButton takes care of the create/update action.

We are also using SelectorViewModelBuilder with a selector to rebuild only when the value returned from the selector is changed, resulting in partial rebuilds. For example, we are only showing the ElevatedButton when the form is validated.

👉 Read more about SelectorViewModelBuilder

With this, we have a functional form UI something like this.

In the final part, let's implement handleTodo method in MaintainTodoViewmodel like this.

  Future<void> handleTodo() {
    if (!isValidated) return Future.value();
    if (_todo == null) {
      return _createTodo();
    }
    return _updateTodo();
  }

  Future<void> _createTodo() async {
    final dto = CreateTodoDto(title: title, description: description);
    final response = await runBusyFuture(_repository.createTodo(dto));
    return response.fold(
      (failure) {
        setError(failure.message);
      },
      (todo) {
        _todosDataService.add(todo);
        _navigationService.back<void>();
      },
    );
  }

  Future<void> _updateTodo() async {
    if (_todo == null) return;
    final dto = UpdateTodoDto(
      title: title,
      description: description,
      completed: completed,
    );
    final response = await runBusyFuture(
      _repository.updateTodo(id: _todo!.id, updateTodoDto: dto),
    );
    return response.fold(
      (failure) {
        setError(failure.message);
      },
      (todo) {
        _todosDataService.add(todo);
        _navigationService.back<void>();
      },
    );
  }

The handleTodo method is responsible for creating or updating a to-do task based on the optional Todo provided in the init method.

It calls the private methods _createTodo and _updateTodo internally. _createTodo creates a data transfer object, passes it to the repository, and navigates back upon successful creation.

Similarly, _updateTodo updates the provided to-do task and navigates back upon successful update.

Finally, we have a fully functional app.

Bonus 🎉

To ensure our code follows best practices and is consistent throughout our project, let's add some linting with very_good_analysis in analysis_options.yaml.

Linting is an important step in the development process as it helps catch potential errors and enforces a set of coding standards. This results in more readable and maintainable code, making it easier for both you and other developers to understand and work with the codebase.

include: package:very_good_analysis/analysis_options.yaml
analyzer:
  exclude:
    - '**/*.router.dart'
    - '**/*.locator.dart'
    - '**/*.config.dart'
    - '**/*.g.dart'
linter:
  rules:
    public_member_api_docs: false

🎉 Congrats, we've made it to the end of Part 5! 🚀 We've successfully built the front end of our full-stack to-do application using Flutter. From importing necessary dependencies to connecting with the backend, we've covered it all. We've even implemented features such as creating and updating todos, handling errors and creating a reactive data service.

It's been an amazing journey, and we've come a long way since Part 1. We've built a complete full-stack to-do application using Dart and Flutter. But our work doesn't stop here. In this series, we haven't covered testing yet, but it's a crucial part of building any application. If you're interested in learning more about testing your code in all the modules we've built in this series, let us know in the comments.

As always, you can refer back to the GitHub repo for this tutorial at https://github.com/saileshbro/full_stack_todo_dart if you need any help. Don't forget to give it a ⭐ and spread the love for the project. Also, if you're stuck or need help, feel free to open an issue or better yet, send a pull request.

Thank you for joining me in this adventure, let's make more amazing apps together. Happy coding! 💻

• Connect to a Postgres database

• Complete the backend routes

• Add a new controller to handle HTTP requests

• Add necessary failures and exceptions

• Fully implement CRUD operations for the to-do application

🚀 Implementing the Backend

It's time to tackle the backend of our to-do app! 💪 Let's get coding! 💻

Importing necessary dependencies 📦

Time to bring in the big guns! 💪 Let's import those dependencies

We will import all the necessary dependencies in the pubspec.yaml file.

dependencies:
  dart_frog: ^0.3.0
  data_source:
    path: ../data_source
  dotenv: ^4.0.1
  either_dart: ^0.3.0
  exceptions:
    path: ../exceptions
  failures:
    path: ../failures
  http: ^0.13.5
  models:
    path: ../models
  postgres: ^2.5.2
  repository:
    path: ../repository
  typedefs:
    path: ../typedefs

🛠️ Setting up the Postgres database

💾 Let's create a database

We will be using the PostgreSQL database for this tutorial. To use the PostgreSQL database for this tutorial, we can set up a test database on elephantsql.com. Simply sign up on the website and click on the option to create a new instance. You should see something similar to this.

Once you add a name, you will be prompted to choose a name for your instance and a region that is nearest to you. I have selected the AP-East-1 region, but you can choose any region that you prefer.

Once you have chosen a name and selected a region, click the Create Instance button. This will redirect you to a dashboard where you can click on the instance name to access the credentials for the database you have just created. The credentials should look similar to this.

Connecting to the Database 🔌

💻 Setting up our database connection like a boss

Setting up environment 🌿

Now that we have created a database, we can connect to it from our application. To do this, we will create a new file .env at the root of the backend directory. This file will contain the credentials for the database that we have just created. The .env file should look similar to this.

Once this is done, we will use the dotenv package to load the environment variables from the .env file. We will also use the postgres package to connect to the database. You can run the following command in the backend directory to add the necessary dependencies.

dart pub add dotenv postgres

This is how .env file should look. Make sure to use your database credentials

DB_HOST=tiny.db.elephantsql.com
DB_PORT=5432
DB_DATABASE=asztgqfq
DB_USERNAME=asztgqfq
DB_PASSWORD=PcIXbvXQLwpEON61GVPzqs0zHyzHyHZc

Creating database connection 🔗

Now, create a backend/lib/db/database_connection.dart file and add the following code.

import 'dart:developer';

import 'package:dotenv/dotenv.dart';
import 'package:postgres/postgres.dart';

class DatabaseConnection {
  DatabaseConnection(this._dotEnv) {
    _host = _dotEnv['DB_HOST'] ?? 'localhost';
    _port = int.tryParse(_dotEnv['DB_PORT'] ?? '') ?? 5432;
    _database = _dotEnv['DB_DATABASE'] ?? 'test';
    _username = _dotEnv['DB_USERNAME'] ?? 'test';
    _password = _dotEnv['DB_PASSWORD'] ?? 'test';
  }

  final DotEnv _dotEnv;
  late final String _host;
  late final int _port;
  late final String _database;
  late final String _username;
  late final String _password;
  PostgreSQLConnection? _connection;

  PostgreSQLConnection get db =>
      _connection ??= throw Exception('Database connection not initialized');

  Future<void> connect() async {
    try {
      _connection = PostgreSQLConnection(
        _host,
        _port,
        _database,
        username: _username,
        password: _password,
      );
      log('Database connection successful');
      return _connection!.open();
    } catch (e) {
      log('Database connection failed: $e');
    }
  }

  Future<void> close() => _connection!.close();
}

Whenever we want to query, we will open a connection to the database and close it once we are done. This will ensure that we are not keeping the connection open for too long.

💉Injecting DatabaseConnection through provider

Create a new file routes/_middleware.dart and add the following code.

import 'package:backend/db/database_connection.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:dotenv/dotenv.dart';

final env = DotEnv()..load();
final _db = DatabaseConnection(env);

Handler middleware(Handler handler) {
  return handler.use(provider<DatabaseConnection>((_) => _db));
}

This middleware is used to provide the DatabaseConnection instance to other parts of the application through a provider.

Fetching DatabaseConnection from provider 🔍

Now in routes/index.dart you can get this DatabaseConnection from RequestContext and use it to query the database.

import 'package:backend/db/database_connection.dart';
import 'package:dart_frog/dart_frog.dart';

Future<Response> onRequest(RequestContext context) async {
  final connection = context.read<DatabaseConnection>();
  await connection.connect();
  final response =
      await connection.db.query('select * from information_schema.tables');
  await connection.close();
  return Response.json(body: response.map((e) => e.toColumnMap()).toList());
}

If you run dart_frog dev, then you should be able to open http://localhost:8080 and see the following output.

We have successfully connected to the database.

Create Database Table 📝

🗃️ Let's build our database table

Before implementing the TodoDataSource, we will need to create the table in the database. To do this, open the elephantsql.com dashboard and click on the BROWSER tab.

Then, execute the following query:

CREATE TABLE todos(
    id SERIAL PRIMARY KEY NOT NULL,
    title VARCHAR(255) NOT NULL,
    description TEXT NOT NULL,
    completed BOOL DEFAULT FALSE,
    created_at timestamp default current_timestamp NOT NULL,
    updated_at timestamp null
);

This PostgreSQL query creates a new table called todos with the following columns:

• id: an integer column that is the table's primary key and is generated automatically by the database (using the SERIAL type). The NOT NULL constraint ensures that this column cannot contain a NULL value.

• title: a string column with a maximum length of 255 characters. The NOT NULL constraint ensures that this column cannot contain a NULL value.

• description: a text column. The NOT NULL constraint ensures that this column cannot contain a NULL value.

• completed: a boolean column with a default value of FALSE.

• created_at: a timestamp column with a default value of the current timestamp. The NOT NULL constraint ensures that this column cannot contain a NULL value.

• updated_at: a timestamp column that can contain a NULL value.

The todos table will be used to store the to-do items in our application. Each row in the table represents a single to-do item, and the table's columns store the data for that to-do item.

Once you run the query, you should see a toast message at the top.

Implementing TodoDataSource 💪

Cooking up some TodoDataSource magic 🔮

We will implement the todo data source in backend/lib/todo/data_source/todo_data_source_impl.dart. This file will contain the implementation of the TodoDataSource interface. We will pass a DatabaseConnection as a dependency to this class.

Create TodoDataSourceImpl and implement TodoDataSource interface, and override necessary methods. The empty implementation should look like this.

Empty TodoDataSource implementation

import 'package:backend/db/database_connection.dart';
import 'package:data_source/data_source.dart';
import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

class TodoDataSourceImpl implements TodoDataSource {
  const TodoDataSourceImpl(this._databaseConnection);
  final DatabaseConnection _databaseConnection;

  @override
  Future<Todo> createTodo(CreateTodoDto todo) {
    throw UnimplementedError();
  }

  @override
  Future<void> deleteTodoById(TodoId id) {
    throw UnimplementedError();
  }

  @override
  Future<List<Todo>> getAllTodo() {
    throw UnimplementedError();
  }

  @override
  Future<Todo> getTodoById(TodoId id) {
    throw UnimplementedError();
  }

  @override
  Future<Todo> updateTodo({required TodoId id, required UpdateTodoDto todo}) {
    throw UnimplementedError();
  }
}

💉Injecting TodoDataSource through provider

Let's add this to our global middleware in routes/_middleware.dart file

import 'package:backend/db/database_connection.dart';
import 'package:backend/todo/data_source/todo_data_source_impl.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:dotenv/dotenv.dart';
final env = DotEnv()..load();
final _db = DatabaseConnection(env);
final _ds = TodoDataSourceImpl(_db);

Handler middleware(Handler handler) {
  return handler
      .use(requestLogger())
      .use(provider<DatabaseConnection>((_) => _db))
      .use(provider<TodoDataSource>((_) => _ds));
}

createTodo implementation

Now we will implement the createTodo method.

  @override
  Future<Todo> createTodo(CreateTodoDto todo) async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        '''
        INSERT INTO todos (title, description, completed, created_at)
        VALUES (@title, @description, @completed, @created_at) RETURNING *
        ''',
        substitutionValues: {
          'title': todo.title,
          'description': todo.description,
          'completed': false,
          'created_at': DateTime.now(),
        },
      );
      if (result.affectedRowCount == 0) {
        throw const ServerException('Failed to create todo');
      }
      final todoMap = result.first.toColumnMap();
      return Todo(
        id: todoMap['id'] as int,
        title: todoMap['title'] as String,
        description: todoMap['description'] as String,
        createdAt: todoMap['created_at'] as DateTime,
      );
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

First, the method establishes a connection to the database using the _databaseConnection object. Then, it uses the query method on the db object to execute an INSERT statement The substitutionValues parameter is used to bind the values from the CreateTodoDto .

If the INSERT statement is successful, the method retrieves the inserted row from the database using the RETURNING * clause and converts it to a map using the toColumnMap method. The method then uses this map to create and return a new Todo object.

getAllTodo implementation

Now we will implement the getAllTodo method.

  @override
  Future<List<Todo>> getAllTodo() async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        'SELECT * FROM todos',
      );
      final data =
          result.map((e) => e.toColumnMap()).map(Todo.fromJson).toList();
      return data;
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

This getAllTodo method is used to retrieve a list of all the to-do items stored in the database. This executes a SELECT query to retrieve all rows from the todos table, maps each row to a Todo object using the Todo.fromJson function, and returns the list of Todo objects.

getTodoById implementation 🔍

Now we will implement the getTodoById method.

@override
Future<Todo> getTodoById(TodoId id) async {
  try {
    await _databaseConnection.connect();
    final result = await _databaseConnection.db.query(
      'SELECT * FROM todos WHERE id = @id',
      substitutionValues: {'id': id},
    );
    if (result.isEmpty) {
      throw const NotFoundException('Todo not found');
    }
    return Todo.fromJson(result.first.toColumnMap());
  } on PostgreSQLException catch (e) {
    throw ServerException(e.message ?? 'Unexpected error');
  } finally {
    await _databaseConnection.close();
  }
}

We execute a SELECT query that selects from todos table where the id equals the provided id. If the query returns an empty result set, we throw a NotFoundException, indicating that the requested to-do item could not be found, else it returns the mapped todo object.

updateTodo implementation 🔧

Here is the implementation of the updateTodo method.

  @override
  Future<Todo> updateTodo({
    required TodoId id,
    required UpdateTodoDto todo,
  }) async {
    try {
      await _databaseConnection.connect();
      final result = await _databaseConnection.db.query(
        '''
        UPDATE todos
        SET title = COALESCE(@new_title, title),
            description = COALESCE(@new_description, description),
            completed = COALESCE(@new_completed, completed),
            updated_at = current_timestamp
        WHERE id = @id
        RETURNING *
        ''',
        substitutionValues: {
          'id': id,
          'new_title': todo.title,
          'new_description': todo.description,
          'new_completed': todo.completed,
        },
      );
      if (result.isEmpty) {
        throw const NotFoundException('Todo not found');
      }
      return Todo.fromJson(result.first.toColumnMap());
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

It executes an UPDATE query on the todos table. If no value is provided for a column, then the COALESCE function is used to keep the existing value in the database unchanged. The updated_at column is set to the current_timestamp. If the result set is empty, it means that no row with the given id was found, so a NotFoundException is thrown.

deleteTodoById implementation 🗑️

Now, we will implement the deleteTodoById method.

  @override
  Future<void> deleteTodoById(TodoId id) async {
    try {
      await _databaseConnection.connect();
      await _databaseConnection.db.query(
        '''
        DELETE FROM todos
        WHERE id = @id
        ''',
        substitutionValues: {'id': id},
      );
    } on PostgreSQLException catch (e) {
      throw ServerException(e.message ?? 'Unexpected error');
    } finally {
      await _databaseConnection.close();
    }
  }

If the delete statement is successful, the method does not return anything.

PostgresSQLException handling 🚨

In all of the methods above, if there is an exception while querying, like PostgresSQLException, it is caught and a ServerException is thrown with a more general error message. Finally, the database connection is closed before the method finishes executing.

Implementing TodoRepository 💪

💪 Time to make that TodoRepository do some work!

We will implement the todo repository in backend/lib/todo/repositories/todo_repository_impl.dart. This file will contain the implementation of the TodoRepository interface. We will pass a TodoDataSource as a dependency to this class.

Empty TodoRepository implementation

Create TodoRepositoryImpl and implement TodoRepository interface, and override necessary methods. The empty implementation should look like this.

import 'package:data_source/data_source.dart';
import 'package:either_dart/either.dart';
import 'package:failures/failures.dart';
import 'package:models/models.dart';
import 'package:repository/repository.dart';
import 'package:typedefs/src/typedefs.dart';

class TodoRepositoryImpl implements TodoRepository {
  TodoRepositoryImpl(this.dataSource);

  final TodoDataSource dataSource;

  @override
  Future<Either<Failure, Todo>> createTodo(CreateTodoDto createTodoDto) {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, void>> deleteTodo(TodoId id) {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, Todo>> getTodoById(TodoId id) {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, List<Todo>>> getTodos() {
    throw UnimplementedError();
  }

  @override
  Future<Either<Failure, Todo>> updateTodo({
    required TodoId id,
    required UpdateTodoDto updateTodoDto,
  }) {
    throw UnimplementedError();
  }
}

💉Injecting TodoRepository through provider

Before implementing the methods of TodoRepository, we will add it to our global middleware so that we can access it from our routes.

import 'package:backend/db/database_connection.dart';
import 'package:backend/todo/data_source/todo_data_source_impl.dart';
import 'package:backend/todo/repositories/todo_repository_impl.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:data_source/data_source.dart';
import 'package:dotenv/dotenv.dart';
import 'package:repository/repository.dart';
final env = DotEnv()..load();
final _db = DatabaseConnection(env);
final _ds = TodoDataSourceImpl(_db);
final _repo = TodoRepositoryImpl(_ds);

Handler middleware(Handler handler) {
  return handler
      .use(requestLogger())
      .use(provider<DatabaseConnection>((_) => _db))
      .use(provider<TodoDataSource>((_) => _ds))
      .use(provider<TodoRepository>((_) => _repo));
}

createTodo implementation

Now we will implement the createTodo method.

  @override
  Future<Either<Failure, Todo>> createTodo(CreateTodoDto createTodoDto) async {
    try {
      final todo = await dataSource.createTodo(createTodoDto);
      return Right(todo);
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

In this code, we are implementing the createTodo method which is part of the TodoRepository interface using dataSource.createTodo method. The dataSource.createTodo method is responsible for inserting the todo into the database. If the insertion is successful, it returns the todo object.

getTodoById implementation

Now we will implement the getTodoById method.

  @override
  Future<Either<Failure, Todo>> getTodoById(TodoId id) async {
    try {
      final res = await dataSource.getTodoById(id);
      return Right(res);
    } on NotFoundException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(
          message: e.message,
          statusCode: e.statusCode,
        ),
      );
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

The method calls the dataSource.getTodoById method, which is responsible for querying the database and returning the todo object. If the todo is found, it returns the value. A NotFoundException is thrown when the todo with the given id is not found in the database.

getTodos implementation

Here, we will implement the getTodos method.

  @override
  Future<Either<Failure, List<Todo>>> getTodos() async {
    try {
      return Right(await dataSource.getAllTodo());
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

We call the dataSource.getAllTodo method. If the method execution is successful, we return the list of todo items.

updateTodo implementation 🔧

Now we will implement the updateTodo method.

  @override
  Future<Either<Failure, Todo>> updateTodo({
    required TodoId id,
    required UpdateTodoDto updateTodoDto,
  }) async {
    try {
      return Right(
        await dataSource.updateTodo(
          id: id,
          todo: updateTodoDto,
        ),
      );
    } on NotFoundException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(
          message: e.message,
          statusCode: e.statusCode,
        ),
      );
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

The method updates the todo using the dataSource.updateTodo method. If the update is successful, it returns the updated todo. If the update fails and a NotFoundException is thrown, it logs the error message and returns a ServerFailure object with the appropriate status code.

deleteTodo implementation

Finally, we will implement the deleteTodo method.

  @override
  Future<Either<Failure, void>> deleteTodo(TodoId id) async {
    try {
      final exists = await getTodoById(id);
      if (exists.isLeft) return exists;
      final todo = await dataSource.deleteTodoById(id);
      return Right(todo);
    } on ServerException catch (e) {
      log(e.message);
      return Left(
        ServerFailure(message: e.message),
      );
    }
  }

We check if a todo exists by calling the this.getTodoById method. If it does not exist, we return a Failure. If the todo does exist, we delete it by calling the dataSource.deleteTodoById.

Handling Exception 🛑

The dataSource methods throw exceptions like ServerException and NotFoundException. We catch these exceptions and log the error message. We then return a Left object containing a ServerFailure object. The ServerFailure object is a custom failure type that we can use to indicate that a server error occurred.

Building the TodoController 🔨

Bringing it all together with our fancy new controller 🎉

The controller will be responsible for handling HTTP requests and sending back the appropriate response. We will implement five methods in the controller:

• index GET /resource 🔍

• show GET /resource/{id} 📖

• store POST /resource 📤

• update PUT/PATCH /resource/{id} 🔗

• delete DELETE /resource/{id} 🗑️

These methods will correspond to the standard HTTP methods for retrieving, creating, updating, and deleting data. By using these methods, we can keep our code clean and organized. This approach is inspired by the Laravel framework's API controller methods.

Abstract HttpController 🔮

We will create a new abstract class in the backend/lib/controller/http_controller.dart called HttpController and which will have five methods.

import 'dart:async';

import 'package:dart_frog/dart_frog.dart';

abstract class HttpController {
  FutureOr<Response> index(Request request);

  FutureOr<Response> store(Request request);

  FutureOr<Response> show(Request request, String id);

  FutureOr<Response> update(Request request, String id);

  FutureOr<Response> destroy(Request request, String id);
}

Empty TodoController implementation

Now for the implementation of this contract, we will create a new class TodoController in the backend/lib/controller/todo_controller.dart file. We will implement each method in the TodoController class.

import 'dart:async';
import 'dart:convert';
import 'dart:io';

import 'package:backend/controller/http_controller.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:either_dart/either.dart';
import 'package:exceptions/exceptions.dart';
import 'package:failures/failures.dart';
import 'package:models/models.dart';
import 'package:repository/repository.dart';
import 'package:typedefs/typedefs.dart';

class TodoController extends HttpController {
  TodoController(this._repo);

  final TodoRepository _repo;
  @override
  FutureOr<Response> index(Request request) async {
    throw UnimplementedError();
  }

  @override
  FutureOr<Response> show(Request request, String id) async {
    throw UnimplementedError();
  }

  @override
  FutureOr<Response> destroy(Request request, String id) async {
    throw UnimplementedError();
  }

  @override
  FutureOr<Response> store(Request request) async {
    throw UnimplementedError();
  }

  @override
  FutureOr<Response> update(Request request, String id) async {
    throw UnimplementedError();
  }

  Future<Either<Failure, Map<String, dynamic>>> parseJson(
    Request request,
  ) async {
    throw UnimplementedError();
  }
}

Parse request body 🔬

Before we implement the methods, we will create a new helper method in HttpController which will be responsible to parse the request body.

If the request body is not a valid JSON, it will return a Left object containing a BadRequestFailure object. If the request body is a valid JSON, it will return a Right object containing the parsed JSON.

Add the following method to the HttpController class.

  Future<Either<Failure, Map<String, dynamic>>> parseJson(
    Request request,
  ) async {
    try {
      final body = await request.body();
      if (body.isEmpty) {
        throw const BadRequestException(message: 'Invalid body');
      }
      late final Map<String, dynamic> json;
      try {
        json = jsonDecode(body) as Map<String, dynamic>;
        return Right(json);
      } catch (e) {
        throw const BadRequestException(message: 'Invalid body');
      }
    } on BadRequestException catch (e) {
      return Left(
        ValidationFailure(
          message: e.message,
          errors: {},
        ),
      );
    }
  }

💉Injecting TodoController through provider

Let's add this to our global middleware routes/_middleware.dart file.

import 'package:backend/db/database_connection.dart';
import 'package:backend/todo/controller/todo_controller.dart';
import 'package:backend/todo/data_source/todo_data_source_impl.dart';
import 'package:backend/todo/repositories/todo_repository_impl.dart';
import 'package:dart_frog/dart_frog.dart';
import 'package:data_source/data_source.dart';
import 'package:dotenv/dotenv.dart';
import 'package:repository/repository.dart';

final env = DotEnv()..load();
final _db = DatabaseConnection(env);
final _ds = TodoDataSourceImpl(_db);
final _repo = TodoRepositoryImpl(_ds);
final _todoController = TodoController(_repo);

Handler middleware(Handler handler) {
  return handler
      .use(requestLogger())
      .use(provider<DatabaseConnection>((_) => _db))
      .use(provider<TodoDataSource>((_) => _ds))
      .use(provider<TodoRepository>((_) => _repo))
      .use(provider<TodoController>((_) => _todoController));
}

Note: We are using requestLogger middleware to log the request and response.

Implementing TodoController 🚀

We will implement the TodoController methods as follows:

index implementation

The index method will be responsible for retrieving all todo items from the database. We will implement it as follows:

  @override
  FutureOr<Response> index(Request request) async {
    final res = await _repo.getTodos();
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      (right) => Response.json(
        body: right.map((e) => e.toJson()).toList(),
      ),
    );
  }

We will call the getTodos method and map the response. If the failure case is returned, we will return a response with an error status code and the error message. Else, we will return a 200 status code and the list of todos.

show implementation

show method will be responsible for retrieving a single to-do item from the database. We will implement it as follows:

  @override
  FutureOr<Response> show(Request request, String id) async {
    final todoId = mapTodoId(id);
    if (todoId.isLeft) {
      return Response.json(
        body: {'message': todoId.left.message},
        statusCode: todoId.left.statusCode,
      );
    }
    final res = await _repo.getTodoById(todoId.right);
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      (right) => Response.json(
        body: right.toJson(),
      ),
    );
  }

We will first call mapTodoId method to validate the id parameter. If it returns a failure, we will return a failure response with the status code. Then we will get the todo item from the repository and return the todo item if it is found. Else, we will return a failure response with the status code.

store implementation

store method is as follows

  @override
  FutureOr<Response> store(Request request) async {
    final parsedBody = await parseJson(request);
    if (parsedBody.isLeft) {
      return Response.json(
        body: {'message': parsedBody.left.message},
        statusCode: parsedBody.left.statusCode,
      );
    }
    final json = parsedBody.right;
    final createTodoDto = CreateTodoDto.validated(json);
    if (createTodoDto.isLeft) {
      return Response.json(
        body: {
          'message': createTodoDto.left.message,
          'errors': createTodoDto.left.errors,
        },
        statusCode: createTodoDto.left.statusCode,
      );
    }
    final res = await _repo.createTodo(createTodoDto.right);
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      (right) => Response.json(
        body: right.toJson(),
        statusCode: HttpStatus.created,
      ),
    );
  }

If parseJson resolves to a failure, we will return a response with an error status code and message.

We will pass the JSON object to the CreateTodoDto.validated method. If this returns a failure, we will return a response with an error status code and message, here it will be ValidationFailure.

We will pass the DTO to createTodo method of the TodoRepository. If creating fails we will return a response with an error status code and message.

If everything goes right, we will return a response with a 201 status code and the to-do item.

destroy implementation

destroy method is as follows

  @override
  FutureOr<Response> destroy(Request request, String id) async {
    final todoId = mapTodoId(id);
    if (todoId.isLeft) {
      return Response.json(
        body: {'message': todoId.left.message},
        statusCode: todoId.left.statusCode,
      );
    }
    final res = await _repo.deleteTodo(todoId.right);
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      (right) => Response.json(body: {'message': 'OK'}),
    );
  }

We will first call mapTodoId method to validate the id parameter. If it returns a failure, we will return a failure response with the status code. Then we will get the delete todo item from the repository and return OK with 200 status code if. If there is a failure, we will return a failure response with the status code.

update implementation

update method will be responsible for updating a single to-do item from the database. We will implement it as follows:

  @override
  FutureOr<Response> update(Request request, String id) async {
    final parsedBody = await parseJson(request);
    final todoId = mapTodoId(id);
    if (todoId.isLeft) {
      return Response.json(
        body: {'message': todoId.left.message},
        statusCode: todoId.left.statusCode,
      );
    }
    if (parsedBody.isLeft) {
      return Response.json(
        body: {'message': parsedBody.left.message},
        statusCode: parsedBody.left.statusCode,
      );
    }

    final json = parsedBody.right;
    final updateTodoDto = UpdateTodoDto.validated(json);
    if (updateTodoDto.isLeft) {
      return Response.json(
        body: {
          'message': updateTodoDto.left.message,
          'errors': updateTodoDto.left.errors,
        },
        statusCode: updateTodoDto.left.statusCode,
      );
    }
    final res = await _repo.updateTodo(
      id: todoId.right,
      updateTodoDto: updateTodoDto.right,
    );
    return res.fold(
      (left) => Response.json(
        body: {'message': left.message},
        statusCode: left.statusCode,
      ),
      (right) => Response.json(
        body: right.toJson(),
      ),
    );
  }

This method is similar to the store method. We will first validate the id parameter and then the JSON body. If both are valid, we will call the updateTodo method of the TodoRepository and then resolve the failure or the updated value.

Implementing Routes 🛣️

We will now implement the routes. These are the routes that we will have

• GET /todos - Get all todos

• GET /todos/:id - Get a single todo

• POST /todos - Create a todo

• PUT /todos/:id - Update a todo

• PATCH /todos/:id - Update a todo

• DELETE /todos/:id - Delete a todo

dart_frog has a file system routing. For example, let's say we need to create todos/1 route. We will create a file routes/todos/[id].dart and it will be mapped to todos/1 route.

Implementing todos/ route

To implement all the HTTP methods related to todos/ route, we will create a new file routes/todos/index.dart.

We will create a file routes/todos/index.dart and implement the routes as follows:

import 'dart:io';

import 'package:backend/todo/controller/todo_controller.dart';
import 'package:dart_frog/dart_frog.dart';

Future<Response> onRequest(RequestContext context) async {
  final controller = context.read<TodoController>();
  switch (context.request.method) {
    case HttpMethod.get:
      return controller.index(context.request);
    case HttpMethod.post:
      return controller.store(context.request);
    case HttpMethod.put:
    case HttpMethod.patch:
    case HttpMethod.delete:
    case HttpMethod.head:
    case HttpMethod.options:
      return Response.json(
        body: {'error': '👀 Looks like you are lost 🔦'},
        statusCode: HttpStatus.methodNotAllowed,
      );
  }
}

Here, we are getting the TodoController from the context and mapping the respective HTTP method to the controller method. We are also handling cases when the HTTP method is not allowed.

Implementing todos/:id route

Similarly, we will create a file routes/todos/[id].dart and implement the routes as follows:

import 'dart:io';

import 'package:backend/todo/controller/todo_controller.dart';
import 'package:dart_frog/dart_frog.dart';

Future<Response> onRequest(RequestContext context, String id) async {
  final todoController = context.read<TodoController>();
  switch (context.request.method) {
    case HttpMethod.get:
      return todoController.show(context.request, id);
    case HttpMethod.put:
    case HttpMethod.patch:
      return todoController.update(context.request, id);
    case HttpMethod.delete:
      return todoController.destroy(context.request, id);
    case HttpMethod.head:
    case HttpMethod.options:
    case HttpMethod.post:
      return Response.json(
        body: {'error': '👀 Looks like you are lost 🔦'},
        statusCode: HttpStatus.methodNotAllowed,
      );
  }
}

Here, we will get the id parameter from the route as a second parameter in onRequest method as a string. This can be anything. This explains the use of mapTodoId function in typedefs package.

We will pass the id parameter to the controller methods. We will also handle the case when the HTTP method is not allowed.

Implementing / route

Finally, we will update routes/index.dart file to return methodNotAllowed response. This is our / route, which will be handled as follows:

import 'dart:io';

import 'package:dart_frog/dart_frog.dart';

Future<Response> onRequest(RequestContext context) async {
  return Response.json(
    body: {'error': '👀 Looks like you are lost 🔦'},
    statusCode: HttpStatus.methodNotAllowed,
  );
}

🧪 Testing backend

Time to put our backend to the test! 🔍

We will run some e2e tests, to verify the backend works fine. create a file backend/e2e/routes_test.dart and implement the tests as follows:

import 'dart:convert';
import 'dart:io';

import 'package:http/http.dart' as http;
import 'package:models/models.dart';
import 'package:test/test.dart';

void main() {
  late Todo createdTodo;
  tearDownAll(() async {
    final response = await http.get(Uri.parse('http://localhost:8080/todos'));
    final todos = (jsonDecode(response.body) as List)
        .map((e) => Todo.fromJson(e as Map<String, dynamic>))
        .toList();
    for (final todo in todos) {
      await http.delete(Uri.parse('http://localhost:8080/todos/${todo.id}'));
    }
  });
  group('E2E -', () {
    test('GET /todos returns empty list of todos', () async {
      final response = await http.get(Uri.parse('http://localhost:8080/todos'));
      expect(response.statusCode, HttpStatus.ok);
      expect(response.body, equals('[]'));
    });

    test('POST /todos to create a new todo', () async {
      final response = await http.post(
        Uri.parse('http://localhost:8080/todos'),
        headers: {
          'Content-Type': 'application/json',
        },
        body: jsonEncode(_createTodoDto.toJson()),
      );
      expect(response.statusCode, HttpStatus.created);
      createdTodo =
          Todo.fromJson(jsonDecode(response.body) as Map<String, dynamic>);
      expect(createdTodo.title, equals(_createTodoDto.title));
      expect(createdTodo.description, equals(_createTodoDto.description));
    });

    test('GET /todos returns list of todos with one todo', () async {
      final response = await http.get(Uri.parse('http://localhost:8080/todos'));
      expect(response.statusCode, HttpStatus.ok);
      final todos = (jsonDecode(response.body) as List)
          .map((e) => Todo.fromJson(e as Map<String, dynamic>))
          .toList();
      expect(todos.length, equals(1));
      expect(todos.first, equals(createdTodo));
    });

    test('GET /todos/:id returns the created todo', () async {
      final response = await http.get(
        Uri.parse('http://localhost:8080/todos/${createdTodo.id}'),
      );
      expect(response.statusCode, HttpStatus.ok);
      final todo =
          Todo.fromJson(jsonDecode(response.body) as Map<String, dynamic>);
      expect(todo, equals(createdTodo));
    });

    test('PUT /todos/:id to update the created todo', () async {
      final updateTodoDto = UpdateTodoDto(
        title: 'updated title',
        description: 'updated description',
      );
      final response = await http.put(
        Uri.parse('http://localhost:8080/todos/${createdTodo.id}'),
        headers: {
          'Content-Type': 'application/json',
        },
        body: jsonEncode(updateTodoDto.toJson()),
      );
      expect(response.statusCode, HttpStatus.ok);
      final todo =
          Todo.fromJson(jsonDecode(response.body) as Map<String, dynamic>);
      expect(todo.title, equals(updateTodoDto.title));
      expect(todo.description, equals(updateTodoDto.description));
    });

    test('PATCH /todos/:id to update the created todo', () async {
      final updateTodoDto = UpdateTodoDto(
        title: 'UPDATED TITLE',
        description: 'UPDATED DESCRIPTION',
      );
      final response = await http.patch(
        Uri.parse('http://localhost:8080/todos/${createdTodo.id}'),
        headers: {
          'Content-Type': 'application/json',
        },
        body: jsonEncode(updateTodoDto.toJson()),
      );
      expect(response.statusCode, HttpStatus.ok);
      final todo =
          Todo.fromJson(jsonDecode(response.body) as Map<String, dynamic>);
      expect(todo.title, equals(updateTodoDto.title));
      expect(todo.description, equals(updateTodoDto.description));
    });

    test('DELETE /todos/:id to delete the created todo', () async {
      final response = await http.delete(
        Uri.parse('http://localhost:8080/todos/${createdTodo.id}'),
      );
      expect(response.statusCode, HttpStatus.ok);
      expect(response.body, jsonEncode({'message': 'OK'}));
    });
    test('GET /todos returns empty list of todos', () async {
      final response = await http.get(Uri.parse('http://localhost:8080/todos'));
      expect(response.statusCode, HttpStatus.ok);
      expect(response.body, equals('[]'));
    });
  });
}

final _createTodoDto = CreateTodoDto(
  title: 'title',
  description: 'description',
);

To run the tests, first, start the backend server by running the following command:

dart_frog dev

And then on a new terminal run the tests:

dart test e2e/routes_test.dart

Wow, we've made it to the end of part 4! 🎉 It's been a wild ride, but we've finally completed the backend of our full-stack to-do application. We connected to a Postgres database, completed all our backend routes, and fully implemented CRUD operations. We even tested our backend to make sure everything is running smoothly.

But we're not done yet! In the final part of this tutorial, we'll be building the front end of our to-do app using Flutter. It's going to be a blast! 💻

Don't forget, you can always refer back to the GitHub repo for this tutorial at https://github.com/saileshbro/full_stack_todo_dart if you need a little help along the way.

Until next time, happy coding! 😄

• Make changes to the failure classes

• Create new failures

  • RequestFailure

  • ValidationFailure

  • ServerFailure

• Create new Exceptions

  • ServerException

  • HttpException

  • NotFoundException

  • BadRequestException

• Add validation to DTOs

• Add JSON converters

Creating and updating packages 📦

In this section, we will create new packages using very_good_cli and update existing ones to efficiently manage the packages in our full-stack to-do application.

Working with Failure classes

It's time to shake things up in the failure department! 💥 Let's get to work on updating our failure classes.

Create build.yaml

We will now create a new file called build.yaml in the failures directory and add the following code. This will change the behaviour of the json_serializable so that it generates JSON keys in snake_case.

targets:
  $default:
    builders:
      json_serializable:
        options:
          any_map: false
          checked: false
          create_factory: true
          disallow_unrecognized_keys: false
          explicit_to_json: true
          field_rename: snake
          generic_argument_factories: false
          ignore_unannotated: false
          include_if_null: true

Update Failure

Let's add a new getter to the Failure abstract class to get the status code of the failure. This will allow us to map the failure to the appropriate HTTP status code in the controller.

abstract class Failure {
  String get message;
+ int get statusCode;
}

Update NetworkFailure

We will update our failure package and add more failures to it. To do this, we will begin by renaming the code field in our NetworkFailure class to statusCode. This will make the field more meaningful and easier for our readers to understand.

class NetworkFailure extends Failure with _$NetworkFailure {
  /// {@macro network_failure}
  const factory NetworkFailure({
    required String message,
-   required int code,
+   required int statusCode,
    @Default([]) List<String> errors,
  }) = _NetworkFailure;

Create new failures

Time to add some more failure friends to our app! 🙌

We'll be creating RequestFailure, ServerFailure, and ValidationFailure to help us map out any potential errors that may occur.

RequestFailure

To create a RequestFailure class, we will create a new file in the src directory called request_failure/request_failure.dart.

import 'dart:io';

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

part 'request_failure.freezed.dart';

@freezed
class RequestFailure extends Failure with _$RequestFailure {
  const factory RequestFailure({
    required String message,
    @Default(HttpStatus.badRequest) int statusCode,
  }) = _RequestFailure;
}

We will create two new classes in the src directory, ServerFailure and ValidationFailure. The ServerFailure class will be used to represent errors that occur on the server side of our application, and the ValidationFailure class will be used to represent validation errors in our application.

ServerFailure

import 'dart:io';

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

part 'server_failure.freezed.dart';

@freezed
class ServerFailure extends Failure with _$ServerFailure {
  const factory ServerFailure({
    required String message,
    @Default(HttpStatus.internalServerError) int statusCode,
  }) = _ServerFailure;
}

ValidationFailure

import 'dart:io';

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

part 'validation_failure.freezed.dart';

@freezed
class ValidationFailure extends Failure with _$ValidationFailure {
  const factory ValidationFailure({
    required String message,
    @Default(HttpStatus.badRequest) int statusCode,
    @Default({}) Map<String, List<String>> errors,
  }) = _ValidationFailure;
}

Don't forget to export and run build_runner 😎

library failures;

export 'src/failure.dart';
export 'src/network_failure/network_failure.dart';
export 'src/request_failure/request_failure.dart';
export 'src/server_failure/server_failure.dart';
export 'src/validation_failure/validation_failure.dart';

💡 Note: You can run the build_runner command by running flutter pub run build_runner build in the terminal.

Working with packages

Get ready for some package updating fun! 📦

Update typedefs package

We will be creating a function called mapTodoId in the typedefs package. This function will be responsible for converting a string id to a TodoId object. This is necessary because we need a way to convert user input into a format our application can understand and use. If the id is not valid, the mapTodoId function will return a RequestFailure object. This will allow us to handle any errors or invalid input gracefully, ensuring that our application is robust and can handle any potential issues

Either<Failure, TodoId> mapTodoId(String id) {
  try {
    final todoId = int.tryParse(id);
    if (todoId == null) throw const BadRequestException(message: 'Invalid id');
    return Right(todoId);
  } on BadRequestException catch (e) {
    return Left(
      RequestFailure(
        message: e.message,
        statusCode: e.statusCode,
      ),
    );
  }
}

The mapTodoId method will return either a TodoId object or a RequestFailure object. Make sure to add the dependencies either_dart and failures to the pubspec.yaml file of the typedefs package.

dependencies:
  either_dart: ^0.3.0
  exceptions:
    path: ../exceptions
  failures:
    path: ../failures

Create a new exceptions package

To handle internal exceptions and map them to the appropriate failures, we will create a new package called exceptions and throw our custom exceptions. For example, if we encounter a PostgreSQLException while inserting a new to-do, we will throw a ServerException and map it to the ServerFailure class. To create the exceptions package, run the following command in the terminal:

very_good create -t dart_pkg exceptions

This package will include different types of exceptions such as ServerException, HttpException, and NotFoundException. The ServerException will be thrown in the case of an internal server error, while the HttpException is an abstract class that will be extended by other exceptions like NotFoundException and BadRequestException. We can use these custom exceptions to handle internal errors and map them to the appropriate failure classes, such as ServerFailure or RequestFailure. We will start by creating a new file inside src/server_exception/server_exception.dart and add the following code:

ServerException

To create ServerException we will create a new file src/server_exception/server_exception.dart and add the following code:

class ServerException implements Exception {
  const ServerException(this.message);

  final String message;
  @override
  String toString() => 'ServerException: $message';
}

HttpExpection

To create HttpException we will create a new file src/http_exception/http_exception.dart and add the following code:

abstract class HttpException implements Exception {
  const HttpException(this.message, this.statusCode);
  final String message;
  final int statusCode;

  @override
  String toString() => '$runtimeType: $message';
}

NotFoundException

Next, we will create NotFoundException, which will be thrown when a resource is not found. To do this, create a new file called src/http_exception/not_found_exception.dart and add the following code:

class NotFoundException extends HttpException {
  const NotFoundException(String message) : super(message, HttpStatus.notFound);
}

BadRequestException

Similarly, we will create a new file inside src/http_exception/bad_request_exception.dart and add the following code:

class BadRequestException extends HttpException {
  const BadRequestException({
    required String message,
    this.errors = const {},
  }) : super(message, HttpStatus.badRequest);

  final Map<String, List<String>> errors;
}

Make sure to import the HttpException. Once you are done with HttpException, add an export statement in http_exception.dart file.

export './bad_request_exception.dart';
export './not_found_exception.dart';

And finally, export the HttpException from exceptions/lib/exceptions.dart file.

library exceptions;

export 'src/http_exception/http_exception.dart';
export 'src/server_exception/server_exception.dart';

Update models package

Let's handle the validation

Ready to add some sass to your data validation? Let's get those DTOs in shape! 💪

To add validation to our CreateTodoDto class, we will create a new static method called validated in models/lib/src/create_todo_dto/create_todo_dto.dart. This method will return either a ValidationFailure object or a CreateTodoDto object. We will use this method to ensure that our to-do creation requests contain all necessary information before they are processed. The validation rules are:

• the title should not be empty

• the description should not be empty

Before we can add the validated method to the CreateTodoDto class, we need to make sure that the necessary packages are added to the pubspec.yaml file.

dependencies:
  either_dart: ^0.3.0
  exceptions:
    path: ../exceptions
  failures:
    path: ../failures
  freezed_annotation: ^2.2.0
  json_annotation: ^4.7.0
  typedefs:
    path: ../typedefs

Now we will create a validated method inside CreateTodoDto

  static Either<ValidationFailure, CreateTodoDto> validated(
    Map<String, dynamic> json,
  ) {
    try {
      final errors = <String, List<String>>{};
      if (json['title'] == null) {
        errors['title'] = ['Title is required'];
      }
      if (json['description'] == null) {
        errors['description'] = ['Description is required'];
      }
      if (errors.isEmpty) return Right(CreateTodoDto.fromJson(json));
      throw BadRequestException(
        message: 'Validation failed',
        errors: errors,
      );
    } on BadRequestException catch (e) {
      return Left(
        ValidationFailure(
          message: e.message,
          errors: e.errors,
          statusCode: e.statusCode,
        ),
      );
    }
  }

Similarly, we will create a new static method called validated to validate the UpdateTodoDto. We will ensure that at least one field is present.

  static Either<ValidationFailure, UpdateTodoDto> validated(
    Map<String, dynamic> json,
  ) {
    try {
      final errors = <String, List<String>>{};
      if (json['title'] == null || json['title'] == '') {
        errors['title'] = ['At least one field must be provided'];
      }
      if (json['description'] == null || json['description'] == '') {
        errors['description'] = ['At least one field must be provided'];
      }
      if (json['completed'] == null) {
        errors['completed'] = ['At least one field must be provided'];
      }
      if (errors.length < 3) return Right(UpdateTodoDto.fromJson(json));
      throw BadRequestException(
        message: 'Validation failed',
        errors: errors,
      );
    } on BadRequestException catch (e) {
      return Left(
        ValidationFailure(
          message: e.message,
          statusCode: e.statusCode,
          errors: e.errors,
        ),
      );
    }
  }

Custom JSON converters

To serialize and deserialize our DateTime objects, we will create a new file called models/lib/src/serializers/date_time_serializer.dart. In this file, we will add the necessary code to handle the serialization and deserialization of DateTime objects.

These classes will implement the JsonConverter interface and provide the necessary logic to convert DateTime objects to and from JSON. The DateTimeConverterNullable class will handle cases where the DateTime object may be null, while the DateTimeConverter class will handle non-null DateTime objects. With these classes in place, we will be able to correctly handle the formatting of DateTime objects when retrieving data from the database.

class DateTimeConverterNullable extends JsonConverter<DateTime?, dynamic> {
  const DateTimeConverterNullable();

  @override
  DateTime? fromJson(dynamic json) {
    if (json == null) return null;
    return const DateTimeConverter().fromJson(json);
  }

  @override
  String? toJson(DateTime? object) {
    if (object == null) return null;
    return const DateTimeConverter().toJson(object);
  }
}
class DateTimeConverter extends JsonConverter<DateTime, dynamic> {
  const DateTimeConverter();

  @override
  DateTime fromJson(dynamic json) {
    if (json is DateTime) return json;
    return DateTime.parse(json as String);
  }

  @override
  String toJson(DateTime object) {
    return object.toIso8601String();
  }
}

Now we can use this converter in our Todo model.

  factory Todo({
    required TodoId id,
    required String title,
    @Default('') String description,
    @Default(false) bool? completed,
-   required DateTime createdAt,
+   @DateTimeConverter() required DateTime createdAt,
-   DateTime? updatedAt,
+   @DateTimeConverterNullable() DateTime? updatedAt,
  }) = _Todo;

Once you have finished updating the Todo model to use the converters.

Don't forget to run build_runner 😎

Woo hoo! We made it to the end of part 3 🎉

In this part, we gave our failure classes a little update and created some new ones. We also added some shiny new exceptions and made sure our DTOs were properly validated. We're almost there, friends! Just a few more steps until we can fully implement the CRUD operations for our awesome to-do app.

In the final part, we'll finally be able to connect to a Postgres database and complete all our backend routes. It's going to be a coding party 🎉 Are you ready to join the fun? I know I am! 🤩

And if you ever need a reference, just head on over to the GitHub repo for this tutorial at https://github.com/saileshbro/full_stack_todo_dart.

Let's get ready to code some magic in part 4! 😄

We will create models, data sources, repositories, and failure classes as a separate Dart package in part 2.

To do this, we will be using very_good_cli.

Setting up Models, Repositories, and Data Services 💻

Installing very_good_cli

very_good_cli, a Command-Line Interface that provides helpful commands and templates for generating various types of projects, including Flutter apps, Flame games, Flutter packages, Dart packages, federated plugins, and Dart CLI projects.

Very Good CLI makes it easy to create and set up these types of projects with a single command, so let's get started!

To install Very Good CLI, open a terminal and enter the following command:

dart pub global activate very_good_cli

To confirm that Very Good CLI has been installed correctly, you can enter the following command in a terminal very_good --version 🚀

Creating typedefs

We will have our typedefs, which will be shared between the backend and frontend of our project. To create a new Dart package for these typedefs, we can use the following command:

very_good create -t dart_pkg typedefs

This will generate a new dart package typedefs. Here -t dart_pkg means we are creating a new dart package.

Once the typedefs package has been created and the necessary files and directories have been generated, you can navigate to typedefs/lib/src/typedefs.dart to create a new typedef.

In this file, you can create a new typedef by adding the following code:

/// Primary key type for a Todo.
typedef TodoId = int;

This will create a new typedef called TodoId, an alias for the type int. This typedef can then be used throughout the backend and frontend of your project to represent an identifier for a to-do item. Once you are done, make sure to export the file from lib/typedefs.dart

library typedefs;
export 'src/typedefs.dart';

We will add additional shared typedefs to this file as needed. GitHub Link

Creating models

Similarly, we will have a separate package to house shared data models.

1. CreateTodoDto This will be used to send and receive payload for creating a new todo.

2. UpdateTodoDto This will be used to send and receive payload for updating an existing todo.

3. Todo This is the representation of the Todo entity.

To create a separate package for models you can use the very_good CLI:

very_good create -t dart_pkg models

Once the package has been created, we will install freezed for JSON serialization and value equality, as this library provides helpful tools for these tasks. We will use json_serializable for JSON serialization. To install freezed and freezed_annotation, open your terminal inside the models package and use the command:

dart pub add freezed json_serializable build_runner -d
dart pub add freezed_annotation json_annotation

Inside models/lib we will create files in the given order. We have created a parent folder for each model to house the generated codes so that it will look cleaner.

.
├── models.dart
└── src
    ├── create_todo_dto
    │   └── create_todo_dto.dart
    ├── todo
    │   └── todo.dart
    └── update_todo_dto
        └── update_todo_dto.dart

Now, in todo.dart we will use freezed package to create a data class.

freezed package is a code generation tool that allows you to create immutable classes with concise, boilerplate-free syntax. It uses the @freezed annotation to generate a number of useful methods and operators for your class, such as ==, hashCode, and copyWith.

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

part 'todo.freezed.dart';
part 'todo.g.dart';

@freezed
class Todo with _$Todo {
  factory Todo({
    required TodoId id,
    required String title,
    @Default('') String description,
    @Default(false) bool? completed,
    required DateTime createdAt,
    DateTime? updatedAt,
  }) = _Todo;

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

Since TodoId is in a separate package, we will have to add it in the models/pubspec.yaml file as a dependency. After adding the pubspec.yaml should look like this.

name: models
description: A Very Good Project created by Very Good CLI.
version: 0.1.0+1
publish_to: none

environment:
  sdk: ">=2.18.0 <3.0.0"

dependencies:
  freezed_annotation: ^2.2.0
  json_annotation: ^4.7.0
  typedefs:
    path: ../typedefs

dev_dependencies:
  build_runner: ^2.3.3
  freezed: ^2.3.2
  json_serializable: ^6.5.4
  lints: ^2.0.0
  mocktail: ^0.3.0
  test: ^1.19.2
  very_good_analysis: ^3.1.0

Similarly, we will create create_todo_dto.dart for CreateDotoDto class.

import 'package:freezed_annotation/freezed_annotation.dart';

part 'create_todo_dto.freezed.dart';
part 'create_todo_dto.g.dart';

@freezed
class CreateTodoDto with _$CreateTodoDto {
  factory CreateTodoDto({
    required String title,
    required String description,
  }) = _CreateTodoDto;

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

Similarly, we will create update_todo_dto.dart for UpdateTodoDto class.

import 'package:freezed_annotation/freezed_annotation.dart';

part 'update_todo_dto.freezed.dart';
part 'update_todo_dto.g.dart';

@freezed
class UpdateTodoDto with _$UpdateTodoDto {
  factory UpdateTodoDto({
    String? title,
    String? description,
    bool? completed,
  }) = _UpdateTodoDto;

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

Once this is done, we run build_runner and generate the necessary code. To generate the missing code, you can run the following command:

dart pub run build_runner build --delete-conflicting-outputs

This will generate *.g.dart and *.freezed.dart files. Once this is done, you will have files inside models/lib in the given order.

.
├── models.dart
└── src
    ├── create_todo_dto
    │   ├── create_todo_dto.dart
    │   ├── create_todo_dto.freezed.dart
    │   └── create_todo_dto.g.dart
    ├── todo
    │   ├── todo.dart
    │   ├── todo.freezed.dart
    │   └── todo.g.dart
    └── update_todo_dto
        ├── update_todo_dto.dart
        ├── update_todo_dto.freezed.dart
        └── update_todo_dto.g.dart

Once you are done creating the models, be sure to export them from lib/models.dart

library models;

export 'src/create_todo_dto/create_todo_dto.dart';
export 'src/todo/todo.dart';
export 'src/update_todo_dto/update_todo_dto.dart';

You can find the GitHub link for models here.

Creating failures

In the next step, we will create a separate package to handle failures in our application. This package will contain all the failures that may occur, such as NetworkFailure or ServerFailure. Whenever we need to handle an error, we will encapsulate the value or error in a union type and return it from a repository. For example, when we make an API call to retrieve data, we may receive either the requested data or an error. By encapsulating this in an Either type, we can effectively handle and manage failures in our app.

This is inspired by ReSo Coder's Clean Architecture tutorial.

To create the failures package:

very_good create -t dart_pkg failures

This will create a new package in failures directory. We will use freezed and json_serializable libraries for data serialization here as well.

dart pub add freezed json_serializable build_runner -d
dart pub add freezed_annotation json_annotation

To begin, we will create a Failure class inside the lib/src/failure.dart directory. This class will be the base for all failure types and will handle and manage our app's failures.

abstract class Failure {
  String get message;
}

We can then create specific failure classes, such as NetworkFailure, to return to the caller whenever there is a network exception. For instance, if we have a TodosRemoteDataSource that makes a call to a backend and encounters a HTTP exception, the data source can throw a NetworkException which will be caught by a repository TodoRepository. The repository will then encapsulate the error in a union type and return either the requested data or the failure to the caller. This allows us to effectively handle and manage failures in our app.

To create a NetworkFailure class, we will create a new file in the src directory called network_failure/network_failure.dart.

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

part 'network_failure.freezed.dart';
part 'network_failure.g.dart';

@freezed
class NetworkFailure extends Failure with _$NetworkFailure {
  const factory NetworkFailure({
    required String message,
    required int code,
    @Default([]) List<String> errors,
  }) = _NetworkFailure;

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

Once you have finished creating the NetworkFailure class, you can run the build_runner command to generate the necessary files for your project.

Make sure to export the failure class from failures/lib/failures.dart

library failures;

export 'src/failure.dart';
export 'src/network_failure/network_failure.dart';

You can view the code from here.

Creating data_source

We will create a new package with very_good_cli for our data source.

very_good create -t dart_pkg data_source

Once the package is created, we can create an abstract data source contract.

import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

abstract class TodoDataSource {
  Future<List<Todo>> getAllTodo();

  Future<Todo> getTodoById(TodoId id);

  Future<Todo> createTodo(CreateTodoDto todo);

  Future<Todo> updateTodo({
    required TodoId id,
    required UpdateTodoDto todo,
  });

  Future<void> deleteTodoById(TodoId id);
}

You can import the missing packages in pubspec.yaml. After importing, it should look like this.

name: data_source
description: A Very Good Project created by Very Good CLI.
version: 0.1.0+1
publish_to: none

environment:
  sdk: ">=2.18.0 <3.0.0"
dependencies:
  models:
    path: ../models
  typedefs:
    path: ../typedefs

dev_dependencies:
  mocktail: ^0.3.0
  test: ^1.19.2
  very_good_analysis: ^3.1.0

The TodoDataSource class will be used by both the frontend and backend of our app to access and manage data related to to-dos. This class will throw known exceptions that can be handled in the TodoRepository. To manage these exceptions, we will create a separate exceptions package where we can register all the exceptions used in our app. The TodoRepository will then be responsible for handling these exceptions, allowing us to effectively manage and handle errors in our application.

Once you are done adding the data source, make sure to export it in data_sources/data_sources.dart

library data_source;

export 'src/todo_data_source.dart';

You can view the code for the data_source from GitHub.

Creating repository

We will make use of the TodoDataSource class to access and manage data related to to-dos. We will also catch any exceptions thrown by the TodoDataSource and serialize them as failures. TodoRepository will then return the failure or the requested data to the caller.

To create the TodoRepository class, we will first navigate to the root directory of our project and create a new package using the very_good CLI:

very_good create -t dart_pkg repository

Once we are done, we will add all the dependencies in pubspec.yaml and run dart pub get to get all the packages.

dependencies:
  either_dart: ^0.3.0
  models:
    path: ../models
  failures:
    path: ../failures
  typedefs:
    path: ../typedefs
  data_source:
    path: ../data_source

To create an abstract TodoRepository class, we will navigate to our project's lib/src directory and create a new file called todo_repository.dart. Inside this file, we will make the TodoRepository class and add the necessary abstract methods that will be used to manage and access data related to to-dos.

import 'package:either_dart/either.dart';
import 'package:failures/failures.dart';
import 'package:models/models.dart';
import 'package:typedefs/typedefs.dart';

abstract class TodoRepository {
  Future<Either<Failure, List<Todo>>> getTodos();

  Future<Either<Failure, Todo>> getTodoById(TodoId id);

  Future<Either<Failure, Todo>> createTodo(CreateTodoDto createTodoDto);

  Future<Either<Failure, Todo>> updateTodo({
    required TodoId id,
    required UpdateTodoDto updateTodoDto,
  });

  Future<Either<Failure, void>> deleteTodo(TodoId id);
}

We are using either_dart to encapsulate the failure and data in the same place.

either_dart is the error handling and railway-oriented programming library is a Dart library that supports async "map" and async "then" functions for working with asynchronous computations and handling errors with Future<Either> values.

After you are done, make sure to export it in src/repository.dart

library repository;

export 'src/todo_repository.dart';

You can find the code for this on GitHub.

Damn! that was a lot of code and a lot of writing 😮‍💨

🎉 In Part 3, we're going to get started on the implementation of our repository! 💻 We'll begin by setting up the backend and establishing database connections. 🔌 It's going to be a lot of fun and a great opportunity to get hands-on with the code. So stay tuned! 😎

This tutorial will create a full-stack to-do application using Dart and Flutter in a monorepo setup.

A monorepo is a version control repository containing multiple projects with common code.

This allows for easier management and collaboration on projects within a single repository. We will share a common code between the frontend and backend of our to-do application, like interfaces, data models e.t.c.

The application's backend will be built using dart_frog, while the front end will be developed using Flutter.

This tutorial teaches you how to:

• 🧰 Set up a monorepo

• 💻 Create a full-stack Dart Flutter application

• 🔗 Manage and share common code between front-end and back end

• 📝 Build a to-do application with CRUD functionality

• 🏁 Complete the tutorial with a functional to-do application

Let's Go! 🚀

Before we can build our full-stack to-do application, we must set up the necessary tools and dependencies. First, we will install melos.

Setup melos 🛠️

Melos is a library that will be used to set up and manage monorepo projects.

To install melos, open a terminal and run the following command:

dart pub global activate melos

This command will install Melos globally, allowing us to use it in any project.

Create a melos.yaml file and add the below content to set up our full-stack to-do application.

name: full_stack_todo_dart
packages:
  - /**/pubspec.yaml

The packages field defines the packages that are part of the monorepo. In this case, we are using the /**/pubspec.yaml pattern, which tells Melos to search for all pubspec.yaml files in the project and consider them as packages.

Hopping into backend with dart_frog 🐸

To handle the server-side logic of our full-stack to-do application, we will use a library called dart_frog.

dart_frog is a lightweight web framework for Dart that makes it easy to build server-side applications.

To install dart_frog, open a terminal and run the following command:

dart pub global activate dart_frog_cli

To create a new dart_frog project, open a terminal and navigate to the directory where you want to create the project. Then, run the following command:

dart_frog create backend

The command "dart_frog" creates a new project with necessary files and directories and adds the dependency "dart_frog" to the project's "pubspec.yaml" file.

Once you have created a new dart_frog project and set up the backend of your full-stack to-do application, you can add a Melos script to run the server. To do this, open the melos.yaml file in the root directory of your project and add the following content:

scripts:
  backend:dev:
    run: melos exec -c 1 --fail-fast -- "dart_frog dev"
    description: Starts the dev server for the backend
    select-package:
      flutter: false

Once these steps have been completed, you can run the backend:dev script by opening a terminal and navigating to the root directory of your project. Then, run the following command melos run backend:dev

This will start the dev server for the backend of your to-do application. You can then start building the server-side logic of your application using dart_frog.

✓ Running on http://localhost:8080 (0.1s)

If you see an output similar to the one above after running the melos run backend:dev command means that the dev server for the backend of your full-stack to-do application has been successfully started.

If you open http://localhost:8080, you should be greeted with Welcome to Dart Frog!

Stay tuned for part-2 ...