Forem: Viet, Nguyen Tuan

The Most Comprehensive Event Rate Limiting Solution for Flutter & Dart Ecosystem

Viet, Nguyen Tuan — Wed, 04 Feb 2026 03:12:08 +0000

The Problem You're Facing

Are you implementing debounce/throttle manually with Timer?

class _SearchState extends State<SearchPage> {
  Timer? _debounceTimer;

  void onSearchChanged(String query) {
    _debounceTimer?.cancel();
    _debounceTimer = Timer(Duration(milliseconds: 300), () {
      _callSearchAPI(query);
    });
  }

  @override
  void dispose() {
    _debounceTimer?.cancel(); // Forget this = memory leak!
    super.dispose();
  }
}

3 critical issues:

❌ Memory leak if you forget to dispose
❌ Race condition - old requests return after new ones
❌ Code duplication every time you need debounce

Solution: flutter_debounce_throttle

An all-in-one library with 360+ tests and 95% coverage that solves everything:

✅ Automatic lifecycle management

class _NewWayState extends State<NewWay> {
  final debouncer = Debouncer(duration: 300.ms);

  void search(String q) {
    debouncer(() => api.search(q)); // That's it!
  }
  // No need to dispose anything!
}

✅ Proper async handling

final controller = ConcurrentAsyncThrottler(
  mode: ConcurrencyMode.replace, // Auto cancel old requests
);

void onSearch(String query) {
  controller(() async {
    final results = await api.search(query);
    setState(() => searchResults = results);
  });
}

✅ Ready-to-use widgets

// Anti-spam button (1 line!)
ThrottledInkWell(
  onTap: () => processPayment(),
  child: Text('Pay \$99'),
)

// Search with loading state
DebouncedQueryBuilder<List<User>>(
  onQuery: (text) async => await searchUsers(text),
  builder: (context, search, isLoading) => TextField(onChanged: search),
)

Quick Comparison

Feature	This lib	easy_debounce	rxdart	Manual Timer
Auto-dispose	✅	❌	⚠️	❌
Async support	✅	❌	✅	❌
Race condition handling	✅	❌	⚠️	❌
Rate Limiter	✅	❌	❌	❌
Flutter Widgets	✅	❌	❌	❌
Server-side (Pure Dart)	✅	❌	❌	✅
Dependencies	0	0	Many	0

Real-World Use Cases

📱 Prevent double-click

ThrottledInkWell(
  duration: 2.seconds,
  onTap: () => processPayment(),
  child: Text('Buy \$99'),
)
// User taps 10 times → only 1 is processed

🔍 Search autocomplete

final debouncer = Debouncer(duration: 300.ms);
TextField(onChanged: (text) => debouncer(() => search(text)))
// Only call API when user stops typing for 300ms

🖥️ Batch DB writes (Backend)

final batcher = BatchThrottler(
  duration: 2.seconds,
  maxBatchSize: 100,
  onBatchExecute: (logs) => db.insertBatch(logs),
);
batcher(() => logEntry);
// 1000 calls → 10 batches → 90% less DB load

💰 Rate limit API

final limiter = RateLimiter(maxTokens: 1000, refillRate: 100);
if (!limiter.tryAcquire()) return 'Rate limit exceeded';
await callOpenAI(prompt);

Advanced Features

🏢 Distributed Rate Limiting (v2.4+)

Rate limiting across multiple server instances with Redis:

final limiter = DistributedRateLimiter(
  key: 'user:$userId',
  store: RedisRateLimiterStore(redis: redis),
  maxTokens: 100,
  refillRate: 10,
);
if (!await limiter.tryAcquire()) return Response(statusCode: 429);

🧹 Auto-cleanup (v2.3+)

Automatically cleanup unused limiters to prevent memory leaks with dynamic IDs:

class PostController with EventLimiterMixin {
  void onLike(String postId) {
    debounce('like_$postId', () => api.like(postId));
  }
}
// Auto-remove unused limiters after 10 minutes
// User scrolls through 1000 posts - no OOM crash!

🎮 ThrottledGestureDetector

Drop-in replacement for GestureDetector with automatic throttling:

ThrottledGestureDetector(
  onTap: () => handleTap(),
  onPanUpdate: (details) => updatePosition(details.delta),
  child: MyWidget(),
)
// Supports 40+ gesture callbacks with auto throttling!

Throttle vs Debounce?

