DEV Community: ROCI

Offline-First Flutter Architecture

ROCI — Sun, 06 Sep 2026 13:03:25 +0000

Deep dive into offline caching with Hive and SQLite.

Why Your Flutter Background Isolates Crash on Android (And How I Fixed It)

ROCI — Sat, 05 Sep 2026 17:02:02 +0000

Building an offline-first task manager with Flutter and native Android widgets means dancing on the edge of two worlds. Recently, while shipping update 0.2.2+63 for ROCIs Tasks, I hit a classic multi-threading trap that’s easy to stumble into when dealing with background isolates, platform channels, and cloud sync.

Here is how I debugged it, solved it, and finally closed the loop on true two-way Google Tasks syncing.

The Mystery: Background Crashes and Broken Tests

While working on background task completion handlers, my app started throwing intermittent runtime errors on Android. The culprit? WidgetsBinding.instance.

If you've ever tried to trigger state updates, platform channel calls, or bindings initialization inside a detached background isolate, you know the pain. Flutter expects a UI binding to be initialized on the main thread. When a background handler fires asynchronously, WidgetsBinding.instance can be null or completely unstable depending on the lifecycle state and platform.

To make matters worse, my test suite was throwing a couple of red flags: a regex validation failure on my new version string format (0.2.2+63), and a Mocktail type-casting error because I hadn't stubbed getGoogleAccessToken() during startup synchronization tests. Standard indie dev Tuesday.

The Root Cause

The Isolate Trap: WidgetsBinding.instance.platformDispatcher relies heavily on an active UI view and bound Flutter engine lifecycle. In background execution contexts (like handling quick actions or background sync triggers), that binding simply isn't guaranteed to exist.
Mocking Blind Spots: As features grow, mocking external auth tokens in unit tests becomes brittle if your initialization sequence suddenly demands them before the mock is set up.

The Solution & Code Architecture

1. Ditching `WidgetsBinding` for Background Tasks

The fix for the background isolate issue was surprisingly clean. Instead of reaching for the UI-bound dispatcher, drop down to the global singleton PlatformDispatcher:

// Before (Unstable in background isolates)
// final dispatcher = WidgetsBinding.instance.platformDispatcher;

// After (Safe globally, even off-main-thread)
final dispatcher = PlatformDispatcher.instance;

This simple swap completely stabilized my background handlers without touching the main UI lifecycle.

2. Bulletproofing Google Tasks Back-Sync

With background stability restored, I tackled true two-way sync. Users expect changes made directly inside Google Tasks (completions, uncompletions, and deletions) to reflect instantly in ROCIs Tasks.

I expanded the GoogleTasksService with paginated task retrieval, ensuring we pull completed and hidden items, and implemented syncGoogleTasksToLocal() inside the TaskProvider:

Future<void> syncGoogleTasksToLocal(List<GoogleTask> remoteTasks) async {
  for (var remote in remoteTasks) {
    final local = _localTasks.firstWhereOrNull((t) => t.googleId == remote.id);

    if (remote.isCompleted && local?.isCompleted == false) {
      await _markLocalCompleted(local!.id);
    } else if (!remote.isCompleted && local?.isCompleted == true) {
      await _markLocalActive(local!.id);
    }
  }

  // Handle deletions: tasks present locally with a Google ID but missing remotely
  await _reconcileDeletedTasks(remoteTasks);
}

I hooked this reconciliation logic directly into app startup (syncWithCloud), manual settings triggers, and lifecycle tab-switches on both mobile and web (home_screen.dart / web_home_screen.dart).

Key Lessons for Other Devs

Beware of Isolate Assumptions: Never assume UI-bound singletons like WidgetsBinding are available outside the main thread. Use PlatformDispatcher.instance for thread-safe global access.
Test Your Version Strings: If you adopt build number formats like +63, update your validation regexes before CI/CD complains.
Stub Everything Early: Keep your Mocktail default stubs updated when expanding authentication flows to prevent mysterious startup crashes in tests.

Try ROCIs Tasks

ROCIs Tasks is built completely offline-first with native Kotlin home screen widgets and seamless cloud sync. If you want to check it out, grab it on Google Play or try the web version:

Google Play: https://play.google.com/store/apps/details?id=com.rocisapps.tasks
Web App: https://tasks.rocisapps.com

Happy coding!

