DEV Community: Tal Aizikov

One subscriptions row, two stores: Stripe and Google Play in Next.js + Supabase

Tal Aizikov — Tue, 13 Oct 2026 15:33:29 +0000

MotionLab sells one Pro plan through two checkouts. On the web it's Stripe Checkout. On Android it's Google Play Billing. Two stores with two lifecycles and two kinds of IDs, plus two ways of telling you something changed. The web app doesn't care about any of that. It wants one answer: is this user Pro right now?

We're building MotionLab, personalized stretching and mobility sessions. Earlier posts covered how AI sessions pick exercises and our Postgres push queue. This one covers billing. Everything funnels into a single subscriptions row per user in Supabase. Stripe webhooks write it, a Play verification endpoint writes it, and the UI only ever reads it.

Stack: Next.js 16.2 (App Router route handlers), Supabase Postgres with a service-role client on the server, stripe 21.x and googleapis for the Android Publisher API. Snippets are trimmed from the real code.

1. One row, keyed by user

Here's the row, as it appears in our Supabase Database types:

subscriptions: {
  Row: {
    user_id: string;
    status: string;
    interval: string | null;
    stripe_customer_id: string | null;
    stripe_subscription_id: string | null;
    stripe_price_id: string | null;
    current_period_end: string | null;
    started_at: string | null;
    cancel_at_period_end: boolean;
    updated_at: string;
  };
};

status uses Stripe's vocabulary (active, trialing, past_due, canceled and so on) and interval is month or year. user_id is the conflict key for every write, so each writer does an upsert(..., { onConflict: "user_id" }) and the last write wins. The client-side type mirrors this with timestamps in milliseconds. A missing row maps to a DEFAULT_SUBSCRIPTION with status: 'none', so the UI never has to handle null.

Yes, the columns say stripe_. They predate the Play integration, and the end of this post covers what that costs.

2. Checkout: put the user ID where every later event can find it

The checkout route verifies the Supabase access token, then creates the session:

const session = await stripe.checkout.sessions.create({
  mode: "subscription",
  customer_email: user.email,
  line_items: [{ price: priceId, quantity: 1 }],
  metadata: { supabaseUid: user.id, referredByCreatorId },
  subscription_data: {
    metadata: { supabaseUid: user.id, referredByCreatorId },
  },
  success_url: `${appUrl}/home?checkout=success`,
  cancel_url: `${appUrl}/pricing`,
  allow_promotion_codes: true,
});

The user ID goes in twice, and that's on purpose. Session metadata lives on the Checkout Session, which only matters for checkout.session.completed. subscription_data.metadata gets copied onto the Subscription itself, and that's the object every later event points at: renewals, plan changes, cancellations, failed payments. If you only set the first one, your webhook can identify the user exactly once, on the first payment.

The same route refuses to create live-mode sessions from localhost:

if (appUrl.includes("localhost") && process.env.STRIPE_SECRET_KEY?.startsWith("sk_live")) {
  return NextResponse.json(
    { error: "Cannot create live-mode checkout sessions from localhost. Set NEXT_PUBLIC_APP_URL." },
    { status: 500 }
  );
}

It's a cheap way to make sure a live key on a laptop can't start real charges during local development.

3. The webhook: raw body first, then re-fetch

Stripe signs the exact bytes it sends, so the signature check needs the raw body. With App Router route handlers that's simple: you read request.text() and skip request.json(). There's no body-parser config to turn off.

export async function POST(request: Request) {
  const body = await request.text();
  const sig = request.headers.get("stripe-signature");
  if (!sig) {
    return NextResponse.json({ error: "Missing signature" }, { status: 400 });
  }

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      sig,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch {
    return NextResponse.json({ error: "Invalid signature" }, { status: 400 });
  }

  const supabase = createServerClient();
  try {
    switch (event.type) {
      // checkout.session.completed, customer.subscription.updated / .deleted,
      // invoice.payment_succeeded / .payment_failed, charge.refunded, charge.dispute.created
    }
    return NextResponse.json({ received: true });
  } catch (err) {
    console.error("[webhook] handler error:", err);
    return NextResponse.json({ error: "Handler error" }, { status: 500 });
  }
}

The outer try matters. If a Stripe API call or our own code throws, the handler returns a 500 and Stripe redelivers. Stripe's webhook docs say it retries for up to three days in live mode.

The same docs also warn that Stripe "doesn't guarantee the delivery of events in the order that they're generated." So for checkout completion and both invoice events, the handler ignores whatever subscription snapshot the event carries. It retrieves the subscription from Stripe and writes the current state:

case "invoice.payment_succeeded": {
  const invoice = event.data.object as Stripe.Invoice;
  const subId =
    (invoice as unknown as { subscription?: string }).subscription ??
    invoice.parent?.subscription_details?.subscription;
  if (!subId) break;
  const sub = await stripe.subscriptions.retrieve(
    typeof subId === "string" ? subId : (subId as { id: string }).id
  );
  const uid = await resolveUid(supabase, sub);
  if (!uid) break;
  await writeSubscription(supabase, uid, sub);
  // ...plus a referral side effect, see section 5
  break;
}

That costs an extra API call per event. In exchange, a late or duplicate delivery writes the subscription as it is now, not as it was when the event fired.

4. Stripe moved two fields under us

That subId expression looks fussy, and git history explains why. Two of the earliest fixes to this webhook trace back to API-shape changes, not logic bugs:

current_period_end moved. Our first version read sub.current_period_end * 1000. In Stripe's 2025-03-31 "basil" API version, billing periods moved from the subscription to its items, so the subscription-level field is gone. The fix landed a day after the first billing commit.
invoice.subscription moved. The same release replaced it with invoice.parent.subscription_details.subscription.

The current mapper reads the period from the first item and guards against it being absent:

async function writeSubscription(
  supabase: ReturnType<typeof createServerClient>,
  uid: string,
  sub: Stripe.Subscription
): Promise<void> {
  const priceItem = sub.items.data[0];
  const interval = priceItem?.price.recurring?.interval as SubscriptionInterval | undefined;

  const { data: existing } = await supabase
    .from("subscriptions")
    .select("started_at")
    .eq("user_id", uid)
    .maybeSingle();
  const existingStartedAt = existing?.started_at
    ? new Date(existing.started_at as string).getTime()
    : null;

  const payload = {
    user_id:              uid,
    status:               sub.status as UserSubscription["status"],
    interval:             interval ?? null,
    stripeCustomerId:     sub.customer as string,
    stripeSubscriptionId: sub.id,
    stripePriceId:        priceItem?.price.id ?? null,
    currentPeriodEnd:     priceItem?.current_period_end
      ? priceItem.current_period_end * 1000
      : null,
    startedAt:            existingStartedAt ?? (sub.start_date * 1000),
    cancelAtPeriodEnd:    sub.cancel_at_period_end,
    updatedAt:            Date.now(),
  };
  // ...then one upsert into subscriptions (snake_case columns, ISO timestamps),
  // { onConflict: "user_id" }
}

Note the started_at read before the write. The profile page shows "Member since", and we didn't want that date to reset every time someone resubscribes or changes plans. Once a row has a start date, later Stripe writes keep it.

There's a small type gap too. charge.invoice exists at runtime but isn't in the Stripe types we're pinned to, so a helper does the cast in one place and nowhere else.

Lesson: pin your SDK and know which API version your webhook endpoint is on. When a field "randomly" goes undefined, check the changelog before you check your logic.

Users from before the migration

MotionLab started on Firebase and moved auth and subscriptions to Supabase in May. Subscriptions created before that carry a firebaseUid in metadata, not a supabaseUid. resolveUid handles both. It prefers the new key and otherwise falls back to the Stripe customer's email:

// New subscriptions use supabaseUid; legacy Firebase ones used firebaseUid
if (sub.metadata?.supabaseUid) return sub.metadata.supabaseUid;

// Legacy: look up the Supabase user by customer email
const customerId = sub.customer as string;
const customer = await stripe.customers.retrieve(customerId);
if (customer.deleted || !("email" in customer) || !customer.email) return null;

const { data } = await supabase.auth.admin.listUsers();
const match = data?.users?.find((u) => u.email === customer.email);
return match?.id ?? null;

Matching on email is a migration bridge, not something to build on. New subscriptions never take that path.

5. Google Play: verify the token on the server, write the same row

On Android, the app completes the purchase with Play Billing and posts the purchase token to /api/play/sync-purchase (the Android client lives in a separate codebase). The route verifies the Supabase token, then asks Google rather than trusting the client:

const publisher = google.androidpublisher({ version: "v3", auth: getPlayAuth() });
const { data } = await publisher.purchases.subscriptionsv2.get({
  packageName: PACKAGE_NAME,
  token: purchase_token,
});

const lineItem = data.lineItems?.[0];
const expiryTimeIso = lineItem?.expiryTime ?? null;
const subscriptionState = data.subscriptionState;

const status: string =
  subscriptionState === "SUBSCRIPTION_STATE_ACTIVE"   ? "active"   :
  subscriptionState === "SUBSCRIPTION_STATE_CANCELED" ? "active"   : // still active until expiry
  subscriptionState === "SUBSCRIPTION_STATE_ON_HOLD"  ? "past_due" :
  subscriptionState === "SUBSCRIPTION_STATE_PAUSED"   ? "past_due" :
  "canceled";

const interval = product_id.includes("monthly") ? "month" : "year";
const now = new Date().toISOString();
const cancelAtPeriodEnd = subscriptionState === "SUBSCRIPTION_STATE_CANCELED";

