DEV Community: ROCI

Shalom Home: my grandpa's phone launcher, rebuilt to stop annoying him.

ROCI — Sun, 04 Oct 2026 12:38:15 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My grandfather Shalom calls me a lot. Usually it is not to chat. It is because his phone moved something.

His WhatsApp icon "jumped" to another page. The shortcut he uses to call my mom, his daughter, disappeared. He did nothing wrong: a long press that lasted a second too long, a swipe that started on an icon instead of the background. Android home screens are built for people who know that icons can be dragged, deleted and stacked into folders. Shalom does not know that, and he should not have to.

So I built him Shalom Home: an Android launcher (the app that is your home screen) built on three ideas.

Nothing moves. One page of big tiles: WhatsApp, Photos, the people he calls. No dragging, no deleting, no folders, no accidental pages. Every change happens in a setup screen hidden behind five taps on the clock and a PIN that only I know. Three wrong PINs lock it.
He can just ask. A big button at the bottom says "דבר איתי" ("talk to me"). He says "תתקשר לבת שלי" ("call my daughter"), or in French, "Appelle ma fille", and the phone does it.
It never surprises him. Every voice action shows a 3-second countdown with a giant red "ביטול" (cancel) button and says out loud what it is about to do.

Around that core, the things he is used to still work, just without the chaos:

Up to 30 people he can call by voice, each with the words he uses for them ("הבת שלי", "ma fille", a nickname).
His own wallpaper shows behind the tiles, so the grandkids' photo stays.
A second page for the Contacts "Direct dial" shortcuts and widgets he relies on. I add them from a picker with real previews. If any app tries to put something on his screen, it waits for my approval.
Setup in Hebrew or English, so anyone in the family can manage it.

Demo

A 36-second walkthrough: the locked home screen, a Hebrew voice request with its countdown, the second page, and the PIN-protected setup. The APK is on the GitHub release page if you want to try it on an Android phone.

Home, on his wallpaper	Second page	Adding a widget	Setup, in Hebrew

Results on my test phrases

I generated Hebrew and French test phrases with a neural TTS voice and ran them through the full pipeline, with a test contact called "Michal" (number 000) whom he calls "הבת שלי", my daughter. In test mode the app only logs what it would do; it never dials.

He says	Whisper heard	Result
תתקשר למיכל (call Michal)	תתקשר למי חל	Michal, keywords
אני רוצה לדבר עם הבת שלי (I want to talk to my daughter)	exact	Michal, keywords
תחייג לילדה (dial the girl)	exact	Michal, Gemma
Appelle ma fille (call my daughter)	exact	Michal, Gemma
איפה התמונות שלי (where are my photos)	איפות מונות שלי	Photos, keywords
מה השעה עכשיו (what time is it)	מה שעכשיו	nothing: Gemma decided it is not a request

On the emulator, keyword requests finish in about a second and Gemma requests in 2 to 6 seconds. On a real Samsung phone it is pretty fast.

Code

RoeeIlouz / shalom-home

A locked, voice-driven Android home screen for my grandpa. Whisper + Gemma run on-device, in Hebrew.

ontology

true

type

readme

domain

saba-home

status

active

Shalom Home

A home screen for my grandfather Shalom's Android phone.

Download the APK and the demo video (v1.0)

He kept calling me because a shortcut had moved to another page, or because the button that calls my mom had disappeared. Shalom Home replaces his launcher with one page of big tiles he cannot drag, delete or swipe away, plus a "דבר איתי" ("talk to me") button: he says what he wants in Hebrew or French, and the phone does it.

All speech recognition and understanding runs on the phone with open-weight models. His voice and his contacts never leave the device, and nothing needs an internet connection after setup.

Home	Second page	Widget picker	Setup (Hebrew)

How it

…

View on GitHub

Source, build instructions and the APK: https://github.com/RoeeIlouz/shalom-home

How I Built It

microphone
  -> Whisper small (whisper.cpp)          speech to Hebrew text, on the phone
  -> fuzzy Hebrew keyword matcher         instant for "call Michal", "open WhatsApp"
  -> Gemma 3 1B (llama.cpp), if unclear   "I want to talk to the girl" -> his daughter
  -> 3 s spoken countdown + cancel        -> place the call / open the app

It is a Kotlin and Jetpack Compose app with two small native libraries: one wraps whisper.cpp, the other llama.cpp. The models are open weights from Hugging Face, downloaded once in setup: Whisper small (190MB) and Gemma 3 1B quantized to 4 bits (800MB). Both run on the phone's CPU.

Whisper does the listening. Two tricks made it usable for short commands:

The decoder is primed with the names of his contacts (initial_prompt), so a spoken name comes out spelled the way it is saved.
The encoder normally processes a fixed 30-second window. For a two-second command I shrink audio_ctx to the length of the clip. On my test emulator, that took transcription from 25 to 45 seconds down to about one second.

The keyword matcher handles what Hebrew speech recognition gets wrong in predictable ways: prefixes glued to words (ל, ה, ו: "לאמא" is "to mom"), final-letter forms, spelling variants like אמא / אימא, and Whisper occasionally splitting one word in two ("למי חל" for "למיכל"). If the match is clear, the language model never wakes up.

Gemma 3 1B handles everything without a keyword: "dial the girl", "I want to talk to my daughter", "Appelle ma fille". This is the part I am proudest of, because of how it is constrained:

// The model may only answer with the id of one of HIS options, or "none".
val grammar = "root ::= \"none\" | \"call0\" | \"call1\" | \"app0\" | ..."
val answer = llm.chat(system, "He said: \"$transcript\"", grammar, maxTokens = 6)

llama.cpp's grammar sampler makes it impossible for the model to output anything else. It cannot invent a phone number, a contact, or an action. The worst it can do is pick the wrong one of his people, and the countdown catches that.

A 1B model has habits, and I found them by testing. Asked "what time is it?", it confidently picked the first app in the list. The fix was a separate yes/no question first ("is this a request to call someone or open an app?"), also grammar-constrained. Now small talk is ignored instead of acted on.

Things that went wrong

My first test dialed a number. My test harness let the countdown finish, and the emulator placed a (simulated) call to the fake contact I had created. Nobody was called, but it was the most important bug of the weekend: test mode now stops before any action, and only a real tap or a confirmed voice request can dial.
Two native libraries, one process. whisper.cpp and llama.cpp each ship their own copy of ggml. I build each into its own JNI library with ggml linked statically and its symbols hidden (-Wl,--exclude-libs,ALL), so they never collide.
Samsung is not the emulator. Two things that worked perfectly on the emulator broke on a real Galaxy. The widget picker crashed because I grouped widgets by app name, and several Samsung apps share one; grouping by package fixed it. And Samsung reported no shortcut permission even for the default home app, so "Direct dial" got a fallback that opens the Contacts shortcut screen directly. Testing on the real phone early would have saved me an evening.

Why Does Open Innovation Matter?

I could not have built this on a closed API, and not just because of cost.

His voice stays in his pocket. Shalom's requests contain the names of his family. With Whisper and Gemma running on the phone, none of it is sent anywhere. After the one-time model download, the phone does not need the internet at all.
It costs nothing to run, forever. He is retired. A voice assistant that needs a subscription, or that stops working when an API changes its pricing, is a voice assistant he will lose.
I could constrain the model's output. Grammar-constrained decoding works because I own the sampling loop. That single feature is what makes it safe to let a small model decide who to call.
I can swap in a better Hebrew model. The Israeli open-source project ivrit.ai publishes Whisper models fine-tuned on Hebrew speech. Because the app loads any whisper.cpp model file, upgrading Shalom's Hebrew recognition is a file copy, not a vendor negotiation.
It runs on his phone. A mid-range Galaxy A with 6GB of RAM runs both models on the CPU. No GPU, no server, no account.

Prize Categories

No partner categories: Shalom Home runs entirely on the phone, so there is nothing to host, no tabular data to forecast and no fine-tuning run. This is an entry for the overall prize.

Disclaimer: Some of the code was generated by Claude Code.

A Windows context menu editor in one PowerShell file

ROCI — Sat, 03 Oct 2026 20:27:29 +0000

The Windows right-click menu is built from several different places, and Windows 11 hides half of it behind "Show more options". Most tools I found each cover one part of it. I wanted one list for all of it, so I built Context Menu Editor: a single PowerShell script with a WPF window, free and MIT licensed.

You can try it without installing anything:

irm https://rocisapps.com/cme | iex

You can read the source first, and the same script is attached to every GitHub release.

Here is how it works, and the parts that were harder than I expected.

Three kinds of entries

Windows builds the menu from three different places, and each one is switched off differently:

Shell verbs under Software\Classes\<class>\shell\<verb>. Adding a LegacyDisable value turns one off without deleting it.
Shell extension handlers under shellex\ContextMenuHandlers (7-Zip, antivirus, PowerToys). You turn one off by adding its CLSID to the per-user Shell Extensions\Blocked list.
Windows 11 packaged items, which apps declare in their AppxManifest.xml as windows.fileExplorerContextMenus. They have no command line at all, only a COM handler, and they are blocked the same way as extensions.

Reading all three into one list, with the right "off" mechanism behind each switch, is most of the work.