Why Google Tasks Sync Was Silently Failing Every Hour (And How I Fixed It)

ROCI — Sat, 05 Sep 2026 16:51:51 +0000

Building an offline-first task app sounds peaceful until you introduce cloud synchronization. Suddenly, you're knee-deep in OAuth scopes, token expirations, and mysterious silent failures that only happen when you step away from your desk for an hour.

In ROCIs Tasks—my offline-first Android task and calendar app built with Flutter and native Kotlin home screen widgets—I recently ran into a multi-layered Google Tasks sync puzzle. Users were experiencing sudden sync dropouts, and worse, the app wasn't telling them why. Let's break down what went wrong and how I built a robust, self-healing auth recovery flow.

The Mystery: The 60-Minute Disappearing Act

Everything worked great during initial testing. You log in, tasks sync beautifully between local SQLite databases and Google Tasks, and native widgets update seamlessly. But after an hour of idle time, background sync would quietly die.

When looking at the logs, three distinct culprits emerged:

The Cloud Console Blindspot: The Google Tasks API simply wasn't enabled in the Google Cloud Console for the project. Classic rookie configuration error.
The 60-Minute Token Wall: OAuth access tokens expire after 60 minutes. When the API threw a GoogleTokenExpiredException, my TaskProvider was catching it, silently ignoring it, and failing indefinitely.
The Web Silent Refresh Gap: While mobile had some token handling, the web platform lacked proper silent scope authorization requests, forcing users to completely re-authenticate manually.

The result? A broken user experience where data simply stopped syncing without any visual feedback.

The Solution & Architecture

To fix this permanently, I needed a multi-pronged approach: fixing the backend configuration, upgrading token handling, and adding graceful UI recovery.

First, I enabled the API in Google Cloud. Next, I tackled the token lifecycle inside our authentication service. I implemented platform-agnostic silent scope authorization requests to ensure tokens could refresh seamlessly without throwing hard errors.

To bridge the gap between the auth layer and the UI, I exposed a reactive state flag in our AuthService:

class AuthService extends ChangeNotifier {
  bool _isGoogleTasksTokenExpired = false;

  bool get isGoogleTasksTokenExpired => _isGoogleTasksTokenExpired;

  void setTokenExpired(bool expired) {
    if (_isGoogleTasksTokenExpired != expired) {
      _isGoogleTasksTokenExpired = expired;
      notifyListeners();
    }
  }

  Future<void> refreshAccessToken() async {
    try {
      // Platform-agnostic silent token request logic
      await _silentAuthClient.requestAccess();
      setTokenExpired(false);
    } catch (e) {
      setTokenExpired(true);
    }
  }
}

Finally, instead of hiding the failure, I brought it to the user's attention gracefully. Using our Glassmorphism design system rules, I added contextual warning banners at the top of the Tasks tab on Mobile and inside the sidebar on Web. With a single tap on 'Reconnect', users trigger a self-healing re-authorization flow right where they are.

Key Lessons for Other Devs

Never silently swallow auth exceptions: If an API call fails due to an expired token, surface that state immediately to your state management layer.
Design for expiration: OAuth tokens will expire. Always build your UI assuming connectivity and auth states can drop at any moment.
Self-healing UI wins: Instead of locking users out or showing generic error toasts, give them a prominent, one-tap path to re-authenticate.

Try ROCIs Tasks

Building ROCIs Tasks as an indie developer has been an incredible journey into bridging Flutter cross-platform power with native Android widgets. If you want to check out an offline-first productivity app with deep calendar integration, take a look at ROCIs Tasks on Google Play or try the web version at tasks.rocisapps.com. Feedback is always welcome!

Why My Flutter App Was Spamming Google Sign-In Prompts (And How I Fixed It)

ROCI — Sat, 05 Sep 2026 16:48:26 +0000

As an indie developer building an offline-first task and calendar app (ROCIs Tasks) using Flutter with native Android Kotlin widgets, nothing gives you sudden micro-heart attacks quite like user bug reports about authentication loops.

Recently, I hit a nasty regression: users were getting hammered with multiple Google sign-in prompts. Tap the Google Tasks sync toggle? Prompt. Tap 'Create Task'? Another prompt. It felt less like a productivity app and more like an aggressive security guard.

Here is the breakdown of why this happened and how I fixed it.

The Mystery: Death by a Thousand Prompts