Throttle: Execute immediately, lock for 300ms, ignore events during lock

Use: Button clicks, scroll events

Debounce: Wait for user to stop for 300ms before executing

Use: Search input, form validation

4 Concurrency Modes:

drop: Ignore new task if busy
replace: Cancel old task, run new one (perfect for search)
enqueue: Queue tasks
keepLatest: Keep only running task + latest task

Mixin for State Management

Works with Provider, GetX, Bloc, Riverpod...

class SearchController extends GetxController with EventLimiterMixin {
  void search(String query) {
    debounceAsync('search', () async {
      final results = await api.search(query);
      update(results);
    }, mode: ConcurrencyMode.replace);
  }

  @override
  void onClose() {
    cancelAll(); // Auto cleanup
    super.onClose();
  }
}

Production Quality

✅ 360+ tests with 95% coverage
✅ Zero dependencies (only meta)
✅ Type-safe (full generic support)
✅ Memory-safe (verified with LeakTracker)
✅ Cross-platform (Mobile, Web, Desktop, Server)

Installation

# Flutter App
dependencies:
  flutter_debounce_throttle: ^2.4.2

# Flutter + Hooks
dependencies:
  flutter_debounce_throttle_hooks: ^2.4.2

# Pure Dart (Server/CLI)
dependencies:
  dart_debounce_throttle: ^2.4.2

Conclusion

If you're using:

❌ Manual Timer → Memory leak risk
❌ easy_debounce → Missing async support
❌ rxdart only for debounce → Overkill dependencies

Then flutter_debounce_throttle is the solution:

✅ Memory-safe by default
✅ Production-tested (360+ tests)
✅ Universal (Flutter + Dart backend)
✅ Zero dependencies

Links:

📦 Pub.dev: https://pub.dev/packages/flutter_debounce_throttle
📚 GitHub: https://github.com/brewkits/flutter_debounce_throttle
🐛 Issues: https://github.com/brewkits/flutter_debounce_throttle/issues

Technical review of flutter_debounce_throttle v2.4.2

Mastering Native Interop in KMP: Why KRelay is the “Ultimate Bridge” Multiplatform

Viet, Nguyen Tuan — Wed, 04 Feb 2026 02:32:54 +0000

KRelay: The Native Interop Bridge for Kotlin Multiplatform

KMP isn't just about sharing code; it's about managing Native UI safely. KRelay is the tool that makes it possible.

In my 15 years of mobile engineering — from J2ME to Flutter and now Kotlin Multiplatform (KMP) — one "final boss" always remains: Native Interop. How do you trigger native UI components like Toasts, Camera, or Navigation from shared code without causing memory leaks, threading crashes, or losing events during screen rotation?

Enter KRelay — a library designed with the Unix Philosophy: "Do one thing and do it well."

The Core Value: Why KRelay?

Traditionally, calling platform-specific code from shared ViewModels requires complex patterns:

Boilerplate Overload: You often need MutableSharedFlow + emit + collectAsState + LaunchedEffect just for a simple notification.
Memory Leaks: Strong references to an Activity or ViewController in shared code prevent garbage collection, leading to OutOfMemoryError.
Event Loss: If you dispatch a command while the UI is recreating (e.g., during rotation), that event is often lost forever.

KRelay solves these issues through three fundamental pillars:

1. Weak Registry

KRelay automatically manages WeakReferences to your platform implementations. When a ViewController or Activity is destroyed, the reference is cleared automatically.

2. Sticky Queue

If your ViewModel dispatches an action while the UI is not ready (e.g., during a cold start or rotation), KRelay queues the action and replays it as soon as the UI registers.

3. Safe Dispatch

All commands are automatically executed on the platform's Main/UI thread (using Looper on Android and GCD on iOS), preventing threading-related crashes.

The "Ultimate Combo": KRelay + Adapter Pattern

One of the biggest hurdles in 2026 is that many modern Swift libraries (like Lottie or Alamofire) are "Pure Swift" and are not visible to Kotlin's cinterop.

The Adapter Pattern combined with KRelay is the most powerful solution:

The Strategy: Define an interface in commonMain (e.g., NavFeature). Create a Swift Adapter that implements this interface and calls your 3rd-party Swift library.
The Benefit: Your ViewModel stays pure and testable. KRelay acts as the safe messenger, handling the threading and lifecycle complexities of the native implementation.

