DEV Community: Md. Al-Amin

DDD (Domain-Driven Design) in Flutter: Too Much or Just Right?

Md. Al-Amin — Wed, 23 Jul 2025 11:30:41 +0000

When it comes to architecting Flutter apps especially large-scale one's developers often find themselves stuck between clean code principles and shipping fast. One of the most debated topics in this space is Domain-Driven Design (DDD).

Some say it’s overkill for mobile apps. Others swear by it. So, what’s the truth?

Let’s break it down.

What is Domain-Driven Design (DDD)?

DDD is a software development philosophy introduced by Eric Evans. The core idea is simple:

Your code should reflect your business domain and logic first not frameworks or UI layers.

It encourages separation between different parts of your app:

Domain layer: Business logic, rules, entities
Application layer: Use cases, orchestration
Infrastructure layer: Frameworks, APIs, databases
Presentation layer: UI (Flutter Widgets in our case)

DDD is about aligning code structure with real-world business models. In large, evolving applications, this separation becomes critical.

The Problem DDD Solves in Flutter

In many Flutter apps, business logic lives inside widgets. It starts small:

ElevatedButton(
  onPressed: () {
    if (formIsValid()) {
      submitForm();
    }
  },
)

Then the logic grows. You add validation, API calls, error handling, retries… and suddenly your widget becomes a monster.

This is where DDD shines.

By separating concerns:

UI stays UI
Business logic lives in the domain
Reusability, testability, and maintainability skyrocket

Is DDD Overkill for Flutter?

When DDD Makes Sense:

Your app is large or growing fast
You have complex business rules
Teams work on different features/modules
You plan to reuse logic across platforms (Web, Mobile, Backend)

When It Might Be Too Much:

You’re building a small MVP or prototype
Your app has minimal business rules
You’re a solo developer with tight deadlines

In those cases, simpler architectures like MVVM or feature-first clean code might be enough.

However, starting clean is easier than refactoring dirty code later.

What DDD Looks Like in Flutter

Here’s a simplified structure using DDD in a Login feature:

lib/
└── features/
    └── auth/
        ├── domain/
        │   ├── entities/
        │   ├── repositories/
        │   └── usecases/
        ├── application/
        │   └── services/
        ├── infrastructure/
        │   └── datasource/
        └── presentation/
            └── pages/

Example: Use Case

class LoginUseCase {
  final AuthRepository repository;

  LoginUseCase(this.repository);

  Future<Either<Failure, User>> call(String email, String password) {
    return repository.login(email, password);
  }
}

In your BLoC or Cubit

Future<void> login(String email, String password) async {
  emit(LoginLoading());
  final result = await loginUseCase(email, password);
  result.fold(
    (failure) => emit(LoginError(failure.message)),
    (user) => emit(LoginSuccess(user)),
  );
}

Your widget now just listens to state changes — and doesn’t know how login works internally.

Real-World Example

A logistics app I worked on had:

Multiple user roles (Driver, Dispatcher, Admin)
Complex order states and workflows
Offline data sync and conflict resolution

By applying DDD:

Each domain (Orders, User, Vehicles) had its own clear logic
Testing became isolated and fast
Features could be worked on independently by different devs

It saved us from chaos when the app scaled from 2 devs to 10+ contributors.

Best Practices for Using DDD in Flutter

Start small, scale wisely : Don’t try to implement DDD in everything from Day 1. Pick a critical feature.
Use packages like get_it, injectable, or riverpod : This help manage dependencies across layers without tight coupling.
Avoid premature abstraction : Abstract only when business logic demands it not to “look clean.”
Write tests per layer : Unit tests for use cases, integration tests for repositories, widget tests for UI.
Communicate with your team : DDD is only powerful when your team understands the domain model.

Final Thoughts

DDD in Flutter isn’t overkill it’s a mindset.

You don’t need to adopt it religiously in every app. But for scalable, maintainable, and testable Flutter apps, DDD gives you a solid foundation.

Start where it hurts the most. Refactor those bloated widgets. Move business logic to the domain. You’ll feel the difference.

Have you tried DDD in Flutter before? What worked? What didn’t? Let’s talk in the comments!

How to Structure a Plugin-Friendly Flutter App

Md. Al-Amin — Tue, 22 Jul 2025 15:38:43 +0000

You’ve probably built a cool feature that you wished you could easily reuse in another app maybe a custom calendar, a payment module, or a chat UI.

But when you try to extract it… you realize it’s deeply coupled to your app.

That’s where plugin-friendly architecture comes in. If you structure your Flutter app the right way from the start, you’ll be able to extract features into packages or plugins effortlessly saving time, avoiding rewrites, and even enabling contributions from others if you’re working in a team or open-source setting.

Let’s explore how to design your Flutter app to be plugin-friendly from day one.

Why Care About Plugin-Friendly Structure?

Here’s why these matters:

Easy code reuse across apps
Convert any feature into a plugin/package
Better testing and maintainability
Clear modular separation
Ideal for enterprise apps and open-source projects

Core Principles of Plugin-Friendly Architecture

Feature Isolation : Each feature should be self-contained UI, logic, services, and dependencies all live inside its own folder or module.
Minimal Coupling to App Layer : Features shouldn’t rely directly on things like BuildContext, global variables, or shared themes.
Use Interfaces and Abstractions : Define contracts for services (like AuthService, PaymentGateway) so they can be swapped or mocked.
Separate Core from Integration : Keep business logic and UI reusable and isolate app-specific wiring (like routes, theme, or platform logic) in the app layer only.

Recommended Folder Structure

Instead of:

lib/
  models/
  views/
  controllers/

Try:

lib/
  app/              ← main app configuration
  features/
    chat/
      data/
      domain/
      presentation/
    auth/
      data/
      domain/
      presentation/
  core/
    widgets/
    utils/
    services/
  plugins/          ← internal reusable packages (optional)

Each feature/ folder could be turned into a standalone package or plugin later.

Tools & Techniques to Use

Use `package:injectable` + `get_it` for DI

Helps decouple features from their concrete dependencies. Each feature can declare what it needs and get it injected.

Leverage Dart’s `export` Keyword

Simplify imports when creating reusable packages.

// lib/auth.dart
export 'src/auth_service.dart';
export 'src/auth_screen.dart';

Use Platform Channels Smartly

When creating features that interact with native code (e.g., camera, sensors), isolate native platform logic inside the feature package and use a clean API for access.

Converting a Feature into a Plugin

Let’s say you’ve built a step_counter feature in your app.

Step 1: Extract the Feature

Move it to a new package:

packages/
  step_counter/
    lib/
      step_counter.dart
      src/
        step_counter_service.dart
        widgets/

Step 2: Expose a Clean API

In step_counter.dart:

library step_counter;

export 'src/step_counter_service.dart';
export 'src/widgets/step_display.dart';

Step 3: Add to App as Dependency

In your main app:

dependencies:
  step_counter:
    path: ../packages/step_counter

Now your feature is modular, testable, and reusable across projects!

Real-World Example

Let’s take the case of a pedometer app you’re building for multiple client brands.

If you structure the core walking logic, distance calculation, and sensor access into a plugin, you can:

Reuse it across different branded apps
Customize UI in each app while keeping core logic consistent
Maintain and test the logic in one place

Best Practices Recap

Feature-first folder structure: Enables modular extraction
Define interfaces in domain layer: Decouples dependencies
Use dependency injection: Improves testability & flexibility
Avoid app-level dependencies in feature code: Keeps features portable
Expose minimal API in packages: Makes reuse easy

