DEV Community: Dinko Marinac

Common Mobile UX Mistakes I See in Almost Every Project

Dinko Marinac — Mon, 02 Mar 2026 09:54:14 +0000

Introduction

Every time I start a new project, the one of the first things I have do is review the designs.

And almost every time, I notice the same pattern: designs that technically work on mobile, but were clearly conceived with desktop thinking. Web patterns are resized, rearranged, and stacked vertically, but the underlying assumptions remain the same.

The problem is not visual quality.

The problem is that mobile is a fundamentally different interaction model.

On mobile:

Screen real estate is limited and vertical
Scroll areas cannot collide
People are using fingers and some parts of the screen are harder to reach

Once you realize that, certain design decisions become obviously problematic. Yet they keep showing up in project after project.

Below are four recurring issues I encounter when reviewing mobile designs, and why they cause friction in real-world use.

Dropdowns

Dropdowns are one of the most common examples of a web pattern that does not translate well to mobile.

On desktop, dropdowns are efficient. They take little space, allow precise selection, and work well with a mouse. On mobile, they introduce several usability issues at once.

Large dropdowns often extend beyond the visible area, hiding options. They frequently create nested scrolling, where the dropdown scrolls independently from the page, making it easy to scroll the wrong element. When dropdowns are used for filtering, they rarely support search well. And when the keyboard appears, it often covers part of the list or any search input entirely.

All of this adds friction to what should be a simple interaction.

A more mobile-friendly alternative is a bottom sheet. Bottom sheets use the full width of the screen, avoid nested scrolling, integrate cleanly with the keyboard, and support longer lists and search naturally.

This is not a new pattern. It is simply a more appropriate one for touch-based interfaces.

Modals

Centered modals are another pattern that often carries over from web to mobile without reconsideration.

On modern phones, screens are tall and devices are commonly used with one hand. The natural resting position of the thumb is in the lower half of the screen. Centered modals place primary actions outside of that comfortable reach zone.

As a result, users frequently need to adjust their grip or use a second hand just to confirm or dismiss a modal. This might seem like a small inconvenience, but repeated many times, it adds noticeable friction to the experience.

Bottom-aligned surfaces, such as bottom sheets, align better with how people actually hold their phones. They keep primary actions within easy reach and preserve a sense of spatial continuity instead of fully interrupting the interface.

Modals are not inherently wrong, but they are often used in situations where a mobile-native pattern would be more ergonomic.

Dashboards and Webshops

Desktop dashboards are designed for overview. They allow users to scan multiple data points at once and compare information side by side.

Mobile dashboards cannot serve the same purpose in the same way.

With limited screen space and a vertical layout, trying to display multiple charts, metrics, and secondary information at once quickly becomes overwhelming. Important information gets pushed down, and users lose a clear sense of what matters most.

Effective mobile dashboards prioritize a single primary metric or insight at the top of the screen, followed by secondary information that can be explored if needed.

The same principle applies to mobile webshops. The product, its value, and the primary call to action must be immediately visible. Additional details can come later.

On mobile, users value focus, not from completeness.

Forms

Forms are one of the most common sources of frustration in mobile applications.

Many mobile forms are direct adaptations of desktop forms, with all fields displayed at once. On a phone, this results in long scrolling sessions, frequent keyboard interruptions, and users losing track of where they are in the process.

Common issues include too many visible fields, lack of logical grouping, incorrect keyboard types, and missing defaults. Each of these increases cognitive load and raises the likelihood that a user will abandon the form entirely.

Mobile-friendly forms are often segmented into smaller steps, reveal fields progressively, and make heavy use of autofill, sensible defaults, and appropriate keyboard configurations.

By reducing the perceived effort, they significantly improve completion rates.

Closing Thoughts

None of these issues are about aesthetics or personal taste.

They stem from ignoring the realities of mobile phone. Fingers are less precise than cursors. Screens are smaller and vertically constrained.

Designing for mobile is not about shrinking interfaces. It is about rethinking interactions to match how people actually use their devices.

Once you build and ship enough mobile products, these problems become hard to ignore. And once you notice them, you start seeing them everywhere.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter and LinkedIn.

Originally posted on my blog.

Going Serverless with Dart: AWS Lambda for Flutter Devs

Dinko Marinac — Mon, 04 Nov 2024 14:11:36 +0000

Introduction

Welcome to part one of my series "Going Serverless with Dart". The point of this series is to show you how to write and deploy serverless logic (also known as cloud functions) to the most popular cloud providers: AWS and GCP.

Before we start, I want to briefly explain what serverless (computing) actually means. I really like this explanation from CloudFlare:

Serverless computing is a method of providing backend services on an as-used basis. A serverless provider allows users to write and deploy code without the hassle of worrying about the underlying infrastructure. Note that despite the name serverless, physical servers are still used but developers do not need to be aware of them.

In other words, serverless computing allows you to use only the backend parts you actually need, without worrying about deployment and maintenance. You pay for the components by usage and they auto-scale, but also introduces the risk of getting a huge bill from spiked usage like a DDOS attack.

Amazon offers its serverless components through a service called AWS (Amazon Web Services). Serverless (aka cloud) functions on AWS are called Lambdas.

They are developed based on a technology called Firecracker, which is a virtualization technology that uses Linux Kernel-based Virtual Machine (KVM) to manage micro virtual machines (one for each function).

Right now, you may be thinking: "Dinko, I don't care about Firecracker, whats that got to with Dart"?

You are about to find out.

Dart Lambda Custom Runtime

Lambdas officially supports typical backend languages like Node.js, Python, Go, Java, and Ruby. If you want to use another language, you can deploying it by using a custom runtime.

In February 2020, AWS introduced a custom runtime for Dart:

You can access the runtime from pub.dev. You will notice one thing, the package has not been updated in the last 3 years (at the time of writing).

Thankfully, there is a fork of the package that provides a similar API but adapted to the null safety standards we are used to.

The runtime supports a lot of AWS services out of the box:

Application Load Balancer
Alexa
API Gateway
AppSync
Cloudwatch
Cognito
DynamoDB
Kinesis
S3
SQS

You can also register custom events.

To access all the different AWS services, you can use packages provided by Agilord. These packages are generated high-level APIs for AWS services.

With the custom runtime and all services accessible via packages, let's get to coding.

Writing your first lambda in Dart

Given all the possibilities with lambdas, I decided to show you how to write a lambda that reacts to a DynamoDB trigger. This is extremely useful for many use cases you might want to cover, especially if you are using AWS Amplify with Flutter, as it comes with DynamoDB by default.

ℹ️ You can find the full code on Github.

The event for DynamoDB update usually looks like this:

{
  "Records": [
    {
      "eventID": "c4ca4238a0b923820dcc509a6f75849b",
      "eventName": "INSERT",
      "eventVersion": "1.1",
      "eventSource": "aws:dynamodb",
      "awsRegion": "us-east-1",
      "dynamodb": {
        "Keys": {
          "id": {
            "S": "12345"
          }
        },
        "NewImage": {
          "id": {
            "S": "12345"
          },
          "name": {
            "S": "Buy groceries"
          }
        },
        "ApproximateCreationDateTime": 1428537600,
        "SequenceNumber": "4421584500000000017450439091",
        "SizeBytes": 26,
        "StreamViewType": "NEW_AND_OLD_IMAGES"
      },
      "eventSourceARN": "arn:aws:dynamodb:us-east-1:123456789012:table/ExampleTableWithStream/stream/2015-06-27T00:48:05.899"
    }
  ]
}

The data includes an array of changed events (Records) with each record containing:

eventID: Unique identifier for the event
eventName: Type of operation (INSERT, MODIFY, DELETE)
dynamodb: Contains the actual data changes
- NewImage: The new state of the item
- Keys: Primary key information

The function we will write will modify the name of the item when its created (inserted) in a DynamoDB table.

The first thing we must do is define a handler function that will handle our events. The FunctionHandler requires a function name and a callback with context which contains runtime information (like region, credentials, etc.) and raw event data.

The name you choose will be the same name you use for the deployment and management of the function later.

FunctionHandler get handleTodoCreation {
  return FunctionHandler(
    name: 'on-create-todo',
    action: (context, event) async {
      final dynamoDb = context.dynamoDb;

      try {
        final records = event['Records'] as List<dynamic>;

        await Future.forEach<dynamic>(records, (record) async {
          if (record['eventName'] == 'INSERT') {
            final newImage = record['dynamodb']['NewImage'];
            final todoId = newImage['id']['S'];
            final currentName = newImage['name']['S'];

            final modifiedName = 'Modified: $currentName';

            await dynamoDb.updateItem(
              tableName: 'todos',
              attributeUpdates: {
                'name': AttributeValueUpdate(
                  action: AttributeAction.put,
                  value: AttributeValue(s: modifiedName),
                ),
              },
              key: Key(hashKeyElement: AttributeValue(s: todoId)),
            );
          }
        });
      } catch (e) {
        print('Error processing DynamoDB stream event: $e');
      }
      return InvocationResult(requestId: context.requestId);
    },
  );
}

The function iterates over the events and checks for INSERT events.

Then it extracts the the todo ID and current name. The name is modified by adding a "Modified: " prefix and then updated in the DynamoDB.

DynamoDB client is provided the aws_dynamodb_api package by Agilord. We can create the client using the credentials available from RuntimeContext. To make this easier to reuse, we can create an extension.