const { error: upsertError } = await supabase.from("subscriptions").upsert(
  {
    user_id:                user.id,
    status,
    interval,
    stripe_customer_id:     null,
    stripe_subscription_id: purchase_token,
    stripe_price_id:        null,
    current_period_end:     expiryTimeIso,
    started_at:             data.startTime ?? now,
    cancel_at_period_end:   cancelAtPeriodEnd,
    updated_at:             now,
  },
  { onConflict: "user_id" }
);

Google's subscription lifecycle guide calls subscriptionsv2.get "the source of truth for subscription management". It also explains the mapping above. A canceled Play subscription keeps its entitlement until expiryTime, which is why CANCELED maps to active with cancel_at_period_end: true, exactly the shape a Stripe "cancel at period end" produces. Account hold and paused subscriptions should lose access, so they map to past_due, which the UI doesn't treat as Pro.

The point of the mapping is that nothing downstream branches on the store. The profile page renders "Renews" or "Cancels" from cancel_at_period_end and current_period_end the same way for both.

Side effects get their own idempotency key

Paid periods also feed a creator-referral ledger. That table has unique (source, external_payment_id), using the Stripe invoice ID or the Play latestOrderId, and inserts go through upsert(..., { onConflict: "source,external_payment_id", ignoreDuplicates: true }). A redelivered webhook or a repeated sync can't double-count a payment. The subscription row can be overwritten freely because it's state. Ledger rows are events, so they need a natural key.

6. Reading it back, and the redirect race

The browser never queries subscriptions directly. It calls /api/subscription with its access token, and the route reads the row with the service-role client and maps it to the shared type. Entitlement in the UI is one line:

const isSubscribed =
  subscription?.status === "active" || subscription?.status === "trialing";

There's one race left. Stripe redirects the browser to /home?checkout=success, and the browser can land there before the webhook has written the row. So the page polls:

// Webhook may not have processed yet when the browser lands on the success URL,
// so retry up to 5x at 2-second intervals until we see an active/trialing status.
async function poll() {
  if (cancelled) return;
  attempts++;
  const [sub, count] = await Promise.all([
    getUserSubscription(user!.id).catch(() => null),
    getGatedSessionCount(user!.id).catch(() => 0),
  ]);
  if (cancelled) return;
  setSubscription(sub);
  setGatedCount(count);
  const isActive = sub?.status === "active" || sub?.status === "trialing";
  if (!isActive && attempts < MAX) {
    setTimeout(poll, 2000);
  }
}

It's bounded and cancellable on unmount. If the webhook is slower than that, the next page load picks the row up anyway, because the auth provider fetches the subscription when the session loads.

What we'd keep, and what we'd change

Normalize at the write, not the read. Both stores collapse into one status vocabulary when they're written, so every reader stays store-agnostic.
Name columns for the concept, not the vendor. stripe_subscription_id holding a Play purchase token works, but it's a trap for the next reader, and "Play rows are the ones where stripe_customer_id is null" is an implicit rule living in a query. A provider column plus external_subscription_id would say it out loud.
One row per user is an assumption. It's right for "one active plan at a time". If a user ever pays through both stores at once, last write wins, so decide on purpose what should happen.
Re-fetch on webhooks where you can. The event tells you that something changed. The API tells you what's true now.

If you're curious what the Pro plan actually unlocks, it's on the pricing page.

How do you model cross-store subscriptions: one row, one row per store, or an entitlements table? Tell us in the comments.

This post was drafted with AI assistance and reviewed by the MotionLab team.

Blocking websites on Android by reading only the address bar

Tal Aizikov — Sat, 10 Oct 2026 15:19:37 +0000

Blocking an app on Android has a clean signal: a window from a blocked package comes to the front. Blocking a website doesn't. To anything watching foreground packages, instagram.com in Chrome is just com.android.chrome, same as a recipe site.

We're building ReClaim, a minimalist Android launcher with app blocking built in. The first post covered the app side of its accessibility service: noticing which app is in front. The same service enforces website rules (blocks, schedules, reminders, limits and hidden sites) by reading one thing, the browser's address bar. This post covers finding that bar without walking the page, telling typing from visiting, and moving a tab off a site the user chose not to open.

(There are other routes, like a local VpnService doing DNS filtering. ReClaim doesn't use one; this is the accessibility route.)

Stack: Kotlin, Hilt, Room, coroutines, minSdk 26, targetSdk 36. Snippets are trimmed from the real code.

1. Asking for a little more

Reading an address bar needs window content and view ids, so the service config grew from window events to this:

<accessibility-service
    android:accessibilityEventTypes="typeWindowStateChanged|typeWindowsChanged|typeWindowContentChanged|typeViewTextChanged"
    android:accessibilityFlags="flagDefault|flagRetrieveInteractiveWindows|flagReportViewIds|flagIncludeNotImportantViews"
    android:canPerformGestures="true"
    android:canRetrieveWindowContent="true"
    android:notificationTimeout="0" />

The key one is FLAG_REPORT_VIEW_IDS. Without it, nodes don't report their view id, and you'd have to guess which field is the address bar from its contents. FLAG_RETRIEVE_INTERACTIVE_WINDOWS matters too, as we'll see.

The service also re-applies them in onServiceConnected(). Its comment: "Ask for address-bar text changes as they happen, including after an app update."

private fun listenForAddressBar() {
    val info = serviceInfo ?: return
    info.eventTypes = info.eventTypes or
        AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED or
        AccessibilityEvent.TYPE_WINDOW_CONTENT_CHANGED or
        AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED or
        AccessibilityEvent.TYPE_WINDOWS_CHANGED
    info.flags = info.flags or
        AccessibilityServiceInfo.FLAG_INCLUDE_NOT_IMPORTANT_VIEWS or
        AccessibilityServiceInfo.FLAG_REPORT_VIEW_IDS or
        AccessibilityServiceInfo.FLAG_RETRIEVE_INTERACTIVE_WINDOWS
    info.notificationTimeout = 0
    serviceInfo = info
}

The disclosure shown before the user enables the service says it plainly: for website rules, ReClaim reads the browser's address bar, "the site address only, never the page itself."

2. Find the bar, skip the page

Address-bar lookup only runs for an allowlist of 30 browser packages (BROWSER_PACKAGES: Chrome and its channels, Firefox, Samsung Internet, Edge, Brave, DuckDuckGo and others). The bar is found by view id, and since browsers don't share one, there's a small set of known names:

private val ADDRESS_BAR_IDS = setOf(
    "url_bar", "url_bar_title", "url_bar_edit_text", "location_bar_edit_text",
    "mozac_browser_toolbar_url_view", "omnibarTextInput", "url_field",
    "address_bar_edit_text", "origin_bar",
)

private fun isAddressBarId(viewId: String?): Boolean {
    if (viewId.isNullOrEmpty()) return false
    return viewId.substringAfterLast('/') in ADDRESS_BAR_IDS
}

substringAfterLast('/') turns com.android.chrome:id/url_bar into url_bar, so one set covers every Chromium build.

The first version used findAccessibilityNodeInfosByViewId(). The code comment records why it went: "searching it by view id walks every node on a site like YouTube and held the prompt back for seconds." The page's accessibility tree can be enormous, and the bar is never in it. So the search became a breadth-first walk that refuses to enter page content and stops after 80 nodes:

private const val MAX_SHELL_NODES = 80

private fun isPageContent(node: AccessibilityNodeInfo): Boolean {
    val cls = node.className?.toString().orEmpty()
    if (cls.contains("WebView", ignoreCase = true)) return true
    if (cls.contains("WebContents", ignoreCase = true)) return true
    val id = node.viewIdResourceName.orEmpty()
    return id.endsWith("/compositor_view_holder") || id.endsWith("/web_contents")
}

// inside the BFS loop
val reading = readingOf(node)                 // non-null only for an address-bar id
if (reading != null && !reading.focused) return reading
if (reading != null && focusedHit == null) focusedHit = reading
if (reading != null || isPageContent(node)) continue   // never descend into the page
for (i in 0 until node.childCount) node.getChild(i)?.let { queue.add(it) }

Two more details:

The bar may not be in the active window. rootInActiveWindow is often the page, while the omnibox sits in a separate toolbar window. The service collects the active root plus every root from windows belonging to that browser package, which is what FLAG_RETRIEVE_INTERACTIVE_WINDOWS unlocks.
Recycling. AccessibilityNodeInfo.recycle() is deprecated in API 33 and does nothing there. With minSdk 26 it still matters on older devices, so every child picked up during the walk is recycled in a finally.

3. From address-bar text to a host

What the bar shows isn't always a URL. Chrome often shows a breadcrumb like reddit.com › r › nosurf. Others show https://www.reddit.com/r/nosurf, or a bare host. normalizeHost() reduces all of them to reddit.com by stripping the scheme, any user@ prefix and a leading www., then cutting at the first delimiter. The delimiter list is the interesting part:

private fun isHostDelimiter(c: Char): Boolean =
    c == '/' || c == '\\' || c == '?' || c == '#' || c == ':' ||
        c.isWhitespace() || c == '>' || c == '<' || c == '›' || c == '‹' ||
        c == '»' || c == '«' || c == '❯' || c == '|' || c == '·' || c == '•' || c == '／'

› is the separator in Chrome's breadcrumb form, and ／ is a full-width slash.

Matching a host against rules is a suffix check on a dot boundary, plus aliases for products with several domains:

fun matchingRuleHost(urlHost: String, rules: Set<String>): String? {
    val host = normalizeHost(urlHost) ?: return null
    rules.firstOrNull { host == it || host.endsWith(".$it") }?.let { return it }
    for (site in KNOWN_WEBSITES) {
        if (site.host !in rules) continue
        if (site.aliases.any { host == it || host.endsWith(".$it") }) return site.host
    }
    return null
}

A reddit.com rule covers old.reddit.com but not notreddit.com. KNOWN_WEBSITES maps 14 products to their site and aliases (youtu.be for YouTube, t.co and twitter.com for X), so a rule is stored once under the canonical host.

4. Typing is not visiting

The trickiest part: the omnibox can show a host the user hasn't opened. As a code comment puts it, a bare host is what "the omnibox shows ... while a suggestion is still only highlighted." Gating on that would block someone for a suggestion they never picked.

The rule that came out of it: an unfocused bar is the page that's open, and so is any value that already has a path, query or breadcrumb. A focused bare host is the editor, and only counts after it sits still:

fun addressBarShowsPage(raw: String): Boolean {
    // ...scheme and userinfo stripped
    return s.any { c ->
        c == '/' || c == '\\' || c == '?' || c == '#' || c == '／' ||
            c == '›' || c == '‹' || c == '»' || c == '«' || c == '❯' || c == '>' || c == '<'
    }
}

"Focused" means input focus (node.isFocused), not accessibility focus. A comment in readingOf() explains why: Chrome often leaves accessibility focus on the omnibox during normal browsing, and treating that as typing "made the gate wait until they left the page."

On the event path, TYPE_VIEW_TEXT_CHANGED also says how the text changed. One character added (at most one removed) while focused, with no path, is a keystroke. Anything else counts as a committed navigation:

val keystroke = event.eventType == AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED &&
    focused &&
    !addressBarShowsPage(raw) &&
    event.addedCount == 1 &&
    event.removedCount <= 1

Untrusted candidates go through a 300 ms settle (FOCUSED_COMMIT_MS): a coroutine waits, and starts over if the bar moves to a different host first. The comment calls that "long enough to skip a keystroke and short enough that landing on a site still gates before the user can settle in."

5. Three ways to notice

There are three signals:

Text-changed events on the address bar. The event carries the new text (and beforeText), so no tree walk is needed.
Content-changed events from a browser, throttled to one read per 200 ms. They also handle a case where our own gate closed without a fresh window event and Chrome was quietly back in front.
A 250 ms poll, which the code calls a "backup read" for a bar that never sends a text event.

The poll is tightly scoped:

private fun websiteWatchActive(): Boolean =
    hiddenWebsites.isNotEmpty() ||
        blockedHosts.isNotEmpty() ||
        reminderHosts.isNotEmpty() ||
        websiteBudgets.isNotEmpty() ||
        websiteDeparture.pending() != null

It only runs while a known browser is the foreground window and at least one website rule exists. The moment another app comes forward, stopBrowserPoll() cancels it. With no website rules, it never starts.

6. Leaving the tab

Blocking an app ends with "go Home". For a website that's not enough: the tab is still on the site, so the gate fires again next time the browser comes forward. So when a website gate closes, ReClaim moves the tab off the site.

WebsiteDeparture arms the request and brings the same browser task back with FLAG_ACTIVITY_REORDER_TO_FRONT, so the open tab is reused instead of launching a new one. Then the service drives the address bar, at most one step every 280 ms:

if (departPhase % 2 == 0) {
    val clicked = bar.performAction(AccessibilityNodeInfo.ACTION_CLICK) ||
        bar.performAction(AccessibilityNodeInfo.ACTION_FOCUS)
} else {
    val url = browserDepartureUrl(browserPackage, departPhase / 2, websiteDeparture.destinationUrl())
    val args = Bundle().apply {
        putCharSequence(AccessibilityNodeInfo.ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE, url)
    }
    bar.performAction(AccessibilityNodeInfo.ACTION_SET_TEXT, args)
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) bar.performAction(ACTION_IME_ENTER)
}
departPhase++