Final Thoughts

Building plugin-friendly Flutter apps doesn’t just help you write cleaner code it prepares you for scale, reuse, testing, and team collaboration.

Whether you’re working on enterprise apps, client projects, or building your own Flutter plugin library this structure will set you up for long-term success.

What’s Next?

In an upcoming post, I’ll show how to publish a custom Flutter plugin to pub.dev — from structuring to versioning and publishing best practices.

Want help structuring your next app or plugin?
Let’s connect on LinkedIn or Twitter I love talking architecture!

Scaling Flutter Apps with Feature-First Folder Structures

Md. Al-Amin — Mon, 21 Jul 2025 11:30:11 +0000

As Flutter apps grow, so does the complexity of maintaining them. One of the most overlooked reasons behind messy, hard-to-scale codebases? Poor project structure.

Many developers start with the default lib/ folder and keep adding files until it becomes a graveyard of widgets, services, and helpers scattered without context. Sound familiar?

Let’s fix that by exploring one of the most effective strategies for scaling Flutter apps: Feature-First Folder Structure.

The Problem with Layer-Based Structure

A typical beginner project might look like this:

lib/
├── models/
├── screens/
├── widgets/
├── services/
├── utils/

This works okay at first, but as features grow:

You start jumping across folders to understand a single flow.
Business logic leaks into UI layers.
Teams step on each other’s toes when working on the same layers.
Code reuse becomes a mess.

The Feature-First Approach: Why It Works

Instead of organizing by type (widgets/models/services), a feature-first structure organizes by features or modules.

lib/
├── features/
│   ├── home/
│   │   ├── data/
│   │   ├── domain/
│   │   ├── presentation/
│   │   └── home_page.dart
│   ├── auth/
│   │   ├── data/
│   │   ├── domain/
│   │   ├── presentation/
│   │   └── login_page.dart
├── core/
│   ├── theme/
│   ├── router/
│   └── common_widgets/

Each feature is isolated it contains its own:

Presentation/UI (widgets, screens)
Domain (use cases, entities)
Data (models, repositories, services)

This aligns beautifully with Clean Architecture, making your code modular, testable, and scalable.

Benefits at Scale

Here’s why this approach shines in large projects:

1. Isolation of Features

Each feature is self-contained, so developers can:

Work independently
Test modules in isolation
Reduce merge conflicts

2. Improved Code Navigation

Want to update the “checkout” feature?
Just go to features/checkout/ — all relevant logic is there.

3. Clean Onboarding

New teammates can focus on just one folder to understand how a feature works, rather than jumping across layers.

4. Fewer Regressions

Because of isolated dependencies, changes in one feature are less likely to break another.

Best Practices for Feature-First Projects

Here’s how to get the most out of this structure:

1. Use Clear Naming

Use consistent names like data, domain, presentation under each feature. Avoid vague names like helpers or misc.

2. Leverage Dependency Injection

Use tools like get_it and injectable to inject services per feature, avoiding tight coupling.

3. Modularize Your Features

In very large apps, split each feature into Dart packages using Flutter’s package structure or melos.

4. Extract Shared Logic to `core/`

Keep global theming, constants, and reusable widgets in core/ to avoid duplication.

Real-World Example: eCommerce App

Let’s say you’re building a large eCommerce app. A feature-first structure could look like:

lib/
├── features/
│   ├── products/
│   │   ├── presentation/
│   │   ├── domain/
│   │   ├── data/
│   ├── cart/
│   ├── checkout/
│   ├── auth/
├── core/
│   ├── theme/
│   ├── localization/
│   ├── common_widgets/

Each team (e.g. cart team, auth team) can build and maintain their own feature independently. This scales beautifully when your app has multiple developers or contributors.

When Not to Use Feature-First?

Feature-first structures are great when:

Your app has 3+ features
You’re working in a team
You’re planning for long-term maintainability

But for tiny apps or MVPs, the added structure may feel like overhead. Start simple evolve as you grow.

Final Thoughts

Your app’s folder structure is more than just an aesthetic choice it directly affects how fast you move, how easily you are onboard new devs, and how confidently you ship features.

A feature-first folder structure brings:

Modularity
Testability
Scalability

So next time you start a new Flutter project (or refactor an old one), consider organizing by features, not just by file type. Your future self (and your team) will thank you.

Want to Go Deeper?

Check out these related topics to dive deeper:

Clean Architecture in Flutter
Dependency Injection with get_it & injectable
Managing state per feature with Bloc or Riverpod

Effective Layered Architecture in Large Flutter Apps

Md. Al-Amin — Sun, 20 Jul 2025 12:43:07 +0000

When your Flutter app grows beyond a few screens and features, your codebase starts to feel like a jungle. You find business logic inside widgets, API calls scattered across UI files, and trying to test anything becomes a nightmare. Sound familiar?

This is where Layered Architecture comes in and not just for the sake of organization, but for maintainability, scalability, and testability.

Let’s break this down from core principles to real-world implementation with no fluff.

What is Layered Architecture?

At its core, layered architecture separates your app’s responsibilities into distinct layers. Each layer focuses on a specific role and communicates only with its adjacent layers.

Here’s the classic 3+1 layered structure in a Flutter context:

Presentation Layer
Application Layer (Use Cases)
Domain Layer (Business Rules)
Data Layer (Repositories, APIs, DB)

Why Layered Architecture Matters in Large Apps

Here’s what layered architecture solves:

Bloated widgets: Business logic is moved out into use cases.
Hard-to-test code: Each layer becomes independently testable.
Tightly coupled APIs: Use repositories and abstractions.
Onboarding new developers: Clear folder boundaries make it easier.
Reusability issues: Business logic is reusable across screens and features.

Breaking Down the Layers (With Dart Examples)

1. Presentation Layer

This is your UI layer. It includes widgets, BLoC, Cubits, or Riverpod providers. This layer should never contain business logic or direct data access.

Responsibilities:

Show UI
React to state changes
Call use cases not services, not APIs

Example:

class ProfileScreen extends StatelessWidget {
  final GetUserProfileUseCase useCase;

  const ProfileScreen(this.useCase);

  @override
  Widget build(BuildContext context) {
    return FutureBuilder(
      future: useCase(),
      builder: (context, snapshot) {
        // show UI
      },
    );
  }
}

2. Application Layer (Use Cases)

This layer represents actions in your app like LoginUser, GetPosts, UpdateCart.

Responsibilities:

Encapsulate one app-level action
Use domain models and repositories
Contain no UI or infrastructure code

Example:

class GetUserProfileUseCase {
  final UserRepository repo;

  GetUserProfileUseCase(this.repo);

  Future<User> call() async {
    return await repo.getUserProfile();
  }
}

3. Domain Layer

This is the core logic of your app where your entities and rules live.

Responsibilities:

Define pure business rules
Be completely Flutter-independent
No external libraries, no platform dependencies

Example:

class User {
  final String id;
  final String name;

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

  bool isValid() => name.isNotEmpty;
}

4. Data Layer

This layer communicates with the outside world APIs, databases, local storage.

Responsibilities:

Implement repository interfaces
Handle API or DB calls
Convert between DTOs and domain models

Example:

class UserRepositoryImpl implements UserRepository {
  final RemoteDataSource remote;

  @override
  Future<User> getUserProfile() async {
    final dto = await remote.fetchUser();
    return User(id: dto.id, name: dto.name);
  }
}

Tools to Support Layered Architecture

Here are some tools and libraries that make working with this structure easier:

State Management: BLoC, Cubit, Riverpod
Dependency Injection: get_it, injectable
Code Generation: freezed, json_serializable
Testing: mocktail, bloc_test, test

Real-World Folder Structure

Organizing by feature first, then by layer within each feature is recommended.

Example structure for a profile feature:

/lib
  /features
    /profile
      /presentation
        profile_screen.dart
        profile_cubit.dart
      /application
        get_user_profile_usecase.dart
      /domain
        entities/user.dart
        repositories/user_repository.dart
      /data
        models/user_dto.dart
        repositories/user_repository_impl.dart

Each feature is modular, self-contained, and easier to navigate or test.

Best Practices

Use interfaces in the domain layer and implement them in the data layer.
Keep presentation logic (UI) separate from business logic (use cases).
Make your domain layer pure Dart with no dependencies.
Avoid injecting services directly into widgets.
Prefer dependency injection over global service locators.

Real-World Use Case: E-Commerce App

In a large shopping app, you might have features like cart, profile, search, checkout. Each of these would:

Have its own use cases like AddToCartUseCase, GetCartItemsUseCase
Use Cubits/Blocs only for managing state
Keep data fetching in data layer via repositories

This structure scales well across multiple teams and codebases.

Common Pitfalls to Avoid

Mixing UI code with business logic (e.g., calling APIs inside widgets)
Skipping domain layer to move faster (you’ll slow down later)
Overusing abstractions when not needed
Injecting concrete classes everywhere instead of interfaces

Final Thoughts

Layered architecture isn’t about creating folders for the sake of it. It’s about controlling the direction of dependencies, limiting complexity, and empowering collaboration.

It helps you:

Scale your app confidently
Keep testing fast and easy
Prevent spaghetti code
Make onboarding developers smooth

If you’re planning to build a large Flutter app that can grow without chaos this architecture is not optional. It’s essential.

Stream vs Future in Dart: Stop Using the Wrong One

Md. Al-Amin — Thu, 17 Jul 2025 10:13:58 +0000

When building Flutter apps, you’ve probably asked yourself:

“Should I use a Future here? Or do I need a Stream?”

Many developers mix these up, which leads to performance issues, hard-to-maintain code, or UI bugs. In this blog, we’ll unpack when to use Future, when to use Stream, and how to avoid the most common mistakes with examples and real-world use cases.

What’s the Difference?

Let’s quickly define the two:

Future

Represents a single asynchronous value.
Completes once.
Best for short-lived operations.

Example: Fetching a user profile from a server.

Stream

Represents a sequence of asynchronous values over time.
Can emit multiple values.
May never complete.
Ideal for long-lived or real-time data.

Example: Receiving real-time messages from a chat app.

Future Example

Future<String> fetchUser() async {
  await Future.delayed(Duration(seconds: 2));
  return 'Alamin Karno';
}

Using it in a FutureBuilder:

FutureBuilder(
  future: fetchUser(),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return CircularProgressIndicator();
    }
    return Text('Hello, ${snapshot.data}');
  },
)

Good use cases for Future:

Fetching one-time data (e.g. user profile, config)
Writing to a local file
Showing a splash delay
Getting device permissions or version info

Stream Example

Stream<int> counterStream() async* {
  for (int i = 0; i < 5; i++) {
    await Future.delayed(Duration(seconds: 1));
    yield i;
  }
}

Using it in a StreamBuilder:

StreamBuilder<int>(
  stream: counterStream(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) return CircularProgressIndicator();
    return Text('Counter: ${snapshot.data}');
  },
)

Good use cases for Stream:

Listening to Firebase/FireStore changes
Real-time chat messages
GPS or sensor updates
Bluetooth data streams
Internet connectivity updates

Common Mistakes to Avoid

Using FutureBuilder for continuous data
Using FutureBuilder with something that emits data repeatedly (like Firebase or a location stream) is a bad idea. FutureBuilder runs once and won’t update when new data comes.

Use StreamBuilder for such cases.

Forgetting to cancel a stream subscription
If you manually use listen() on a stream, don’t forget to cancel it in dispose():

late StreamSubscription subscription;

@override
void initState() {
  subscription = someStream.listen((event) {
    // handle event
  });
  super.initState();
}

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

Using Stream.fromFuture() without reason
This is unnecessary unless you’re working with an API that only takes a stream. Don’t turn a Future into a Stream unless the use case requires it.

Real-World Use Cases (In Words)

User login: Use Future — it’s a one-time action that returns a result.
Firebase Firestore updates: Use Stream — documents can change any time.
Location tracking: Use Stream — location changes over time.
Get device info or permissions: Use Future.
Live sensor data from a fitness app: Use Stream.

Advanced Tips

Creating your own Stream

Stream<int> generateStream() async* {
  yield 1;
  await Future.delayed(Duration(seconds: 1));
  yield 2;
}

Combine multiple streams using RxDart:

Rx.combineLatest2(stream1, stream2, (a, b) => '$a & $b');

Convert stream to future if you only need the first value:

final result = await myStream.first;

Best Practices

Use FutureBuilder for short, one-time data needs.
Use StreamBuilder for long running or changing data.
Always dispose of stream subscriptions if you manually listen to them.
Avoid Stream.periodic() unless absolutely needed.
For complex use cases, use rxdart for reactive patterns like debouncing, combining streams, etc.

Conclusion

Choosing between Future and Stream is not just about personal preference it’s about picking the right tool for the job.

Use Future for short, one-time tasks.
Use Stream when data changes over time.

Mastering this will help you write faster, cleaner, and more reactive Flutter apps and avoid many hidden bugs in your UI or business logic.

I Trusted Dart’s Null Safety… and It Still Crashed My App

Md. Al-Amin — Wed, 16 Jul 2025 08:42:56 +0000

It was a chill Thursday night. I was working on a profile update feature for one of my Flutter apps. I had just refactored a bunch of code and felt pretty confident.

After all, Dart has null safety now what could go wrong?

The app launched, everything looked good. But then… Crash.
Not a red screen. Not a console warning. A full-on, “Unhandled exception: Null check operator used on a null value.”

I was confused.

“Wait, I’m using null safety. Isn’t this stuff supposed to be impossible now?”

I had sprinkled a few ! operators here and there (you know, just to keep the compiler happy). But that one exclamation mark brought the whole thing down.

That was my wake-up call.

And that night, I went deep into understanding Dart’s null safety. In this post, I’ll share:

What I did wrong
How Dart null safety really works
What tools Dart gives you (?, !, late, required)
Best practices to keep your app safe, clean, and crash-free

What Is Null Safety, Really?

Null safety in Dart means you have to explicitly declare when a variable can be null.

Before null safety, any variable could potentially be null, leading to tons of runtime crashes.

Now, you write:

String name = 'Md. Al-Amin'; // non-nullable
String? nickname;            // nullable

Dart forces you to think about nulls. It doesn’t let you do:

print(nickname.length); // ❌ compile error

You need to check if it’s null:

if (nickname != null) {
  print(nickname.length);
}

Or use ! to say “I promise this isn’t null” (but use it carefully… more on that soon).

What I Did Wrong: The Dangerous `!` Operator

Back to my bug…

I had this code:

String? userToken;

// later...
apiClient.setToken(userToken!);

In my head, I was sure userToken was initialized before calling setToken. But in reality, it wasn’t.

That ! is called the null assertion operator, and it basically says:

“Trust me, this is not null don’t check, just run.”

