Coder Legion - Recent posts tagged flutterdev

Automate Unused Asset Cleanup in Flutter

Thu, 03 Sep 2026 09:23:34 +0000

Let's be realistic, every Flutter project accumulates dead weight over time, big images not deleted, a logo variant from a rebrand, a placeholder image a dev forgot to delete.
Individually they're small but they add up to real APK/IPA size.

I built cleanbev to fix that locally, and I now a new upgrade is available a GitHub Action so the check runs automatically on every pull request, instead of running it localy.

What cleanbev actually does

cleanbev is a command-line tool for Dart and Flutter projects. It:

Reads your pubspec.yaml to find every declared asset
Scans your Dart code for references to each one
Reports anything declared but never referenced
Optionally deletes what you confirm

Locally, it's interactive:

dart pub global activate cleanbev
dart pub global run cleanbev --assets-path assets/images

✓ Asset assets/images/logo_white_bg.png is not used in the project. Do you want to delete it? · no
Asset assets/images/logo_white_bg.png has not been deleted.

✓ Asset assets/images/download_image-car.jpeg is not used in the project. Do you want to delete it? · yes
Asset assets/images/download_image-car.jpeg has been deleted.

It's also available as an MCP server, so editor-integrated agents (VS Code, Cursor, Visual Studio) can call it directly while you're working.

The gap: someone could forgot to cleanup some assets before pushing

A local CLI tool only helps if someone remembers to run it but in practice, unused-asset cleanup falls into the same bucket as "update the changelog" or "check for outdated dependencies" but under
deadline pressure this could be skipped.
The only way it reliably happens is if CI enforces it.

That's what the new Cleanbev Asset Check action does.

Using it

Add this into any Flutter repo's .github/workflows/:

name: Check Unused Assets

on:
  pull_request:
    branches: ["main"]

jobs:
  cleanbev-asset-check:
    name: Cleanbev Asset Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Cleanbev
        uses: koukibadr/cleanbev-action@v1
        with:
          assets-path: "assets"
          blocking: "true"

Inputs

Input	Description	Default
`assets-path`	Path to the assets directory to scan	`assets`
`blocking`	Fail the job when unused assets are found	`false`

Two ways to run it

blocking: "false" (default) — reports what it finds, cleans it up, never fails the build. Good for a low-friction "just keep things tidy" job on a schedule or on pushes to main.
blocking: "true" — turns it into a real PR gate. If a PR introduces an asset that's never referenced, the check fails until it's cleaned up or actually used. This is what I run on pull requests.

Try it

Action: github.com/marketplace/actions/cleanbev-asset-check
CLI on pub.dev: pub.dev/packages/cleanbev
MCP server on PyPI: pypi.org/project/cleanbev-mcp

It's a small tool solving a small, annoying problem. If you try it on a real project and hit a bug please send me your issues and PRs.

flutter_skin — Live Remote Skin Engine Demo | Change Flutter Colors Without Rebu

Mon, 06 Jul 2026 06:20:40 +0000

Live Remote Skin Engine Demo | Change Flutter Colors Without Rebuilding.
This is the first demo of flutter_skin — a remote skin engine
for Flutter I've been building for the past few months.

This is the alpha. Color tokens only for now. Typography,
spacing, border radii, and A/B testing are coming.

Built by Badr Kouki
Flutter contributor | pub.dev publisher

Fskin alpha version is Live

Thu, 25 Jun 2026 08:39:15 +0000

Every Flutter dev has been here.
Design changed the primary color.
You open the codebase.
You update the hex.
You build.
You submit.
You wait. a full day for a color.

There’s a better solution now: Fskin

I built flutter_skin. Publish from a dashboard and the App updates on realtime No build. No review. No restart.

Alpha is live today.

Eunify: Cross-Platform Continuity System for Android and MacOS

Sun, 17 May 2026 22:12:01 +0000

I Was Just Solving a Problem that I Face as an Android Phone User
Working With MacOS. I Am Sure There's Someone Else Out There With
Similar Challenges

I developed Eunify, a continuity platform engineered to create a seamless, native-feeling ecosystem between macOS and Android. By bridging these two distinct operating systems, Eunify eliminates workflow friction and ensures uninterrupted cross-device synchronization for productivity and communication.

Core Features

Universal Clipboard: Instantly synchronize your clipboard across operating systems. Text or media copied on your macOS machine is immediately available to paste on your Android device.

Fluid Browser Handoff: Maintain uninterrupted browsing sessions across devices. You can drag and drop an active tab into Eunify on macOS to instantly launch it on your Android device, or push a tab from Android to pop up seamlessly on your Mac.

Bidirectional File Transfer: Securely and rapidly send files directly back and forth between your macOS and Android devices without relying on external cloud services.

Biometric Authentication Integration: Enhance your security workflow by leveraging your Android device's native biometric sensors to unlock your macOS laptop.

Video Call Continuity: Effortlessly hand off active video calls from your macOS machine to your Android device, allowing you to transition from your desk to mobile without dropping the connection.

The Coordinated BLoC Pattern in Flutter — A Practical Guide

Sat, 09 May 2026 08:12:03 +0000

The Coordinated BLoC Pattern in Flutter — A Practical Guide

This post is based on real production code. Every mistake documented here was hit in the wild, debugged, and understood the hard way.

At first, coordinating multiple BLoCs from initState feels harmless.

Then the screen grows.

Now:

some data depends on the authenticated user
some sections support silent refresh
some should show loading spinners
some should skip fetching if cached
pull-to-refresh has different behaviour than initial load

And suddenly your screen becomes the orchestration layer for half the app.

This article covers a pattern for extracting that orchestration into its own BLoC: the Coordination BLoC pattern.

More importantly, it covers the production mistakes this pattern introduces — especially the ones that fail silently.

What Problem Does This Solve?

Imagine a home screen that needs data from three different sources:

meditation groups
saadhna progress
user favourites

Each has its own BLoC.
Each BLoC is independent.
But they all need to be triggered together after the user's profile loads.

You also want smart refresh behaviour:

if data is fresh → silently refresh in background
if data is missing → show loading state
pull-to-refresh should force reload everything

Naively, you handle all of this inside initState:

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

  final profileState = context.read<ProfileBloc>().state;

  if (profileState is ProfileLoaded) {
    context.read<HomeMeditationGroupsBloc>()
        .add(FetchHomeMeditationGroups());

    context.read<SaadhnaBloc>()
        .add(FetchAllSaadhnaGroups());

    context.read<UserFavouritesBloc>()
        .add(FetchUserFavouriteMeditations(profileState.id));
  }
}

At first this works fine.

Then more conditions appear:

freshness checks
silent refreshes
auth dependencies
feature flags
retry behaviour
analytics
cross-bloc coordination

And now your screen knows too much about how loading works.

The Coordination BLoC pattern extracts orchestration logic into its own BLoC.

The screen fires one high-level event.
The coordination bloc decides what happens.

Mental Model

The coordination bloc owns:

when things load
why they load
which events should fire

The feature blocs still own:

data
business logic
rendering state

The coordination bloc orchestrates.
It does not aggregate UI state.

Architecture

                    ProfileBloc
                         │
                         ▼
             HomeCoordinationBloc
                         │
      ┌──────────────────┼──────────────────┐
      ▼                  ▼                  ▼
HomeMeditationBloc   SaadhnaBloc   UserFavouritesBloc

The coordination bloc becomes the single orchestration point for screen-level loading behaviour.

The screen no longer knows:

which blocs exist
which events they need
which dependencies they have
which refresh strategy they use

Implementation

1. Events

Keep events coarse-grained and intent-based.

sealed class HomeCoordinatorEvent {}

class HomeDataFetch extends HomeCoordinatorEvent {}

class HomeDataRefresh extends HomeCoordinatorEvent {}

Event Intent

Event	Meaning
`HomeDataFetch`	Smart load with freshness checks
`HomeDataRefresh`	Force reload everything

2. States

The coordination bloc does not own feature data.

Its responsibility is orchestration, not aggregation.

sealed class HomeCoordinatorState {}

class HomeCoordinatorInitialState
    extends HomeCoordinatorState {}

The UI still reads directly from feature blocs:

BlocBuilder<HomeMeditationGroupsBloc,
    HomeMeditationGroupsState>(
  builder: (context, state) {
    // render UI
  },
)

This separation is important.

The coordination bloc coordinates behaviour.
The feature blocs remain the source of truth.

3. The Coordination BLoC

The key idea

The screen fires one event:

HomeDataFetch()

The coordination bloc decides:

which blocs should refresh
whether data is stale
whether loading should be silent
whether user context is required