extension ContextExtensions on RuntimeContext {
  DynamoDB get dynamoDb => DynamoDB(
        region: region,
        credentials: AwsClientCredentials(
          accessKey: accessKey,
          secretKey: secretAccessKey,
          sessionToken: sessionToken,
        ),
      );
}

Lastly, we must register the function handler using the invokeAwsLambdaRuntime method.

Future<void> main(List<String> args) async {
  await invokeAwsLambdaRuntime([handleTodoCreation]);
}

We can use the AWS Console to test the function, but first, we must deploy it.

Deployment

There are many ways to deploy an AWS Lambda, but the two main ones are uploading a .zip file or Docker image or using Infrastructure-as-Code solutions like Serverless Framework, AWS CDK, or Terraform.

I'll show you how to deploy using a .zip file uploaded through the AWS Console since it also teaches you a little bit about which permissions you need to grant.

ℹ️ If you are curious about IaC deployment, I would recommend using AWS CDK. This article explains really well how to use it for deploying a DynamoDB triggered Lambda.

⚠️ When deploying Lambdas in production, make sure you follow the best security practices to avoid your data being compromised or leaving your endpoint vulnerable to attacks like DDOS. Common techniques include securing the Lambda with AWS API Gateway and giving it minimal permissions needed.

Before starting the deployment, make sure you have a DynamoDB table named todos. If you don't have have, go to DynamoDB in the AWS Console and create a new table named todos with a partition key Id. All other values can be default ones.

Enable event streaming in DynamoDB

First, we must enable DynamoDB Streams:

Go to your todos table in the DynamoDB console
Click on "Exports and streams" tab
Under "DynamoDB stream details", click "Turn on"
Select "New and old images" as the view type (this gives you both before/after states)
Click "Turn on stream"

Create a .zip file

Next, we must create a zip file.

If you are using Mac or Windows, you must use Docker for this. If you are using Linux, you can just create a zip directly instead.

Make sure you have Docker installed. The easiest way is to install Docker Desktop.

I've prepared a runnable bash script which will take care of this step. Your project must also contain a Dockerfile which instructs docker how to build an image for AWS.

After running the script, you should have an output folder with boostrap and function.zip files inside. This function.zip is what you will upload to AWS.

Create a lambda and upload .zip

Go to Lambda Console:

* Open AWS Console

* Search for "*Lambda*"

* Click "*Create function*"

Configure basic settings:

* Select "*Author from scratch*"

* Use the function name you specified in the handler (`on-create-todo` in the example)

* For Runtime, select "*Amazon Linux 2*"

* Architecture: select *x86\_64* or *arm64*, mine was arm64

* Click "*Create function*"

Upload your zip:

* In the Code tab of your function

* Click "*Upload from*" dropdown

* Select "*.zip file*"

* Upload your Dart zip file

* Click "*Save*"

Configure the handler:

* In the Runtime settings section

* Click "*Edit*"

* Set handler to `on-create-todo`

* Click "*Save*"

Create a Dynamo DB trigger

In the Configuration tab, click "Add Trigger".

Then:

Select "DynamoDB" as the trigger source
Find the todos table and click the long link
Make sure "Activate Trigger" is checked ☑️

Configure Environment Variables

In the Configuration tab, find the "Environment variables" sub-tab and click "Edit".

Click "Add environment variable"
The key should be: AWS_EXECUTION_ENV
The value should be: AWS_Lambda_provided.al2
Click "Save"

This is needed for the RuntimeContext of the lambda.

Grant permissions

Lastly, we want to grant permissions.

Click on the Configuration tab of your Lambda
Click on "Permissions"
Click on the role name listed under "Execution role"
Add the required policy:

* In the IAM role page, click "*Add permissions*" → "*Create inline policy*"