Users trying to sync their tasks were seeing back-to-back sign-in overlays. Even worse, generic email/password users were occasionally getting swept into the credential flow. That is a textbook way to tank your app's retention on Google Play.

Root Cause Analysis

Digging into the codebase revealed three distinct culprits conspiring against my users:

Decoupled Auth in Google Sign-In v7: Authentication (ID token) and Authorization (Access token/scopes) are now separate steps. My code was calling attemptLightweightAuthentication() inside getGoogleAccessToken() whenever the cache missed. On Android, this doesn't always fail silently—it can trigger a Credential Manager overlay chooser.
The Amnesiac In-Memory Session: The authenticated GoogleSignInAccount object was never stored in memory. Every single token request started completely from scratch.
Redundant Scopes: My mobile build was requesting the Google Calendar scope (https://www.googleapis.com/auth/calendar). But on mobile, ROCIs Tasks uses device_calendar for native OS calendar integration. Asking for the web calendar scope via Google Sign-In triggered redundant, scary permission consent prompts.

The Solution & Architecture

To clean this up, I refactored the AuthService with a strict caching and platform-aware scope strategy.

First, I introduced an in-memory session cache and hooked into the authentication event stream on startup:

class AuthService {
  GoogleSignInAccount? _googleUser;

  Future<void> initialize() async {
    _googleSignIn.authenticationEvents.listen((event) {
      if (event is GoogleSignInAccountEvent) {
        _googleUser = event.user;
      }
    });
    await _restoreGoogleSignInSession();
  }

  // Smart startup restoration - only for users who actually linked Google Tasks
  Future<void> _restoreGoogleSignInSession() async {
    if (_userHasLinkedGoogleTasks) {
      _googleUser = await _googleSignIn.attemptLightweightAuthentication();
    }
  }
}

Next, I split the requested scopes by platform. Web needs the Calendar API; mobile handles it natively via the OS device calendar:

List<String> getScopesForPlatform() {
  if (kIsWeb) {
    return [
      'email',
      'profile',
      'https://www.googleapis.com/auth/tasks',
      'https://www.googleapis.com/auth/calendar',
    ];
  } else {
    // Mobile uses device_calendar for native OS integration
    return [
      'email',
      'profile',
      'https://www.googleapis.com/auth/tasks',
    ];
  }
}

Finally, I unified SharedPreferences token caching across platforms so that access tokens survive app restarts without forcing unnecessary network calls.

Key Lessons for Other Devs

Never assume silent auth is silent: Modern Android credential managers can surface UI when you least expect it. Cache your user state locally.
Audit your OAuth scopes: Don't request web-only API scopes on mobile if your app handles things natively via platform channels.
Respect your users' intent: Generic email/password accounts should never touch Google OAuth logic on startup.

Wrapping Up

Building ROCIs Tasks as a solo indie dev means obsessing over details like smooth auth flows so the app feels as native and polished as possible. If you want to check out an offline-first task manager with native Kotlin widgets built in Flutter, take a look at ROCIs Tasks on Google Play or visit tasks.rocisapps.com. Happy coding!

How I Fixed a Firestore Stream Race Condition That Reverted Task Toggles

ROCI — Thu, 18 Jun 2026 08:56:24 +0000

I'm building an Android task manager (ROCIs Tasks) with Flutter. The app uses an offline-first architecture: tasks live in Hive locally and sync to Firestore when online.
Users reported a maddening bug — they'd tap to complete a task, the checkbox would animate, and then... it would snap back to incomplete. Here's what was happening and how I fixed it.
The Race Condition
The app listens to a Firestore stream for real-time updates:
_tasksSubscription = _firestoreService.getActiveTasksStream().listen(
(events) async {
for (final event in events) {
final cloudTask = event.task;
// process cloud task...
}
},
);
When a user toggles a task, the app:

Updates the local Hive store immediately
Fires notifyListeners() so the UI updates
Sends the write to Firestore asynchronously The problem: the Firestore query filters isCompleted == false. The moment the write reaches Firestore, the task disappears from the stream — which emits a removed event. Meanwhile, the Firestore write hasn't fully propagated, so the snapshot data is stale. The listener processes the stale snapshot, overwrites the local state, and the UI reverts. Here's the timeline: User taps "complete" → Local Hive: isCompleted = true ✓ → UI updates ✓ → Firestore write sent (async) → Firestore stream emits: task removed from "active" query → Listener processes stale snapshot: isCompleted = false → Overwrites local Hive with false ✗ → UI reverts ✗ The entire round-trip happens in milliseconds. The user sees a flash of completion followed by an instant revert. The Fix: _pendingLocalWrites Guard I added a map that tracks recently toggled tasks and their intended state: final Map _pendingLocalWrites = {}; When a task is toggled, I record the intended state before writing to Firestore: Future toggleTaskCompletion(Task task) async { task.isCompleted = !task.isCompleted; task.completedAt = task.isCompleted ? DateTime.now() : null; // Record the intended state so the Firestore stream doesn't revert it _pendingLocalWrites[task.id] = task.isCompleted; notifyListeners(); await _source.addTask(task); _firestoreService.updateTask(task).catchError((e, s) { _errorHandlingService.logError(e, s, reason: 'Background cloud updateTask failed'); }).whenComplete(() { // Allow stream to handle this task again after Firestore write settles Future.delayed(const Duration(seconds: 3), () { _pendingLocalWrites.remove(task.id); }); }); } In the stream listener, I check the guard before processing each event: final pendingState = _pendingLocalWrites[cloudTask.id]; if (pendingState != null) { // We recently toggled this task — don't let stale data revert it if (event.type == SyncEventType.removed && pendingState) { // We just completed this task — the removed event is expected. // Update Hive to reflect completion from the latest snapshot. final (latestTask, isMissing) = await _firestoreService.fetchTaskById(cloudTask.id); if (latestTask != null && latestTask.isCompleted) { await _source.addTask(latestTask); await _cancelTaskNotificationsById(latestTask.id); needsUpdate = true; } continue; } if (event.type != SyncEventType.removed && !pendingState) { // We just uncompleted this task — ignore the stale cloud event. continue; } } After 3 seconds (enough for Firestore to propagate), the guard is removed and normal stream processing resumes. Why 3 Seconds? Firestore writes typically propagate in 100-500ms. I used 3 seconds as a conservative buffer that covers:
Slow network connections
Firestore replication lag under load
The stream batching multiple events It's a tradeoff — during those 3 seconds, genuine cloud updates to that task from other devices are also suppressed. For a single-user task manager, that's acceptable. For a collaborative app, you'd want a more sophisticated conflict resolution strategy. Key Takeaways
Firestore streams are great, but they're not instant. The gap between a local write and the stream reflecting it is a race condition window.
Offline-first needs local-first UI updates. Updating Hive before sending to Firestore ensures the UI never feels laggy. The stream is for background sync, not for driving the UI.
Simple guard maps work. You don't need a full state machine or optimistic concurrency control for most cases. A Map with a TTL is enough.

4. Test with bad network conditions. This bug was invisible on fast WiFi. It appeared on cellular with 200ms+ latency.

If you're building offline-first Flutter apps with Firestore, this pattern is worth knowing. The full app is in open beta on the Play Store — happy to answer questions about the architecture.

If you have an idea on how to optimize the process, I would love to know!

DEV Community: ROCI

Offline-First Flutter Architecture

Why Your Flutter Background Isolates Crash on Android (And How I Fixed It)

The Mystery: Background Crashes and Broken Tests

The Root Cause

The Solution & Code Architecture

1. Ditching WidgetsBinding for Background Tasks

2. Bulletproofing Google Tasks Back-Sync

Key Lessons for Other Devs

Try ROCIs Tasks

Why Google Tasks Sync Was Silently Failing Every Hour (And How I Fixed It)

The Mystery: The 60-Minute Disappearing Act

The Solution & Architecture

Key Lessons for Other Devs

Try ROCIs Tasks

Why My Flutter App Was Spamming Google Sign-In Prompts (And How I Fixed It)

The Mystery: Death by a Thousand Prompts

Root Cause Analysis

The Solution & Architecture

Key Lessons for Other Devs

Wrapping Up

How I Fixed a Firestore Stream Race Condition That Reverted Task Toggles

4. Test with bad network conditions. This bug was invisible on fast WiFi. It appeared on cellular with 200ms+ latency.

If you're building offline-first Flutter apps with Firestore, this pattern is worth knowing. The full app is in open beta on the Play Store — happy to answer questions about the architecture.

1. Ditching `WidgetsBinding` for Background Tasks