class HomeCoordinationBloc
    extends Bloc<HomeCoordinatorEvent,
        HomeCoordinatorState> {

  final HomeMeditationGroupsBloc
      homeMeditationGroupsBloc;

  final SaadhnaBloc saadhnaBloc;

  final UserFavouritesBloc
      userFavouritesBloc;

  final ProfileBloc profileBloc;

  late StreamSubscription profileSubscription;

  HomeCoordinationBloc({
    required this.homeMeditationGroupsBloc,
    required this.saadhnaBloc,
    required this.userFavouritesBloc,
    required this.profileBloc,
  }) : super(HomeCoordinatorInitialState()) {

    // Register handlers FIRST
    on<HomeDataFetch>(_fetchData);
    on<HomeDataRefresh>(_refetchData);

    // Trigger immediately if already loaded
    if (profileBloc.state is ProfileLoaded) {
      add(HomeDataFetch());
    }

    // Otherwise wait for profile load
    profileSubscription = profileBloc.stream
        .where((state) => state is ProfileLoaded)
        .take(1)
        .listen((_) {
          add(HomeDataFetch());
        });
  }

  void _fetchData(
    HomeDataFetch event,
    Emitter emit,
  ) {
    final userId =
        (profileBloc.state as ProfileLoaded).id;

    final isMeditationFresh =
        homeMeditationGroupsBloc.state
            is HomeMeditationGroupsFetched;

    final isSaadhnaFresh =
        saadhnaBloc.state
            is SaadhnaGroupsFetched;

    final isFavFresh =
        userFavouritesBloc.state
            is UserFavouritesFetched;

    homeMeditationGroupsBloc.add(
      isMeditationFresh
          ? SilentRefreshHomeMeditationGroups()
          : FetchHomeMeditationGroups(),
    );

    saadhnaBloc.add(
      isSaadhnaFresh
          ? RefetchAllSaadhnaGroups()
          : FetchAllSaadhnaGroups(),
    );

    userFavouritesBloc.add(
      isFavFresh
          ? RefetchUserFavouriteMeditations(userId)
          : FetchUserFavouriteMeditations(userId),
    );
  }

  void _refetchData(
    HomeDataRefresh event,
    Emitter emit,
  ) {
    final userId =
        (profileBloc.state as ProfileLoaded).id;

    homeMeditationGroupsBloc.add(
      RefreshHomeMeditationGroups(),
    );

    saadhnaBloc.add(
      FetchAllSaadhnaGroups(),
    );

    userFavouritesBloc.add(
      RefetchUserFavouriteMeditations(userId),
    );
  }

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

Dependency Injection (GetIt)

This is where most production bugs come from.

sl.registerLazySingleton(
  () => HomeMeditationGroupsBloc(
    getMeditationGroupsByType: sl(),
  ),
);

sl.registerLazySingleton(
  () => SaadhnaBloc(
    getAllGroups: sl(),
  ),
);

sl.registerLazySingleton(
  () => UserFavouritesBloc(),
);

sl.registerLazySingleton(
  () => HomeCoordinationBloc(
    homeMeditationGroupsBloc: sl(),
    saadhnaBloc: sl(),
    userFavouritesBloc: sl(),
    profileBloc: sl(),
  ),
);

BLoC Providers

BlocProvider<UserFavouritesBloc>(
  create: (context) => sl<UserFavouritesBloc>(),
),

BlocProvider<HomeMeditationGroupsBloc>(
  create: (context)
      => sl<HomeMeditationGroupsBloc>(),
),

BlocProvider<SaadhnaBloc>(
  create: (context) => sl<SaadhnaBloc>(),
),

BlocProvider<HomeCoordinationBloc>(
  create: (context)
      => sl<HomeCoordinationBloc>(),
),

The Screen

The screen now knows nothing about orchestration.

@override
Widget build(BuildContext context) {
  return LiquidPullToRefresh(
    onRefresh: () async {
      context.read<HomeCoordinationBloc>()
          .add(HomeDataRefresh());
    },
    child: ListView(
      children: [
        BlocBuilder<
            HomeMeditationGroupsBloc,
            HomeMeditationGroupsState>(
          builder: (context, state) {
            // render section
          },
        ),
      ],
    ),
  );
}

Mistakes to Not Make

Mistake 1: Registering Handlers After Calling `add()`

This causes a runtime Bad state error.

// WRONG
HomeCoordinationBloc(...)
    : super(HomeCoordinatorInitialState()) {

  if (profileBloc.state is ProfileLoaded) {
    add(HomeDataFetch());
  }

  on<HomeDataFetch>(_fetchData);
}

// CORRECT
HomeCoordinationBloc(...)
    : super(HomeCoordinatorInitialState()) {

  on<HomeDataFetch>(_fetchData);

  if (profileBloc.state is ProfileLoaded) {
    add(HomeDataFetch());
  }
}

The BLoC library checks for a handler immediately when add() is called.

Constructor order matters.

Mistake 2: Using `registerFactory`

This bug is especially nasty because everything appears to work — except the UI never updates.

// WRONG
sl.registerFactory(
  () => HomeMeditationGroupsBloc(...),
);

What happens:

Coordination bloc gets Instance A
UI listens to Instance B
Events fire correctly
Data loads correctly
UI never rebuilds

Two blocs.
Two states.
Zero visible errors.

// CORRECT
sl.registerLazySingleton(
  () => HomeMeditationGroupsBloc(...),
);

Rule

Any bloc referenced by a coordination bloc should usually be a singleton.

Mistake 3: Forgetting to Cancel Stream Subscriptions

// WRONG
@override
Future<void> close() => super.close();

// CORRECT
@override
Future<void> close() {
  profileSubscription.cancel();
  return super.close();
}

Otherwise the subscription can attempt to call add() on a closed bloc.

Mistake 4: Forgetting `.take(1)`

Without .take(1):

profileBloc.stream
    .where((state) => state is ProfileLoaded)
    .listen((_) => add(HomeDataFetch()));

Every future ProfileLoaded state retriggers fetches.

That can create phantom refreshes after:

token refreshes
profile edits
re-authentication

Usually you only want the first load:

profileBloc.stream
    .where((state) => state is ProfileLoaded)
    .take(1)
    .listen((_) => add(HomeDataFetch()));

Mistake 5: Mixing `GetIt` and `context.read`

// Confusing and unnecessary
_homeCoordinationBloc =
    GetIt.instance<HomeCoordinationBloc>();

Then later:

context.read<HomeCoordinationBloc>()

Pick one access pattern.

If the bloc comes from BlocProvider,
prefer context.read<X>().

Mistake 6: Leaving Half the Logic in the Screen

Once you introduce a coordination bloc, commit to it.

// Split ownership
context.read<HomeCoordinationBloc>()
    .add(HomeDataFetch());

context.read<SaadhnaBloc>()
    .add(FetchAllSaadhnaGroups());

Now orchestration lives in two places.

That is worse than either approach alone.

The Hidden Cost: Forced Singletons

This pattern introduces a real architectural tradeoff.

Your feature blocs now live for the entire app lifecycle.

That means:

cached state survives navigation
previous data persists
memory usage increases
state does not automatically reset

This is usually correct for:

home feeds
dashboards
cached content
long-lived tabs

This is usually dangerous for:

forms
temporary workflows
checkout flows
wizard-style screens

Do not accidentally turn screen-scoped state into app-scoped state.

When To Use This Pattern

Use it when:

3+ blocs must coordinate together
another bloc's state gates loading
loading logic contains real conditions
orchestration is reused across screens
refresh behaviour is non-trivial

When NOT To Use It

Do not use it when:

you're only triggering 1-2 blocs
coordination is just sequential add() calls
the screen logic is still simple
feature blocs should remain screen-scoped

In those cases, a BlocListener is simpler and cleaner.

The Simpler Alternative

For smaller flows:

BlocListener<ProfileBloc, ProfileState>(
  listenWhen: (prev, curr) =>
      curr is ProfileLoaded &&
      prev is! ProfileLoaded,

  listener: (context, state) {
    final userId =
        (state as ProfileLoaded).id;

    context.read<HomeMeditationGroupsBloc>()
        .add(FetchHomeMeditationGroups());

    context.read<SaadhnaBloc>()
        .add(FetchAllSaadhnaGroups());

    context.read<UserFavouritesBloc>()
        .add(
          FetchUserFavouriteMeditations(
            userId,
          ),
        );
  },

  child: YourScreen(),
)

This solution:

is smaller
avoids singletons
avoids stream subscriptions
avoids an extra bloc entirely

Start here first.

Graduate to coordination blocs only when the orchestration becomes genuinely complex.

Summary

	Coordination BLoC	BlocListener
Complexity	High	Low
Testability	High	Medium
Reusability	High	Low
Singleton Requirement	Usually Yes	No
Best For	Complex orchestration	Simple fan-out logic

The Coordination BLoC pattern is a real solution for real complexity.

The mistake is introducing it too early.

Start simple.
Escalate only when the orchestration actually demands it.

Optimizing Flutter Apps: A Deep Dive into Dart DevTools

Fri, 08 May 2026 09:59:05 +0000

Most Flutter developers know how to build apps. Far fewer know how to build fast ones. The gap between a good app and a great one often isn't in the features. It's in the frames dropped, the memory leaked, and the milliseconds lost.

Dart DevTools is your toolkit for closing that gap. This guide walks through each of its major panels, what they're good for, and how to actually use them on a real app.

Before you start: Always profile in profile mode, not debug mode. Debug mode runs with extra assertions and overhead that will skew every reading you take.
flutter run --profile

The Flutter Inspector gives you a live, interactive view of your widget tree. Think of it as browser DevTools, but for your UI hierarchy. Here are the four toggles you'll use most.

Slow Animations

Complex animations can be impossible to debug at full speed. Toggling Slow Animations in the Inspector, or setting this in code, drops them to 20% speed so you can catch glitches frame by frame.

import 'package:flutter/scheduler.dart';

void main() {
  timeDilation = 5.0; // 5× slower
  runApp(const MyApp());
}

Guidelines & Baselines

Enables visual overlays that draw:

Scroll direction indicators on scrollable widgets
Widget boundaries (render object outlines)
Text baselines to catch misaligned typography

This is particularly useful when you suspect a layout issue but cannot pinpoint which widget is the culprit.

Highlight Repaints

Every time a widget repaints, it flashes a continuous stream of color. If your entire screen is flashing because a small loading spinner is animating, you have a problem.

I once traced a scrolling jank issue to a blinking typing indicator that was forcing an entire chat screen to repaint every frame.

The fix is a RepaintBoundary. It tells Flutter to isolate that subtree into its own render layer, so its repaints do not cascade upward.

RepaintBoundary(
  child: MyAnimatedWidget(),
)

Use this around widgets that animate independently, such as loaders, progress bars, and live counters.

Highlight Oversized Images

If an image is decoded at 2000×2000px but displayed at 100×100px, you're wasting memory on 39,900 pixels that will never be seen. This toggle shows them as negative and rotates them as shown in the image

The fix is straightforward. Constrain decoding at the source:

Image.network(
  'https://example.com/large-image.jpg',
  cacheWidth: 200,
  cacheHeight: 200,
)

Flutter will downsample the image before caching it, significantly reducing memory pressure on image-heavy screens.

2. App Size Analysis — Know What You're Shipping

A bloated app takes longer to download, longer to install, and gives a worse first impression before the user has even launched it. The --analyze-size flag gives you a breakdown of exactly what's eating into your bundle.

For Android

flutter build apk --analyze-size

For iOS

flutter build ipa --analyze-size

This outputs a JSON file that you import directly into DevTools. Once loaded, you get two views:

Dominator Tree

Shows which packages are responsible for the largest chunks of your app size. If a utility package you barely use is claiming 3MB, it is worth reconsidering.

Call Graph

Maps how your dependencies import each other. This is how you find transitive dependencies you did not know you had. A package pulls another package, which pulls another, each silently adding weight.

Size is a feature.

3. Performance & Jank Tracking — Chasing Smooth Frames

The target is 60 frames per second. That gives each frame exactly 16.6 milliseconds to build and render. Any frame that exceeds this budget is called a jank, and users feel every one of them, even if they cannot name what's wrong.

The Performance tab lets you:

Record a session of real app interactions
View a flame chart of frame build times
Click into expensive frames to see exactly which build, layout, or paint call consumed the most time

The key is to record specific interactions rather than letting it run indefinitely. Navigate to the screen you suspect is slow, hit record, reproduce the issue, then stop. A focused recording is far easier to read than five minutes of noise.

Look for the red frames in the timeline. Those are your jank frames. Drill into them, and you'll usually find one of three things:

An expensive build() method
An unnecessary full-tree rebuild
A synchronous operation blocking the main thread

Heavy JSON parsing, large computations, or image processing should not run on the UI isolate. Move them to another isolate using compute() whenever possible.

final result = await compute(parseLargeJson, jsonString);

4. Network & CPU Profiling — Under the Hood

Network Tab

If you've ever tried to debug an API issue by reading through a wall of flutter: {...} in the debug console, the Network tab will feel like a revelation.

It captures every HTTP request your app makes and displays:

Full request and response headers
Response body and status codes
Request timing and duration

No more print-statement archaeology. You can see at a glance if a request is failing, slow, or returning unexpected data.

CPU Profiler

The CPU Profiler records a flame chart of method calls while your app runs. When something feels sluggish but the Performance tab does not show obvious jank, this is where you look.

It is especially good for catching:

Expensive operations accidentally running on the main isolate
Framework callbacks firing more often than expected
Third-party packages with surprisingly heavy footprints

5. Memory & Debugger — Stability Under Pressure

Memory Tab

Memory leaks are silent killers. Your app might run perfectly in testing and degrade over time in production as memory accumulates and is never released.

The most common culprit in Flutter is forgetting to dispose() objects that hold onto resources.

class MyWidget extends StatefulWidget { ... }

class _MyWidgetState extends State<MyWidget>
    with SingleTickerProviderStateMixin {

  late AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      vsync: this,
      duration: const Duration(seconds: 1),
    );
  }

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