But Dart doesn’t protect you here. If userToken is null, you crash.
And that’s exactly what happened.

Let’s Break Down the Null Safety Tools

? → Nullable Variable

String? email;

This means email can be either a String or null.

Use ? when:

You’re receiving data from external sources (APIs, storage, etc.)
A variable truly might not be set (optional fields)

! → Null Assertion

String? email;
print(email!); // You better be 100% sure it's not null

Use this only when you’re absolutely certain a value can never be null at that point.

When it’s okay:

if (email != null) {
  print(email!); // you're safe here
}

When it’s dangerous:

print(email!.length); // if email is null = crash!

Tip: Avoid using ! unless you’ve done a prior null check.

late → Delayed Initialization

What if a variable can’t be set immediately, but you’re sure it’ll be set before use?

late String token;

void init() {
  token = fetchToken();
}

void makeRequest() {
  print(token); // Dart assumes it's set before use
}

If you forget to assign it before access Dart throws an error at runtime.

Use late when:

You want to avoid null, but initialize later (e.g., in initState)
You’re working with dependency injection

Don’t use it as a lazy shortcut for avoiding ? or !.

required → Non-nullable named parameters

Before null safety:

void createUser(String name, String email);

After null safety:

void createUser({required String name, required String email});

If the caller doesn’t pass name or email, Dart throws a compile-time error.

Use required for:

Named parameters that are essential
Enforcing contracts in your API or widget constructors

Real-World Use Case: User Profile Model

Let’s look at a simple User model that could crash if nulls aren’t handled well:

class User {
  final String name;
  final String? email;
  final String? phone;

  User({
    required this.name,
    this.email,
    this.phone,
  });
}

Now, when rendering UI:

Text(user.email ?? 'No email available'),

That’s safe. No ! needed. No risk of crash.

Best Practices for Null Safety in Dart

Here’s what I learned and now live by:

Do This

Use ? when data may be null
Use required for essential fields
Check nulls before using values
Use defaults like ??
Write unit tests for null cases

Avoid This

Making everything late to avoid ?
Forcing values with ! everywhere
Trusting external data blindly
Assuming things are initialized
Ignoring edge cases in models

Extra Tip: Null-Aware Operators in Dart

Dart gives you some powerful operators:

?? → Default value if null

print(user.email ?? 'No email');

??= → Assign default if null

email ??= 'unknown@example.com';

?. → Safe access

print(user.profile?.bio); // If profile is null, won’t crash

Final Thoughts

Dart’s null safety is amazing, but it only works if we understand how to use it.

Null safety doesn’t mean “no more crashes.”
It means: “You now have the power to prevent them, but you have to think.”

My Advice to You

Avoid the ! unless you’re absolutely sure
Use ? and null-aware operators liberally they’re your friends
Don’t go overboard with late — it’s powerful, but sharp
And always, always test your edge cases

If Dart asks you to handle nulls, it’s not being annoying its saving future you from a nightmare.

I’d love to hear from you:

Have you ever been betrayed by a !? Or misused late and got runtime surprises?
Share your experience and let’s help each other write safer Dart code.

Stop the Confusion: Flutter State Management Explained

Md. Al-Amin — Tue, 15 Jul 2025 16:44:29 +0000

Let’s be honest for a sec…

“Should I use setState, or Provider, or Riverpod?
I heard Bloc is better for large apps, but isn’t it too much for small ones?
Oh wait, now everyone’s talking about Signals...”

If that sounds familiar, you’re not alone.
State management in Flutter is one of the most debated and misunderstood topics in the community.

But here’s the truth:

You don’t need to learn all the state management libraries.
You just need to understand when and why to use each based on your app’s complexity.

In this post, we’ll walk through:

What state management actually means in Flutter
Real-world examples (small to large app scenarios)
A friendly comparison of setState, Provider, Bloc, Riverpod
The cost of choosing the wrong tool
My personal journey and what I recommend today

Let’s make state management make sense.

What Is State Management, Really?

Before we dive into tools, let’s clear this up.

“State” = any piece of data that affects your UI.

This can be:

A counter value (int count)
User login status (bool isLoggedIn)
A fetched list of posts (List<Post>)
A form input (String email)

Whenever that data changes, the UI needs to update to reflect the new state.

So:

State management = keeping track of changes + rebuilding the right parts of the UI.

Sounds simple… until your app has 15 screens, 3 types of state, and 2 developers fighting over where the logic should live.

Real-World Analogy: Managing State = Managing Conversations

Imagine you’re at a party with a few friends. One person says something, and a few others react.

If only 2 people are talking, it’s easy to manage.

But if everyone’s shouting across the room things get chaotic.
That’s what happens when your app grows without proper state separation.

State management helps you:

Decide who owns the state
Control who should rebuild when it changes
Keep everything o*rganized and predictable*

Scenario 1: The Simple App (Counter, Toggle, Form)

Let’s say you’re building a simple counter or toggle switch. One widget, one screen.

Here’s what works beautifully:

class MyCounter extends StatefulWidget {
  @override
  State<MyCounter> createState() => _MyCounterState();
}

class _MyCounterState extends State<MyCounter> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Count: $count'),
        ElevatedButton(
          onPressed: () => setState(() => count++),
          child: Text('Increment'),
        ),
      ],
    );
  }
}

Use setState when:

Your state is local to one widget
Your app is simple
No business logic, no shared state

setState is not evil it's fast and perfect for UI-local state.

Scenario 2: Medium App (Login Flow, Theme Toggle, Auth State)

Now your app has 3–5 screens. You need to:

Keep track of whether the user is logged in
Show a different home screen if not
Share data across screens (e.g., user info, theme mode)

This is where setState breaks down it doesn’t persist across screens, and passing state through constructors becomes messy.

Use Provider when:

You need to share state across multiple widgets or screens
You want separation of concerns (UI ≠ business logic)
You still want things to feel Flutter-native

Example:

class AuthProvider with ChangeNotifier {
  bool isLoggedIn = false;

  void login() {
    isLoggedIn = true;
    notifyListeners();
  }
}

Then in UI:

final auth = Provider.of<AuthProvider>(context);
auth.login();

Works well with small to medium apps
Easy learning curve
Plays nicely with Consumer, Selector, and performance tools

Scenario 3: Large App (Chat App, eCommerce, Real-Time Data)

Let’s say:

You have 10+ screens
Multiple async calls
Business logic needs to be testable
You need to separate UI, UseCase, Repository, Data Source

Here’s where Bloc or Cubit shines.

With Bloc, you structure your app like a real system, with clear layers.

// Event
class LoadUserEvent extends UserEvent {}

// State
class UserLoaded extends UserState {
  final User user;
  UserLoaded(this.user);
}

// Bloc
class UserBloc extends Bloc<UserEvent, UserState> {
  final UserRepo repo;

  UserBloc(this.repo) : super(UserInitial()) {
    on<LoadUserEvent>((event, emit) async {
      final user = await repo.getUser();
      emit(UserLoaded(user));
    });
  }
}

Use Bloc or Cubit when:

You want strict structure + testability
You’re working in a team
You need predictable, event-driven logic
You’re building apps with real business logic

Yes, it’s more boilerplate but in large apps, that structure is gold.

Scenario 4: Clean & Modern State (with Less Boilerplate)

Now say you love Provider’s simplicity but wish it had:

Better modularity
More control
Support for scoped overrides
Built-in testing features

Enter: Riverpod

Riverpod is like a modern evolution of Provider. It’s fully DI-friendly, testable, and stateless at its core.