* Choose **JSON** and paste this policy:

    ```json
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "dynamodb:GetRecords",
            "dynamodb:GetShardIterator",
            "dynamodb:DescribeStream",
            "dynamodb:ListStreams",
            "dynamodb:UpdateItem"
          ],
          "Resource": [
            "arn:aws:dynamodb:<region>:<account-id>:table/todos/stream/*",
            "arn:aws:dynamodb:<region>:<account-id>:table/todos"
          ]
        }
      ]
    }
    ```

    You can find the region and the account id in the Lambda function ARN:

    ![How to find the region and account id for granting permissions for DynamoDB](https://cdn.hashnode.com/res/hashnode/image/upload/v1730719831761/cb2b6b43-9678-4d1a-9e9f-79a1100e1fd9.png)

Click "Next"
Give it a name (e.g., TodosStreamReadAccess)
Click "Create policy"

Testing the lambda

Firstly, you can test the lambda using the "Test" tab of of your Lambda and by providing the JSON specified at the beginning.

If something crashes or doesn't work, the AWS console error logs should be helpful. In case they are not, modify the lambda to output more errors and redeploy until you can solve the problem.

The real test is done by going the the DynamoDB.

Click "View all tables"
Click on the todos table
Click "Explore table items"
Click "Create item"
Create an item similar to this:
Click "Create Item"
Find the new items
Refresh the page
The item with the same id (123456) should now have a Modified: prefix in the name

Congratulations 🎉, you have successfully written and deployed your first Dart Lambda on AWS!

Conclusion

Well, there you have it! You've just built and deployed your first Dart function on AWS Lambda. While it might seem like a lot of setup at first, you now have the power to write your cloud functions in the same language as your Flutter apps. Pretty neat, right?

Sure, using Dart for Lambda functions isn't as straightforward as using Python or Node.js, and you'll have to deal with a custom runtime. But hey, being able to share code between your app and cloud functions might just make it worth the extra effort.

If you are using AWS Amplify with your Flutter app, writing Lambdas using Dart now makes you a Full-stack Flutter developer. You have the ability to write serverless logic and your cross-platform app using Flutter and Dart.

In the next part of this series, we'll take what we've learned and see how it compares to building serverless functions on the Google Cloud Platform.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter or LinkedIn.

Flutter vs Native: Why Flutter Wins for TV App Development

Dinko Marinac — Mon, 16 Sep 2024 09:44:04 +0000

Introduction

Recently, a client requested a prototype for an Android TV Launcher app. Given the requirements that they might want to expand into mobile, I decided to give Flutter a chance at developing a TV app.

I wrote my opinion on LinkedIn and it caught quite a bit of attention:

My background in TV app development includes three Android TV apps: two enterprise-level applications built with XMLs (one for a big telecom provider and a white-labeled TV app for hotels called Smartell) and a smaller TV app developed using Jetpack Compose.

In this article, I’ll try to share my experience and opinion on why Flutter is better for TV development than native Android, regardless of whether you are using Jetpack Compose or XML.

Lack of technical debt

One of the most significant advantages of Flutter over native Android development is the lack of technical debt.

Whether you're using Jetpack Compose or XML layouts, the technical debt in native Android development is glaringly apparent and destroys the developer experience. Google learned from its mistakes and designed Flutter without the same problems.

Here are some examples of the common problems you have to deal with as an Android developer:

Back button handling
Permission handling
Compose:
- Compose navigation, especially passing parameters
- Preview doesn’t work with ViewModels and requires mocking data
- Passing click handlers and properties to deeply nested Composables
- Performance impact
Managing multiple Activities
Services are a mess
Notifications are a mess
Random Gradle errors and Kotlin version misalignment

This is not to say Flutter doesn’t inherit some of these problems, it does, but the packages provided by the community and the design of the technology makes this way easier.

This alone speeds up the developer's productivity by a very large amount.

Cross-Platform Potential

When you are choosing a tech stack, it’s important to take into consideration how you are going to scale. Generally speaking, you can scale horizontally and vertically.

On the backend, vertically means a more powerful machine, and horizontally means more instances.

In mobile and TV, vertically means more users on the single platform, and horizontally means more users on the adjacent platforms. Moreover, it’s often the case that you must ensure a multi-platform experience from the start, and this is where Flutter shines.

You can expand your TV app to mobile, desktop, and web, but most importantly, to other TV platforms.

Nowadays, you can build a TV with Flutter for the following platforms (besides Android TV):

Apple TV with a custom Flutter engine by Sasha Denisov
Samsung Tizen with officialy supported Flutter-Tizen
LG webOS with the official support

The only unsupported platform remains Roku, but I think that will be easily solvable in the future.

Backend-as-a-Service support

If you are a startup, moving fast is of utmost importance, so creating a backend from scratch is rarely an option.

Flutter plays well with modern backend solutions like Firebase, Supabase, AWS Amplify, Appwrite, and PocketBase. This gives you a variety of options to choose from whether you are an indie developer, startup, established company, agency, or enterprise.

In contrast, official support for Android is available only for Firebase, AWS Amplify, and Appwrite. Supabase has community made Kotlin SDK.

A hidden problem here is that Firebase and Amplify are Java libraries with Kotlin support, which means that they don’t give the full power of Kotlin as a language and you are left writing your own workaround to fit your architecture or use community packages, which might get abandoned.

Conclusion

Based on my extensive experience with both native Android TV app development and Flutter, I can confidently say that Flutter is the superior choice for most TV app projects. The increased development speed, reduced technical debt, and cross-platform capabilities make it an excellent investment for businesses looking to create high-quality, maintainable TV applications.

While native development still has its place, especially for highly platform-specific features, Flutter's advantages in terms of developer productivity and code maintainability cannot be overstated. As the Flutter ecosystem continues to grow and mature, it's poised to become the go-to solution for TV app development across all major platforms.

If you're starting a new TV app project or considering a rewrite of an existing application, I strongly recommend giving Flutter a serious look. The benefits in terms of development speed, code quality, and future-proofing your application are well worth the initial learning curve.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter or LinkedIn.

Adding a "Done" Button to iOS Numpad in Flutter

Dinko Marinac — Mon, 19 Aug 2024 07:32:00 +0000

This week I had to add an “done” action to a numbers only text field. Seems easy.

textInputAction: TextInputAction.done

Done.

Couple of hours later I got a message: “Doesn’t work on iOS”.

I went on Google to search for a solutions. Stack Overflow suggested to change my keyboard type and add an a TextInputFormatter :

textInputAction: TextInputAction.done,
keyboardType: TextInputType.numberWithOptions(signed: true, decimal: true)
inputFormatters: <TextInputFormatter>[
  FilteringTextInputFormatter.digitsOnly,
],

This solution works, but now, the user gets a regular keyboard and can enter anything, which is not the behaviour I am looking for.

I should be able to have only numbers and decimal separators (. , ,) on the keyboard and a done button to finish typing.

After some research, I found the problem → iOS doesn’t support this behaviour. Even native developers have their workarounds.

Thankfully, Flutter has a plugin that can help: KeyboardActions.

You can use this to add any actions above the keyboard. A great example are Slack and Notion which add buttons for styling about the keyboard in their mobile apps.

Here’s how it works.

First you need to define all the actions you want to add to this keyboard.

final FocusNode _focusNode = FocusNode();

KeyboardActionsConfig get _keyboardActionsConfig {
    return KeyboardActionsConfig(
      keyboardActionsPlatform: KeyboardActionsPlatform.ALL,
      keyboardBarColor: const Color(0xFFCAD1D9), //Apple keyboard color
      actions: [
        KeyboardActionsItem(
          focusNode: _focusNode,
          toolbarButtons: [
            (node) {
              return GestureDetector(
                onTap: () => node.unfocus(),
                child: Container(
                  padding: const EdgeInsets.all(12.0),
                  child: Text(
                    S.of(context).done,
                    style: const TextStyle(
                      color: Color(0xFF0978ED), //Done button color
                      fontWeight: FontWeight.bold,
                    ), 
                  ),
                ),
              );
            }
          ],
        ),
      ],
    );
  }

All “Done” button does is unfocusing of the TextField we are currently using, which is where the onTap method implementation comes from. I’m using Apple’s default coloring here, but you could you anything you want.

After that you need to wrap your TextField with the KeyboardActions Widget.

KeyboardActions(
  config: _keyboardActionsConfig,
  disableScroll: true,
  child: TextFormField(
    focusNode: _focusNode, // <-- don't forget to add the focus node
    controller: widget.controller,
    onChanged: (value) {
        final input = double.tryParse(value) ?? 0
        //TODO: do something with the input
    }
    labelText: widget.labelText,
    keyboardType:
        const TextInputType.numberWithOptions(decimal: true),
    textInputAction: TextInputAction.done,
  ),
);

Make sure not to forget adding the focus node to the field, otherwise this will not work.

The end result looks like this:

That’s it. You made your product manager happy.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter and LinkedIn.

Until next time, happy coding!

Integrating Multiple Analytics Services in Flutter: The Modular Way

Dinko Marinac — Mon, 29 Jul 2024 15:01:39 +0000

Introduction

In the world of mobile app development, analytics play a crucial role in understanding user behavior and making data-driven decisions.

However, integrating analytics into your Flutter app can often lead to tightly coupled code and difficulty in switching between analytics providers.

Migrating analytics is not like turning a switch and it takes time for data to settle in the new platforms, while at the same time, the data is still needed to make decisions.

To ease the migration and management of 2 (and possibly more platforms) I’ve used the following modular approach which I will show here with Mixpanel and PostHog as examples.

Ready to integrate some analytics?

Full code can be found on GitHub.

Interface and event

To use multiple analytics services, we need to create a common interface so we can talk to each of the platforms in a unified way.

abstract class AnalyticsService {
  void track(AnalyticsEvent event);
  void identify(String userId);
  void reset();
}

This interface defines the core functionality we expect from any analytics service: tracking, identifying with the user upon login, and resetting upon logout.

Next, we need to define a generic event class:

abstract class AnalyticsEvent {
  String get eventName;
  Map<String, dynamic> get properties;
}

Let’s integrate this with our services.

Concrete implementation

Before you start the implementation, make sure you follow the official guides on how to integrate Mixpanel and Posthog.

Concrete implementations of these services are just proxy calls to the underlying platform.

class MixpanelAnalyticsService implements AnalyticsService {
  final Mixpanel _mixpanel;

  MixpanelAnalyticsService(this._mixpanel);

  @override
  void track(AnalyticsEvent event) {
    _mixpanel.track(event.eventName, properties: event.properties);
  }

  @override
  void identify(String userId) {
    _mixpanel.identify(userId);
  }

  @override
  void reset() {
    _mixpanel.reset();
  }
}

class PostHogAnalyticsService implements AnalyticsService {
  final Posthog _posthog;

  PostHogAnalyticsService(this._posthog);

  @override
  void track(AnalyticsEvent event) {
    _posthog.capture(
      eventName: event.eventName,
      properties: event.properties.map((key, value) => MapEntry(key, value as Object)),
    );
  }

  @override
  void identify(String userId) {
    _posthog.identify(userId: userId);
  }

  @override
  void reset() {
    _posthog.reset();
  }
}

To be able to swap out analytics on the fly or use multiple services at once, we need a service that will encapsulate all the services. Let’s call it CompoundAnalyticsService.

class CompoundAnalyticsService implements AnalyticsService {
  final List<AnalyticsService> _services;

  CompoundAnalyticsService(this._services);

  @override
  void track(AnalyticsEvent event) {
    for (var service in _services) {
      service.track(event);
    }
  }

  @override
  void identify(String userId) {
    for (var service in _services) {
      service.identify(userId);
    }
  }

  @override
  void reset() {
    for (var service in _services) {
      service.reset();
    }
  }
}

Additionally, if you are using a state management solution and feature flags, you can turn on and off particular analytics on the fly. Here’s an example with Riverpod:

final _mixpanelAnalyticsServiceProvider = Provider<AnalyticsService>((ref) {
  final mixpanel = ref.watch(mixpanelProvider);
  return MixpanelAnalyticsService(mixpanel);
});

final _posthogAnalyticsServiceProvider = Provider<AnalyticsService>((ref) {
  final posthog = ref.watch(posthogProvider);
  return PostHogAnalyticsService(posthog);
});

final analyticsServiceProvider = Provider<AnalyticsService>((ref) {
  final flags = ref.watch(featureFlagsProvider);
  return CompoundAnalyticsService([
    if (flags.enableMixpanel) ref.watch(_mixpanelAnalyticsServiceProvider),
    if (flags.enablePosthog) ref.watch(_posthogAnalyticsServiceProvider),
  ]);
});

Usage

To start using all of this we need an event. Let’s say we want to share something in the app: a photo, video, or another app.

enum ShareEventItem { photo, video, app }

class ShareEvent implements AnalyticsEvent {
  final ShareEventItem item;

  ShareEvent({required this.item});

  @override
  String get eventName => 'Share';

  @override
  Map<String, dynamic> get properties => {
        'item': item.toString().split('.').last,
      };
}

Now, we can use our analytics service to track that even to any number of platforms like this:

class MyHomePage extends StatelessWidget {
  final AnalyticsService analyticsService;

  const MyHomePage({Key? key, required this.analyticsService}) : super(key: key);

  void _onShareItem(ShareEventItem item) {
    analyticsService.track(ShareEvent(item: item));
// Perform actual share action
  }

// Widget build method...
}

The benefits of this approach are:

Modularity: Easy to add or remove analytics providers without changing app logic
Type Safety: Events are defined as classes, providing compile-time checks
Separation of Concerns: Analytics logic is separate from business logic
Consistency: Ensures consistent event tracking across the app
Testability: Easy to mock analytics service for unit testing

Conclusion

By implementing this modular approach to analytics in your Flutter app, you can enjoy greater flexibility, maintainability, and consistency in your analytics implementation. It allows you to easily switch between or combine different analytics providers, ensuring that your app's analytics strategy can evolve with your needs.

Remember, the key to successful analytics is not just in the implementation, but in defining meaningful events that provide actionable insights for your app's growth and improvement.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter and LinkedIn.

Until next time, happy coding!

Flutter Design Systems: Exploring Modern Alternatives to Material Design

Dinko Marinac — Mon, 15 Jul 2024 12:55:00 +0000

Introduction

Design systems are essential frameworks that ensure consistency and coherence in application development, providing a unified language for designers and developers. They encompass guidelines, components, and tools that streamline the design and implementation process.

In Flutter, Material Design is the default design system, deeply integrated to provide a seamless development experience. However, while Material Design offers a robust set of components and styling options, it can sometimes be restrictive or verbose, making customization and extension challenging.

This article explores alternative design systems for Flutter that address these limitations, offering more flexibility, ease of use, and unique features that cater to diverse project needs.

Mix

Mix is an expressive styling system for Flutter which takes inspiration from Tailwind CSS. The idea is to reduce the verbosity of Flutter's default styling system by bundling all the styling into a single variable and applying it to the view.

Other mobile declarative frameworks like Jetpack Compose and SwiftUI take a very similar approach*. C*ommon things like paddings, margins, background colors, view shape, and clickability are all applied through view modifiers.

Mix is designed to be utility-first and provides simple and low-level utilities for you to use it directly or create your own design system based on it.

How styling with Mix look like?

In Flutter, you might style a Container with elevation and color like this:

Container(
  height: 100,
  width: 100,
  margin: EdgeInsets.symmetric(
    vertical: 10,
    horizontal: 20,
  ),
  decoration: BoxDecoration(
    color: Colors.blue,
    borderRadius: BorderRadius.circular(10),
    border: Border.all(
      color: Colors.black,
      width: 1,
      style: BorderStyle.solid,
    ),
  ),
  child: Text('Container'),
);

This is how it would look like with Mix:

final style = Style(
  $box.height(100),
  $box.width(100),
  $box.margin(10, 20),
  $box.color.blue(),
  $box.borderRadius(10),
  $box.border(
    color: Colors.black,
    width: 1,
    style: BorderStyle.solid,
  ),
);

Box(
  style: style,
  child: Text('Hello Mix'),
);

The biggest difference to the Flutter styling system is that Mix uses a Style class which encompasses all available styling for that specific class. Styles can be extended, modified, and composed.

final baseStyle = Style(
  $box.height(100),
  $box.width(100),
  $box.color.purple(),
  $box.borderRadius(10),
);

// extend base style with new properties
final newStyle = baseStyle.add(
  $box.border.width(2),
  $box.border.color.black(),
);

// modify the color
final newStyleColored = baseStyle.add(
  $box.color.blue(),
);

// combine and merge styles
final borderStyle = Style(
  $box.border.width(2),
  $box.border.color.black(),
);

final baseBorderedStyleCombined = Style.combine([
  baseStyle,
  borderStyle,
]);

final baseBorderedStyleMerged = baseStyle.merge(borderStyle);

Mix goes a step further in developer experience with a system to create widget variants and widget modifiers.

Remember all the times that you wanted to have one widget that has the exact same functionality, but just different enough styling that now it needs a completely different Widget implementation? Mix solves that very elegantly because each variant can have its own Style class instead of creating different widgets because the order of widgets is different.

The last feature I want to highlight is the ability to create widget modifiers. Instead of wrapping your widgets with another widget just to add padding or clickability, you can create a modifier that will do the same thing under the hood for you. This gets rid of the mess that deeply nested widgets create.

Mix comes with a predefined set of very common widget modifiers like scale, opacity, aspect ratio, clip, visibility, and others that turn your code from this:

Visibility(
  visible: false,
  child: Box(
    child: const Text('Invisible box'),
  ),
);

to this:

final style = Style(
  $with.visibility(false),
);

Box(
  style: style,
  child: const Text('Invisible box'),
);

Mix is the most promising and welcome change to the world of Flutter styling in years. The author has also mentioned that there is an official design system called Remix UI that’s in the works.

Shadcn

Shadcn is the Flutter port of the super popular UI toolkit shadcn/ui.

The idea behind the original Shadcn is that it’s not just a component library you import and use and you have a hard time building upon it because of the provided APIs. It’s a set of reusable components you can copy and paste into your app to create your design system and your own component library.

The Flutter port provides you with a customizable component library which you can build on top of, but because it’s open source, nothing stops you from copy-pasting the code into your project.

To keep compatibility with the original Flutter App API, Shadcn offers 3 different app constructors:

ShadApp - used to run pure Shadcn styling system
ShadApp.material - used to run Shadcn along Material
ShadApp.cupertino - used to run Shadcn along Cupertino

Having all 3 of them enables you to migrate gradually over the course of months or just use the components you like.

Theme data is inspired by the Material, enabling you to use the existing knowledge to style the app. The difference comes from the ShadDecoration, which is responsible for the styling of the most components library provides.

Components range from simple ones like buttons and switches to more complicated ones like resizable panels, tables, and sheets (bottom, top, side).

The documentation comes with a preview and the code for all the components, which makes it easy for anybody to pick up the library and start building.

Moon & Modular UI

Moon and Modular UI are UI kits created to streamline development efforts by providing frequently used components. They are based on their respective design system, but they are not as powerful as the ones specified before.

Moon

Moon is a design system created by the YoloGroup. They use it for all their product and the design system spans multiple programming languages.

The Flutter package is actually a UI kit that comes with prebuilt components ready to kickstart the process of building the UI. It consists of primitive components like Alert, Avatar, Accordion, Button, Chip, and composite components like search with a list of multi-select combo box.

The theming is done through a ThemeExtension, making it compatible with the tight coupling Flutter has with Material.

final lightTokens = MoonTokens.light.copyWith(
  colors: MoonColors.light.copyWith(
    piccolo: Colors.blue,
    textPrimary: Colors.amber,
  ),
  typography: MoonTypography.typography.copyWith(
    heading: MoonTypography.typography.heading.apply(fontFamily: "DMSans"),
  ),
);

final lightTheme = ThemeData.light().copyWith(
    extensions: <ThemeExtension<dynamic>>[MoonTheme(tokens: lightTokens)],
  );

Moon’s documentation also comes with a preview of all of the widgets included and enables you to see and customize the components.

Modular UI

Modular UI is a set of pre-built Flutter widgets Inspired by material-tailwind and Shadcn.

The kit consists of commonly used components like alerts, buttons, tab bars, switches, and sliders, but also comes with more complex components like carousel, sign-in card, and sign-up card which enable you to create very common UI and flow elements very quickly.

Conclusion

Material Design remains a powerful and integral part of Flutter, but alternative design systems like Mix, Shadcn, Moon, and Modular UI offer compelling solutions for those who seek more flexibility and simplicity in their projects.

Mix, with its Tailwind CSS-inspired utility-first approach, significantly reduces the verbosity of Flutter's default styling. Shadcn provides a versatile component library that integrates seamlessly with Material or Cupertino, allowing for gradual migration and customization. Moon and Modular UI streamline development with pre-built components based on their respective design systems, catering to primitive and complex UI needs.

If you still prefer to work within the Material Design framework but seek enhanced customization, I would recommend FlexColorScheme, a package that simplifies the process of implementing complex color schemes for Material Design in Flutter, offering more flexibility and extensibility.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter and LinkedIn.

Until next time, happy coding!

Enhancing Your Flutter Project with Typesafe Packages

Dinko Marinac — Mon, 03 Jun 2024 12:37:27 +0000

Introduction

Flutter's popularity has surged thanks to its ability to build beautiful and performant cross-platform applications. Large projects with many teams and developers often face a lot errors on a smaller or a larger scale due to the size of the project.

One of those problems is type safety.

What is typesafe code?

Remember all those times you added a new asset and used it in a widget. You run the app, but then it crashes because Flutter couldn’t find the asset? You probably forgot to add it to the pubspec.yaml.

I’ll give you another example.

You want to call methods from native code. Flutter provides Method Channels for this. You have to make sure that you call the correct method, with the correct parameters, otherwise, you’ll get an error like this:

Unhandled Exception: MissingPluginException(No implementation found for method getBatteryLevel on channel samples.flutter.dev/battery)

This is what typesafe code prevents from happening. Typesafe means that variables are statically checked for appropriate assignment at compile time.

As projects grow, ensuring type safety becomes crucial to maintaining code quality and preventing runtime errors.

This blog will explore how to make your Flutter project more typesafe using various packages:

Typesafe Method Channels: pigeon
Typesafe REST APIs: chopper and retrofit
Typesafe GraphQL: ferry
Typesafe Routing: go_router_builder
Typesafe Assets: flutter_gen
Typesafe Environment Variables: envied

Let's dive into each of these and see how they can take your Flutter project from error-prone to error-free.

Typesafe Method Channels with Pigeon

Method channels in Flutter facilitate communication between the Dart and native sides of an app (iOS and Android). Traditionally, method channels use dynamic typing, which can lead to runtime errors if the method names or argument types do not match.

pigeon eliminates these issues by generating type-safe code for method channels. It can also generate code for accessing a Dart method from native code, which can come in handy.

Non-Typesafe Code

Typically you would write something like this in your Flutter project:

import 'package:flutter/services.dart';

class FlutterBridge {
  static const MethodChannel _channel = MethodChannel('com.example.app/channel');

  Future<String?> getMessage() async {
    final String? message = await _channel.invokeMethod('getMessage');
    return message;
  }

  Future<void> sendMessage(String message) async {
    await _channel.invokeMethod('sendMessage', {'text': message});
  }
}

And then write appropriate platform implementations:

For Android (MainActivity.kt ):

import android.os.Bundle
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodChannel

class MainActivity: FlutterActivity() {
    private val CHANNEL = "com.example.app/channel"

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)
        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, CHANNEL).setMethodCallHandler {
            call, result ->
            when (call.method) {
                "getMessage" -> {
                    val message = getMessage()
                    result.success(message)
                }
                "sendMessage" -> {
                    val text = call.argument<String>("text")
                    sendMessage(text)
                    result.success(null)
                }
                else -> {
                    result.notImplemented()
                }
            }
        }
    }

    private fun getMessage(): String {
        return "Hello from Android!"
    }

    private fun sendMessage(message: String?) {
        // Handle the message
    }
}