The Memory tab shows a real-time chart of heap allocation. If memory climbs steadily as you navigate through your app and never comes back down, you likely have a leak.

Reproduce the navigation repeatedly and watch the graph. A healthy app's memory should stabilize over time.

Debugger

The built-in debugger supports:

Breakpoints
Step-through execution
Variable inspection

All without leaving DevTools.

This is useful for tracking down logic bugs that only appear in certain states, or for understanding a complex call chain without littering your codebase with print() calls.

Key Principles to Take Away

Profile Mode Is Non-Negotiable

Debug mode adds overhead that makes everything look slower than it is. Measure performance in profile mode, always.

Do Not Optimize Blindly

Reach for DevTools when you observe a real problem:

A user complaint
A visible stutter
A reported crash

Premature optimization creates complexity without measurable benefit.

Older Devices Are Your Benchmark

An app that runs smoothly on a flagship device might choke on a three-year-old mid-range phone. Test on the weakest hardware your users are likely to have.

Dart DevTools removes the guesswork from Flutter performance.

Each panel answers a specific category of question:

What's rendering
What's too big
What's too slow
What's leaking

Use them together, and you'll spend less time wondering why your app feels sluggish and more time fixing it.

Thanks to Aswin Gopinathan for this wonderful workshop, from which I got the knowledge for this blog. Do check it out on Youtube

Why Your Flutter UI Freezes: Understanding Async, Await, Compute & Isolates

Thu, 07 May 2026 11:28:09 +0000

You're building a Flutter app. Everything feels smooth — taps register instantly, animations glide, scrolling is butter.

Then one day you load a large dataset. Maybe 15,000 transactions from a crypto API. Maybe a chunky image processing job. Maybe just a fat JSON response.

And suddenly: the UI freezes. Buttons stop responding. Animations stutter. Scrolling locks up. Users notice.

Your first instinct? Blame async/await.

Bad news: async/await is innocent. The real culprit is something more fundamental — and once you understand it, you'll never guess at Flutter performance problems again. You'll engineer around them.

The Uncomfortable Truth: Dart Is Single-Threaded

Every Flutter app runs inside a Dart isolate. That isolate has:

Its own memory
Its own event loop
One execution thread

One. Single. Thread.

Picture it as a conveyor belt:

→ RENDER FRAME → HANDLE TAP → RENDER FRAME → YOUR HEAVY WORK → RENDER FRAME →

The belt moves forward only when each item finishes. If "YOUR HEAVY WORK" takes 3 seconds, the belt stops for 3 seconds. No rendering. No touch events. Nothing.

That's your UI freeze. That's jank.

The Biggest Misconception in Flutter Development

Here's what most developers assume:

await heavyCalculation(); // "this runs in the background, right?"

Wrong.

async/await does not move work to another thread. It does not create parallelism. It does not make your code run somewhere else.

What it actually means is:

"Pause this function here. Resume it later when the Future completes."

That's it. That's the whole trick.

To prove it — this code freezes your UI completely, even with async/await:

Future<void> freezeUI() async {
  for (var i = 0; i < 1000000000; i++) {} // CPU grinding on the UI thread
}

// Calling this:
await freezeUI(); // Still freezes. async didn't save you.

The work is still running on the same isolate as your UI. await just made it look like it wouldn't.

So What Does Async-Await Actually Do Well?

Async shines when your code is waiting, not working.

When you make a network request:

final response = await http.get(Uri.parse('https://api.example.com/data'));

Here's what actually happens under the hood:

Dart initiates the request
Dart tells the OS: "ping me when this finishes"
The isolate is now free — it goes back to rendering, handling taps, running animations
When the response arrives, Dart resumes your function from where it left off

No blocking. No freezing. The isolate was idle anyway — it was waiting on the network, not computing.

This is non-blocking I/O. And async/await handles it beautifully.

The problem only starts when you stop waiting and start working.

The Dart Event Loop (And Why It Matters)

To really understand async behavior, you need to know how Dart schedules work.

Dart's event loop has two queues:

Microtask Queue (High Priority)

Used for:

Future continuations (what runs after an await)
scheduleMicrotask() calls

Event Queue (Normal Priority)

Used for:

Timer callbacks
Network/IO completions
Gesture events
Platform messages

The loop runs like this:

1. Run all synchronous code
2. Drain every pending microtask
3. Execute one event from the event queue
4. Repeat forever

This ordering has a real-world consequence. Here's a classic puzzle:

void main() {
  print("A");                                    // sync
  Future(() => print("B"));                      // event queue
  scheduleMicrotask(() => print("C"));           // microtask queue
  print("D");                                    // sync
}

Output:

A
D
C
B

Why? Because:

A and D are synchronous — they run first, in order
C is a microtask — it runs before any events
B is in the event queue — it runs last

Knowing this helps you reason about execution order, debug subtle timing bugs, and understand why async/await resumptions feel immediate (they're microtasks).

The JSON Parsing Trap

Here's where developers get burned all the time.

Your app fetches data. The network call is fine — async, non-blocking, smooth. But then:

final response = await http.get(url);               // non-blocking, isolate is free
final data = jsonDecode(response.body);             // CPU-heavy, blocks the isolate

jsonDecode on a small payload? No problem. On 15,000 transaction records? That single line can block your UI for 2–4 seconds.

The network call wasn't your enemy. The parsing was.

This is the trap: the operation after await can still freeze your UI if it's CPU-intensive.

The Fix: Isolates

An isolate is an independent Dart execution environment. It has:

Its own memory heap (completely separate from your UI isolate)
Its own event loop
Its own thread

Unlike OS threads, isolates cannot share memory. This eliminates entire classes of bugs — no race conditions, no mutex deadlocks, no shared-state corruption. Instead, isolates communicate by passing messages.

Main Isolate                    Worker Isolate
─────────────                   ──────────────
UI rendering                    JSON parsing
Touch handling       ←──────→   Image processing
Animations          (messages)  Heavy computation

While the worker isolate grinds through CPU work, your UI isolate keeps rendering at 60fps.

`compute()`: Isolates Without the Ceremony

Spawning a raw isolate involves some boilerplate. For one-off tasks, Flutter gives you compute():

// Before: freezes UI
final transactions = jsonDecode(response.body);

// After: runs in a separate isolate, UI stays smooth
final transactions = await compute(parseTransactions, response.body);

Where parseTransactions is a top-level or static function:

List<Transaction> parseTransactions(String rawJson) {
  final decoded = jsonDecode(rawJson) as List;
  return decoded.map((e) => Transaction.fromJson(e)).toList();
}

compute() under the hood:

Spawns a new isolate
Sends your data to it (via message passing — it gets copied)
Runs your function
Returns the result to the main isolate
Destroys the worker isolate

One function call. UI stays responsive. Task done in parallel.

When `compute()` Isn't Enough: Persistent Isolates

compute() is great for one-shot jobs. But spawning and destroying isolates has overhead. If you're doing continuous background work — like a live transaction feed, streaming parser, or on-device ML inference — you want a persistent isolate.

// Pseudo-code for a long-running isolate
final receivePort = ReceivePort();
final isolate = await Isolate.spawn(backgroundWorker, receivePort.sendPort);

receivePort.listen((message) {
  // Handle result from background isolate
  setState(() => _data = message);
});

Use persistent isolates when:

You're processing a continuous stream of data
You're running local AI/ML models
You have a background sync engine
The spawning overhead of compute() becomes measurable

The Decision Framework

Every time you write async code, ask: am I waiting or working?

Scenario	Use
API call / network request	`async/await`
Database read/write	`async/await`
File I/O	`async/await`
Timer / delay	`async/await`
JSON parsing (large)	`compute()`
Image processing	`compute()`
Encryption / hashing	`compute()`
One-off heavy computation	`compute()`
Streaming data parser	Persistent Isolate
On-device ML inference	Persistent Isolate
Background sync engine	Persistent Isolate

Real-World Example: Crypto Wallet Transaction Feed

Let's put it all together with a realistic scenario.

Your wallet app fetches 15,000 transactions. Naïve implementation:

// Freezes UI for multiple seconds
Future<void> loadTransactions() async {
  final response = await http.get(transactionsUrl);   // fine
  final txs = jsonDecode(response.body);              //  blocks here
  setState(() => _transactions = txs);
}

Better:

// UI stays responsive throughout
Future<void> loadTransactions() async {
  final response = await http.get(transactionsUrl);                    // non-blocking
  final txs = await compute(parseTransactions, response.body);         // off-thread
  setState(() => _transactions = txs);                                 // back on UI thread
}

List<Transaction> parseTransactions(String json) {
  return (jsonDecode(json) as List)
      .map((e) => Transaction.fromJson(e))
      .toList();
}

The user never sees a freeze. Scrolling stays smooth at 60fps while thousands of transactions parse in the background.

Common Myths, Killed

"Async/await makes my code multithreaded"
No. It handles asynchronous waiting. Multithreading requires isolates.

"If I put await before it, it won't block the UI"
Only if the work is I/O-bound. CPU-heavy code blocks regardless of await.

"compute() is some kind of magic optimization"
It's just a thin wrapper around isolate spawning. The magic is the isolate, not the function.

"Dart can only use one CPU core"
False. Each isolate can run on its own OS thread. Dart can use all your cores through isolates.

The Mental Model That Fixes Everything

Burn this into your brain:

async/await  →  for WAITING
isolates     →  for WORKING

That's the whole framework. Every Flutter performance bug related to async ultimately comes down to confusing these two. Once you stop conflating them, you stop guessing — and start building apps that are genuinely fast.

Your UI thread should only wait. Never grind.

Everything about Stateful & Stateless widgets in Flutter

Mon, 04 May 2026 03:34:50 +0000

Flutter's widget system looks deceptively simple on the surface — everything is a widget, you compose them, and the UI appears. But once you go deeper, you realize Flutter made a very deliberate architectural decision by splitting widgets into two kinds: Stateless and Stateful. Understanding why that split exists, and how the machinery behind it works, is what separates developers who use Flutter from developers who truly understand it.

Before distinguishing the two, it's worth being precise about what a widget actually is in Flutter's model.

A widget is an immutable description of a piece of UI. That's it. It's a configuration object — a blueprint. It doesn't draw anything, it doesn't hold layout state, it doesn't live on screen. It just describes what should exist.

Flutter maintains three separate trees to actually make that description come alive:

Widget tree — The lightweight, immutable descriptions you write in code. Rebuilt frequently.
Element tree — The long-lived, mutable counterpart to each widget. Elements persist across rebuilds and act as the glue between widgets and render objects.
RenderObject tree — The heavy, layout-and-paint layer. This is what actually measures, positions, and renders pixels.

This separation is critical to Flutter's performance. Rebuilding the widget tree is cheap because widgets are just Dart objects with a few fields. The element and render object trees, which are expensive to create, are preserved and updated incrementally.

Stateless Widgets

A StatelessWidget is a widget whose entire output is determined solely by its constructor arguments. Given the same inputs, it will always produce the same widget tree — there is no internal state that can change between builds.

class GreetingCard extends StatelessWidget {
  final String name;
  final String message;

  const GreetingCard({super.key, required this.name, required this.message});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Hello, $name'),
        Text(message),
      ],
    );
  }
}