final counterProvider = StateProvider<int>((ref) => 0);

ref.read(counterProvider.notifier).state++;

It works with hooks, async providers, FutureProvider, and integrates beautifully with Clean Architecture.

Use Riverpod when:

You want fine-grained control without the Bloc boilerplate
You prefer composition over inheritance
You like working declaratively and test-first

Comparison Table: Flutter State Management at a Glance

What Happens If You Pick the Wrong One?

Let’s be real:

Picking Bloc for a 2-screen app = frustration
Using setState in a real-time shopping app = chaos
Using Provider for deeply nested reactive logic = rebuild madness

That’s why choosing the right tool for the job is key. Don’t just follow trends understand your app’s needs.

My Journey (And What I Recommend)

When I started:

I used setState for everything.
Then I discovered Provider — and it changed my life.
On a large team project, we used Bloc, and it made the architecture scale.
Now, for personal and clean projects, I use Riverpod it’s declarative, scalable, and clean.

So, here’s my general recommendation:

Very Small (1–2 screens) - setState
Small to Medium - Provider or Riverpod
Large / Team Projects - Bloc or Riverpod
Apps with Clean Architecture - Riverpod + DI or Bloc + get_it

Final Thoughts

State management in Flutter isn’t about picking the “best” tool it’s about picking the right tool for your app’s complexity.

Start simple. Learn why things break. Then scale your tools as your app grows.

And remember:

Clean architecture isn’t about more code it’s about code that makes sense later.

I’d Love to Hear From You

What’s your go-to state management solution?
Have you had pain points switching from one to another?
Want me to break down Riverpod or Bloc in the next post?

Let’s keep learning and keep Flutter clean.

Why Clean Flutter Apps Use Dependency Injection and Yours Should Too

Md. Al-Amin — Mon, 14 Jul 2025 09:58:58 +0000

Have you ever written a widget that somehow ended up knowing about your database, API client, local storage, and maybe even Firebase auth?

Be honest we’ve all been there.

At first, everything works fine. You call a service from your UI, get the result, display it. But a few weeks later…

Your widget’s build() method is 100+ lines
Your HomeScreen knows about every feature in the app
Writing a test requires bootstrapping your entire app

Welcome to tight coupling hell.

The good news? There’s a simple fix it’s called Dependency Injection (DI). And in this post, I’m going to show you why it matters, how it works in Flutter, and how to start using it in your real apps.

Let’s go.

First, What the Heck Is Dependency Injection?

Think of it like this:

Instead of your class creating everything it needs, you just give it what it needs from the outside.

For example, if a class needs an ApiClient, you don’t create one inside it. You pass one in like a gift.

This makes the class:

Easier to test
Easier to replace
Easier to maintain

Let’s compare:

Without DI

class UserService {
  final _api = ApiClient(); // tightly coupled

  Future<User> getUser() async => _api.fetchUser();
}

Now UserService is stuck with ApiClient. You can’t test it with mock data, and swapping out the API layer will break your app.

With DI

class UserService {
  final ApiClient api;

  UserService(this.api);

  Future<User> getUser() async => api.fetchUser();
}

Now you can inject any version of ApiClient a mock, a test version, or a real one and UserService won’t care. That’s the beauty of DI.

Why Should You Care?

Let me show you 3 reasons you’ll thank yourself later:

Your Code Becomes Modular

When each class receives its dependencies, you can change one thing without touching everything.

Imagine replacing Firebase Auth with Supabase. If you injected your AuthService, the change is painless. If not… you’re in for a lot of refactoring.

You Can Actually Write Unit Tests

With DI, testing becomes clean and easy:

final userService = UserService(MockApiClient());

No need to mock the entire app or spin up a widget. You test what matters and only that.

It Makes Clean Architecture Possible

If you want to follow clean architecture in Flutter (UI → Use Cases → Repositories → Data Sources), you need DI to keep layers separate.

Otherwise, your app becomes one big spaghetti plate where everything touches everything.

How to Do Dependency Injection in Flutter

Let’s talk tools.

You can do DI manually (by passing things into constructors), or use tools like:

get_it – Service locator (basic but powerful)
injectable – Code generator built on top of get_it
Riverpod – Great for DI + state management in one
provider – Can be used for simple DI too

In this blog, I’ll show you get_it + injectable the combo I personally use in most of my apps.

Real-World Example: User Profile Feature

Let’s say we’re building a user profile screen. Here’s the flow:

ProfileScreen → ProfileCubit → GetUserProfileUseCase → UserRepository → ApiClient

Our goal is:

The screen only knows about the Cubit
The Cubit only knows about the use case
Each layer is injected, not hardcoded

Step 1: Add Dependencies

In your pubspec.yaml:

dependencies:
  get_it: ^7.6.0
  injectable: ^2.3.0

dev_dependencies:
  build_runner: ^2.4.0
  injectable_generator: ^2.4.0

Step 2: Set Up the DI Container

Create a file: lib/di/injection.dart

import 'package:get_it/get_it.dart';
import 'package:injectable/injectable.dart';
import 'injection.config.dart'; // this will be generated

final getIt = GetIt.instance;

@InjectableInit()
Future<void> configureDependencies() async => getIt.init();

Then run:

flutter pub run build_runner build

Step 3: Annotate Classes

Let’s annotate our repository and services.

API Client

@lazySingleton
class ApiClient {
  Future<User> getUser() async {
    // Fetch user from API
  }
}

User Repository

abstract class UserRepository {
  Future<User> getProfile();
}

@LazySingleton(as: UserRepository)
class UserRepositoryImpl implements UserRepository {
  final ApiClient api;

  UserRepositoryImpl(this.api);

  @override
  Future<User> getProfile() => api.getUser();
}

Use Case

@injectable
class GetUserProfileUseCase {
  final UserRepository repo;

  GetUserProfileUseCase(this.repo);

  Future<User> call() => repo.getProfile();
}

Cubit

@injectable
class ProfileCubit extends Cubit<ProfileState> {
  final GetUserProfileUseCase getUser;

  ProfileCubit(this.getUser) : super(ProfileInitial());

  Future<void> loadProfile() async {
    final user = await getUser();
    emit(ProfileLoaded(user));
  }
}

Now, anywhere in your app, you can get your Cubit like this:

final cubit = getIt<ProfileCubit>();

Clean. Testable. Scalable.

Best Practices for DI in Flutter

Here are a few do’s and don’ts I’ve learned the hard way:

Do This

Use @LazySingleton for services
Use abstract interfaces
Mock dependencies in tests
Group dependencies in one place (like injection.dart)
Keep your layers decoupled

Don’t Do This

Create services directly in widgets
Hardcode concrete classes everywhere
Depend on real APIs during unit tests
Scatter initialization logic across files
Let UI talk directly to repositories or APIs

Quick Bonus: Mocking in Tests

Let’s say you want to test GetUserProfileUseCase.

class FakeRepo implements UserRepository {
  @override
  Future<User> getProfile() async => User(name: 'Fake User');
}

Then test it:

void main() {
  final useCase = GetUserProfileUseCase(FakeRepo());

  test('returns fake user', () async {
    final user = await useCase();
    expect(user.name, 'Fake User');
  });
}

No app. No UI. Just pure logic.

Wrap-Up: What You Learned

Dependency Injection decouples your code and keeps things clean
It’s the foundation of scalable, testable Flutter apps
Tools like get_it + injectable make DI simple and maintainable
You can follow clean architecture patterns without the pain

Final Thought

If your app is still wiring up dependencies manually in widgets it’s time to level up.