Technical Deep-Dive

KRelay is a high-performance Runtime bridge, avoiding the complexity and build-time overhead of KSP or reflection.

Installation

Add the library to your shared module's dependencies:

// shared/build.gradle.kts
commonMain.dependencies {
    implementation("dev.brewkits:krelay:1.0.0")
}

Core API Usage

Defining and using a feature is straightforward:

// 1. Define (commonMain)
interface ToastFeature : RelayFeature {
    fun show(message: String)
}

// 2. Dispatch (Shared Logic)
KRelay.dispatch<ToastFeature> { it.show("Hello!") }

// 3. Register (Android/iOS Native)
KRelay.register<ToastFeature>(AndroidToastImpl(context))

Advanced Features

Priority System: Use ActionPriority (LOW to CRITICAL) to ensure important events like error dialogs are replayed first.
Performance Metrics: Monitor dispatch counts and queue statistics per feature to optimize your app.
Safe Clean-up: Use clearQueue<T>() in your ViewModel's onCleared() to prevent lambda capture leaks.

Project Architecture

KRelay's internal structure is optimized for platform-specific efficiency:

KRelay/
├── commonMain/        # Core registry and queue logic
│   └── KRelay.kt, Priority.kt, Metrics.kt
├── androidMain/       # Android Looper and ReentrantLock
│   └── Lock.android.kt, MainThreadExecutor.android.kt
└── iosMain/           # iOS GCD and NSRecursiveLock
    └── Lock.ios.kt, MainThreadExecutor.ios.kt, KRelay+Extensions.swift

Important Limitations

Process Death: KRelay's queue is in-memory and does not survive process death. Never use it for critical transactions like payments.
Singleton Scope: While simple for most apps, large Super Apps should use Feature Namespacing to avoid registry conflicts.

Verdict

KRelay isn't trying to be a state manager or a background worker. It is a focused, reliable messenger for one-way UI commands. By combining KRelay with the Adapter Pattern, you gain the flexibility to use any native library while maintaining the cleanest shared code architecture possible.

Start building safer KMP apps today.

GitHub Repository: github.com/brewkits/krelay

Tags: #KotlinMultiplatform #KMP #NativeInterop #AndroidDev #iOSDev #CleanArchitecture

Grant: The “No-Nonsense” Permission Manager for Kotlin Multiplatform

Viet, Nguyen Tuan — Wed, 04 Feb 2026 02:26:24 +0000

Stop Fighting with Android Manifests and Info.plist. Request permissions in shared code like a boss.

After solving the UI Command problem, I ran into the next biggest wall in Kotlin Multiplatform (KMP) development: Runtime Permissions.

The Current Chaos

Android: You need ActivityResultLauncher, ContextCompat.checkSelfPermission, manifest entries, and complex logic for shouldShowRequestPermissionRationale.

iOS: You need AVCaptureDevice.requestAccess, PHPhotoLibrary, delegates, and async completion blocks.

The Shared Problem: How do you unite these two chaotic worlds into a clean, linear flow in your ViewModel?

Enter Grant.

🎯 What is Grant?

Grant is a permission manager built specifically for Kotlin Multiplatform, designed with a "Headless & Coroutines-First" philosophy.