Flutter calls build() on a stateless widget when its parent rebuilds and passes it new configuration. The widget itself has no lifecycle beyond that single build() call — no initialization, no teardown, no reactive hooks.

The `const` Optimization

Stateless widgets shine when paired with const constructors. When Flutter encounters a const widget in a rebuild, it can short-circuit the entire subtree — it knows the widget is identical to the previous one (same type, same arguments, canonicalized at compile time), so there's nothing to diff.

// Flutter will never rebuild this subtree unless the parent explicitly changes it
const Icon(Icons.star, color: Colors.amber, size: 24);

For UI elements that are truly static — icons, labels, decorative containers — const is a free performance win. Make it a habit to use const wherever possible and let the Dart analyzer enforce it with the prefer_const_constructors lint.

Stateful Widgets

A StatefulWidget is for UI that needs to change over time based on user interaction, async results, animations, or any other runtime event. The key design decision Flutter made here is that the widget and its state are two separate objects.

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

  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    return TextButton(
      onPressed: () => setState(() => _count++),
      child: Text('Count: $_count'),
    );
  }
}

Why separate them? Because widgets are immutable and short-lived, but state needs to persist. When Flutter rebuilds the Counter widget, it creates a brand-new Counter object — but the _CounterState instance that holds _count is kept alive by the element tree. The element simply calls widget.build() on the new widget description while retaining the existing State object beneath it.

The Stateful Lifecycle

State objects have a full lifecycle managed by the Flutter framework. Understanding each phase is essential for writing correct, leak-free Flutter code.

`createState()`

Called on the widget (not the state) to create the associated State object. This happens exactly once — when the widget is first inserted into the tree.

@override
State<MyWidget> createState() => _MyWidgetState();

`initState()`

The first method called on the State object after it's created. This is where you perform one-time initialization — subscribing to streams, setting up animation controllers, making initial API calls.

@override
void initState() {
  super.initState(); // Always call super first
  _controller = AnimationController(vsync: this, duration: const Duration(milliseconds: 300));
  _fetchInitialData();
}

initState() runs before the first build, and context is available but restricted here — you cannot call context-dependent operations like Navigator.of(context) from initState(). Use didChangeDependencies() or a post-frame callback for that.

`didChangeDependencies()`

Called immediately after initState(), and again whenever an InheritedWidget that this state object depends on changes. For example, if your widget reads from Theme.of(context) or a custom InheritedWidget, and that data changes, didChangeDependencies() fires before the next build.

@override
void didChangeDependencies() {
  super.didChangeDependencies();
  // Safe to use context-dependent APIs here
  final locale = Localizations.localeOf(context);
  _updateForLocale(locale);
}

`build()`

The only required override. Called every time the state is marked dirty — after setState(), after didChangeDependencies(), after didUpdateWidget(), and during the initial render. Must be pure and free of side effects.

`setState()`

The mechanism for signaling that internal state has changed and the widget needs to rebuild.

setState(() {
  _count++;
  _isLoading = false;
});

When you call setState(), Flutter marks the element as dirty. It doesn't trigger an immediate rebuild — instead, it schedules a frame. At the start of the next frame, Flutter walks the element tree, finds all dirty elements, and calls build() on each of them. The widget returned by build() is then reconciled against the previous widget using the element tree (more on this below).

`didUpdateWidget()`

Called when the parent rebuilds and passes a new widget instance to this state's element. The old widget is passed as an argument, giving you a chance to react to configuration changes.

@override
void didUpdateWidget(covariant MyWidget oldWidget) {
  super.didUpdateWidget(oldWidget);
  if (widget.userId != oldWidget.userId) {
    _fetchDataForUser(widget.userId);
  }
}

This is the correct place to respond to external prop changes — not initState(), which only runs once.

`deactivate()`

Called when the State object is temporarily removed from the tree — for example, when a widget is moved to a different subtree location using a GlobalKey. This is uncommon in everyday Flutter code, but important to know.

`dispose()`

Called when the State object is permanently removed from the tree. This is where you clean up resources — cancel timers, close streams, dispose animation controllers, remove listeners.

@override
void dispose() {
  _controller.dispose();
  _scrollController.dispose();
  _subscription.cancel();
  super.dispose(); // Always call super last
}

Forgetting to dispose() resources is one of the most common sources of memory leaks in Flutter apps.

How Reconciliation Actually Works

When a dirty element rebuilds, it gets a new widget from build(). Flutter then needs to decide: does the existing child element still apply, or does it need to be replaced?

Flutter checks two things in order:

Type — Is the new widget the same runtime type as the widget the element currently holds?
Key — If a key is present, does it match?

If both match, Flutter reuses the element and simply updates its widget reference. The underlying RenderObject is updated in place — expensive layout state is preserved.

If either differs, Flutter deactivates the old element, creates a new one, and mounts it. For stateful widgets, this means the State is disposed and a new one is created from scratch.

// Scenario: parent conditionally renders one of two widgets
if (_showA)
  const WidgetA()   // Type: WidgetA
else
  const WidgetB()   // Type: WidgetB — new element, old state discarded

Keys: Making Reconciliation Precise

By default, Flutter reconciles children by type and position. For static, fixed-size lists this works perfectly. But for dynamic, reorderable, or filtered lists, positional matching breaks down.

// Imagine these items get reordered from [A, B] to [B, A]
// Without keys, Flutter sees: position 0 = same type, position 1 = same type
// It reuses the same elements — the state of A bleeds into B's position
Column(
  children: [
    TodoItem(label: 'B'),
    TodoItem(label: 'A'),
  ],
)

Keys tell Flutter explicitly which element corresponds to which widget, regardless of position.

`LocalKey`

Scoped to siblings within the same parent. The common variants are:

ValueKey<T> — keyed by a value (most common, use with IDs or strings)
ObjectKey — keyed by object identity
UniqueKey — generates a new key every time (forces recreation — use deliberately)

ListView(
  children: _todos.map((todo) =>
    TodoItem(key: ValueKey(todo.id), label: todo.label)
  ).toList(),
)

Now when items reorder, Flutter correctly matches each TodoItem to its element by ID, preserving the right state in the right place.

`GlobalKey`

Unique across the entire widget tree. A GlobalKey lets you access a widget's State, BuildContext, or RenderObject from anywhere in the app.

final _formKey = GlobalKey<FormState>();

// Later:
if (_formKey.currentState!.validate()) {
  _formKey.currentState!.save();
}

GlobalKey is powerful but expensive — Flutter maintains a global registry for them. Avoid using them as a shortcut to reach into widget state; prefer proper state management patterns for that. Use GlobalKey when you genuinely need framework-level access — form validation, imperative scroll control, or moving a subtree across the tree while preserving its state.

The `mounted` Property and Async Safety

Every State object has a mounted boolean. It becomes true after initState() runs and transitions to false after dispose(). It exists to solve a specific and common problem: calling setState() after the widget has been removed from the tree.

Future<void> _loadData() async {
  final result = await repository.fetchItems(); // async gap — widget may be disposed here

  setState(() => _items = result); //  throws if widget was already disposed
}

The safe pattern:

Future<void> _loadData() async {
  final result = await repository.fetchItems();

  if (mounted) {
    setState(() => _items = result);
  }
}

This is especially important in scenarios where a user navigates away while a network call is still in flight, or when a parent removes the widget before the async operation completes. The mounted check is a lightweight guard that prevents both the exception and the logical error of mutating dead state.

When to Use Which

The choice is usually straightforward once you internalize the rule:

If the widget can fully describe its UI from its constructor arguments alone, use StatelessWidget. If it needs to track any internal state that changes over time, use StatefulWidget.

Some practical heuristics:

Pure display widgets (cards, labels, icons, decorative layouts) → StatelessWidget with const
Anything with user interaction that changes appearance (toggles, counters, form fields) → StatefulWidget
Animations → StatefulWidget with SingleTickerProviderStateMixin
Widgets that only receive state from above (via constructor or InheritedWidget) and just render it → StatelessWidget

It's also worth noting that the separation isn't just about correctness — it's about communicating intent. A StatelessWidget signals to every reader of your code: this widget has no internal moving parts. That's a strong, useful guarantee.

Putting It All Together

Flutter's architecture makes more sense when you see the whole picture at once:

Widgets are cheap, immutable blueprints. Rebuilt frequently, thrown away without ceremony.
Elements are the persistent, mutable objects that hold the tree together. They match incoming widgets to existing state.
RenderObjects are expensive and preserved. Updated in place whenever possible.
Stateful widgets get a separate State object, anchored to an element, that survives widget rebuilds.
setState() marks elements dirty and schedules a frame — not an immediate rebuild.
Reconciliation by type and key determines whether to reuse or replace elements.
Keys make that reconciliation correct when position alone isn't enough.
mounted is your safety net for async operations that outlive the widget.

Every Flutter performance tip — minimizing rebuilds, using const, lifting state appropriately, keying lists — traces back to understanding these fundamentals. Once the model is clear, the best practices follow naturally.

Top Package: GoRouter Advanced Navigation Tutorial 2026

Tue, 10 Feb 2026 22:40:29 +0000

Advanced GoRouter tutorial—bottom nav with preserved state, nested routes, typed navigation, and auth redirects. GoRouter is Flutter's official best navigation system, stable in maintenance mode.
Features: Deep linking, ShellRoute for tabs, typed routes via builder.

The Hidden Gem of Flutter Lists: Unlocking scrollable_positioned_list's Superpowers

Tue, 10 Feb 2026 19:56:35 +0000

As Flutter developers, we've all faced the common challenge: building lists that need more control than the standard ListView provides. Whether it's scrolling to a specific index, tracking which items are visible, or implementing complex navigation patterns, Flutter's built-in widgets sometimes leave us wanting more.

Enter scrollable_positioned_list – a powerful yet often-overlooked package from Google's flutter.widgets repository that solves these problems elegantly.

In this comprehensive guide, we'll explore the hidden gems of this package and demonstrate how it can transform your Flutter applications.

Why scrollable_positioned_list Matters

The Problem with Standard ListView

Flutter's ListView is excellent for basic scrolling, but it has significant limitations:

No built-in scrollToIndex() – You must develop custom solutions to measure element offsets
No visibility detection – Determining which items are currently visible requires complex workarounds
Limited programmatic control – Jumping to specific items is non-trivial

The scrollable_positioned_list Solution

This package addresses all these limitations with a clean, well-documented API that maintains the familiar ListView.builder pattern while adding powerful capabilities.

According to the official documentation, this widget allows scrolling to a specific item and determining what items are currently visible – exactly what advanced Flutter applications need.

Installation and Setup

Add the package to your pubspec.yaml:

dependencies:
  scrollable_positioned_list: ^0.3.8