Start small. Use DI for one feature.
Once you see how clean and testable it becomes you won’t go back.

Why Your Flutter App Rebuilds Too Much — And How to Fix It

Md. Al-Amin — Sun, 13 Jul 2025 18:27:40 +0000

You press a button.
You change one value.
Suddenly your whole screen rebuilds even widgets that had nothing to do with the change.

You might be thinking:

“But I only called setState() once… what’s the problem?”

Flutter is fast but unnecessary widget rebuilds can ruin performance, cause visual flicker, battery drain, and even crash low-end devices.

In this post, we’re going deep into:

What actually causes rebuilds
Real-world examples of excessive rebuilds
Tools to detect them
And how to fix them the right way

If you want your Flutter app to feel smooth, battery-friendly, and production-grade this is for you.

How Flutter Really Rebuilds Widgets

Flutter’s UI is declarative.
That means you don’t manually change UI elements you describe what the UI should look like at any given state.

When state changes, Flutter rebuilds affected widgets.

But here’s the catch:

Flutter rebuilds from the top of the widget tree down unless you break it into smaller, optimized parts.

And sometimes, it rebuilds more than you expected.

Common Rebuild Triggers

Here are the most common ways widgets get rebuilt (sometimes unnecessarily):

setState() — Rebuilds the entire widget that called it
InheritedWidget (e.g. Theme, MediaQuery) — Rebuilds all widgets using it when it changes
Provider, Riverpod, Bloc — Depends on how you consume the state — poor use = unnecessary rebuilds
Parent widget rebuilds — All child widgets rebuild unless marked const or separated

Real-World Bug: App Feels Laggy on Every Tap

Let’s say you built a shopping cart screen:

class CartScreen extends StatefulWidget {
  @override
  _CartScreenState createState() => _CartScreenState();
}

class _CartScreenState extends State<CartScreen> {
  int quantity = 1;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Cart'),
        ElevatedButton(
          onPressed: () => setState(() => quantity++),
          child: Text('Add'),
        ),
        ProductImage(), // This shouldn't change
        Text('Quantity: $quantity'),
      ],
    );
  }
}

Problem:
When you press “Add”, setState triggers a rebuild of the entire CartScreen, including ProductImage() which is expensive to rebuild.

Solution:
Extract ProductImage into a StatelessWidget, outside the rebuild scope:

@override
Widget build(BuildContext context) {
  return Column(
    children: [
      Text('Cart'),
      ElevatedButton(
        onPressed: () => setState(() => quantity++),
        child: Text('Add'),
      ),
      const ProductImage(), // const prevents rebuild!
      Text('Quantity: $quantity'),
    ],
  );
}

How to Detect Rebuilds

Flutter gives you a few powerful ways to catch excessive rebuilding:

1. Use debugPrintRebuildDirtyWidgets = true;
Add this in main():

void main() {
  debugPrintRebuildDirtyWidgets = true;
  runApp(MyApp());
}

Now every widget rebuild will be printed in the debug console.

2. Wrap widgets in RepaintBoundary

RepaintBoundary(
  child: SomeExpensiveWidget(),
)

This separates the render pipeline Flutter won’t repaint this widget unless its own state changes.

3. Use Flutter DevTools
Go to Flutter DevTools > Performance > Rebuild Stats
You’ll see exactly which widgets rebuilt and how often.

This is gold when debugging complex UI behavior.

Case Study: Flutter App Lagging on List Scroll

A developer built a chat app. Each message item had:

Profile picture
Name
Last message
Timestamp
Online status

Whenever any new message arrived all messages were rebuilding. Why?

Problem:
They used a ListView.builder, but placed the entire message list inside a widget that updated when any message changed.

BlocBuilder<ChatCubit, ChatState>(
  builder: (context, state) {
    return ListView.builder(
      itemCount: state.messages.length,
      itemBuilder: (context, index) {
        return ChatTile(message: state.messages[index]);
      },
    );
  },
)

Every time the ChatCubit emitted a new message, the entire ListView rebuilt.

Fix:
Use ListView.separated or optimize rebuilds by checking which items actually changed, or use indexed rebuild logic (like flutter_bloc’s buildWhen).

Best Practices to Prevent Excessive Rebuilds

Extract widgets into small, reusable components
Use const constructors when possible
Use Selector or Consumer wisely in Provider
Use buildWhen / select to control rebuild triggers
Use RepaintBoundary for images, charts, maps

Don’t

Put all UI inside one giant build()
Forget to mark stateless widgets as const
Wrap entire widget trees in BlocBuilder
Allow every state change to rebuild the whole tree
Let heavy widgets redraw every frame

Quick Tips

Use const liberally especially for static widgets
Memorize data or cache widgets if they don’t change often
Use ValueNotifier and ValueListenableBuilder for simple UI state (faster than full state management for small tasks)
Profile with DevTools every time you add new UI logic

Summary: What You Learned

Flutter rebuilds widgets declaratively, but you control the scope
Rebuilding too much = lag, Jank, bad UX
Use tools like debugPrintRebuildDirtyWidgets, RepaintBoundary, and DevTools
Optimize using const, smaller widgets, and smart state consumption

Final Thought

Your Flutter app may “work,” but that doesn’t mean it’s efficient.
Understanding how and when widgets rebuild helps you write smoother, cleaner, production-ready code.

So next time you face a lag or Jank that doesn’t make sense check who’s rebuilding. It might just be that innocent widget you forgot to const.

Stop Using initState() Like That: Async, Await & Flutter’s Lifecycle Explained

Md. Al-Amin — Sat, 12 Jul 2025 15:00:43 +0000

Have you ever written an async function inside initState() to fetch data or show a loading indicator only to find your UI doesn’t update or crashes with a cryptic error?

You’re not alone. Almost every Flutter dev has been there.

The real issue?
You’re using initState() wrong and Dart’s event loop + widget lifecycle aren’t forgiving about it.

This blog will help you understand what’s really happening, teach you the right way to handle async logic in initState(), and walk through real-world examples and fixes.

Let’s fix that weird bug for good.

First, What Is `initState()` Really?

In Flutter, initState() is a lifecycle method that’s called once when your StatefulWidget is inserted into the widget tree.

It’s the perfect place to:

Initialize variables
Start animations
Setup controllers
Trigger data fetching

But here’s the catch:
It must remain synchronous.

You can’t mark initState() as async and if you try to await something inside it, you might get strange bugs like:

setState called after dispose
UI not rebuilding
App freezes or doesn’t respond

What Not to Do

Let’s say you want to fetch data when the screen opens:

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

  fetchData(); // async function
}

Future<void> fetchData() async {
  final data = await api.getData();
  setState(() {
    _data = data;
  });
}

Sounds reasonable, right? But here’s what could go wrong:

Your UI might rebuild before data is ready.
If the widget is disposed while the async call is still running, setState() throws an error.
A loading spinner might not even show until the data is fetched.

The Right Way: Use `addPostFrameCallback()`

To make sure your async code runs after the first build, use:

WidgetsBinding.instance.addPostFrameCallback((_) {
  fetchData();
});

Now your initState() stays sync, and your async logic starts after the widget is on-screen.

Example:

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

  WidgetsBinding.instance.addPostFrameCallback((_) {
    _loadInitialData();
  });
}

Future<void> _loadInitialData() async {
  setState(() => _isLoading = true);

  final result = await api.getData();

  if (!mounted) return; // avoid calling setState after dispose

  setState(() {
    _data = result;
    _isLoading = false;
  });
}