ACTION_IME_ENTER is the constant 16908372, the value of android.R.id.accessibilityActionImeEnter (API 30). It submits the omnibox without touching the keyboard.

The first two attempts load a static hold page on tryreclaim.io. Its copy ("You blocked Instagram. Hold on. You set this aside for a reason.") rides in the query string, so one noindex page covers blocks, limits, cancelled reminders and hidden sites. If that never sticks, later attempts use about:blank. (Without a hold URL, the first attempts use the browser's start page: chrome://newtab for Chromium builds, about:home for Firefox.)

Two safeguards keep this from becoming a loophole:

It gives up. After MAX_DEPART_PHASE = 8 steps, or 3 seconds, the request clears. Then the gate is allowed to fire again: as the code puts it, "a failed navigation is not a way past the rule."
Cancel isn't a pass. If the bar shows anything else after Cancel and then the site again, that's a new visit and the gate asks immediately.

7. Same rules, different key

Websites reuse the app machinery. Blocked hosts come from the same three-way combine as blocked packages in our scheduled blocks post, with a schedule_websites table alongside schedule_apps. Reminders reuse the app reminder scheduler under a prefixed key:

// Package names are reverse-DNS and never use this prefix.
const val SITE_KEY_PREFIX = "site:"
fun siteKey(host: String): String = "$SITE_KEY_PREFIX$host"

Time is the one thing that couldn't be reused. UsageStatsManager only sees the browser, not the site, so ReClaim records time itself: a Room table keyed by (host, day) that stores only reminded or limited sites, flushed every 20 seconds while the visit is open. The entity's doc comment: "Other browsing is not stored."

8. Trade-offs

This depends on browser internals. View ids like url_bar aren't a public API, and a browser update could rename one. A browser missing from the allowlist isn't covered. The upside: no root, no VPN, no device admin. The service reads view ids and class names of at most 80 toolbar nodes per window, plus the address-bar text.

Wrapping up

Find the bar by view id, and never descend into the WebView.
An unfocused bar, or one with a path, is a visit. A focused bare host has to settle first.
Prefer events, and scope any polling to "browser in front and rules exist."
After a gate, move the tab away, and make sure failure re-arms the gate instead of muting it.

For the user side of these rules, we wrote up app limits vs. blocking vs. reminders. ReClaim isn't on Google Play yet; it's waitlist-only for now at tryreclaim.io.

Have you built anything on top of accessibility events, or found a cleaner way to tell an omnibox suggestion from a real visit? Tell us in the comments.

This post was drafted with AI assistance and reviewed by the ReClaim team.

A Postgres table as our push queue: retries, dead letters, and FCM in Next.js

Tal Aizikov — Thu, 08 Oct 2026 18:57:26 +0000

A push notification looks like a one-liner: call Firebase Cloud Messaging with a device token, a title and a body. Then the real questions arrive. What happens when FCM is down for a minute? What if the user turned reminders off? What if the token belongs to a phone that was wiped last month? And how do you know whether anyone opened the thing?

We're building MotionLab, personalized stretching and mobility sessions. In an earlier post we covered how AI sessions pick exercises. This one is about a less glamorous part of the same MotionLab-Web repo: the notification backend. There's no queue service and no worker fleet. One Postgres table is the queue, the state machine and the audit trail, and a handful of Next.js route handlers drive it.

Stack: Next.js 16.2 (App Router route handlers on the Node runtime), Supabase Postgres, firebase-admin for FCM, and Vercel Cron. Snippets are trimmed from the real code.

1. The table is the queue

Every notification is a row, and its status column is the state machine: pending, sent, delivered, retrying or dead.

create table if not exists public.notifications (
    id              uuid primary key default gen_random_uuid(),
    user_id         uuid not null references auth.users(id) on delete cascade,
    type            text not null,               -- maps to a preference category
    title           text not null,
    body            text not null,
    data            jsonb not null default '{}'::jsonb,
    channel         text not null default 'push', -- push | email | sms (future)
    status          text not null default 'pending',
    attempt_count   int  not null default 0,
    next_attempt_at timestamptz not null default now(),
    failed_reason   text,
    created_at      timestamptz not null default now(),
    sent_at         timestamptz,
    delivered_at    timestamptz,
    opened_at       timestamptz,
    read_at         timestamptz
);

-- Cron dispatch query: due rows still in flight
create index if not exists notifications_due_idx
    on public.notifications(next_attempt_at) where status in ('pending', 'retrying');

A few things this buys:

Retries are just data. attempt_count, next_attempt_at and failed_reason live on the row, so a retry is an UPDATE, not a message re-published somewhere else.
The partial index only covers work in flight. Sent, delivered and dead rows pile up over time, but the index the dispatcher reads only holds pending and retrying rows. Postgres partial indexes are made for exactly this "small hot subset of a big table" shape.
Lifecycle timestamps are separate columns. sent_at, delivered_at, opened_at and read_at are each set once, which makes the metrics in section 7 plain SQL.

Device tokens get their own table with a unique token and an active flag (plus another partial index on active tokens per user), and preferences are one row per user with a boolean per category.

2. Enqueue: check preferences before writing anything

All sends go through one enqueue() function. The first thing it does is read the user's preferences and decide whether the notification should exist at all:

// notification.type → notification_preferences column. Unknown types are not gated.
const CATEGORY_COLUMN: Record<string, string> = {
  marketing: "marketing",
  reminder: "reminders",
  reminders: "reminders",
  system: "system_updates",
  system_update: "system_updates",
  // ...
};

if (channel === "push" && prefs?.push_enabled === false) {
  return { skipped: true, reason: "push_disabled" };
}
const col = CATEGORY_COLUMN[params.type];
if (col && prefs && prefs[col] === false) {
  return { skipped: true, reason: `category_disabled:${col}` };
}

Two small decisions worth calling out:

The map accepts aliases. reminder and reminders both land on the reminders column, so a caller can't skip the gate because of a plural.
Defaults live in the schema, not the code. In notification_preferences, marketing defaults to false and the other categories default to true. Marketing is opt-in without any special-casing in TypeScript.

A skipped notification is never inserted. Otherwise the row goes in as pending with next_attempt_at = now(), a created event is logged, and enqueue() immediately calls attemptSend() on it. The cron job is the retry path, not the normal path.

3. One attempt: send, then record what happened

attemptSend() is the heart of it. It loads the row, bails out early if the row is already finished, gathers the user's active tokens, and hands everything to a channel:

if (n.status === "sent" || n.status === "delivered" || n.status === "dead") {
  return { skipped: true };
}

const result = await channelFor(n.channel).send(
  { id: n.id, title: n.title, body: n.body, data: n.data },
  { tokens }
);

// Permanently invalid tokens → deactivate.
if (result.invalidTokens.length > 0) {
  await supabase
    .from("device_tokens")
    .update({ active: false, updated_at: new Date().toISOString() })
    .in("token", result.invalidTokens);
}

Then exactly one of three things happens to the row: it's marked sent, it's moved to dead, or it gets a new next_attempt_at. The backoff schedule is a plain array:

// Retry schedule: Attempt 1 immediate, then 30s, 2m, 10m, 1h. After the 5th → dead-letter.
export const BACKOFF_MS = [0, 30_000, 120_000, 600_000, 3_600_000];
export const MAX_ATTEMPTS = BACKOFF_MS.length;

const attempt = n.attempt_count + 1;
// ...success → status "sent"; attempt >= MAX_ATTEMPTS → status "dead"
const delay = BACKOFF_MS[attempt] ?? BACKOFF_MS[BACKOFF_MS.length - 1];
const nextAttemptAt = new Date(Date.now() + delay).toISOString();

The indexing is easy to misread, so here it is spelled out. The first attempt fails with attempt === 1, so the wait is BACKOFF_MS[1], 30 seconds. Index 0 is never used as a delay; it documents that attempt one is immediate. After the fifth failure, attempt >= MAX_ATTEMPTS and the row goes to dead, with a failed event whose meta records the reason and a console.error line for the logs.

One thing that took a moment to internalize: next_attempt_at is a "not before", not a timer. Nothing wakes up at that instant. The row simply becomes eligible, and the next run of the drain job (section 6) picks it up. So the real retry delay is the backoff or the time until the next drain, whichever is longer. If you copy this pattern, the cron schedule is as much a part of your retry policy as the array is.

4. Channels: the dispatcher doesn't know it's doing push

The dispatcher only talks to an interface:

export interface NotificationChannel {
  send(notification: OutboundNotification, recipient: DeliveryRecipient): Promise<DeliveryResult>;
}

export interface DeliveryResult {
  /** True if at least one endpoint accepted the message. */
  success: boolean;
  /** Tokens FCM rejected as permanently invalid (deactivate them). */
  invalidTokens: string[];
  error?: string;
}

channelFor(n.channel) returns a PushChannel for push (and as the default). EmailChannel and SmsChannel exist as stubs that throw, so the channel column and the dispatcher are already shaped for them.

The push channel does one job that's easy to forget: FCM's data payload must be a flat string-to-string map, and our data column is JSONB. So the channel flattens it and always adds the notification's own id:

// FCM data must be string→string; include notification_id so the client can ack/deep-link.
const data: Record<string, string> = { notification_id: n.id };
for (const [k, v] of Object.entries(n.data ?? {})) {
  data[k] = typeof v === "string" ? v : JSON.stringify(v);
}

That notification_id is what makes read receipts possible later. It's also why "success" means at least one device accepted the message. A user with a phone and a tablet shouldn't see a retry because one of them is offline.

5. FCM: per-token results and token hygiene

The FCM wrapper uses sendEachForMulticast from the Firebase Admin SDK, which returns one result per token instead of a single pass/fail:

const INVALID_TOKEN_CODES = new Set([
  "messaging/registration-token-not-registered",
  "messaging/invalid-registration-token",
  "messaging/invalid-argument",
]);

const res = await messaging.sendEachForMulticast({
  tokens,
  notification: { title: msg.title, body: msg.body },
  data: msg.data ?? {},
  android: { priority: "high" },
});
return res.responses.map((r, i) => ({
  token: tokens[i],
  success: r.success,
  error: r.error?.message,
  invalidToken: r.error ? INVALID_TOKEN_CODES.has(r.error.code) : false,
}));

Per-token results are what feed the active = false update in section 3. Tokens go stale all the time (reinstalls, wiped phones, revoked permissions). Flagging them instead of deleting them keeps a history, and the partial index on active tokens means dead ones cost nothing on the read path.

Two setup details: the admin app is initialized lazily from a service-account JSON env var and reused while the function instance stays warm (admin.apps.length > 0), and every route that touches it declares export const runtime = "nodejs", because firebase-admin needs the Node runtime, not the Edge runtime.

6. The drain: a cron route that only does catch-up

Retries are picked up by a Vercel Cron job that calls a GET route. Vercel sends Authorization: Bearer $CRON_SECRET, and the route refuses anything else, including the case where the secret isn't configured at all:

const auth = request.headers.get("authorization");
if (!process.env.CRON_SECRET || auth !== `Bearer ${process.env.CRON_SECRET}`) {
  return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
}

That !process.env.CRON_SECRET || guard matters. Without it, a missing env var turns the check into auth !== "Bearer undefined", which anyone can satisfy.

The drain itself is short. It selects due rows oldest-first, up to a limit, and runs each through the same attemptSend() used by enqueue():

const { data: due } = await supabase
  .from("notifications")
  .select("id")
  .in("status", ["pending", "retrying"])
  .lte("next_attempt_at", new Date().toISOString())
  .order("next_attempt_at", { ascending: true })
  .limit(limit);

That query matches the partial index from section 1 exactly: same status filter, same sort column. Because there's only one send path, backoff and dead-lettering behave the same whether a row is on its first attempt or its fourth.

7. Read receipts through RLS, and metrics in one view

The server writes notifications with Supabase's service-role client, which bypasses row-level security. Signed-in users get read-only access to their own rows:

create policy notifications_owner_select on public.notifications
    for select using (auth.uid() = user_id);

But clients do need to report "delivered", "opened" and "read". Rather than open up UPDATE, those go through three SECURITY DEFINER functions that can touch exactly one timestamp on exactly one row the caller owns:

create or replace function public.mark_notification_opened(p_id uuid)
returns void language plpgsql security definer set search_path = public as $$
begin
    update public.notifications
       set opened_at = coalesce(opened_at, now())
     where id = p_id and user_id = auth.uid();
    if found then
        insert into public.notification_events(notification_id, user_id, event)
        values (p_id, auth.uid(), 'opened');
    end if;
end $$;

grant execute on function public.mark_notification_opened(uuid) to authenticated;

where ... user_id = auth.uid() means a guessed id from another account matches nothing.
coalesce(opened_at, now()) keeps the first open time when a client acks twice.
if found only logs an event when a row really matched.
set search_path = public pins name resolution, which the Postgres docs recommend for SECURITY DEFINER functions, since they run with the owner's privileges.

The delivered variant also moves status to delivered, but only from pending, sent or retrying, so a late ack can't revive a dead row.

Every step also lands in an append-only notification_events table, and a view turns the timestamp columns into per-type rates with Postgres FILTER clauses:

round(count(*) filter (where opened_at is not null)::numeric
      / nullif(count(*) filter (where delivered_at is not null), 0), 4) as open_rate,

The nullif(..., 0) returns NULL instead of dividing by zero for a type that hasn't delivered anything yet.

8. Broadcasts and segments

Sending to a group goes through broadcast(), which resolves a segment to user ids and calls enqueue() for each of them, so every user's preferences still apply. Segments are one const object that serves as the allowlist, the type and the human-readable label:

export const SEGMENTS = {
  all: "All users with an active device",
  inactive_7d: "No session in the last 7 days",
  never_sessioned: "Has the app but has never completed a session",
  mobility_test_due: "Last mobility test was more than 30 days ago",
  // ...
} as const;

export type Segment = keyof typeof SEGMENTS;

export function isValidSegment(value: unknown): value is Segment {
  return typeof value === "string" && value in SEGMENTS;
}

The admin route validates the request body with isValidSegment(), returns the valid keys in its 400 error, and echoes SEGMENTS[segment] in the response, so whoever triggered the send can see who it targeted in plain words. Adding a segment means adding one key and one case. The switch over Segment lets TypeScript flag a key that has no query yet.

Every segment starts from users with at least one active device token, since there's no point resolving people we can't reach. Most are then simple set differences. inactive_7d is "has ever completed a session" minus "completed one in the last 7 days", so someone who has never done a session isn't counted as lapsed. They have their own never_sessioned segment.

broadcast() then enqueues in batches of 25 with Promise.all, and catches errors per user so one bad row doesn't sink the batch:

batch.map((userId) =>
  enqueue({ userId, ...params }).catch((e) => {
    console.error(`[broadcast] enqueue failed for ${userId}:`, e);
    return { error: "exception" };
  })
)

The result is three counters, enqueued, skipped and errors, where "skipped" means the user's own preferences said no.

What we'd tell someone building the same thing

If you already have Postgres, try a table before adding a queue service. Status, attempts and next_attempt_at on the row, plus a partial index on in-flight work, covers retries and dead letters for a small team.
Gate on preferences before inserting. Put the defaults in the schema so opt-in categories stay opt-in.
Keep one send path. The first attempt and every retry run the same function.
Treat next_attempt_at as eligibility. Your drain schedule sets the real floor on retry latency.
Ask FCM for per-token results. Deactivate tokens that are permanently invalid, and count a send as a success if any device got it.
Let clients write through narrow SECURITY DEFINER functions, not broad UPDATE policies.

If you want to see what all this is in service of, MotionLab builds stretching sessions around how your body feels today, and the blog has the mobility side of things.

How do you handle notification retries? Postgres table, a hosted queue, or something like pg-boss? We'd like to hear what's worked for you in the comments.

This article was drafted with AI assistance and reviewed by the MotionLab team.

Scheduled app blocks in Kotlin: day bitmasks, overnight windows, and a Flow that wakes on time

Tal Aizikov — Tue, 06 Oct 2026 15:19:19 +0000

A one-off app block is simple to model: a package name and a timestamp. When the timestamp passes, the block is over. A recurring block is harder. "Block these apps from 22:00 to 06:00 on weeknights" has to answer questions like: is it active right now, when does it end, what happens when it crosses midnight, and how does a background service find out the moment it starts?

We're building ReClaim, a minimalist Android launcher with app blocking built in. In an earlier post we covered the launcher plumbing: the HOME intent, LauncherApps, usage stats and the accessibility service. This one goes deep on a single feature, scheduled blocks: the Room schema, the time math, and the coroutine Flow that tells enforcement exactly when to wake up.

Stack: Kotlin, Room 2.6, Hilt, coroutines, minSdk 26. Snippets are trimmed from the real code.

1. The schema: minutes from midnight and a 7-bit day mask

A schedule is one row, plus membership rows for the apps (and websites) it covers:

/**
 * A recurring block window. [startMinutes]/[endMinutes] are minutes from midnight.
 * [daysMask] is a 7-bit mask, bit 0 = Monday … bit 6 = Sunday.
 */
@Entity(tableName = "schedules")
data class ScheduleEntity(
    @PrimaryKey(autoGenerate = true) val id: Long = 0,
    val name: String,
    val startMinutes: Int,
    val endMinutes: Int,
    val daysMask: Int,
    val enabled: Boolean = true,
)

@Entity(tableName = "schedule_apps", primaryKeys = ["scheduleId", "packageName"])
data class ScheduleAppEntity(
    val scheduleId: Long,
    val packageName: String,
)

A few deliberate choices here:

Times are minutes from midnight, not timestamps. A schedule is a wall-clock rule ("22:00 local"), not an instant, so 1320 means the same thing every week.
Days are a bitmask, not seven booleans or a child table. Bit 0 is Monday, which lines up with java.time.DayOfWeek, where MONDAY.value == 1. So "today's bit" is just 1 shl (dayOfWeek.value - 1). Since minSdk is 26, java.time is available without desugaring.
Membership uses composite primary keys. (scheduleId, packageName) makes duplicates impossible at the database level, and an app can belong to any number of schedules.

The mask also keeps the UI code small. Toggling a day chip is one xor, and the list screen gets readable summaries from a when over common masks:

fun toggleDay(dayIndex: Int) =
    _draft.update { it.copy(daysMask = it.daysMask xor (1 shl dayIndex)) }

private fun daysSummary(mask: Int): String = when (mask) {
    0b1111111 -> "Every day"
    0b0011111 -> "Weekdays"
    0b1100000 -> "Weekends"
    0 -> "No days"
    else -> DAY_SHORT.filterIndexed { i, _ -> (mask and (1 shl i)) != 0 }.joinToString(", ")
}

The repository exposes a UI-friendly ScheduleView (schedule plus its package and host lists) by combine-ing three Room Flows and grouping membership rows by scheduleId. Because Room's observable queries re-emit when their tables change, any edit to a schedule or its apps flows through without manual refresh.

2. "Is this schedule active right now?"

Same-day windows are easy: the day bit is set and start <= now < end. Overnight windows are the interesting case. If a schedule runs 22:00 to 06:00, then at 02:00 on Saturday the question isn't "is Saturday selected?" It's "was Friday selected?", because that's the night the window started.

private fun isActiveNow(schedule: ScheduleEntity, now: LocalDateTime): Boolean {
    val minutes = now.hour * 60 + now.minute
    val todayBit = 1 shl (now.dayOfWeek.value - 1)          // Monday=1 -> bit 0
    val yesterdayBit = 1 shl ((now.dayOfWeek.value + 5) % 7)
    return if (schedule.startMinutes <= schedule.endMinutes) {
        (schedule.daysMask and todayBit) != 0 &&
            minutes >= schedule.startMinutes && minutes < schedule.endMinutes
    } else {
        // Overnight window (e.g. 22:00–06:00).
        ((schedule.daysMask and todayBit) != 0 && minutes >= schedule.startMinutes) ||
            ((schedule.daysMask and yesterdayBit) != 0 && minutes < schedule.endMinutes)
    }
}

The (value + 5) % 7 expression is "yesterday's bit index" written without branches. Today's index is value - 1. Yesterday's is value - 2, wrapped into 0..6, which is (value - 2 + 7) % 7, or (value + 5) % 7. On Monday (value == 1) that gives 6, Sunday's bit.

So for a Monday–Friday 22:00–06:00 schedule:

Friday 23:30 is active (Friday's bit, after the start).
Saturday 02:00 is active (yesterday was Friday).
Monday 02:00 is not active, because Sunday isn't selected. The weeknight rule doesn't leak into Sunday night.

now is a parameter defaulting to LocalDateTime.now(), and the public functions built on this take it the same way. That keeps the time math independent of the system clock, so you can reason about it (or test it) with fixed dates.

"Which packages are blocked by schedules right now?" is then a filter plus a set:

suspend fun blockedPackagesNow(now: LocalDateTime = LocalDateTime.now()): Set<String> {
    val activeIds = scheduleDao.enabledSchedules()
        .filter { isActiveNow(it, now) }.map { it.id }.toSet()
    if (activeIds.isEmpty()) return emptySet()
    return scheduleDao.allScheduleApps()
        .filter { it.scheduleId in activeIds }
        .map { it.packageName }
        .toSet()
}

3. "When does it end?" and overlapping schedules

The block screen shows a countdown, so it needs an end instant. For an overnight window, that's either this morning (the early-morning tail) or tomorrow morning (the evening part):

private fun windowEndEpochMillis(schedule: ScheduleEntity, now: LocalDateTime): Long {
    val midnight = now.toLocalDate().atStartOfDay()
    val endToday = midnight.plusMinutes(schedule.endMinutes.toLong())
    val end = when {
        schedule.startMinutes <= schedule.endMinutes -> endToday
        now.hour * 60 + now.minute < schedule.endMinutes -> endToday // early-morning tail
        else -> endToday.plusDays(1)
    }
    return end.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli()
}

Rules are evaluated in local time. Conversion through ZoneId.systemDefault() happens only at the edge, where something needs to wait or count down.

Schedules can overlap, and an app can have a one-off block on top. Whichever ends later wins. scheduledBlockEndMillis() loops over every active schedule covering the package and keeps the latest end. The block repository then merges that with the temporary block:

suspend fun activeBlockUntil(packageName: String): Long? {
    val temp = temporaryBlockUntil(packageName)
    val scheduled = scheduleRepository.scheduledBlockEndMillis(packageName)
    return listOfNotNull(temp, scheduled).maxOrNull()
}

null means "not blocked", which is all the launcher's tap handler checks. The block screen's ViewModel re-reads it every second for its countdown and shows "expired" once it returns null.

4. Waking up exactly when a window starts or ends

The accessibility service that enforces blocks system-wide keeps the blocked set in memory, so each window event is a set lookup. That set comes from a Flow. Our first version recomputed it whenever a block changed and once a minute. That works, but "blocked at 22:00" could mean 22:00:59.

The current version computes when the next transition is due instead. It walks the next eight days for every enabled schedule and collects every future start and end instant:

suspend fun millisUntilNextTransition(now: LocalDateTime = LocalDateTime.now()): Long {
    val zone = ZoneId.systemDefault()
    val nowEpoch = now.atZone(zone).toInstant().toEpochMilli()
    var soonest = Long.MAX_VALUE
    for (schedule in scheduleDao.enabledSchedules()) {
        val overnight = schedule.startMinutes > schedule.endMinutes
        for (dayOffset in 0..7) {
            val date = now.toLocalDate().plusDays(dayOffset.toLong())
            val dayBit = 1 shl (date.dayOfWeek.value - 1)
            if ((schedule.daysMask and dayBit) == 0) continue
            val dayStart = date.atStartOfDay()
            val start = dayStart.plusMinutes(schedule.startMinutes.toLong())
                .atZone(zone).toInstant().toEpochMilli()
            val end = dayStart.plusMinutes(schedule.endMinutes.toLong())
                .let { if (overnight) it.plusDays(1) else it }
                .atZone(zone).toInstant().toEpochMilli()
            if (start > nowEpoch) soonest = minOf(soonest, start)
            if (end > nowEpoch) soonest = minOf(soonest, end)
        }
    }
    return if (soonest == Long.MAX_VALUE) Long.MAX_VALUE else soonest - nowEpoch
}

Why eight days? A Saturday-only schedule still needs a real answer on a Sunday, and scanning 0..7 guarantees every selected weekday appears. Long.MAX_VALUE only means "no enabled schedule has any day selected".

A tiny flow {} turns that into a ticker:

private fun scheduleTicker(): Flow<Unit> = flow {
    while (true) {
        emit(Unit)
        delay(scheduleRepository.millisUntilNextTransition().coerceIn(1_000L, 60_000L))
    }
}

Two details matter:

It re-reads live schedule state every iteration, so an edit doesn't leave it waiting on a stale instant.
The delay is clamped to 1–60 seconds. The floor stops a tight loop at a boundary. The ceiling means a schedule created after a long wait began is still noticed within a minute, and it doubles as a general safety net.

The ticker is then one input of a three-way combine:

val blockedPackages: Flow<Set<String>> = combine(
    blockDao.observeAll(),          // one-off blocks changed
    scheduleRepository.schedules,   // a schedule was created/edited/toggled/deleted
    scheduleTicker(),               // a start or end boundary was crossed
) { rows, _, _ ->
    val now = System.currentTimeMillis()
    val temporary = rows.filter { it.blockedUntil > now }.map { it.packageName }.toSet()
    temporary + scheduleRepository.blockedPackagesNow()
}

The schedule list and the ticker's Unit are only triggers; the answer is re-queried each time. Turning a schedule off therefore lifts its block immediately through the second input, without waiting for the ticker.

5. Acting on the change, not just the next app switch

An updated set alone isn't enough. If you're already in an app when its schedule starts, staying put isn't a switch, so onAccessibilityEvent() never fires. The service's collector checks the current foreground app the moment the set changes:

scope.launch {
    blockRepository.blockedPackages.collect { newBlocked ->
        blockedPackages = newBlocked
        val fg = lastForegroundPackage
        if (fg != null && fg != packageName && fg in newBlocked) {
            withContext(Dispatchers.Main) { runCatching { redirectToBlocked(fg) } }
        }
    }
}

redirectToBlocked() is the same function the window-event path uses, with a one-second per-package debounce. The two paths can fire within the same instant (the set changing is often what an app switch would have seen a moment later), and the debounce keeps them from stacking two block screens.

6. Saving: an `@Upsert` gotcha and replace-all membership

Saving a schedule upserts the row, then replaces its membership lists:

suspend fun saveSchedule(view: ScheduleView): Long {
    val upserted = scheduleDao.upsertSchedule(
        ScheduleEntity(view.id, view.name.ifBlank { "Schedule" },
            view.startMinutes, view.endMinutes, view.daysMask, view.enabled),
    )
    // @Upsert only reports a real rowid for an insert; an update came back as -1.
    val id = if (view.id != 0L) view.id else upserted
    scheduleDao.clearScheduleApps(id)
    scheduleDao.addScheduleApps(view.packages.map { ScheduleAppEntity(id, it) })
    // ...same for schedule_websites
    return id
}

The gotcha: @Upsert returning Long reads like "the row's id", but in our case an update came back as -1. Using that blindly would write every edited schedule's apps under schedule -1. The fix is to trust the id you already have for edits and only use the return value for fresh inserts.

7. Friction that only goes one way

One product rule shapes the edit screens. Adding apps or tightening hours saves with a single tap. Turning a schedule off, deleting it, or saving an edit that drops apps goes through a HoldToConfirmDialog that needs a five-second press; releasing early resets it.

The edit ViewModel snapshots the schedule's packages when it opens and diffs on save:

fun removedPackages(): List<String> =
    (originalPackages - _draft.value.packages.toSet()).toList()

The comment on the dialog explains the reasoning better than we can here: "the moment of wanting out is exactly the moment the original intent deserves a chance to win."

8. Reusing it for websites

When we added website blocking, schedules got a schedule_websites table, and the website repository got the same combine and ticker. Because the time logic lives in ScheduleRepository, websites inherited overnight windows, overlaps and on-time wake-ups for free.

Wrapping up

The pieces that made scheduled blocks manageable:

Store wall-clock rules as minutes plus a day bitmask, and convert to epoch time only at the edges.
For overnight windows, check yesterday's bit for the early-morning tail.
When schedules overlap, the latest end wins.
Compute the next transition and sleep until then, with a clamp as a backstop.
React to the blocked set changing, not only to app switches.

If you're curious how this looks from the user's side, we wrote up how blocks and schedules fit together. ReClaim isn't on Google Play yet; there's a waitlist at tryreclaim.io.

How do you handle recurring time windows in your apps? Bitmasks, cron strings, or something else? We'd like to hear about it in the comments.

This post was drafted with AI assistance and reviewed by the ReClaim team.

Gemini picks the stretch IDs. TypeScript fills the minutes.

Tal Aizikov — Sat, 03 Oct 2026 15:17:23 +0000

Large language models are great at choosing what belongs in a workout. They are unreliable at how long that workout should last.

When we shipped AI sessions for MotionLab — personalized stretching routines built around how your body feels today — we deliberately split those two jobs. Gemini picks stretch IDs from a fixed catalogue. Our Next.js route validates those IDs and fills or trims the list until the session lands near the duration the user asked for. The model never invents an exercise, and it never owns the clock.

This post walks through the real pipeline in our MotionLab-Web repo: the catalogue we send the model, the JSON contract, the local duration loop, and how that fits next to the deterministic generator we already used for non-AI routines. Snippets are trimmed from production TypeScript.

Stack, for context: Next.js 16.2, React 19, Supabase, Firebase, Stripe, and Zustand. The AI route calls Gemini 2.5 Flash.

Why not ask the model for a full routine?

An early temptation with any fitness AI is: send the user prompt, get back names, durations, cues, and ordering. That fails in three boring ways.

Hallucinated exercises. A model will happily invent a stretch that is not in your library, misspell an ID, or mix two moves into one name.
Duration drift. "About 15 minutes" in natural language does not map cleanly to a sum of per-exercise seconds, especially when some moves are side-specific and count twice.
Content you already wrote. We already store instructions, breathing cues, equipment, and target areas per exercise. Regenerating that text per request would be slower, less consistent, and harder to review.

So the model is a selector, not an author. It returns a short JSON object: a session name, a session type, and an array of IDs that must already exist in ALL_EXERCISES.

The catalogue the model actually sees

Every exercise in the library is compacted into one line before it goes into the system prompt: id|targetAreas|stretchType. No long descriptions. No video URLs. Just enough for the model to match "tight hips after desk work" to the right IDs.

const CATALOGUE = ALL_EXERCISES
  .map((e) => `${e.id}|${e.targetAreas.join(",")}|${e.stretchType}`)
  .join("\n");

const SYSTEM = `You are a mobility coach. Given user input and the exercise list, select 4-8 exercises.
Reply ONLY with valid JSON (no markdown, no code fences):
{"name":"<short session name>","type":"DAILY_MAINTENANCE|PRE_WORKOUT|POST_WORKOUT","ids":["id1","id2",...]}
Rules: no duplicate ids, ids must be from the list, prioritize areas user mentions, avoid redundant overlaps.

Exercises (id|targetAreas|stretchType):
${CATALOGUE}`;

That keeps the prompt dense. The catalogue currently has on the order of seventy-five stretches and growing; sending full copy for each would burn tokens for little gain. The client only needs to send a free-text prompt and an optional durationMinutes (we default to 15).

Calling Gemini with thinking turned off

The route is a standard App Router POST handler. We require a non-empty prompt and a configured GEMINI_API_KEY, then hit Gemini 2.5 Flash with a low temperature and a hard cap on output tokens. For this classification-style job we also set thinkingBudget: 0 so the model does not spend tokens on an internal chain-of-thought we will throw away.

const geminiRes = await fetch(
  `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=${key}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      contents: [{ role: "user", parts: [{ text: `${SYSTEM}\n\nUser: ${prompt}` }] }],
      generationConfig: {
        temperature: 0.3,
        maxOutputTokens: 512,
        thinkingConfig: {
          thinkingBudget: 0, // disable thinking — not needed for simple classification
        },
      },
    }),
  }
);

After the response comes back we strip accidental markdown fences, JSON.parse the text, and map IDs through a real lookup table. Anything not in ALL_EXERCISES is dropped. If nothing valid remains, we return 422 instead of improvising.

const exerciseMap = Object.fromEntries(ALL_EXERCISES.map((e) => [e.id, e]));
let exercises = (parsed.ids ?? [])
  .filter((id) => exerciseMap[id])
  .map((id) => exerciseMap[id]);

if (!exercises.length) {
  return NextResponse.json({ error: "No valid exercises returned" }, { status: 422 });
}

That single filter is the safety rail. The model can only point at rows we already ship.

Filling and trimming to the user's clock

Gemini is asked for 4–8 IDs. That set is rarely the exact length of a 7-, 15-, or 25-minute session. Side-specific stretches also double their durationSeconds because each side gets its own hold. So duration is computed locally:

const targetSeconds = durationMinutes * 60;

const calcDur = (e: (typeof ALL_EXERCISES)[0]) =>
  e.isSideSpecific ? e.durationSeconds * 2 : e.durationSeconds;

let filledSeconds = exercises.reduce((s, e) => s + calcDur(e), 0);

if (filledSeconds < targetSeconds - 60) {
  const aiIds = new Set(exercises.map((e) => e.id));
  const tightAreas = new Set(exercises.flatMap((e) => e.targetAreas));
  const supplementPool = shuffle(
    ALL_EXERCISES.filter(
      (e) => !aiIds.has(e.id) && e.targetAreas.some((a) => tightAreas.has(a))
    )
  );
  for (const ex of supplementPool) {
    if (filledSeconds >= targetSeconds - 60) break;
    exercises.push(ex);
    filledSeconds += calcDur(ex);
  }
}

If the AI list is short, we supplement from exercises that share the same target areas the model already chose. That keeps the session thematically coherent without a second model call. Then we trim so the accumulated length does not overrun the target by more than a minute:

const finalExercises: typeof exercises = [];
let accSeconds = 0;
for (const ex of exercises) {
  const dur = calcDur(ex);
  if (accSeconds + dur <= targetSeconds + 60) {
    finalExercises.push(ex);
    accSeconds += dur;
  }
}

The ±60 second buffer matches how people experience a timed session: one stretch longer or shorter than the label is fine; three minutes over is not. Session type is validated against a small allowlist (DAILY_MAINTENANCE, PRE_WORKOUT, POST_WORKOUT) with a safe default if the model returns something else.

The response is a normal Routine object: ID, name, duration, type, full exercise records, and a short description that quotes the user's prompt. The client already knows how to render guided timers from that shape.

The deterministic twin: non-AI generation

AI sessions are not the only path. Most daily routines still go through generateRoutine in src/lib/routine/generator.ts — no LLM involved. That function takes a fixed duration of 7, 15, or 25 minutes, a routine type, optional sport keys, optional tight areas, and optional exclusions. It mirrors the weighting logic we use on Android.

Sport keys expand into priority target areas (running → hamstrings, calves, ankles, hip flexors; swimming → shoulders, upper back, neck, chest; and so on). Tight areas are merged first, then sport areas. The pool is filtered to matching exercises when possible. Sport-related exercises are double-weighted in a candidate list, the list is shuffled, and we walk it until the second budget is filled — again with no repeats and the same side-specific duration math.

export function generateRoutine(options: {
  durationMinutes: 7 | 15 | 25;
  type: RoutineType;
  sport?: string | null;
  tightAreas?: TargetArea[];
  excludeIds?: string[];
  focusId?: string;
}): Routine {
  // ... build focusAreas from tightAreas + sport maps ...
  // weight sport-specific exercises 2x, shuffle, fill without repeats
}

For 15- and 25-minute sessions we sometimes extend a non-sided stretch to 120 seconds so longer blocks do not need twice as many distinct moves. Daily focus IDs (desk job, wake-up, lower body, and so on) can further restrict the pool when the catalogue has enough tagged exercises.

The important design point: AI and non-AI paths share one exercise catalogue and one duration model. Gemini only replaces the "which IDs first" step. Everything else — validation, timing, UI — stays identical. That made shipping AI sessions a route and a prompt, not a second product surface.

Practical lessons

Keep the model inside a closed set. If your product has a curated library, send IDs (or compact rows) and reject anything else. Do not ask the model to invent catalogue entries.

Own duration in application code. Summing typed fields you control is cheaper and more predictable than asking an LLM to hit a minute target.

Reuse the domain object. Returning the same Routine shape as the deterministic generator meant the player, history, and analytics did not need an AI-specific branch.

Turn off features you do not need. For ID selection, low temperature and thinkingBudget: 0 cut latency and cost without hurting quality.

Supplement thematically, do not random-pad. When we need more minutes, we pull from the same target areas the model already emphasized. Padding with unrelated stretches would feel like a broken personalization promise.

Where this sits in the product

Users can still pick a classic session type and duration and get a weighted routine with no model call. When they want to describe a situation in plain language — post–leg day, pre-run warm-up, shoulders locked up from swimming — AI sessions take that sentence, pick IDs, and hand the same timer experience. We wrote more about the product framing on the MotionLab blog; the implementation above is what sits behind the generate button.

If you are wiring Gemini (or any LLM) into a domain with a real inventory — recipes, workouts, lesson plans, spare parts — the same split applies: let the model choose from your SKUs, and let your code enforce quantities, prices, and clocks.

This article was drafted with AI assistance and reviewed by the MotionLab team.

Building a minimal Android launcher in Kotlin: lessons from ReClaim

Tal Aizikov — Thu, 01 Oct 2026 14:40:59 +0000

A launcher sounds like a big piece of software. It's the first thing you see when you unlock your phone and the thing you return to every time you press Home. But on Android, a launcher is "just" an app with one particular intent filter, plus a lot of small decisions about what to show and when.

We're building ReClaim, a minimalist Android launcher meant to make productive apps instant and distracting apps intentional. This post walks through the platform pieces it uses: how an app becomes the Home screen, how it lists and launches other apps, how it reads usage data, and how it enforces app blocks outside its own UI. Along the way we cover a few Android quirks we ran into.

For context, the app is written in Kotlin with Jetpack Compose and Material 3. It uses an MVVM structure with Hilt for dependency injection, Room for blocks and schedules, and DataStore for preferences. It targets minSdk 26 and targetSdk 36. The snippets below are trimmed versions of the real code.

1. Becoming a Home app

Android picks a Home screen by resolving an intent with ACTION_MAIN and CATEGORY_HOME. Any activity that declares that category is a candidate:

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:launchMode="singleTask"
    android:clearTaskOnLaunch="true"
    android:stateNotNeeded="true"
    android:excludeFromRecents="true"
    android:windowSoftInputMode="adjustNothing">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.HOME" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

The attributes matter as much as the filter:

singleTask means there is only ever one instance of the Home activity. Pressing Home while you're already on it doesn't create a new one.
clearTaskOnLaunch and stateNotNeeded tell the system the Home task can be reset and doesn't need saved state restored. That suits a screen users expect to look the same every time.
excludeFromRecents keeps the launcher out of the Recents list.
adjustNothing stops the keyboard from resizing the layout when search opens.

Because the activity is singleTask, pressing Home while ReClaim is already in front delivers the intent to onNewIntent() instead of recreating the activity. That's the hook for "go back to the main page and close whatever overlay is open":

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    setIntent(intent)
    rootViewModel.onHomePressed() // emits on a SharedFlow the Compose UI collects
}

See Tasks and the back stack for how these launch modes behave.

2. Asking to be the default (and checking you really are)

Declaring the filter only makes you eligible. The user still has to choose you. On API 29+ the cleanest way to ask is RoleManager with ROLE_HOME, which shows a native system dialog. Below that, or when no dialog would appear, you fall back to the system Home-app picker via Settings.ACTION_HOME_SETTINGS:

fun requestRoleIntent(context: Context): Intent? {
    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.Q) return null
    val rm = context.getSystemService(RoleManager::class.java) ?: return null
    if (!rm.isRoleAvailable(RoleManager.ROLE_HOME)) return null
    if (rm.isRoleHeld(RoleManager.ROLE_HOME)) return null // system would finish instantly, no dialog
    return rm.createRequestRoleIntent(RoleManager.ROLE_HOME)
}

fun homeSettingsIntent(): Intent =
    Intent(Settings.ACTION_HOME_SETTINGS).addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)

Here's the quirk. Android records the default launcher in two places: the ROLE_HOME holder and the PackageManager's preferred-activity entry for the Home intent. They can disagree. We hit a state where the preferred-activity entry had been dropped while the role stayed put. Home then resolved to the system chooser, and the user saw "Select a Home app" after a reboot or a low-memory kill, even though isRoleHeld() still returned true.

So to answer "does pressing Home actually open us?", we resolve the real Home intent instead of trusting the role:

fun isDefaultLauncher(context: Context): Boolean {
    val intent = Intent(Intent.ACTION_MAIN).addCategory(Intent.CATEGORY_HOME)
    val resolved = context.packageManager
        .resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY)
    return resolved?.activityInfo?.packageName == context.packageName
}

fun isHomeRoleStale(context: Context) =
    holdsHomeRole(context) && !isDefaultLauncher(context)

When the state is stale, the role request finishes without showing anything, because the role is already held. What did repair it was re-selecting the launcher in the system Home-app picker, so the setup screen explains that step instead of showing a dead "Enable" button.

3. Listing and launching apps with LauncherApps

You can query PackageManager for CATEGORY_LAUNCHER activities. But LauncherApps is the API built for launchers. It returns launchable activities for a user profile and gives you callbacks when packages are added, removed or changed. Wrapping that in a callbackFlow gives the rest of the app a reactive list:

private val launcherApps = context.getSystemService(LauncherApps::class.java)
private val myUser = Process.myUserHandle()

fun currentApps(): List<RawApp> =
    launcherApps.getActivityList(null, myUser).map {
        RawApp(it.componentName.packageName, it.componentName.className, it.label.toString())
    }

fun observeApps(): Flow<List<RawApp>> = callbackFlow {
    val callback = object : LauncherApps.Callback() {
        override fun onPackageAdded(pkg: String?, user: UserHandle?) { trySend(currentApps()) }
        override fun onPackageRemoved(pkg: String?, user: UserHandle?) { trySend(currentApps()) }
        override fun onPackageChanged(pkg: String?, user: UserHandle?) { trySend(currentApps()) }
        override fun onPackagesAvailable(p: Array<out String>?, u: UserHandle?, r: Boolean) { trySend(currentApps()) }
        override fun onPackagesUnavailable(p: Array<out String>?, u: UserHandle?, r: Boolean) { trySend(currentApps()) }
    }
    launcherApps.registerCallback(callback, Handler(Looper.getMainLooper()))
    trySend(currentApps())
    awaitClose { launcherApps.unregisterCallback(callback) }
}.flowOn(Dispatchers.Default)

Launching goes through launcherApps.startMainActivity(component, user, null, null). If that fails, it falls back to PackageManager.getLaunchIntentForPackage().

Two notes:

Package visibility. Since Android 11, apps only see a filtered set of other packages (package visibility). A launcher has to list everything, so ReClaim declares QUERY_ALL_PACKAGES. That's a core-functionality use under Google Play's permission policy, but it's a policy-reviewed permission, so only declare it if your app really is a launcher.
Uninstalling. The context menu starts Intent.ACTION_DELETE with a package: URI. On newer PackageInstaller UIs the confirmation dialog didn't appear at all unless the app also declared REQUEST_DELETE_PACKAGES. We also check FLAG_SYSTEM and FLAG_UPDATED_SYSTEM_APP first, so tapping Uninstall on a built-in app explains why it can't be removed instead of silently doing nothing.

A design decision worth mentioning: the Home screen shows a small set of user-chosen favorites with full-color icons. The full app drawer is a text-only alphabetical list with search and an A–Z index bar. The goal, straight from our product spec, is access to every installed app "without making distracting apps visually appealing." Leaving icons out of the drawer is the simplest friction we could add.

4. Reading usage data without fooling yourself

ReClaim uses UsageStatsManager for two things. One is suggesting apps to block together, based on the most-used apps over the last seven days. The other is showing per-app usage on its time-limit and reminder screens. It needs the special PACKAGE_USAGE_STATS access, which the user grants in Settings (Settings.ACTION_USAGE_ACCESS_SETTINGS). You check it through AppOpsManager, not the normal runtime-permission APIs:

fun hasUsageAccess(): Boolean {
    val mode = appOps.unsafeCheckOpNoThrow( // checkOpNoThrow below API 29
        AppOpsManager.OPSTR_GET_USAGE_STATS, Process.myUid(), context.packageName
    )
    return mode == AppOpsManager.MODE_ALLOWED
}

For the "most used this week" list, queryUsageStats(INTERVAL_DAILY, start, end) summed by package is good enough.

For "how long have I used this app today", it wasn't. The aggregated stats are bucketed by day internally. A query that starts at local midnight could still include part of the previous day's bucket until it rolled over, which quietly breaks anything that resets at midnight. The fix was to replay the raw event stream from queryEvents() and sum foreground segments ourselves:

private fun foregroundMillis(pkg: String, start: Long, end: Long): Long {
    val events = usageStatsManager.queryEvents(start, end)
    val e = UsageEvents.Event()
    var active = 0; var segmentStart = -1L; var total = 0L
    while (events.hasNextEvent()) {
        events.getNextEvent(e)
        if (e.packageName != pkg) continue
        when (e.eventType) {
            UsageEvents.Event.MOVE_TO_FOREGROUND -> {
                if (active == 0) segmentStart = e.timeStamp.coerceIn(start, end)
                active++
            }
            UsageEvents.Event.MOVE_TO_BACKGROUND -> if (active > 0 && --active == 0) {
                total += e.timeStamp.coerceIn(start, end) - segmentStart
            }
        }
    }
    if (active > 0) total += end - segmentStart // still in the foreground
    return total
}

The counter, instead of naive foreground/background pairing, handles an app briefly switching between its own activities without double-counting.

One more trap: the usage data only reliably reflects a session once it has ended. For live checks while an app is still open, ReClaim tracks the current session's start with SystemClock.elapsedRealtime() and adds it on top of the historical total.

5. Enforcing blocks outside the launcher

Blocking inside your own UI is easy: before launching, check whether the package is blocked and show a block screen instead. But users don't only open apps from the launcher. They also use Recents, notifications, links and other apps. For system-wide enforcement, ReClaim offers an optional AccessibilityService that watches which app comes to the foreground.

The service config subscribes to window events only:

<accessibility-service
    android:accessibilityEventTypes="typeWindowStateChanged|typeWindowsChanged"
    android:accessibilityFeedbackType="feedbackGeneric"
    android:notificationTimeout="100"
    ... />

The core of the handler is short:

override fun onAccessibilityEvent(event: AccessibilityEvent?) {
    val e = event ?: return
    if (e.eventType != AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) return
    val pkg = e.packageName?.toString() ?: return
    if (pkg == "com.android.systemui" || pkg == packageName) return // shade, QS, our own UI
    if (pkg !in blockedPackages) { lastPackage = pkg; return }

    // Debounce so one app switch doesn't stack several block screens.
    val now = SystemClock.elapsedRealtime()
    if (pkg == lastPackage && now - lastRedirectAt < 1_000L) return
    lastPackage = pkg; lastRedirectAt = now

    startActivity(Intent(this, BlockedActivity::class.java).apply {
        addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK)
        putExtra(BlockedActivity.EXTRA_PACKAGE, pkg)
    })
}

A few lessons from building this:

Ignore System UI. The notification shade, quick settings and the volume panel briefly take window focus without the user leaving their app. Treating them as an app switch caused wrong behavior downstream, so com.android.systemui is skipped entirely.
You can't kill another app. Android gives third-party apps no API to force-stop another app's process. Sending the user to a full-screen block (or Home) is the permitted way to do it.
Keep the blocked set in memory. blockedPackages comes from a Flow that merges temporary blocks from Room with scheduled blocks. It's re-evaluated whenever a block changes and once a minute so schedules switch on and off on time. The event handler only does a set lookup.
Blocks don't have an "undo". The repository deliberately has no public unblock(). A block simply expires. That's a product decision, not a technical one, but it shapes the data layer: expired rows are pruned lazily and the DAO's delete method exists only for cleanup.
Stay alive. Setup offers the one-tap REQUEST_IGNORE_BATTERY_OPTIMIZATIONS dialog so Doze/App Standby is less likely to restrict blocking in the background.

Accessibility APIs are sensitive, and Google Play treats non-accessibility uses of them as a policy-reviewed case. ReClaim shows its own disclosure dialog before sending the user to Accessibility settings. It says plainly that ReClaim isn't an accessibility tool, that only the foreground app's identity is checked, and that screen content is never read or sent off the device. The single exception is reading a picture-in-picture window's on-screen bounds so a video left playing after a block can be swiped away. If you build something similar, write that disclosure first. It forces you to keep the service small.

6. Small things nobody tells you

Pulling down notifications from a gesture has no public API. Launchers commonly call the hidden StatusBarManager.expandNotificationsPanel() via reflection, which needs the EXPAND_STATUS_BAR permission. Wrap it in runCatching. It's not guaranteed to exist.
Default shortcuts (Phone, Photos) are resolved from the system: ACTION_DIAL and CATEGORY_APP_GALLERY. Ignore results whose package is "android", because that's the resolver/chooser, not a real default.
Web search fires ACTION_WEB_SEARCH and falls back to a browser URL, so it still works on devices without a search app.

Wrapping up

The interesting part of a launcher isn't the grid of icons. It's the platform plumbing underneath: the HOME intent and its launch modes, the gap between ROLE_HOME and what Home actually resolves to, LauncherApps for the app list, usage events you have to replay yourself, and an accessibility service kept as small as possible.

ReClaim isn't on Google Play yet. If you want to try it when it launches, there's a waitlist at tryreclaim.io. If you're more interested in the user side of this, here's how we think about a minimal Android home screen setup.

Questions about any of the Android APIs above, or a launcher quirk you've hit yourself? Drop them in the comments.

This post was drafted with AI assistance and reviewed by the ReClaim team. Code excerpts are from the ReClaim app.

DEV Community: Tal Aizikov

One subscriptions row, two stores: Stripe and Google Play in Next.js + Supabase

1. One row, keyed by user

2. Checkout: put the user ID where every later event can find it

3. The webhook: raw body first, then re-fetch

4. Stripe moved two fields under us

Users from before the migration

5. Google Play: verify the token on the server, write the same row

Side effects get their own idempotency key

6. Reading it back, and the redirect race

What we'd keep, and what we'd change

Blocking websites on Android by reading only the address bar

1. Asking for a little more

2. Find the bar, skip the page

3. From address-bar text to a host

4. Typing is not visiting

5. Three ways to notice

6. Leaving the tab

7. Same rules, different key

8. Trade-offs

Wrapping up

A Postgres table as our push queue: retries, dead letters, and FCM in Next.js

1. The table is the queue

2. Enqueue: check preferences before writing anything

3. One attempt: send, then record what happened

4. Channels: the dispatcher doesn't know it's doing push

5. FCM: per-token results and token hygiene

6. The drain: a cron route that only does catch-up

7. Read receipts through RLS, and metrics in one view

8. Broadcasts and segments

What we'd tell someone building the same thing

Scheduled app blocks in Kotlin: day bitmasks, overnight windows, and a Flow that wakes on time

1. The schema: minutes from midnight and a 7-bit day mask

2. "Is this schedule active right now?"

3. "When does it end?" and overlapping schedules

4. Waking up exactly when a window starts or ends

5. Acting on the change, not just the next app switch

6. Saving: an @Upsert gotcha and replace-all membership

7. Friction that only goes one way

8. Reusing it for websites

Wrapping up

Gemini picks the stretch IDs. TypeScript fills the minutes.

Why not ask the model for a full routine?

The catalogue the model actually sees

Calling Gemini with thinking turned off

Filling and trimming to the user's clock

The deterministic twin: non-AI generation

Practical lessons

Where this sits in the product

Building a minimal Android launcher in Kotlin: lessons from ReClaim

1. Becoming a Home app

2. Asking to be the default (and checking you really are)

3. Listing and launching apps with LauncherApps

4. Reading usage data without fooling yourself

5. Enforcing blocks outside the launcher

6. Small things nobody tells you

Wrapping up

6. Saving: an `@Upsert` gotcha and replace-all membership