Then import it:

import 'package:scrollable_positioned_list/scrollable_positioned_list.dart';

Hidden Gem #1: Programmatic Scrolling with scrollToIndex

The most powerful feature is the ability to scroll to any item programmatically – functionality that standard ListView simply doesn't provide.

class ScrollableListExample extends StatefulWidget {
  @override
  _ScrollableListExampleState createState() => _ScrollableListExampleState();
}

class _ScrollableListExampleState extends State<ScrollableListExample> {
  final ItemScrollController _itemScrollController = ItemScrollController();
  final ItemPositionsNotifier _itemPositionsNotifier = ItemPositionsNotifier();
  final List<String> _items = List.generate(100, (index) => 'Item ${index + 1}');

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('ScrollablePositionedList Demo')),
      body: Column(
        children: [
          Padding(
            padding: const EdgeInsets.all(16.0),
            child: Row(
              mainAxisAlignment: MainAxisAlignment.spaceEvenly,
              children: [
                ElevatedButton(onPressed: () => _scrollToIndex(0), child: const Text('To Start')),
                ElevatedButton(onPressed: () => _scrollToIndex(_items.length - 1), child: const Text('To End')),
                ElevatedButton(onPressed: () => _scrollToIndex(49), child: const Text('To Middle')),
              ],
            ),
          ),
          Expanded(
            child: ScrollablePositionedList.builder(
              itemCount: _items.length,
              itemScrollController: _itemScrollController,
              itemPositionsNotifier: _itemPositionsNotifier,
              itemBuilder: (context, index) => ListTile(
                title: Text(_items[index]),
                subtitle: Text('Position: ${index + 1}'),
              ),
            ),
          ),
        ],
      ),
    );
  }

  void _scrollToIndex(int index) {
    _itemScrollController.scrollTo(index: index, duration: const Duration(seconds: 2), curve: Curves.easeInOutCubic);
  }
}

Advanced Options:

// Jump immediately (no animation)
void _jumpToIndex(int index) => _itemScrollController.jumpTo(index: index);

// Scroll with custom alignment (0.0 = top, 0.5 = center, 1.0 = bottom)
void _scrollToCenter(int index) {
  _itemScrollController.scrollTo(index: index, alignment: 0.5, duration: const Duration(milliseconds: 500));
}

Hidden Gem #2: ItemPositionListener – Tracking What's Visible

The ItemPositionListener monitors which items are visible – perfect for reading progress, lazy loading, or scroll-synced animations.

class ReadingProgressExample extends StatefulWidget {
  @override
  _ReadingProgressExampleState createState() => _ReadingProgressExampleState();
}

class _ReadingProgressExampleState extends State<ReadingProgressExample> {
  final ItemPositionsNotifier _itemPositionsNotifier = ItemPositionsNotifier();
  double _readingProgress = 0.0;

  @override
  void initState() {
    super.initState();
    _itemPositionsNotifier.itemPositions.addListener(_updateProgress);
  }

  @override
  void dispose() {
    _itemPositionsNotifier.itemPositions.removeListener(_updateProgress);
    super.dispose();
  }

  void _updateProgress() {
    final positions = _itemPositionsNotifier.itemPositions.value;
    if (positions.isNotEmpty) {
      final minIndex = positions.where((p) => p.itemLeadingEdge < 1).reduce((min, p) => p.itemLeadingEdge < min.itemLeadingEdge ? p : min).index;
      final maxIndex = positions.where((p) => p.itemTrailingEdge > 0).reduce((max, p) => p.itemTrailingEdge > max.itemTrailingEdge ? p : max).index;
      setState(() => _readingProgress = ((minIndex + maxIndex) / 200).clamp(0.0, 1.0));
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Reading Progress'), bottom: PreferredSize(preferredSize: const Size.fromHeight(4), child: LinearProgressIndicator(value: _readingProgress))),
      body: ScrollablePositionedList.builder(itemCount: 100, itemPositionsNotifier: _itemPositionsNotifier, itemBuilder: (context, index) => Padding(padding: const EdgeInsets.all(16.0), child: Text('Chapter ${index + 1}', style: const TextStyle(fontSize: 18)))),
    );
  }
}

Detecting Fully Visible Items:

bool isItemFullyVisible(ItemPosition position) => position.itemLeadingEdge >= 0 && position.itemTrailingEdge <= 1;

List<int> getFullyVisibleIndices() => _itemPositionsNotifier.itemPositions.value.where(isItemFullyVisible).map((p) => p.index).toList();

Hidden Gem #3: Variable Height Items Support

This package handles items of varying heights gracefully – crucial for dynamic content apps.

class VariableHeightListExample extends StatelessWidget {
  final ItemScrollController _scrollController = ItemScrollController();
  final List<_ContentItem> _items = List.generate(50, (index) {
    final lines = (index % 5) + 1;
    return _ContentItem(title: 'Article ${index + 1}', content: 'This article has $lines lines.\n' * lines);
  });

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Variable Height List'), actions: [
        IconButton(icon: const Icon(Icons.arrow_downward), onPressed: () => _scrollController.scrollTo(index: _items.length - 1, duration: const Duration(seconds: 2)))
      ]),
      body: ScrollablePositionedList.builder(
        itemCount: _items.length,
        itemScrollController: _scrollController,
        itemBuilder: (context, index) => Card(
          margin: const EdgeInsets.all(8),
          child: Padding(
            padding: const EdgeInsets.all(16),
            child: Column(crossAxisAlignment: CrossAxisAlignment.start, children: [
              Text(_items[index].title, style: Theme.of(context).textTheme.titleLarge),
              const SizedBox(height: 8), Text(_items[index].content)
            ]),
          ),
        ),
      ),
    );
  }
}

class _ContentItem {
  final String title, content;
  _ContentItem({required this.title, required this.content});
}

Hidden Gem #4: Scroll Offset Tracking

class ScrollOffsetExample extends StatefulWidget {
  @override
  _ScrollOffsetExampleState createState() => _ScrollOffsetExampleState();
}

class _ScrollOffsetExampleState extends State<ScrollOffsetExample> {
  final ItemPositionsNotifier _positionsNotifier = ItemPositionsNotifier();
  final ItemScrollController _scrollController = ItemScrollController();
  double _currentScrollOffset = 0.0;

  @override
  void initState() {
    super.initState();
    _positionsNotifier.itemPositions.addListener(() {
      final positions = _positionsNotifier.itemPositions.value;
      if (positions.isNotEmpty) setState(() => _currentScrollOffset = positions.first.itemLeadingEdge);
    });
  }

  @override
  void dispose() {
    _positionsNotifier.itemPositions.removeListener(() {});
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Offset: ${_currentScrollOffset.toStringAsFixed(2)}')),
      body: Stack(
        children: [
          Positioned(top: -_currentScrollOffset * 0.5, left: 0, right: 0, child: Container(height: 200, decoration: BoxDecoration(gradient: LinearGradient(colors: [Colors.blue.shade200, Colors.purple.shade200])))),
          ScrollablePositionedList.builder(
            itemCount: 50,
            itemScrollController: _scrollController,
            itemPositionsNotifier: _positionsNotifier,
            padding: const EdgeInsets.only(top: 150),
            itemBuilder: (context, index) => ListTile(title: Text('Item ${index + 1}'), subtitle: Text('Offset: ${_currentScrollOffset.toStringAsFixed(2)}')),
          ),
        ],
      ),
    );
  }
}

Implement a table of contents that highlights the current section – perfect for documentation sites.

class ScrollSpyExample extends StatefulWidget {
  @override
  _ScrollSpyExampleState createState() => _ScrollSpyExampleState();
}

class _ScrollSpyExampleState extends State<ScrollSpyExample> {
  final ItemScrollController _scrollController = ItemScrollController();
  final ItemPositionsNotifier _positionsNotifier = ItemPositionsNotifier();
  final List<String> _sections = List.generate(20, (index) => 'Section ${index + 1}');
  int _activeSection = 0;

  @override
  void initState() {
    super.initState();
    _positionsNotifier.itemPositions.addListener(() {
      final positions = _positionsNotifier.itemPositions.value;
      if (positions.isNotEmpty) {
        final mostVisible = positions.reduce((a, b) => (a.itemLeadingEdge.abs() + a.itemTrailingEdge.abs()) / 2 < (b.itemLeadingEdge.abs() + b.itemTrailingEdge.abs()) / 2 ? a : b);
        if (_activeSection != mostVisible.index) setState(() => _activeSection = mostVisible.index);
      }
    });
  }

  @override
  void dispose() {
    _positionsNotifier.itemPositions.removeListener(() {});
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Scroll Spy Navigation')),
      body: Row(
        children: [
          Container(
            width: 200,
            color: Colors.grey[100],
            child: ListView.builder(
              itemCount: _sections.length,
              itemBuilder: (context, index) {
                final isActive = index == _activeSection;
                return ListTile(
                  title: Text(_sections[index], style: TextStyle(fontWeight: isActive ? FontWeight.bold : FontWeight.normal, color: isActive ? Colors.blue : Colors.black87)),
                  selected: isActive,
                  onTap: () => _scrollController.scrollTo(index: index, duration: const Duration(milliseconds: 300), alignment: 0.0),
                );
              },
            ),
          ),
          Expanded(
            child: ScrollablePositionedList.builder(
              itemCount: _sections.length,
              itemScrollController: _scrollController,
              itemPositionsNotifier: _positionsNotifier,
              itemBuilder: (context, index) => Container(height: 300, padding: const EdgeInsets.all(24), child: Text(_sections[index], style: Theme.of(context).textTheme.headlineMedium)),
            ),
          ),
        ],
      ),
    );
  }
}

Common Pitfalls and Solutions

Pitfall 1: Controller Not Attached

Problem: Calling scrollTo before the controller is attached.

Solution:

void _safeScrollTo(int index) {
  if (_itemScrollController.isAttached) {
    _itemScrollController.scrollTo(index: index);
  } else {
    WidgetsBinding.instance.addPostFrameCallback((_) {
      if (_itemScrollController.isAttached) _itemScrollController.scrollTo(index: index);
    });
  }
}

Pitfall 2: CustomScrollView Incompatibility

Problem: Doesn't work well inside CustomScrollView with other slivers.

Solution: Use as standalone or consider super_sliver_list for complex sliver scenarios. See GitHub Issue #32.

Pitfall 3: Alignment Confusion

Solution: The alignment parameter specifies where the target item positions:

0.0 = Top of viewport
0.5 = Center of viewport
1.0 = Bottom of viewport

Feature	ListView	scrollable_positioned_list	CustomScrollView
Basic scrolling	✅	✅	✅
scrollToIndex()	❌	✅	❌
Visibility detection	❌	✅	❌
Variable height items	✅	✅	✅
Custom sliver integration	❌	❌	✅

Use scrollable_positioned_list for: scroll-to-index, visibility tracking, scroll-offset animations, reading progress, scroll spy navigation.

Use standard ListView for: basic scrolling, maximum performance, CustomScrollView integration.

Real-World Example: Music Player with Queue