Real-World Case: Spinner Doesn’t Show

You write this:

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

Future<void> _loadData() async {
  setState(() => _loading = true);

  await Future.delayed(Duration(seconds: 2)); // simulate API call

  setState(() {
    _loading = false;
    _data = ['A', 'B', 'C'];
  });
}

But on running it, the spinner doesn’t show!
Why? Because the UI hasn’t had time to build before the async work blocks it.

Fix: Let the UI build first

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

  WidgetsBinding.instance.addPostFrameCallback((_) {
    _loadData();
  });
}

Now your loading indicator appears immediately, and the UI updates smoothly.

Best Practices for `initState()` and Async

Keep initState() synchronous
Use addPostFrameCallback to trigger async task
Check mounted before calling setState() after async
Show loading indicators clearly

Don’t

Mark initState() as async
Call await directly in initState()
Assume your widget is always alive
Run long tasks before first build

Bonus Tip: Use `FutureBuilder` for Stateless Data Loading

If you’re just fetching something once and don’t need full-blown state management, FutureBuilder might be simpler:

FutureBuilder<List<String>>(
  future: api.getItems(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) return CircularProgressIndicator();
    return ListView(
      children: snapshot.data!.map(Text.new).toList(),
    );
  },
)

But be cautious FutureBuilder runs the future every time the widget rebuilds unless cached.

Summary: What You Learned

initState() runs before your widget is on screen don’t block it
Async code should be scheduled using addPostFrameCallback or similar techniques
Always check mounted before calling setState() after await
Flutter lifecycle + Dart’s event loop = weird bugs unless handled correctly

Final Thoughts

Understanding initState() and how async fits into the Flutter lifecycle is a game-changer. It prevents flaky UI, unexpected errors, and improves performance.

Next time your spinner doesn’t spin, or your UI feels stuck now you know where to look.

More Blogs Like This

If you liked this one, check out my last post: Understanding Dart’s Event Loop: Why Your Async Code Acts Weird

Understanding Dart’s Event Loop: Why Your Async Code Acts Weird

Md. Al-Amin — Fri, 11 Jul 2025 11:19:54 +0000

Have you ever written asynchronous code in Flutter or Dart, and something just didn’t behave the way you expected?

Maybe you scheduled a Future, but it didn’t run immediately.
Maybe your setState() inside a Future.delayed() broke the UI.
Maybe you used await, but things still executed out of order.

If that sounds familiar welcome to the world of Dart’s Event Loop.

In this article, we’ll dive deep into how Dart’s asynchronous engine works not just to fix bugs, but to reason like the Dart runtime itself.

What is an Event Loop?

The Event Loop is the core of Dart’s asynchronous execution model. It powers:

Futures
async / await
UI updates
Timers and animations

When you write Dart code, it’s executed on a single thread, which means asynchronous code must be carefully scheduled and executed without blocking.

So how does Dart handle this?
Using two queues:

Dart has TWO types of queues:

Microtask Queue: High priority, runs before any event tasks.
Event Queue (aka Event Loop): Regular events like I/O, timer callbacks.

Execution Order: Microtasks vs Event Tasks

Here’s the general order of execution in Dart:

Run the current synchronous code
Run all microtasks (until the microtask queue is empty)
Run one event task
Repeat steps 2–3

Let’s make it visual 👇

import "dart:async";

void main() {
  print('1');

  scheduleMicrotask(() => print('2'));
  Future(() => print('3'));
  Future.delayed(Duration.zero, () => print('4'));
  Future(() async {
    print('5');
    await Future.delayed(Duration.zero);
    print('6');
  });
  scheduleMicrotask(() => print('7'));

  print('8');
}

What gets printed?

Let’s break it down:

print('1'): sync -> Immediately
scheduleMicrotask(...): Microtask -> After sync
Future(...): Event queue -> Later
Future.delayed: Event queue -> Later
await Future.delayed(...): Event queue → Suspends, resumes as microtask
print('8'): Sync -> Immediately

So, microtasks always run before event queue tasks and that causes most unexpected behavior in Flutter apps.

Real-World Flutter Problem

Problem: UI Not Updating After await

void _onPressed() async {
  setState(() {
    _loading = true;
  });
  await Future.delayed(Duration(seconds: 2));
  setState(() {
    _loading = false;
  });
}

You click a button. The spinner is supposed to show, wait 2 seconds, then disappear.

But… the UI doesn’t show the spinner during the delay.

Fix: Yield control using Future.delayed(Duration.zero)

void _onPressed() async {
  setState(() => _loading = true);

  await Future.delayed(Duration.zero); // give time for rebuild
  await Future.delayed(Duration(seconds: 2));

  setState(() => _loading = false);
}

Why does this work?
Because Future.delayed(Duration.zero) moves the execution into the event queue, giving Flutter time to rebuild the UI before the delay.

How Dart Awaits Work (Under the Hood)

When you await a Future, Dart:

Registers a callback
Returns control to the event loop
When the Future completes, schedules that callback as a microtask

So, in an async function, everything after await is treated like a microtask.

Use Case: Background Sync in a Flutter App

Imagine you’re building a task manager app. After opening the home screen, it fetches user tasks from local storage, then syncs with the server:

void initState() {
  super.initState();
  _loadTasks();
}

void _loadTasks() async {
  final local = await storage.getTasks();
  setState(() => _tasks = local);

  final updated = await api.syncTasks(local);
  setState(() => _tasks = updated);
}

This seems fine… but users report UI Jank during startup.

Optimized Approach

void initState() {
  super.initState();

  // Let UI load first
  WidgetsBinding.instance.addPostFrameCallback((_) => _loadTasks());
}

void _loadTasks() async {
  final local = await storage.getTasks();
  setState(() => _tasks = local);

  // Let microtasks/UI catch up
  await Future.delayed(Duration.zero);

  final updated = await api.syncTasks(local);
  setState(() => _tasks = updated);
}

addPostFrameCallback: Defers work until after first frame
Future.delayed(Duration.zero): Gives the UI time to breathe

This respects Dart’s event loop while improving perceived performance.

Best Practices for Dart’s Event Loop

Use Future.delayed(Duration.zero) to yield control
Schedule background work after first frame using addPostFrameCallback
Use scheduleMicrotask for priority work (rare)
Profile UI Jank with DevTools

Avoid

Heavy sync logic in UI methods
Calling async code in initState() without care
Misusing await assuming it instantly pauses execution
Ignoring long frame times during async ops

Conclusion

Dart’s event loop isn’t just an engine detail it shapes how your code behaves. Understanding it helps:

Write smoother UI updates
Debug async bugs
Build better architecture for real-world apps

The next time you await doesn’t feel like it’s waiting, or your setState() doesn’t fire as expected check the queues. It’s probably a microtask thing.

Bonus Tip: Want to Explore Live?

Paste this code into DartPad and tweak the order of Future, scheduleMicrotask, and print statements to see the event loop in action.

I Thought This Was Private… Again! But Freezed Had a Different Story

Md. Al-Amin — Wed, 02 Jul 2025 12:52:51 +0000

It was 10:30 PM on a typical night. Instead of winding down, I was tuned into a bi-weekly Flutter session hosted by the Flutter Bangladesh Group, led by none other than Momshad Dinury bhai, the group’s admin and a Senior Software Engineer at Brain Station 23.

That night’s topic?
Freezed package’s latest major update and the breaking changes it introduced.