For iOS (AppDelegate.swift):

import UIKit
import Flutter

@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    GeneratedPluginRegistrant.register(with: self)

    let controller : FlutterViewController = window?.rootViewController as! FlutterViewController
    let channel = FlutterMethodChannel(name: "com.example.app/channel",
                                      binaryMessenger: controller.binaryMessenger)

    channel.setMethodCallHandler({
      (call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in
      if call.method == "getMessage" {
        result(self.getMessage())
      } else if call.method == "sendMessage" {
        if let args = call.arguments as? [String: Any],
           let text = args["text"] as? String {
          self.sendMessage(message: text)
        }
        result(nil)
      } else {
        result(FlutterMethodNotImplemented)
      }
    })

    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

  private func getMessage() -> String {
    return "Hello from iOS!"
  }

  private func sendMessage(message: String) {
    // Handle the message
  }
}

Typesafe Code with Pigeon

First, add pigeon to your dev_dependencies in pubspec.yaml:

dev_dependencies:
  pigeon: ^19.0.1

Create a Dart file (e.g., pigeons.dart) to define the interface:

dartCopy code
import 'package:pigeon/pigeon.dart';

class Message {
  String? text;
}

@HostApi()
abstract class Api {
  Message getMessage();
  void sendMessage(Message message);
}