class MusicPlayerQueue extends StatefulWidget {
  const MusicPlayerQueue({Key? key}) : super(key: key);
  @override
  _MusicPlayerQueueState createState() => _MusicPlayerQueueState();
}

class _MusicPlayerQueueState extends State<MusicPlayerQueue> {
  final ItemScrollController _scrollController = ItemScrollController();
  final ItemPositionsNotifier _positionsNotifier = ItemPositionsNotifier();
  final List<Song> _playlist = List.generate(50, (index) => Song(title: 'Track ${index + 1}', artist: 'Artist ${(index % 10) + 1}', duration: Duration(minutes: 3, seconds: (index * 7) % 60)));
  int _currentTrackIndex = 0;
  bool _isPlaying = false;

  void _playTrack(int index) {
    setState(() => _currentTrackIndex = _currentTrackIndex = index);
    _scrollController.scrollTo(index: index, alignment: 0.5, duration: const Duration(milliseconds: 400), curve: Curves.easeInOut);
  }

  void _nextTrack() => _playTrack((_currentTrackIndex + 1) % _playlist.length);
  void _previousTrack() => _playTrack((_currentTrackIndex - 1 + _playlist.length) % _playlist.length);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Music Player'), actions: [
        IconButton(icon: Icon(_isPlaying ? Icons.pause : Icons.play_arrow), onPressed: () => setState(() => _isPlaying = !_isPlaying))
      ]),
      body: Column(
        children: [
          Container(
            padding: const EdgeInsets.all(16),
            color: Colors.blue.shade50,
            child: Row(children: [
              const Icon(Icons.music_note, size: 48),
              const SizedBox(width: 16),
              Expanded(child: Column(crossAxisAlignment: CrossAxisAlignment.start, children: [
                Text(_playlist[_currentTrackIndex].title, style: const TextStyle(fontWeight: FontWeight.bold)),
                Text(_playlist[_currentTrackIndex].artist),
                Text(_formatDuration(_playlist[_currentTrackIndex].duration))
              ])),
              IconButton(icon: const Icon(Icons.skip_previous), onPressed: _previousTrack),
              IconButton(icon: const Icon(Icons.skip_next), onPressed: _nextTrack)
            ]),
          ),
          Expanded(
            child: ScrollablePositionedList.builder(
              itemCount: _playlist.length,
              itemScrollController: _scrollController,
              itemPositionsNotifier: _positionsNotifier,
              itemBuilder: (context, index) {
                final song = _playlist[index];
                final isPlaying = index == _currentTrackIndex;
                return ListTile(
                  leading: CircleAvatar(backgroundColor: isPlaying ? Colors.blue : Colors.grey[300], child: Icon(isPlaying ? (_isPlaying ? Icons.pause : Icons.play_arrow) : Icons.music_note, color: isPlaying ? Colors.white : Colors.black54)),
                  title: Text(song.title, style: TextStyle(fontWeight: isPlaying ? FontWeight.bold : FontWeight.normal, color: isPlaying ? Colors.blue : null)),
                  subtitle: Text(song.artist),
                  trailing: Text(_formatDuration(song.duration)),
                  onTap: () => _playTrack(index),
                );
              },
            ),
          ),
        ],
      ),
    );
  }

  String _formatDuration(Duration d) => '${d.inMinutes}:${d.inSeconds.toString().padLeft(2, '0')}';
}

class Song {
  final String title, artist;
  final Duration duration;
  Song({required this.title, required this.artist, required this.duration});
}

Key Takeaways

The scrollable_positioned_list package is a hidden gem every Flutter developer should know:

Solves Real Problems – Addresses ListView limitations without complexity
Clean API – Familiar ListView.builder pattern with powerful features
Google-Maintained – Part of google/flutter.widgets repository
Production-Ready – Used in apps like API Dash
Feature-Rich – scrollToIndex(), visibility tracking, offset monitoring

Perfect for: playlist apps, documentation readers, chat apps, table of contents, any precise scroll control scenario.

Conclusion

The scrollable_positioned_list package fills a crucial gap in Flutter's ecosystem by providing scrollToIndex(), visibility tracking, and scroll offset monitoring – all while maintaining the familiar ListView.builder API. Try it in your next project!

Why Theme Setup Matters (More Than You Think)

Tue, 18 Nov 2025 10:30:26 +0000

Dark mode isn’t just aesthetics anymore — it’s part of the vibe. Users expect apps to feel native, polished, and flexible. Good theming isn’t just flipping background colors; it’s about creating a consistent design language that can scale across dozens of screens. Flutter makes this super smooth with its built-in theming system, but you’ve gotta wire it right from day one.

So let's set up a proper Light + Dark theme structure that’s clean, maintainable, and future-proof.

️ Step 1: Create Your Theme Files

Don’t dump theme code directly into main.dart. That’s chaos energy. Instead, create a dedicated folder:

lib/
theme/

light_theme.dart
dark_theme.dart
theme_colors.dart

Example: light_theme.dart
import 'package:flutter/material.dart';
import 'theme_colors.dart';

ThemeData lightTheme = ThemeData(
brightness: Brightness.light,
primaryColor: AppColors.primary,
scaffoldBackgroundColor: Colors.white,
appBarTheme: const AppBarTheme(

backgroundColor: Colors.white,
foregroundColor: Colors.black87,
elevation: 0,

),
colorScheme: const ColorScheme.light(),
);

Example: dark_theme.dart
import 'package:flutter/material.dart';
import 'theme_colors.dart';

ThemeData darkTheme = ThemeData(
brightness: Brightness.dark,
primaryColor: AppColors.primary,
scaffoldBackgroundColor: Colors.black,
appBarTheme: const AppBarTheme(

backgroundColor: Colors.black,
foregroundColor: Colors.white,
elevation: 0,

),
colorScheme: const ColorScheme.dark(),
);

Example: theme_colors.dart
import 'package:flutter/material.dart';

class AppColors {
static const primary = Color(0xFF6750A4);
}

Separating colors like this makes it easier to manage branding changes without nuking your whole codebase.

Step 2: Set Up Theme Switching

Most apps either follow system theme automatically or give users a toggle. Flutter makes both easy.

Inside main.dart:
import 'package:flutter/material.dart';
import 'theme/light_theme.dart';
import 'theme/dark_theme.dart';

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

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

@override
State createState() => _MyAppState();
}

class _MyAppState extends State {
ThemeMode themeMode = ThemeMode.system;

@override
Widget build(BuildContext context) {

return MaterialApp(
  title: 'Themed App',
  theme: lightTheme,
  darkTheme: darkTheme,
  themeMode: themeMode,
  home: HomeScreen(
    onThemeChange: (mode) {
      setState(() => themeMode = mode);
    },
  ),
);

}
}

This gives your app three modes:
ThemeMode.light
ThemeMode.dark
ThemeMode.system (the smart default)

️ Step 3: Add a Toggle Switch in Your UI
Give users control. At minimum, drop a Switch somewhere in your settings screen.
Example settings widget:
class HomeScreen extends StatelessWidget {
final Function(ThemeMode) onThemeChange;
const HomeScreen({super.key, required this.onThemeChange});

@override
Widget build(BuildContext context) {

final currentBrightness = MediaQuery.of(context).platformBrightness;

return Scaffold(
  appBar: AppBar(title: const Text('Theme Demo')),
  body: Column(
    children: [
      ListTile(
        title: const Text("Light Mode"),
        leading: const Icon(Icons.light_mode),
        onTap: () => onThemeChange(ThemeMode.light),
      ),
      ListTile(
        title: const Text("Dark Mode"),
        leading: const Icon(Icons.dark_mode),
        onTap: () => onThemeChange(ThemeMode.dark),
      ),
      ListTile(
        title: const Text("System Default"),
        leading: const Icon(Icons.phone_android),
        subtitle: Text("Current: $currentBrightness"),
        onTap: () => onThemeChange(ThemeMode.system),
      ),
    ],
  ),
);

}
}

This setup is simple but super effective — and instantly feels like a real, production app.

Step 4: Customize Widgets with Theme Extensions (Pro Level)

Once your app grows, you’ll hit the limits of stock ThemeData. That’s where Theme Extensions come in — letting you build your own reusable style blocks.

Example:
class ExtraColors extends ThemeExtension {
final Color cardBackground;
const ExtraColors({required this.cardBackground});

@override
ExtraColors copyWith({Color? cardBackground}) {

return ExtraColors(cardBackground: cardBackground ?? this.cardBackground);

}

@override
ExtraColors lerp(ThemeExtension? other, double t) {

if (other is! ExtraColors) return this;
return ExtraColors(
  cardBackground: Color.lerp(cardBackground, other.cardBackground, t)!,
);

}
}

Add it inside your theme:

extensions: const [ ExtraColors(cardBackground: Colors.grey), ],

This is the kinda structure big apps use — scalable, organized, clean.

Step 5: Test Like a Pro
Don’t trust your eyes; test with Flutter’s built-in theme toggling.

Run:
flutter run --dart-define=theme=light
flutter run --dart-define=theme=dark

Or in DevTools:
Click the "Device Settings" tab
Flip system theme live
Watch your app glow up

Final Thoughts
Dark mode isn’t "optional polish" anymore. It’s part of the standard UX checklist. Flutter gives you a ridiculously good theming system out of the box — but only if you structure it right. With separate theme files, ThemeMode switching, extensions, and organized color management, your app instantly jumps into that premium tier where everything feels intentional.

Building “R U Ready” – My Flutter Dating App Development Journey

Tue, 04 Nov 2025 11:59:38 +0000

I’ve been working on a new project called R U Ready, a full-featured Flutter dating app, and it’s been one of the most technically enriching experiences in my Flutter journey.

The goal is to build a real-time, scalable, and intuitive dating platform using Flutter + Firebase as the core stack. I started with a modular architecture to ensure clean separation between UI, logic, and data layers — applying principles of Clean Architecture and MVVM for maintainability.

Key modules include:

Authentication Layer using Firebase Auth (Email/Mobile)

Profile Management with dynamic Firestore data binding

Swipe Engine built with custom animation controllers for smooth profile transitions

Chat System using Firestore real-time streams and optimized query listeners

App Theming & State Management implemented via Provider and ChangeNotifier for reactive UI updates

Throughout the process, I’ve learned how to fine-tune Firestore query performance, implement pagination, handle context-safe navigation, and optimize rebuilds using widget lifecycle awareness.

Currently, I’m focusing on extending the architecture for Reels and Group Chat features while integrating AdMob monetization and in-app upgrades.

Every commit teaches me something new about building production-grade apps with Flutter.

Why I Started Creating Models in My Flutter Project

Wed, 20 Aug 2025 18:01:17 +0000

When I was building my music app in Flutter, I began with the “quick and dirty” way of handling data. You know that vibe coding flow — fetch some JSON, dump it in a Map<String, dynamic>, and just wire it up to the UI. It felt fast at first, but it quickly turned into a mess.

Take this example: I was fetching playback data from my service and passing it around like this:

class PlaybackWidget extends StatelessWidget {
  final Map<String, dynamic> playbackData;

  PlaybackWidget({required this.playbackData});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text("Now playing: ${playbackData['title']}"),
        Text("Artist: ${playbackData['artist']}"),
        Text("Mode: ${playbackData['playbackMode']}"),
      ],
    );
  }
}