Honestly, I was there out of curiosity. I’ve used freezed in several projects, and I love how it handles immutability, union types, and copyWith. But that night, I stumbled onto something I didn’t expect… again.

Freezed’s Major Update: What Changed?

Momshad bhai shared that freezed now requires a keyword like sealed or abstract when defining classes using the factory constructor.

Here’s the change:

@freezed
-class Person with _$Person {
+abstract class Person with _$Person {
  const factory Person({
    required String firstName,
    required String lastName,
    required int age,
  }) = _Person;

  factory Person.fromJson(Map<String, Object?> json)
      => _$PersonFromJson(json);
}

Or for union types:

@freezed
-class Model with _$Model {
+sealed class Model with _$Model {
  factory Model.first(String a) = First;
  factory Model.second(int b, bool c) = Second;
}

This migration was required because of changes in Dart itself. But as I followed the example, something caught my attention:

@freezed
abstract class Person with _$Person {
  const factory Person({
    required String firstName,
    required String lastName,
    required int age,
  }) = _Person;

  factory Person.fromJson(Map<String, Object?> json) => _$PersonFromJson(json);
}

Wait… _Person and _$PersonFromJson?

They start with an underscore aren’t those private?
Yet, they’re accessible right here in the same file.

My mind instantly went back to something I had written not long ago: I Thought This Was Private… Until Dart Surprised Me

Dart Privacy Refresher: Underscore Isn’t File-Private

If you’ve used Dart for a while, you know that prefixing a class or variable with _ makes it private.

But what kind of private?

Here’s the twist: Dart’s privacy is scoped to the library, not the file.

That means as long as your files are part of the same library, they can share each other’s private members.

Enter `part` and `part of`: The Glue Behind Code Generation

Here’s how this works behind the scenes:

In your Dart file (person.dart), you’ll see:

part 'person.freezed.dart';
part 'person.g.dart';

Inside those generated files (like person.freezed.dart), you’ll find:

part of 'person.dart';

This tells Dart: “Hey, all these files are part of the same library.”
So suddenly, _Person and _$PersonFromJson, even though private by naming convention, are accessible.

Mind = Blown

What Are `_$Person` and `_Person` Anyway?

Here’s the breakdown of what freezed generates:

_$Person: A mixin or helper generated by freezed, giving you the .copyWith(), .toString(), .hashCode, etc.
_Person: The actual implementation class behind your factory constructor.
_$PersonFromJson(): A function created by json_serializable to handle deserialization.

All of this becomes possible due to part and part of.

New Dart Feature: Pattern Matching

One more thing I learned from that session: freezed no longer generates map() or when() methods for pattern matching.

Now, you’re expected to use Dart’s native pattern matching syntax. For example:

final model = Model.first('42');

final result = switch (model) {
  First(:final a) => 'first $a',
  Second(:final b, :final c) => 'second $b $c',
};

No more model.map() magic. This aligns better with modern Dart, but it also means we must adjust our habits.

But why `abstract` or `sealed` Now?

This was a change enforced by Dart itself.

When using factory constructors, Dart now expects you to mark the class as either:

abstract: Meaning it cannot be instantiated directly.
sealed: Meaning it can only be subclassed within the same file great for union types and pattern matching.

So, this change is less about freezed itself and more about keeping up with Dart’s stricter and cleaner type system.

Key Takeaways

Here’s what I walked away with from a 10:30 PM session that was supposed to be “just another meetup”:

Dart’s privacy is library-scoped, not file-scoped.
part and part of allow generated code to access and expose private classes across files.
freezed’s latest update aligns with modern Dart features like sealed, abstract, and native pattern matching.
Code generation feels magical but understanding the “why” behind the magic makes you a better dev.

Final Thoughts

It’s wild how small moments like a late-night tech session can lead to big learning.

What looked like an accessibility bug (_Person, _$Person) was actually a deep Dart feature.
And what felt like a confusing migration (sealed, abstract) was Dart evolving into a cleaner, more expressive language.

Big thanks to Momshad Dinury bhai and the Flutter Bangladesh Group for organizing these sessions.

They don’t just teach you tools they lead you into deeper understanding.

If you liked this, you might also enjoy my earlier post: I Thought This Was Private… Until Dart Surprised Me

Was this helpful? Drop a comment or share your own “Dart surprise” moment I’d love to hear it.
Happy Fluttering!

DEV Community: Md. Al-Amin

DDD (Domain-Driven Design) in Flutter: Too Much or Just Right?

What is Domain-Driven Design (DDD)?

The Problem DDD Solves in Flutter

Is DDD Overkill for Flutter?

When DDD Makes Sense:

When It Might Be Too Much:

What DDD Looks Like in Flutter

Real-World Example

Best Practices for Using DDD in Flutter

Final Thoughts

How to Structure a Plugin-Friendly Flutter App

Why Care About Plugin-Friendly Structure?

Core Principles of Plugin-Friendly Architecture

Recommended Folder Structure

Tools & Techniques to Use

Use package:injectable + get_it for DI

Leverage Dart’s export Keyword

Use Platform Channels Smartly

Converting a Feature into a Plugin

Step 1: Extract the Feature

Step 2: Expose a Clean API

Step 3: Add to App as Dependency

Real-World Example

Best Practices Recap

Final Thoughts

What’s Next?

Scaling Flutter Apps with Feature-First Folder Structures

The Problem with Layer-Based Structure

The Feature-First Approach: Why It Works

Benefits at Scale

1. Isolation of Features

2. Improved Code Navigation

3. Clean Onboarding

4. Fewer Regressions

Best Practices for Feature-First Projects

1. Use Clear Naming

2. Leverage Dependency Injection

3. Modularize Your Features

4. Extract Shared Logic to core/

Real-World Example: eCommerce App

When Not to Use Feature-First?

Final Thoughts

Want to Go Deeper?

Effective Layered Architecture in Large Flutter Apps

What is Layered Architecture?

Why Layered Architecture Matters in Large Apps

Breaking Down the Layers (With Dart Examples)

1. Presentation Layer

2. Application Layer (Use Cases)

3. Domain Layer

4. Data Layer

Tools to Support Layered Architecture

Real-World Folder Structure

Best Practices

Real-World Use Case: E-Commerce App

Common Pitfalls to Avoid

Final Thoughts

Stream vs Future in Dart: Stop Using the Wrong One

What’s the Difference?

Future Example

Stream Example

Common Mistakes to Avoid

Real-World Use Cases (In Words)

Advanced Tips

Best Practices

Conclusion

I Trusted Dart’s Null Safety… and It Still Crashed My App

What Is Null Safety, Really?

What I Did Wrong: The Dangerous ! Operator

Let’s Break Down the Null Safety Tools

Real-World Use Case: User Profile Model

Best Practices for Null Safety in Dart

Extra Tip: Null-Aware Operators in Dart

Final Thoughts

My Advice to You

I’d love to hear from you:

Stop the Confusion: Flutter State Management Explained

What Is State Management, Really?

Real-World Analogy: Managing State = Managing Conversations

Use `package:injectable` + `get_it` for DI

Leverage Dart’s `export` Keyword

4. Extract Shared Logic to `core/`

What I Did Wrong: The Dangerous `!` Operator

First, What Is `initState()` Really?

The Right Way: Use `addPostFrameCallback()`

Best Practices for `initState()` and Async

Bonus Tip: Use `FutureBuilder` for Stateless Data Loading

Enter `part` and `part of`: The Glue Behind Code Generation

What Are `_$Person` and `_Person` Anyway?

But why `abstract` or `sealed` Now?