Run the Pigeon tool to generate the necessary code:

flutter pub run pigeon --input pigeons.dart

This generates platform-specific code ensuring that method calls are type-safe, reducing the risk of mismatches and errors.

Typesafe GraphQL with Ferry

If you are using GraphQL, ferry provides a fully type-safe client by leveraging code generation. This ensures that queries, mutations, and subscriptions conform to the GraphQL schema, catching errors at compile time rather than at runtime. It also comes with a side package ferry_hive_store if you want to have offline persistence using Hive.

Non-Typesafe Code

import 'package:graphql_flutter/graphql_flutter.dart';

class GraphQLService {
  final GraphQLClient _client;

  GraphQLService(this._client);

  Future<void> fetchData() async {
    const String query = '''
      query GetItems {
        items {
          id
          name
        }
      }
    ''';

    final QueryResult result = await _client.query(QueryOptions(document: gql(query)));
    if (result.hasException) {
      print(result.exception.toString());
      return;
    }

    final items = result.data?['items'];
    print(items);
  }
}

Typesafe Code with Ferry

Add ferry and its code generation dependencies:

dependencies:
  ferry: ^0.16.0+1
  gql_http_link: ^1.0.1+1

dev_dependencies:
  ferry_generator: ^0.10.0
  build_runner: ^2.4.10

Move your GraphQL query into a .graphql file:

query GetItems {
        items {
          id
          name
        }
      }

Generate the necessary types by running:

flutter pub run build_runner build

Use your queries in a typesafe manner:

import 'package:ferry/ferry.dart';
import 'package:ferry_hive_store/ferry_hive_store.dart';
import 'package:ferry_http/ferry_http.dart';

final query = GFetchUserReq((b) => b..vars.id = 1);

final client = FerryClient(
  link: HttpLink('https://api.example.com/graphql'),
  cache: HiveStore(),
);

final response = await client.request(query).first;

if (response.hasErrors) {
  // Handle errors
} else {
  final user = response.data!.user;
  print('User: ${user.name}, Email: ${user.email}');
}

Type-Safe REST API with Retrofit and Chopper

Both Retrofit and Chopper and type safe REST API generators, but they cover different libraries. Chopper is based on http package, while Retrofit is based on dio package. Both are inspired by Retrofit for Android.

Non-Type-Safe Code

Directly using the http and dio requires manual handling of JSON parsing and lacks compile-time verification of API definitions, including path and query parameters.

1. HTTP

import 'dart:convert';
import 'package:http/http.dart' as http;

Future<MyModel> fetchPost(int id) async {
  final response = await http.get(Uri.parse('https://api.example.com/posts/$id'));
  if (response.statusCode == 200) {
    return MyModel.fromJson(jsonDecode(response.body));
  } else {
    throw Exception('Failed to load post');
  }
}

2. dio

dartCopy code
import 'package:dio/dio.dart';

Future<MyModel> fetchPost(int id) async {
  try {
    final response = await Dio().get('https://api.example.com/posts/$id');
    return MyModel.fromJson(response.data);
  } catch (e) {
    throw Exception('Failed to load post');
  }
}

Typesafe Code with Chopper and Retrofit

Both Chopper and Retrofit use build_runner to generate the underlying network logic by wrapping around http and dio. By using annotations you can focus on defining API contracts and business logic without sacrificing type safety.

Chopper

import 'package:chopper/chopper.dart';

part 'api_service.chopper.dart';

@ChopperApi(baseUrl: '/posts')
abstract class ApiService extends ChopperService {
  @Get(path: '/{id}')
  Future<Response<MyModel>> getPostById(@Path() int id);
}

2. Retrofit

import 'package:retrofit/retrofit.dart';

part 'api_service.g.dart';

@RestApi(baseUrl: "https://api.example.com")
abstract class ApiService {
  factory ApiService(Dio dio, {String baseUrl}) = _ApiService;

  @GET("/posts/{id}")
  Future<MyModel> getPostById(@Path("id") int id);
}

Now you can call your APIs like any other method in the app.

Typesafe Routing with GoRouterBuilder

Routing is a critical aspect of any Flutter app. Most used navigator packages are go_router. auto_route. AutoRoute provides typesafe and generated routes out of the box, while GoRouter relies on go_router_builder package.

Non-Typesafe Code

import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';

final GoRouter _router = GoRouter(
  routes: <GoRoute>[
    GoRoute(
      path: '/',
      builder: (BuildContext context, GoRouterState state) => HomeScreen(),
    ),
    GoRoute(
      path: '/details',
      builder: (BuildContext context, GoRouterState state) {
        final String id = state.queryParams['id'] ?? '';
        return DetailsScreen(id: id);
      },
    ),
  ],
);

Typesafe code with GoRouterBuilder

go_router_builder integrates with the go_router package to provide type-safe routes.

Add dependencies:

dependencies:
  go_router: ^14.1.4

dev_dependencies:
  go_router_builder: ^2.7.0

Define your routes in a Dart file:

import 'package:go_router/go_router.dart';

part 'app_routes.g.dart';

@TypedGoRoute<HomeRoute>(path: '/')
class HomeRoute {}

@TypedGoRoute<DetailsRoute>(path: '/details')
class DetailsRoute {
  final String id;

  DetailsRoute({required this.id});
}

Run the generator:

flutter pub run build_runner build

This will generate all the routes for you. The code generator combines all top-level routes into a single list called $appRoutes which you need to use to initialize the GoRouter instance:

final _router = GoRouter(routes: $appRoutes);

You can now navigate and pass parameters without worrying about something going wrong:

void _tap() => DetailsRoute(id: 'p1').go(context);

Typesafe Assets with FlutterGen

Managing assets in Flutter can become cumbersome as your project scales. flutter_gen helps manage this by generating type-safe code for your assets. The package also provides utils for Lottie, Rive, and SVG files.

Always configure your assets in pubspec.yaml:

flutter:
  assets:
    - assets/images/

Non-Typesafe Code

Image.asset('assets/images/logo.png')

Typesafe Code with FlutterGen

Add flutter_gen:

dev_dependencies:
  flutter_gen: ^5.5.0+1

Run the generator:

flutter pub run build_runner build

Access your assets safely:

import 'package:my_app/gen/assets.gen.dart';

Image.asset(Assets.images.logo.path);

Typesafe Environment Variables with Envied

Managing environment variables securely and type-safely can be challenging. envied makes it easy. Envied can also obfuscate your API keys to make them more secure, but beware, it’s just a xor of two strings and anybody who wants to steal your API keys will steal them.

Adding envied:

dependencies:
  envied: ^0.5.4+1

dev_dependencies:
  build_runner: ^2.4.10

Create an .env file and a Dart class for the environment variables:

API_KEY=your_api_key

import 'package:envied/envied.dart';

part 'env.g.dart';

@Envied(path: '.env')
abstract class Env {
  @EnviedField(varName: 'API_KEY')
  static const String apiKey = _Env.apiKey;
}

Run the generator:

flutter pub run build_runner build

Access your environment variables safely:

final apiKey = Env.apiKey;

Conclusion

By integrating these packages into your Flutter project, you can significantly enhance type safety, making your code more robust and maintainable. Leveraging pigeon for method channels, ferry for GraphQL,chopperand retrofit for REST APIs, go_router_builder for routing, flutter_gen for assets, and envied for environment variables, you can catch errors at compile time, ensuring a more reliable and error-free codebase.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter or LinkedIn.

Until next time, happy coding!

Reposted from my blog.

Styling your Dart Jaspr website with Tailwind CSS and DaisyUI

Dinko Marinac — Mon, 27 May 2024 10:33:46 +0000

Introduction

If you are a Flutter developer like me, you know that one of the main pain points for Flutter web is SEO. The solution to that is Jaspr, a Dart web framework that looks and feels like Flutter but renders normal HTML/CSS like React.

The key difference with Flutter lies in the usage of CSS. Mobile developers are not very used to this type of styling. Tailwind CSS has emerged as a leader in the CSS libraries space, offering a pragmatic approach to styling websites without sacrificing flexibility or design freedom.

However, this comes with a steep learning curve.

Luckily, we have DaisyUI, a component library built on top of Tailwind CSS, providing ready-made components and a variety of themes. It significantly simplifies the process of creating beautiful UI elements.

For instance, compare a basic button styled with Tailwind CSS versus DaisyUI:

DaisyUI includes 28 themes, allowing for extensive customization. Even Marc Louvion, author of ShipFast, is a big fan.

In this post, we'll explore how to integrate these libraries into your Jaspr project to create and elevate your styling game to the next level.