It worked. But every time I typed playbackData['title'], I felt uneasy. One typo like playbackData['titel'] and boom — runtime error. On top of that, the widget didn’t tell me what kind of data it really expected. Was playbackMode a string? An enum? A number? I had to keep it all in my head.

Switching to Models

After wrestling with this a few times, I finally decided to create a proper model for my playback data.

enum PlaybackMode { repeat, shuffle, normal }

class Playback {
  final String title;
  final String artist;
  final PlaybackMode playbackMode;

  Playback({
    required this.title,
    required this.artist,
    required this.playbackMode,
  });

  factory Playback.fromJson(Map<String, dynamic> json) {
    return Playback(
      title: json['title'],
      artist: json['artist'],
      playbackMode: PlaybackMode.values.firstWhere(
        (e) => e.toString() == 'PlaybackMode.${json['playbackMode']}',
      ),
    );
  }

  Map<String, dynamic> toJson() {
    return {
      'title': title,
      'artist': artist,
      'playbackMode': playbackMode.name,
    };
  }
}

Now my widget looked much cleaner:

class PlaybackWidget extends StatelessWidget {
  final Playback playback;

  PlaybackWidget({required this.playback});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text("Now playing: ${playback.title}"),
        Text("Artist: ${playback.artist}"),
        Text("Mode: ${playback.playbackMode.name}"),
      ],
    );
  }
}

Suddenly everything felt safer. Autocomplete worked, I didn’t worry about typos, and my code told me exactly what kind of data I was dealing with.

What I Learned

Models might look like “extra code” at first, but in reality, they save time and mental energy. Instead of juggling raw maps everywhere, you give your app a solid data structure to lean on.

In my case, once I switched to models in my music app, my code got way easier to maintain. Adding new fields, refactoring, or passing data between widgets stopped being a headache.

So if you’re just hacking away in Flutter and think models are overkill — trust me, they’re not. Future-you will thank present-you for adding them.

How I Paid Off a Little Technical Debt in My Flutter Music App

Fri, 15 Aug 2025 12:08:11 +0000

So here’s the story.
I was facing a technical debt kind of issue in my Flutter music app — my MusicPlaybackService was doing two jobs:

Talking to the audio engine (audio_service + just_audio) to play/pause/skip.
Acting like a ChangeNotifier to update the UI about song lists, current song, etc.

Why this was bad

At first, it felt convenient.
"Why not just let one class handle everything, right?"

But here’s the problem with one giant class doing multiple jobs:

Unnecessary widget rebuilds: Even small playback state changes could cause the entire UI to refresh.
Harder debugging: Was a bug coming from the UI or the audio engine? You never know without digging deep.
Tight coupling: Any change in playback logic risked breaking the UI.
Poor testability: Couldn’t mock or test the UI without pulling in the full audio player.

The Refactor

I split the responsibilities like this:

Before:

MusicPlaybackService
   ↳ Handles playback (play/pause/skip)
   ↳ Stores allSongs, currentSong
   ↳ Notifies UI of changes

After:

MusicPlaybackService   → Only handles audio playback logic
PlaybackProvider       → Holds UI-facing state & notifies widgets

How the new structure works

MusicPlaybackService → Talks to the background audio handler, keeps pure playback logic. No notifyListeners() here.
PlaybackProvider → Watches the service, stores the current song list, play state, etc., and only notifies the UI when something UI-relevant changes.

Benefits I noticed immediately

Fewer unnecessary rebuilds → smoother scrolling, faster tab switches.
Easier debugging → I instantly know whether an issue is in the audio engine or UI.
More modular code → I can swap playback logic without rewriting UI state.
Better testing → I can mock the provider without worrying about actual audio playback.

Lesson learned

If your service class is doing too much — step back and split the responsibilities.
It’s like having a drummer who’s also trying to do the vocals and mix the sound live. Eventually… something’s going to be off-beat.

When to Use setState, Provider, and Consumer in Flutter

Mon, 11 Aug 2025 10:32:32 +0000

Imagine you’re building a music player app
You have:

A Play button on the player screen
A Mini Player at the bottom of the home screen
A Playlist screen showing all songs

Now… Flutter gives you multiple ways to manage data and update the UI.
Three of the most common are:

Think of setState as saying:

“Hey Flutter, just repaint this small part of the UI because something here changed.”

When to use:

Simple, temporary state
Widget-specific changes
Doesn’t need to be shared across the app

Music App Example:
Updating the Play/Pause button icon when the user taps it.

class PlayButton extends StatefulWidget {
  @override
  _PlayButtonState createState() => _PlayButtonState();
}

class _PlayButtonState extends State<PlayButton> {
  bool isPlaying = false;

  void togglePlay() {
    setState(() {
      isPlaying = !isPlaying; // just flip the icon state
    });
  }

  @override
  Widget build(BuildContext context) {
    return IconButton(
      icon: Icon(isPlaying ? Icons.pause : Icons.play_arrow),
      onPressed: togglePlay,
    );
  }
}

Here, only the Play button changes — no need to bother the rest of the app.

Provider — The “shared state manager”

Think of Provider as:

“I have data that multiple widgets need to know about, even if they’re far apart.”

When to use:

App-wide or screen-wide shared data
State needs to survive across multiple widgets/screens
Perfect for your music queue, playback status, user preferences

Music App Example:
Keeping track of the currently playing song so both Mini Player and Full Player Screen update together.

class MusicProvider extends ChangeNotifier {
  String? currentSong;

  void playSong(String song) {
    currentSong = song;
    notifyListeners(); // tell all listening widgets to rebuild
  }
}

// Provide at top level
void main() {
  runApp(
    ChangeNotifierProvider(
      create: (_) => MusicProvider(),
      child: MyApp(),
    ),
  );
}

Now you can read this currentSong anywhere in your app — that’s the magic.

Consumer — The “I only want to rebuild this tiny part” trick

Think of Consumer as:

“I’ll listen to the Provider’s changes, but only rebuild this small widget, not the whole screen.”

When to use:

Optimize performance (avoid rebuilding the entire widget tree)
Listen to changes in one spot only

Music App Example:
Updating just the song title in the mini player without reloading the play button or progress bar unnecessarily.

class MiniPlayer extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.grey[900],
      child: Row(
        children: [
          Consumer<MusicProvider>(
            builder: (context, music, _) {
              return Text(
                music.currentSong ?? "No song playing",
                style: TextStyle(color: Colors.white),
              );
            },
          ),
          Icon(Icons.play_arrow, color: Colors.white),
        ],
      ),
    );
  }
}

Only the Text widget rebuilds when the song changes — everything else stays put.

Why does my Flutter music player jump from 0:00 to actual time? (One-liner fix inside!)

Fri, 08 Aug 2025 05:35:20 +0000

I hit a weird (but common) UI issue in my Flutter music player app:

Whenever I tapped the mini player to open the full screen player, the seek bar would flash 0:00 for a split second — and then jump to the actual current timestamp.

It looked like playback was restarting every time. Spoiler: it wasn’t.

What was happening?

The full screen player uses a StreamBuilder to listen to the current position (Stream). But when the widget builds, that stream hasn’t emitted anything yet — so it shows 0:00 by default.

Only after the stream sends the actual position does the UI update. That tiny delay causes the annoying visual "jump".

initialData: musicService.currentPosition,

Adding this to the StreamBuilder gives it a starting value immediately — the latest position we already have from our service.

So now the UI starts at the right place without waiting for the stream to emit.

No more flicker. No more weird jumps. Just smooth playback

Hope this helps someone else!

Music App Bug: Songs Broke on Switching — Here’s Why

Sun, 03 Aug 2025 22:32:31 +0000

I was facing this annoying issue in Flutter music player:

When you tap songs quickly (like switching from one to another), playback breaks, mini player disappears, and you have to tap again to play. It was 2-3 times out of every 10 switch.

It took me a while to trace it. I tried:

Making our playback function async
Adding delays
Debugging tap triggers

But nothing worked.

Then I found the real culprit:

await _player.stop(); //  this innocent-looking line was breaking everything

The Wrong Code

In the background audio handler's updateQueue() method:

Future<void> updateQueue(List<MediaItem> newQueue) async {
  final newAudioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  await _player.setAudioSource(_playlist, initialIndex: 0);
  await _player.stop(); // ❌ this line breaks playback!

  queue.add(newQueue);
}

What’s the Problem?

This creates a race condition:

setAudioSource() loads and prepares the new song(s).
Immediately after, stop() wipes the loaded source.
So by the time the player is supposed to play, there's nothing left
to play.

This bug especially shows up during rapid song switching, because set -> stop -> play happens too fast and gets out of sync.

The Right Code

Future<void> updateQueue(List<MediaItem> newQueue) async {
  final newAudioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  _playlist.clear();
  _playlist.addAll(newAudioSources);

  await _player.setAudioSource(_playlist, initialIndex: 0);

  if (_player.playing) {
    await _player.play();
  }

  queue.add(newQueue);
}

If you're using just_audio and audio_service, never call stop() right after setAudioSource().
You're basically loading a song and immediately throwing it away.

Let the player handle resets internally unless you truly need to stop everything.

Happy building!

Query Smarter, Not Harder

Sat, 26 Jul 2025 19:58:21 +0000

If you're building a music app with on_audio_query, it’s tempting to call querySongs() everywhere—home screen, playlists, search, etc. But this means repeated storage scans → slower UI, battery drain, and unnecessary complexity.

The Wrong Way – Querying Every Time

final OnAudioQuery audioQuery = OnAudioQuery();

Future<List<SongModel>> getSongs() async {
  return await audioQuery.querySongs(); // Called in every screen
}

In each screen:

final songs = await getSongs(); // Repeats scan again

Fetch once in a service (e.g., MusicPlaybackService):

class MusicPlaybackService extends ChangeNotifier {
  List<SongModel> _allSongs = [];

  Future<void> loadSongs() async {
    final OnAudioQuery query = OnAudioQuery();
    _allSongs = await query.querySongs();
    notifyListeners();
  }

  List<SongModel> get allSongs => _allSongs;
}

Provide it globally:

runApp(
  ChangeNotifierProvider(
    create: (_) {
      final service = MusicPlaybackService();
      service.loadSongs(); // Fetch once
      return service;
    },
    child: MyApp(),
  ),
);

Reuse anywhere without re-querying:

final allSongs = context.watch().allSongs;

Benefits

No repeated disk access.
Faster UI transitions (playlist, search, player use the same list).
Centralized state → easier maintenance.

UI issues are beautiful.....

Fri, 25 Jul 2025 10:29:26 +0000

Ever had your Flutter screen layout shift or break when your text changes length?

The Problem

In my music player screen, long song titles caused the UI to push down — shifting the seek bar & controls, or worse, throwing an overflow error.

Here’s how the screen was built without LayoutBuilder:

// Problematic layout
return Padding(
  padding: const EdgeInsets.all(20),
  child: Column(
    children: [
      const SizedBox(height: 80),
      AnimatedBeatCircle(size: 300, isPlaying: true),

      // Title (may be 1 or 2 lines)
      Text(
        mediaItem.title,
        maxLines: 2,
        overflow: TextOverflow.ellipsis,
      ),

      const SizedBox(height: 10),
      // Seek bar + playback controls follow
      ...
    ],
  ),
);