# Turn a shell extension off for the current user (restart Explorer afterwards)
$blocked = [Microsoft.Win32.Registry]::CurrentUser.CreateSubKey(
    'Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked')
$blocked.SetValue('{00000000-0000-0000-0000-000000000000}', '')   # the handler's CLSID

Do not use the registry provider

All registry access goes through Microsoft.Win32.Registry. The PowerShell registry provider treats the * in HKCU\Software\Classes\*\shell as a wildcard, so a path that means "all files" quietly matches other keys. The .NET API takes the path literally:

$shell = [Microsoft.Win32.Registry]::CurrentUser.OpenSubKey('Software\Classes\*\shell')
$shell.GetSubKeyNames()

Send to, and items with no command line

Send to is a folder of shortcuts, so adding an app is easy. Windows 11 packaged items are not: Blip, for example, has a submenu of devices and no executable to point a shortcut at. The shortcut targets a small C# helper instead, which finds the item by its CLSID and calls it on the selected files, the way Explorer does. Submenu entries are matched by title first and by position only as a fallback, so pairing a new device does not change where an existing shortcut sends.

The helper is compiled at runtime with Add-Type and stored outside the script's folder, so shortcuts keep working if the editor moves.

One script, built from many files

The source is split into small files: core functions, UI, XAML, and JSON for the tweaks list. A Compile.ps1 stitches them into the single script people run. Two details only showed up with the one-line launch:

irm | iex passes a byte order mark through as code, which breaks parsing. The output is therefore pure ASCII and written without a BOM, and the compiler refuses non-ASCII characters.
Windows PowerShell 5.1 reads a BOM-less file as ANSI, which is only safe because of the ASCII rule.

The short URL is a redirect on my own domain to the latest GitHub release asset, so a new release is live as soon as it is published.

Startup time

The first version took about two seconds before any window appeared, and most of that was reading the registry. Two changes helped.

Open the window first. It appears straight away with a "reading" state, and the scan runs once the first frame is on screen:

$Window.Add_ContentRendered({
    $Window.Dispatcher.BeginInvoke(
        [System.Windows.Threading.DispatcherPriority]::Background,
        [Action]{ Invoke-Scan; Update-View })
})

The window now appears in 0.6 to 0.8 seconds, and the full list is ready at about the same total time as before.

Cache the compiled helper. Compiling the C# types cost 0.1 to 0.3 seconds on every start. Now they are compiled once and loaded from a cache file in about 15 milliseconds:

Add-Type -TypeDefinition $source -OutputAssembly $dll -OutputType Library   # first run only
Add-Type -LiteralPath $dll                                                  # every run

An elevated run never loads that cache. An administrator process should not load code from a folder a standard user can write to, so it compiles in memory instead.

PowerShell traps I hit

Variable names are case-insensitive, so a local $s quietly replaced a global $S. The shared state is now $App.
A function that returns an array with return ,$array can come out nested after @() or a pipeline. Returning the array directly is safer.
R is an alias for Invoke-History, which matters when a script defines a short helper function.
The `u{...} Unicode escape does not exist in Windows PowerShell 5.1.

Testing without touching your own menus

-LibraryOnly loads every function without opening the window, so the scanner and every write operation can be scripted. An early test run wrote into my real Send to folder, which taught me to point tests at a temporary Send to folder and a temporary backup folder. A separate sweep opens every page of the window and fails on any error, in both PowerShell 7 and 5.1.

Safety

Anything you edit or delete is exported to a .reg file first, and the last change can be undone from the status bar. Per-user changes need no administrator rights. The script makes no network calls except downloading itself again when you choose "run as administrator".

Try it, and tell me what is missing

Run it: irm https://rocisapps.com/cme | iex
Source (MIT): https://github.com/RoeeIlouz/ROCIsContextMenu-Editor
Guides: get the full right-click menu back in Windows 11 and remove items from the right-click menu

I am the author. If something breaks on your setup, or an entry is missing from the list, open an issue on GitHub. Please include your Windows version, PowerShell edition and what caused it to break.

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

Shalom Home: my grandpa's phone launcher, rebuilt to stop annoying him.

What I Built

Demo

Results on my test phrases

Code

RoeeIlouz / shalom-home

A locked, voice-driven Android home screen for my grandpa. Whisper + Gemma run on-device, in Hebrew.

Shalom Home

How it

How I Built It

Things that went wrong

Why Does Open Innovation Matter?

Prize Categories

Disclaimer: Some of the code was generated by Claude Code.

A Windows context menu editor in one PowerShell file

Three kinds of entries

Do not use the registry provider

Send to, and items with no command line

One script, built from many files

Startup time

PowerShell traps I hit

Testing without touching your own menus

Safety

Try it, and tell me what is missing

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