To get started quickly, you can check out the quickstart repo on GitHub.

Tailwind Integration

Integrating Tailwind CSS into your Jaspr project is straightforward. Follow these steps to get up and running:

Install Tailwind:

First, you'll need to install Tailwind CSS. Open your terminal and run the following command:
```
npm install -g tailwindcss
```
For versions 0.1.0 and 0.1.1 of Jaspr, this installation is required. If you're using version 0.2.0, follow the instructions here.
Jaspr Integration:

Add the integration package jaspr_tailwind as a dev dependency to your Jaspr project using Dart's package manager:
```
dev_dependencies:
  jaspr_tailwind: ^0.1.1
```

Setup Stylesheet:

After installing Tailwind, you need to set up the stylesheet in your project. Create a styles.tw.css file in your project's web folder with the following content:

@tailwind base;
@tailwind components;
@tailwind utilities;

Next, link this stylesheet in your index.html:

<link href="/assets/styles.tw.css" rel="stylesheet">

If you are using @client or server Jaspr setup, link it in your main Dart file (lib/main.dart):

void main() {
  runApp(Document(
    title: 'My Tailwind Site',
    head: [
      link(href: 'styles.css', rel: 'stylesheet'),
    ],
    body: App(),
  ));
}

DaisyUI Integration

With Tailwind CSS integrated, adding DaisyUI is the next step.

Install DaisyUI:

Install DaisyUI by running the following command:
```
npm i -D daisyui@latest
```

Configure Tailwind to use DaisyUI:

Create a tailwind.config.js file in the root folder of your project. Add DaisyUI to the Tailwind plugins in this configuration file:

/** @type {import('tailwindcss').Config} */
module.exports = {
    content: [],
    theme: {
        extend: {},
    },
    daisyui: {
        themes: [
          "light",
          "dark",
        ],
      },
    plugins: [require("daisyui")],
};

This setup will enable the standard light and dark themes.

If your integration is not working, refer to this guide. The most common issue is missing content configuration.

Colors & Theming

Tailwind CSS provides an extensive palette of colors that you can use to customize your website. With DaisyUI, you can easily adjust these colors to match your desired theme.

DaisyUI uses semantic coloring, which means that colors are named according to their usage/function. It’s the same thing MaterialUI does.

There are 4 base usage colors: primary, secondary, accent, and neutral. Each of them also has a -content counterpart, which is typically used to provide contrast to text and icons on the background using the base color.

Additionally, there are also 4 state colors: info, success, warning, and error, used for displaying various information and state to the user, and a base color group, usually used for backgrounds.

Using this styling system enables you to quickly change colors and iterate on themes, in the same way ThemeData does that in Flutter.

DaisyUI comes with 28 pre-built themes, making it simple to change the overall look and feel of your site. You can customize themes or create your own using the DaisyUI Theme Generator.

Themes are added and modified in the tailwind.config.js file. Make sure to run jaspr clean and jaspr serve after changing the theme configuration to ensure that Jaspr has the latest CSS configuration available.

Examples

DaisyUI and Tailwind are meant to be used together. Let’s style a primary button with a trailing icon that moves to the right when the button is hovered.

The basic primary button looks like this:

button(classes: "btn btn-primary",[text("Let's talk")], onClick: () {},)

Classes btn and btn-primary shape the button and give it the primary color. Let’s add a right arrow next to the text with a small margin:

button(
    classes: "btn btn-primary",
    [
      text("Let's talk"),
      i(
          classes:
              "fa-solid fa-arrow-right ml-2",
          [])
    ],
    onClick: () {}),

Finally, let’s make the arrow move to the right when the button is hovered:

button(
    classes: "group btn btn-primary px-8",
    [
      text("Let's talk"),
      i(
          classes:
              "fa-solid fa-arrow-right ml-2 ease-in-out duration-300 group-hover:translate-x-1",
          [])
    ],
    onClick: () {}),

The result will look something like this:

Useful Links

Here are some resources to help you further customize and troubleshoot your setup:

DaisyUI FAQ: Learn how to solve the most common DaisyUI issues.
Daisy UI Theme Docs: Learn how to customize DaisyUI themes.
Daisy UI Color Docs: Learn how to customize DaisyUI colors.
Daisy UI Config Docs: Learn how to customize DaisyUI configuration.
Daisy UI Theme Generator: Customize and generate themes for DaisyUI to match your project's aesthetics.
Stackblitz: Test DaisyUI theme changes in real time.

Conclusion

Integrating Tailwind CSS and DaisyUI with your Jaspr project opens up a world of possibilities for creating stunning, responsive websites. With the utility-first approach of Tailwind and the pre-built components of DaisyUI, you can streamline your development process and focus on building beautiful, functional web applications.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter or LinkedIn.

Until next time, happy coding!

Reposted from my blog.

Building Animated Buttons in Flutter with Lottie

Dinko Marinac — Mon, 29 Apr 2024 08:48:39 +0000

In mobile app development, user interface elements play a crucial role in enhancing the user experience. Companies like Apple, Spotify, and Airbnb pay a lot of attention to small details that elevate the user experience to another level.

One of those details is animations.

Subtle, slick, and polished animations create an unmatching user experience.

There are many ways to add animations to your Flutter app, but some are more easier to do then the other. You will get the mock bang for your buck by using:

Navigation transition animations
animations package
Animated buttons

There are two libraries that can help you create smoothly animated buttons in Flutter: Lottie and Rive.

The focus of this tutorial will be to show you how to create an animated record video button using a Lottie animation.

Here’s what are are going to build:

Let’s dive in!

Animation and the key frames

First, we have to find the animation that we are going to use. The best place to find free Lottie animations is LottieFiles.

For this tutorial, we are going to use this nice Record/Stop Button animation by Chris Gannon.

What I really like about LottieFiles is that it features an editor when you create an account. Inside this editor, you can play the animation, change it, and play around with it.

When open the editor, it will look something like this:

The part we are interested in is this bottom bar in the purple outline. Here you can control the playing of the video and see the frame counter, which is the most important information for controlling the animation.

When you play the animation a couple of times you can see there are 3 parts to it:

Intro (frames 0-60)
Start playing (frames 60-180)
Stop playing (frame 180-241)

We can use the starting times of the animation to control at which moments the animation needs to be started, stopped, or reset.

Let’s get to coding.

Coding

To start off, we need to add Lottie to the pubspec.yaml:



dependencies:
    lottie: ^3.1.0

We will also need two animation checkpoints:



const _introAnimationEnd = 60 / 240;
const _lastStopIconAnimationEnd = 180 / 240;

Let’s define our button:



class RecordButton extends StatefulWidget {
  const RecordButton({
    Key? key,
    required this.onStartRecording,
    required this.onStopRecording,
    this.size = 200,
  }) : super(key: key);

  final VoidCallback? onStartRecording;
  final VoidCallback? onStopRecording;
  final double size;

  @override
  State<RecordButton> createState() => _RecordButtonState();
}

class _RecordButtonState extends State<RecordButton> with SingleTickerProviderStateMixin {
  bool isRecording = false;
  late final AnimationController _controller;