Issue:

If the title is short → empty space.
If it’s long → seek bar/control buttons shift or overflow.
UI feels unstable between different songs.

The Fix: Use LayoutBuilder + Expanded

By wrapping the layout in a LayoutBuilder and explicitly splitting the screen into:

Top (flexible): Beat circle, title, artist

Bottom (fixed): Seek bar, playback controls

We pin the bottom UI and allow the top to adapt safely.

// Fixed layout
return LayoutBuilder(
  builder: (context, constraints) {
    return Column(
      children: [
        Expanded(
          child: Padding(
            padding: const EdgeInsets.all(20),
            child: Column(
              children: [
                AnimatedBeatCircle(size: 300, isPlaying: true),
                const SizedBox(height: 20),
                Text(
                  mediaItem.title,
                  maxLines: 2,
                  overflow: TextOverflow.ellipsis,
                ),
                Text(mediaItem.artist ?? ''),
              ],
            ),
          ),
        ),

        // Bottom stays pinned no matter what
        Padding(
          padding: const EdgeInsets.symmetric(horizontal: 20.0),
          child: Column(
            mainAxisSize: MainAxisSize.min,
            children: [
              Slider(...),
              Row(...), // duration labels
              Row(...), // controls
            ],
          ),
        ),
      ],
    );
  },
);

Result:

Layout is predictable
Playback controls stay pinned
UI looks great no matter how long the song title is!

Fixing a Tricky Playback Issue in My Flutter Music App

Thu, 24 Jul 2025 10:37:42 +0000

I recently ran into a subtle but super frustrating issue in my Flutter music player app using just_audio and audio_service. It had to do with updating the playback queue when selecting a new song — and I want to share how I fixed it.

The Problem

Let’s say I have 5 songs:

a  b  c  d  e

Here's what was happening:

I open the app and click on song b.

Music starts playing . I can see the notification with controls.

I click next in the notification → it moves to c. Perfect!

I go back to the app and tap on song a.

Now... song plays but playback control like next and previous don't work.

So clearly, something went wrong when I tried to load a new playlist and song from the UI.

My (Buggy) Code

This is how I was updating the queue in my AudioHandler:

Future<void> updateQueue(List<MediaItem> newQueue) async {
  await _player.stop();              // Stop current audio
  _playlist.clear();                 //  Clear existing playlist

  final audioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  _playlist.addAll(audioSources);   //  Add new items to old list
  await _player.setAudioSource(_playlist); //  Reuse the same playlist

  queue.add(newQueue);              //  Update the queue
}

The Hidden Issue

I was clearing and modifying the same _playlist instance that was already connected to the player.

just_audio doesn't always like it when you mutate a ConcatenatingAudioSource after it's been set — especially if it's already active in playback.

That caused inconsistent behavior.

The Fix: Use a Fresh Playlist Instance

Instead of modifying the existing _playlist, I now create a brand new ConcatenatingAudioSource every time I update the queue:

@override
Future<void> updateQueue(List<MediaItem> newQueue) async {
  await _player.stop(); // Stop safely

  final newAudioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  final newPlaylist = ConcatenatingAudioSource(children: newAudioSources); // Fresh playlist

  await _player.setAudioSource(newPlaylist); // Clean set

  _playlist.clear();         // Optional: if you track items
  _playlist.addAll(newAudioSources);

  queue.add(newQueue);       // Update queue after setting source
}

When working with just_audio and audio_service, always pass a new AudioSource instance when switching playlists or queues.
Avoid mutating an existing one after it’s been assigned to the player. Otherwise, you'll run into strange bugs like:

Next/Previous buttons breaking
Playback getting stuck
Notifications going out of sync

One wrong activity caused me 10+ hours of debugging

Tue, 22 Jul 2025 10:48:31 +0000

The music app I vibe coded is working fine but I wanted to improve it. So I decided to add some extra features like playing in the background so that I can control playback from notification bar. Cool right ?

I also wanted to refactor my code because It would give me huge pain if I scale it just from here. I started working on it, I fixed all errors of refactoring but when I say

flutter run

It gives me an error which forced me scratch my head for days.

The Activity class declared in your AndroidManifest.xml is wrong...

Now I'm trying to fix things in xml file which I needed to actually make change in MainActivity.kt . The only thing I needed to replace below code

class MainActivity: FlutterFragmentActivity() {}

with this

class MainActivity: AudioServiceFragmentActivity() {}

Finally I'm a bit relieved. I did learn a lot as I actually reverse engineered code, refactored so much just to find answers. Now I really need a break lol.....................

After facing weird permission issues, I built my own music app in 6 hours.

Mon, 14 Jul 2025 06:13:19 +0000

Ever noticed how even the simplest apps want access to everything?
I just wanted to play music — not hand over my call logs.

Even lightweight music players come loaded with creepy permission requests. Contacts? Call data? Overlay access? Just to hit play on a song?

It didn’t sit right with me.
So I decided to build my own.

1: Why I Chose to Build My Own Music App

I’ve always had a very specific music taste — mostly soulful tracks, spiritual sounds, and some of 90s nostalgia.

Sure, I could stream them on Spotify or YouTube like everyone else. But I’ve always preferred keeping my own MP3 collection — offline, in my control, with zero interruptions.

The real issue began when I started noticing how these music apps behave.

They demand weird permissions.
They push random ads. That I understand, I'm fine with it.

Last week, I finally snapped. I figured — why not just make my own app?

I’d been meaning to learn mobile development anyway, so this felt like the perfect excuse.

After checking out a few frameworks, I settled on Flutter — lightweight and flexible. My laptop isn’t built for Android Studio (tried that once, it basically gave up), so I kept things minimal.

Set up took an hour or two. I plugged in my phone, enabled developer mode, and got my first “Hello World” up and running.

From there, it just flowed — I picked up Dart, started testing small things with help from AI, and slowly began to see my idea take shape.

2: Only Building What I Actually Needed

Once I had the basics working, I tested it out with a single MP3 file. Just dropped it into the assets folder and tried playing it through the app. It worked.

That small win gave me the push to go further.

Next up — scanning local storage for all my saved music files. I added logic to pull out MP3s from the phone’s directories, and once that was done, I layered in the essentials:

Play / Pause

Skip

Auto-play

Total duration

Current time tracking

No recommendations. No suggestions. No sneaky tracking.
Just clean, simple playback — the way I wanted it.

The UI is still very barebones, and honestly, that’s fine for now. I’m slowly working on polishing it up. But I’m clear on one thing:
It’ll stay lightweight. No junk. No shady permissions.

Just a music player that respects your privacy — and plays your songs.

3 : What’s Next

For now, I’m just refining the app to suit my personal use. Clean UI, maybe dark mode, and a couple of nice-to-have touches that I actually care about. I might upload it to the Play Store at some point — not because I want to compete with big apps, but just to share something that feels simple and respectful of users.

Honestly, building this was fun. More than that, it felt right. I got to learn, create, and finally use an app that doesn’t ask me for things it shouldn’t.

But now I’m curious…
Have you ever felt weird giving an app permission to read your call logs just to play music?
What problems have you run into?
And hey — do you still listen to local MP3s, or are you all-in on streaming?

Reelora

Thu, 03 Jul 2025 08:09:19 +0000

Body Highlights:

Journey of building Reelora from scratch

Key features (Smart Search, Pagination, Firebase Login, TMDB API integration)

UI decisions (Dark Mode, shimmer loaders, scroll-based triggers)

Handling offline states and in-app updates

Open testing feedback loop & future plan

CTA:
Try the app on Play Store (Open Testing):
https://play.google.com/store/apps/details?id=com.dk.reelora

Live on Play Store this Sunday
iOS coming next

Coder Legion - Recent posts tagged flutterdev

Automate Unused Asset Cleanup in Flutter

What cleanbev actually does

The gap: someone could forgot to cleanup some assets before pushing

Using it

Inputs

Two ways to run it

Try it

flutter_skin — Live Remote Skin Engine Demo | Change Flutter Colors Without Rebu

Fskin alpha version is Live

Eunify: Cross-Platform Continuity System for Android and MacOS

The Coordinated BLoC Pattern in Flutter — A Practical Guide

The Coordinated BLoC Pattern in Flutter — A Practical Guide

What Problem Does This Solve?

Mental Model

Architecture

Implementation

1. Events

Event Intent

2. States

3. The Coordination BLoC

The key idea

Dependency Injection (GetIt)

BLoC Providers

The Screen

Mistakes to Not Make

Mistake 1: Registering Handlers After Calling add()

Mistake 2: Using registerFactory

Rule

Mistake 3: Forgetting to Cancel Stream Subscriptions

Mistake 4: Forgetting .take(1)

Mistake 5: Mixing GetIt and context.read

Mistake 6: Leaving Half the Logic in the Screen

The Hidden Cost: Forced Singletons

When To Use This Pattern

When NOT To Use It

The Simpler Alternative

Summary

Optimizing Flutter Apps: A Deep Dive into Dart DevTools

1. Flutter Inspector — The Widget Tree X-Ray

Slow Animations

Guidelines & Baselines

Highlight Repaints

Highlight Oversized Images

2. App Size Analysis — Know What You're Shipping

Dominator Tree

Call Graph

3. Performance & Jank Tracking — Chasing Smooth Frames

4. Network & CPU Profiling — Under the Hood

Network Tab

CPU Profiler

5. Memory & Debugger — Stability Under Pressure

Memory Tab

Debugger

Key Principles to Take Away

Profile Mode Is Non-Negotiable

Do Not Optimize Blindly

Older Devices Are Your Benchmark

Why Your Flutter UI Freezes: Understanding Async, Await, Compute & Isolates

The Uncomfortable Truth: Dart Is Single-Threaded

The Biggest Misconception in Flutter Development

So What Does Async-Await Actually Do Well?

The Dart Event Loop (And Why It Matters)

Microtask Queue (High Priority)

Event Queue (Normal Priority)

The JSON Parsing Trap

The Fix: Isolates

compute(): Isolates Without the Ceremony

When compute() Isn't Enough: Persistent Isolates

The Decision Framework

Real-World Example: Crypto Wallet Transaction Feed

Common Myths, Killed

The Mental Model That Fixes Everything

Everything about Stateful & Stateless widgets in Flutter

What Is a Widget, Really?

Stateless Widgets

The const Optimization

Stateful Widgets

The Stateful Lifecycle

createState()

Mistake 1: Registering Handlers After Calling `add()`

Mistake 2: Using `registerFactory`

Mistake 4: Forgetting `.take(1)`

Mistake 5: Mixing `GetIt` and `context.read`

`compute()`: Isolates Without the Ceremony

When `compute()` Isn't Enough: Persistent Isolates

The `const` Optimization

`createState()`

`initState()`

`didChangeDependencies()`

`build()`

`setState()`

`didUpdateWidget()`

`deactivate()`

`dispose()`

`LocalKey`

`GlobalKey`

The `mounted` Property and Async Safety