❌ It is NOT a UI library (it won't force ugly popups on you)
✅ It is a System Engine that abstracts the operating system, giving you full control over the UI/UX while it handles the dirty work

🏆 Why Grant is the "De-Facto Standard" for 2026

1️⃣ Unified API (One Enum to Rule Them All)

Forget about checking Android SDK versions or iOS authorization statuses manually. Grant abstracts everything into a simple, type-safe Enum.

You don't need to know the difference between Android API 33 and iOS 16 under the hood. Grant handles it.

2️⃣ Linear Logic (Suspend Functions)

Permissions are inherently transactional: Ask → Wait → Result.

Instead of callbacks (which lead to "Callback Hell") or complex Delegates, Grant uses suspend functions natively. Your logic runs top-to-bottom, making it incredibly readable and maintainable.

3️⃣ Smart Status Handling

The hardest part of permissions isn't asking; it's handling when the user says "No, and don't ask again."

Android: The system dialog stops appearing
iOS: The status becomes .denied

Grant detects this state automatically across platforms, allowing you to guide the user to System Settings instantly.

🛠️ The "Clean" Architecture Way

Let's look at the difference between the traditional way and the Grant way.

❌ The Old Way (The Pain)

You have to inject an Activity into your ViewModel (causing leaks), or create complex interfaces in commonMain and implement them separately for each platform. Your code becomes fragmented and hard to test.

✅ The Grant Way (The Solution)

You handle permissions directly in your Shared Code (ViewModel/UseCase), with zero Android Context or iOS Delegates required.

class CameraViewModel : ViewModel() {
    fun onCaptureClicked() {
        viewModelScope.launch {
            // 1. Check current status
            val status = Grant.check(Permission.CAMERA)
            when (status) {
                PermissionStatus.GRANTED -> openCamera()

                PermissionStatus.DENIED -> {
                    // 2. Request (Suspends until user decides)
                    val result = Grant.request(Permission.CAMERA)
                    if (result.isGranted) {
                        openCamera()
                    } else {
                        showErrorUI("We need camera access to take photos.")
                    }
                }

                PermissionStatus.PERMANENTLY_DENIED -> {
                    // 3. Handle "Don't ask again" scenario
                    showSettingsDialog()
                }
            }
        }
    }
}

🚀 The Killer Feature: Handling "Permanently Denied"

A major UX pain point occurs when a user accidentally clicks "Don't ask again" (Android) or denies permission (iOS). Subsequent requests fail silently, making your app look broken.

Grant solves this with a single line of code:

if (Grant.status(Permission.CAMERA) == PermissionStatus.PERMANENTLY_DENIED) {
    // Opens the specific System Settings page for your app
    Grant.openSettings()
}

This is the polish of a library built by product veterans: It solves the UX problem, not just the technical one.

📊 Technical Face-Off: Grant vs. The World

Let's break down exactly why Grant outperforms traditional methods (like Moko-Permissions or Accompanist):

1. Configuration & Setup

Approach	Experience
Traditional	❌ High friction. Often requires binding to an Activity or wrapping your Compose UI in a special Provider.
Grant	✅ Zero-Config. Just add the dependency. It automatically hooks into the lifecycle context-aware components.

2. Control Flow

Approach	Experience
Traditional	❌ Relies on Callbacks or reactive Streams/Flows, which can complicate simple transactional logic.
Grant	✅ Uses Suspend Functions. This keeps your business logic linear and easy to reason about.

3. Architecture Compatibility

Approach	Experience
Traditional	❌ Tightly coupled to the UI Layer. Hard to use inside a ViewModel or Domain UseCase.
Grant	✅ Headless. It works perfectly inside ViewModels, keeping your UI code dumb and your logic code smart.

4. Boilerplate

Approach	Experience
Traditional	❌ Requires passing Context or Activity references manually.
Grant	✅ Context-Aware. It handles the platform context injection under the hood, keeping your shared code pure.

👨‍💻 Final Verdict

In modern software architecture, specifically KMP, we strive for "Platform Transparency." Your business logic shouldn't care if it's running on an iPhone 15 or a Pixel 9.

Grant is the perfect abstraction layer to achieve this transparency for permissions. It hides the ugly, fragmented platform APIs and gives you a clean, powerful, and safe toolset.

If you are looking for a "Complete & Elite" permission solution for your next KMP project, Grant is the way to go.

🔗 Links

👉 GitHub Repo: https://www.github.com/brewkits/Grant

Tags: #KotlinMultiplatform #KMP #AndroidDev #iOSDev #Permissions #CleanArchitecture

KMP WorkManager: Enterprise-Grade Background Tasks for Kotlin Multiplatform

Viet, Nguyen Tuan — Thu, 22 Jan 2026 01:57:51 +0000

We all love Kotlin Multiplatform (KMP). Sharing business logic, networking, and data layers between Android and iOS is a dream come true. But let's be honest: there is one specific area where the "write once, run everywhere" dream often turns into a fragmented nightmare.

Background Processing.

If you are coming from Android, you are used to WorkManager. It's robust, persistent, and handles constraints like "only run when charging" beautifully.

Then you port your logic to iOS. You encounter BGTaskScheduler.

Suddenly, you realize:

Android tasks are persistent; iOS tasks are opportunistic and can be killed at any moment.
Android supports complex constraints; iOS is extremely strict (mostly just network).
The worst part: If an iOS user force-quits the app, your background task logic might be dead in the water, potentially corrupting data if you were halfway through a multi-step chain.

I spent months battling these discrepancies in enterprise projects. I wanted the reliability of Android's WorkManager, but on both platforms.

The existing libraries were mostly thin wrappers. They let you schedule a task, but they didn't solve the hard engineering problems of state restoration and OS resource limits.

So, I built KMP WorkManager.

The "Gap" in the Ecosystem

When I analyzed the existing solutions, I found they were missing critical "Enterprise-grade" features required for production apps:

Chain State Restoration: What happens if a multi-step workflow (Download → Process → Upload) gets killed by iOS at step 2? Most libs just restart from step 1 next time, wasting battery and data.

Reliability vs. Speed: Writing to UserDefaults or flat files on iOS is fine for small apps, but what if you have a queue of 500 offline analytics events?

Developer Experience: I didn't want to write Swift callbacks. I wanted a pure Kotlin API.

I decided to treat iOS constraints not as a bug, but as a feature to be managed gracefully.

Introducing KMP WorkManager

This isn't just a wrapper. It's a full-fledged task orchestration engine built for reliability.

Here is how you schedule a periodic sync task. Look familiar?

// Shared Code (CommonMain)
val result = scheduler.enqueue(
    id = "data-sync",
    trigger = TaskTrigger.Periodic(intervalMs = 15.minutes.inWholeMilliseconds),
    workerClassName = "SyncWorker",
    constraints = Constraints(
        requiresNetwork = true,
        // On Android, this uses Foreground Service
        // On iOS, this requests BGProcessingTask
        isHeavyTask = true
    )
)

One API. Both platforms. Zero platform-specific boilerplate in your ViewModels.

Under the Hood: Engineering for Stability

I want to highlight three specific technical decisions that make this library production-ready.

1. The O(1) Append-Only Queue

On iOS, file I/O can become a bottleneck when managing persistent queues. In early versions, we saw performance hits when queueing hundreds of tasks because of O(N) serialization.

In v2.1.0, we rewrote the iOS persistence layer to use an Append-Only Queue architecture with atomic operations.

Enqueue: O(1) complexity (appending to file).
Dequeue: O(1) complexity (pointer arithmetic).

The Result: Benchmarks showed a 13x to 40x performance improvement over standard serialization methods. Enqueueing 100 chains dropped from ~1000ms to just 24ms.

2. Graceful Shutdown & State Restoration

This is my favorite feature. iOS gives background tasks about 30 seconds (or slightly more for processing tasks). If you run out of time, the system kills you.

We implemented a Graceful Shutdown mechanism. When iOS signals expiration:

The library intercepts the signal.
It creates a "savepoint" for your current Task Chain.
It halts execution cleanly.
Next time the app runs, it resumes exactly from the last successful step.

No data loss. No restarted downloads.

3. Transparent Exact Alarms

Android has AlarmManager for exact timing. iOS doesn't allow background code execution at exact times (only notifications).

Instead of faking it or failing silently, the library introduces ExactAlarmIOSBehavior. You decide explicitly how to handle this platform discrepancy:

scheduler.enqueue(
    id = "morning-reminder",
    trigger = TaskTrigger.Exact(time),
    workerClassName = "ReminderWorker",
    constraints = Constraints(
        // Explicitly handle iOS limitations
        exactAlarmIOSBehavior = ExactAlarmIOSBehavior.SHOW_NOTIFICATION
    )
)

SHOW_NOTIFICATION: Just show a UI alert (Apple approved).
ATTEMPT_BACKGROUND_RUN: Try to run code (Best effort, not guaranteed).
THROW_ERROR: Fail fast during dev to catch logic errors.

My Commitment to Maintenance

This project is not a weekend hobby. It was born out of frustration in production environments and is built to stay.

Tests: The library currently has 236+ Unit & Integration Tests running on CI.
Documentation: We have extensive docs on migration, best practices, and architecture.
Roadmap: We are actively working on v2.2.0 (File Coordination Strategy) and v2.3.0 (SQLDelight integration).

Try it out

The library is available on Maven Central.

implementation("dev.brewkits:kmpworkmanager:2.3.0")

I've included a comprehensive Demo App in the repo that simulates real-world scenarios like Chains, Failures, and Push Notifications so you can see it in action before integrating.

👉 Check out the GitHub Repository

I'd love to hear your feedback. If you are struggling with background tasks in KMP, give this a spin and let me know if it eases your pain!

Cover image credit: Generated with DALL-E, edited by author.