  @override
  void initState() {
    _controller = AnimationController(vsync: this);
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
   return Placeholder();
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
}

The button has 2 callbacks, onStartRecording and onStopRecording and an optional size property to change the size of the button. It needs to be a StatefulWidget to support the AnimationController.

The button has 3 states:

initial state
ready to record state
recording state

Each of these states corresponds to one of the animation parts mentioned previously.

First, the button enters the initial state in the onLoaded() method of the Lottie widget and plays the intro animation using the controller:



Lottie.network(
        "<https://assets.codepen.io/35984/record_button.json>",
        controller: _controller,
        onLoaded: (composition) {
          _controller.duration = composition.duration;
          _controller.animateTo(_introAnimationEnd);
        },

The button is now ready to start recording. When the user presses the button it will enter the recording state and play the record state animation. During the recording state, the user can press the button again to stop the recording and play the animation to the end.



return GestureDetector(
      onTap: () {
        setState(() {
          isRecording = !isRecording;
        });
        if (isRecording) {
          widget.onStartRecording?.call();
          _controller.animateTo(_lastStopIconAnimationEnd);
        } else {
          widget.onStopRecording?.call();
          _controller.animateTo(1);
        }
      },

There is one last case we need to take care of. When the user presses the button to stop the recording, and animation will go to the end. The next press would start the recording, but the animation would not play because it was already at the end. To fix this, we need to add the listener to reset the animation to the correct frame (_introAnimationEnd) in the onLoaded() method:



 onLoaded: (composition) {
          _controller.addListener(() {
            if (_controller.value == 1) {
              _controller.value = _introAnimationEnd;
            }
          });
        },

The final result looks like this:



const _introAnimationEnd = 60 / 240;
const _lastStopIconAnimationEnd = 180 / 240;

class RecordButton extends StatefulWidget {
  const RecordButton({
    Key? key,
    required this.onStartRecording,
    required this.onStopRecording,
    this.size = 200,
  }) : super(key: key);

  final VoidCallback? onStartRecording;
  final VoidCallback? onStopRecording;
  final double size;

  @override
  State<RecordButton> createState() => _RecordButtonState();
}

class _RecordButtonState extends State<RecordButton> with SingleTickerProviderStateMixin {
  bool isRecording = false;
  late final AnimationController _controller;

  @override
  void initState() {
    _controller = AnimationController(vsync: this);
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () {
        setState(() {
          isRecording = !isRecording;
        });
        if (isRecording) {
          widget.onStartRecording?.call();
          _controller.animateTo(_lastStopIconAnimationEnd);
        } else {
          widget.onStopRecording?.call();
          _controller.animateTo(1);
        }
      },
      child: Lottie.network(
        "<https://assets.codepen.io/35984/record_button.json>",
        controller: _controller,
        width: widget.size,
        height: widget.size,
        fit: BoxFit.fill,
        repeat: false,
        onLoaded: (composition) {
          _controller.duration = composition.duration;
          _controller.animateTo(_introAnimationEnd);
          _controller.addListener(() {
            if (_controller.value == 1) {
              _controller.value = _introAnimationEnd;
            }
          });
        },
      ),
    );
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
}

You can also find the full code as a gist on my Github.

Conclusion

In this tutorial, you have learned how to find a nice Lottie animation, determine the key frames, and create a button that uses it. Hopefully, you can use this to bring your user experience to the next level with some slick animations.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter or LinkedIn.

Until next time, happy coding!

Reposted from my blog.

Beyond Code Generation: Crafting Custom Hive Adapters

Dinko Marinac — Tue, 23 Apr 2024 08:35:45 +0000

Hive is the oldest and most used local database in Flutter. While it’s not recommended to use it since it’s not maintained anymore, if you are a consultant or a freelancer you will get a project which still uses it.

Since Github Copilot has come out, I’ve been migrating off using build_runner on larger projects because code generation for 1 change can take a couple of minutes at a time. Projects using hive_generator fall into that category.

To speed things up, I usually write adapters by hand. You might ask yourself, “why”? Using hive_generator is good enough.

The pros outweigh the cons by a large margin:

improved build_runner speed
cleaner models (no annotations)
no need for models only used for database storage
easier migration
manually written adapters are easier to maintain
adapters are easily testable
less code overall

I will show you how you can write adapters manually. Using Github Copilot will speed up this process tenfold.

Ready? Let’s dive in.

Hive Crash Course

Before we delve into writing custom adapters, let's quickly recap the basics of Hive for those new to it.

Hive is a lightweight and fast key-value database for Flutter and Dart, allowing you to persistently store objects locally. Here's a brief rundown of how to use Hive:

Setup: First, you need to add the hive and hive_flutter dependencies to your pubspec.yaml file and initialize Hive in your Flutter app.

dependencies:
  hive: ^2.2.3
  hive_flutter: ^1.1.0

## you will not be needing this since you will learn how to write adapters by yourself  
dev_dependencies:
    hive_generator: ^2.0.1

Model Definition: Define your data model classes that you want to persist in Hive. When you are using a generator, these classes should extend HiveObject and have fields that are supported by Hive.

    import 'package:hive_flutter/hive_flutter.dart';

    part 'user.g.dart';

    @HiveType(typeId: 0)
    class User extends HiveObject {
      @HiveField(0)
      final int id;

      @HiveField(1)
      final String name;

      @HiveField(2)
      final String profilePictureUrl;

      @HiveField(3)
      final bool isPremium;

      User({required this.id, required this.name, required this.profilePictureUrl, required this.isPremium});
    }

Adapter Registration: Register adapters for your model classes.

// Initialize Hive
await Hive.initFlutter();

// Register adapter for User class
Hive.registerAdapter<User>(UserAdapter());

Box: Open a Hive box to store your data. Boxes act like tables in traditional databases and are where you store your objects.

// Open a box named 'users'
var box = await Hive.openBox<User>('users');

// If you have a very large collection, use lazyBox
await Hive.openLazyBox('users');
final lazyBox = Hive.lazyBox('users');

CRUD Operations: Perform CRUD (Create, Read, Update, Delete) operations on your data by putting, getting, updating, and deleting objects in/from the box.

// Store/update the user in the box
await box.put('john', user);

// Retrieve the user from the box
var retrievedUser = box.get('john');
print(retrievedUser!.name); // Output: John

// Delete the user
await box.delete('john');

Box close: Close the Box when you are done with using the data.
```
await box.close();
```

Writing custom adapters for any class

Custom adapters in Hive allow you to define how objects of your custom classes are serialized and deserialized into binary format for storage. Let's walk through an example of creating a class and writing a custom adapter for it.

I will use the previously mentioned User class without the Hive annotations:

class User {
  final int id;
  final String name;
  final String profilePictureUrl;
  final bool isPremium;

  User({
    required this.id,
    required this.name,
    required this.profilePictureUrl,
    required this.isPremium,
  });
}

To write a custom adapter, you have to 3 things:

extend TypeAdapter with an appropriate type (User in this case)
give the adapter a typeId
make sure you are writing and reading properties in the same order

Reading and writing in a different order will cause your data to be corrupt if it’s the same type, or it throws an exception because casting to the type you want will not be possible.

Let’s look at the example of how to properly write an adapter:

import 'package:hive_flutter/hive_flutter.dart';

class UserAdapter extends TypeAdapter<User> {
  UserAdapter(this.typeId);

  @override
  final int typeId;

  @override
  User read(BinaryReader reader) {
    final id = reader.read() as int;
    final name = reader.read() as String;
    final profilePictureUrl = reader.read() as String;
    final isPremium = reader.read() as bool;

    return User(
        id: id,
        name:name,
        profilePictureUrl: profilePictureUrl,
        isPremium: Premium,
      );
  }

  @override
  void write(BinaryWriter writer, User obj) {
    writer
      ..write(obj.id)
      ..write(obj.name)
      ..write(obj.profilePictureUrl)
      ..write(obj.isPremium);
  }
}

In the above adapter:

We specify the typeId to uniquely identify the adapter.
The read method reads data from the binary and constructs a User object.
The write method writes the User object to the binary.

Now, let's compare the manually written adapter with the code generated by Hive for the User class.

// GENERATED CODE - DO NOT MODIFY BY HAND

part of 'user.dart';

// **************************************************************************
// TypeAdapterGenerator
// **************************************************************************

class UserAdapter extends TypeAdapter<User> {
  @override
  final int typeId = 0;

  @override
  User read(BinaryReader reader) {
    final numOfFields = reader.readByte();
    final fields = <int, dynamic>{
      for (var i = 0; i < numOfFields; i++) reader.readByte(): reader.read(),
    };
    return User(
      id: fields[0] as int,
      name: fields[1] as String,
      profilePictureUrl: fields[2] as String,
      isPremium: fields[3] as bool,
    );
  }

  @override
  void write(BinaryWriter writer, User obj) {
    writer
      ..writeByte(4)
      ..writeByte(0)
      ..write(obj.id)
      ..writeByte(1)
      ..write(obj.name)
      ..writeByte(2)
      ..write(obj.profilePictureUrl)
      ..writeByte(3)
      ..write(obj.isPremium);
  }
}

The code that we wrote is almost the same expect for one key difference: Hive uses numbers associated with the field to make sure the fields are serialized and deserialized in the correct order. They are also used in case you need to migrate.

Special case: Enums

Hive doesn’t support enums of the box, so we have to serialize them as well. Luckily, we can do this in a very generic way for non-enhanced enums.

There are 2 ways we can solve this problem:

Taking advantage of values, which always returns the list in the order that is written in the code. That way we only need to save the index of the value.

import 'package:hive_flutter/hive_flutter.dart';

class EnumClassAdapter<T extends Enum> extends TypeAdapter<T> {
  EnumClassAdapter(this.typeId, this.values);

  @override
  final int typeId;

  final List<T> values;

  @override
  T read(BinaryReader reader) {
    return values[reader.read() as int];
  }

  @override
  void write(BinaryWriter writer, T obj) {
    writer.write(obj.index);
  }
}

Taking advantage of name property which returns the value of the enum as a String and then searches the values for it, which eliminates the need to store the index correctly.

import 'package:hive_flutter/hive_flutter.dart';

class EnumClassAdapter<T extends Enum> extends TypeAdapter<T> {
  EnumClassAdapter(this.typeId, this.values);

  @override
  final int typeId;

  final List<T> values;

  @override
  T read(BinaryReader reader) {
    final enumString = reader.read() as String;
    return values.firstWhere((e) => e.name == enumString);
  }

  @override
  void write(BinaryWriter writer, T obj) {
    writer.write(obj.name);
  }
}

Then all you have to do is register the adapter and just cast the class as usual when writing other adapters:

enum Category { one, two, three }

Hive.registerAdapter<Category>(EnumClassAdapter<Category>(1, Category.values));
await Hive.initFlutter();

I usually chose option number 2 because it is less error-prone. If you choose option 1, you must not change the order of the enum values because your data will become corrupted.

Conclusion

In this article, we've explored the process of writing custom Hive adapters manually. Although code generation tools like hive_generator exist, manually written adapters offer several advantages, including improved build speed, cleaner models, easier migration, and better maintainability.

By understanding how to write custom adapters, you have greater control over how your data is serialized and deserialized, allowing you to tailor the storage mechanism to your specific needs.

So next time you're working on a Flutter project with Hive, consider crafting your adapters by hand for a more efficient and flexible solution.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter or LinkedIn.

Until next time, happy coding!

Reposted from my blog.

Guarding routes in Flutter with GoRouter and Riverpod

Dinko Marinac — Mon, 26 Feb 2024 09:38:44 +0000

Introduction

Guarding routes is a very common topic amongst mobile developers.

The problem can be boiled down to the following question:

"How can I have permission on the routes in my app?"

If you are using Flutter and Navigator 2.0 you can choose between the 3 most popular libraries for navigation: GoRouter, AutoRoute, and Beamer. AutoRouter and Beamer support Guards out of the box, but GoRouter does not. If you are using GoRouter, this article is for you.

The most common use case for route guarding is authentication. If the user is logged in, all functionality is available to him, if he is not, most or none is.

I will be using Riverpod as my preferred state management library, but you could use any other, the same principles apply.

GoRouter `redirect`

GoRouter exposes a redirect property that can be used to navigate the user on a different route. In the example of authentication guarding, the user would be redirected to the login page if he is not authenticated.

The redirect is defined as follows:

typedef GoRouterRedirect = FutureOr<String?> Function(BuildContext context, GoRouterState state);

The callback supplies the BuildContext and GoRouterState and expects a nullable String as a result. If String is returned, it should be an existing route, and that means that a redirect will occur and the user will be redirected to the specified location. If null is returned, no redirect will occur.

Reacting to changes

The biggest issue is that the router must be specified when the app is created and there is no information about whether the user is logged in or not. Furthermore, this state can change during the runtime and the router should react accordingly. To solve this, the authentication state of the app should be observed.

Since I'm using Riverpod, this would translate to:

1. Create a provider that exposes the authentication state

2. Create a router provider

3. Watch the router provider in ProviderScope and supply the app with the router.

Let's say you have an auth service which exposes the authentication state as a nullable User object (like Firebase Authentication does). You can create a StreamProvider which exposes this state:

final currentUserProvider = StreamProvider<User?>((ref) {
  final auth = ref.watch(firebaseAuthProvider);
  return auth.authStateChanges();
});

The next step is to create a routerProvider:

final routerProvider = Provider((ref) {
  return _routeConfig(redirect: (context, state) {
    final authState = ref.read(currentUserProvider);
    if (authState.isLoading || authState.hasError) return null;

    final isAuthenticated = authState.valueOrNull != null;
    final isAuthenticating = state.matchedLocation == Routes.login;

    if (!isAuthenticated) {
      return Routes.login;
    }

    if (isAuthenticating) {
      return Routes.dashboard;
    }

    return null;
  });
});

GoRouter _routeConfig({GoRouterRedirect? redirect = null}) => GoRouter(
      redirect: redirect,
      routes: [
          // routes..  
      ],  
     );

The _routeConfig method creates a router with a specified redirect. This is your router.

Redirect logic is as follows:

If the authentication state is loading or there is an error, don't perform the redirect.
If user is not authenticated, redirect him to login
If user is authenticated and on login, redirect to dashboard

The only thing left to do is to connect the router to MaterialApp:

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

  @override
  Widget build(BuildContext context) {
    return ProviderScope(
      observers: [ProviderLogger()],
      child: Consumer(
        builder: (_, ref, __) {
          final router = ref.watch(routerProvider);
          return MaterialApp.router(
            routerConfig: router,
            title: 'Flutter Demo',
            theme: AppTheme.lightTheme,
            darkTheme: AppTheme.darkTheme,
            themeMode: ThemeMode.dark,
            localizationsDelegates: [AppLocalizations.delegate],
          );
        },
      ),
    );
  }
}

Conclusion

That's it! If your user logs out or fails authentication for any reason, they will be redirected to the login page. Once they log in they can freely navigate within the app.

If you have found this short tutorial on how to implement route guarding in Flutter with GoRouter and Riverpod valuable, make sure to like and follow for more content like this.

Reposted from my blog.

Implementing Infinite Scroll with Riverpod's AsyncNotifier

Dinko Marinac — Mon, 19 Feb 2024 09:10:29 +0000

Introduction

I recently had a task for a client on a project which uses Riverpod for state managment: Create an infinite scroll that can be very easily reused.

You might the tempted to answer: "there's a package for that".

You would be right, the most notable one is riverpod_infinite_scroll. However, it has not been updated for 16 months and uses a StateNotifier, which will be deprecated and requires additional setup to work with API calls.

Other solutions also rely on a rigid paging structure and go off the assumption that pages are always numbers, which is mostly true for the endpoints you consume but might be false for the UI. An example would be a banking app that displays transactions daily, weekly, or monthly. In that case, the page might not be an int, it might be a DateTime or a String.

Riverpod introduced AsyncNotifier into its catalog to simplify the most common use-case: async loading of the data. In this article, we will take advantage of that and learn how to abstract pagination which can be reused within the app.

The article is split into two parts: the code required on the data layer, and the code required on the UI layer.

Data Layer

A common question people ask about pagination is:

"How do I design the class that holds my state to keep track of the page I'm currently on, while simultaneously holding all the data?"

The answer is that you don't need the state class here. The UI doesn't need the information about which page is being loaded or how it is being done. The more of this logic is abstracted, the better.

Let's start by defining what the class that takes care of pagination needs to have. Every paginated response has 2 important variables: page and pageSize. We can ignore the page size since it can be static.

We also need to know what endpoint to call and when to load the next page. Additionally, if there is a need for non-integer paging, we have to know what is the initial value and how to compute the next value.

The result is the following interface:

abstract class PaginationController<T, I> {
  I get initialPage;

  late I currentPage = initialPage;

  FutureOr<List<T>> loadPage(I page);

  Future<void> loadNextPage();

  I nextPage(I currentPage);
}

The interface takes in 2 generic parameters:

<T>, which represents type of data we are returning
<I>, which represent the type of the index we use for pages.

We are operating with 2 values:

initialPage, which will the initial page we want to load
currentPage, which is used to keep track of what page we are currently on

There are also 3 methods here:

loadPage() is used to describe how to fetch a new page
nextPage() is used to calculate a new page index before fetching
loadNextPage() is used from the UI when the user scrolls to the end

How to connect this with AsyncNotifier? The answer is by using a mixin, which enables every notifier to adopt this interface without inheritance. Composition is favored over inheritance here because inheritance creates strictly defined rules for a class, which is not mandatory.

mixin AsyncPaginationController<T, I> on AsyncNotifier<List<T>> implements PaginationController<T, I> {
  @override
  late I currentPage = initialPage;

  @override
  FutureOr<List<T>> build() async => loadPage(initialPage);

  @override
  Future<void> loadNextPage() async {
    state = const AsyncLoading();

    final newState = await AsyncValue.guard(() async {
      currentPage = nextPage(currentPage);
      final elements = await loadPage(currentPage);
      return [...?state.value, ...elements];
    });
    state = newState;
  }
}

This mixin makes sure currentPage is tracked, the initialPage is loaded and the loadNextPage() appends new page elements, so the only thing left is to define the initial page, how to load the page, and how to calculate the next page index.

An example of an AsyncNotifier using this will look like (I'm using the MVVM architecture here):

class DataViewModel extends AsyncNotifier<List<Data>> with AsyncPaginationController<Data, int> {

  late final repository = ref.read(dataRepositoryProvider);

  @override
  final initialPage = 0;

  @override
  FutureOr<List<Data>> loadPage(int page) async {
    return repository.fetchData(page);
  }

  @override
  int nextPage(int currentPage) => currentPage + 1;
}

UI layer

Now that the data layer is taken care of, it's the UI layer's turn. With an AsyncNotifier designed like this, the only thing the UI needs to do is call the loadNextPage() method once the scroll is detected.

There are 2 ways you can approach to detecting the end of the scroll behavior in a ListView.

ScrollController (you can use hooks here with Riverpod)

final ScrollController scrollController = ScrollController();

void _scrollListener() {
    if (scrollController.offset >= scrollController.position.maxScrollExtent &&
        !scrollController.position.outOfRange) {
      viewModel.loadNextPage();
    }
  }
  @override
  Widget build(BuildContext context) {
    final state = ref.watch(dataViewModelProvider);

    return switch (state) {
        AsyncData(:final value) => _list(context, value),
        AsyncError(:final error) => Text('Error: $error'),
        _ => const Center(child: CircularProgressIndicator()),
      };
  }

  Widget _list(BuildContext context, List<Data> data) {
    scrollController.addListener(() {
        _scrollListener();
      });

    return ListView.builder(
      itemCount: data.length,
      itemBuilder: (context, index) {
        return ListTile(
          title: Text(data[index].name),
          subtitle: Text(data[index].description),
        );
      },
    );
  }

NotificationListener widget


@override
  Widget build(BuildContext context) {
    final state = ref.watch(dataViewModelProvider);

    return switch (state) {
        AsyncData(:final value) => _list(context, value),
        AsyncError(:final error) => Text('Error: $error'),
        _ => const Center(child: CircularProgressIndicator()),
      };
  }

  Widget _list(BuildContext context, List<Data> data) {
    return NotificationListener(
      onNotification: (ScrollNotification scrollInfo) {
        if (scrollInfo is ScrollEndNotification &&
            scrollInfo.metrics.axisDirection == AxisDirection.down &&
            scrollInfo.metrics.pixels >= scrollInfo.metrics.maxScrollExtent) {
          viewModel.loadNextPage();
        }
        return true;
      },
      child: ListView.builder(
        itemCount: data.length,
        itemBuilder: (context, index) {
          return ListTile(
            title: Text(data[index].name),
            subtitle: Text(data[index].description),
          );
        },
      ),
    );
  }

I have chosen the NotificationListener since it's much less code and less code means less maintenance.

If you have enjoyed this short tutorial on how to make an infinite scrollable list with Riverpod, make sure to like and follow for more content like this.

Reposted from my blog.