DEV Community: Daonware

FairTrack — Building an Offline-First Nutrition Tracker for Android (No Account, No Cloud, No Ads)

Daonware — Fri, 10 Jul 2026 12:46:21 +0000

Why I built another calorie tracker

Every mainstream calorie tracker follows roughly the same playbook: create an account before you're allowed to log a banana, sync your eating habits to a server, and monetize that data one way or another — subscriptions, ads, or both. I wanted something different: an app that opens straight into today's diary, stores everything locally, and sends exactly one thing over the network — a barcode I chose to scan.

That app is FairTrack, and version 1.0.1 just shipped as the first public release. It's built with Kotlin and Jetpack Compose, and it's source-available on GitHub. In this post I want to walk through some of the more interesting engineering decisions: the offline-first data model, why there's no charting library, how the Room migrations are structured, and the privacy trade-offs that shaped the architecture.

Repo: github.com/daonware-it/FairTrack

The stack, briefly

Concern	Choice
Language	Kotlin 2.3.20
UI	Jetpack Compose (Material 3), Glance for widgets
Architecture	MVVM, unidirectional state via `StateFlow`
DI	Hilt
Persistence	Room (versioned migrations), DataStore for preferences
Networking	Retrofit, OkHttp, kotlinx.serialization
Background work	WorkManager
Images	Coil

minSdk is 24 (Android 7.0), with core library desugaring so java.time is usable across all supported versions.

Offline-first is a data-modeling problem, not a UI problem

"Offline-first" is often treated as a caching layer bolted onto an otherwise online app. I wanted it to be the default state, not a fallback. Concretely that meant:

A curated offline catalogue of 116 fruits and vegetables, bundled with the app, so the single most common logging action — "I ate an apple" — never touches the network at all.
Micronutrient reference data derived from the German Bundeslebensmittelschlüssel (BLS 4.0, Max Rubner-Institut, CC BY 4.0), also bundled locally, covering 14 vitamins and minerals against EU nutrient reference values (Regulation 1169/2011).
Barcode scanning as the only network-dependent path. CameraX + ML Kit handle the scan itself on-device; only the resolved barcode is sent to the Open Food Facts API (ODbL license) to fetch product data. No analytics SDK ships in the dependency graph — that's directly checkable in the build files. The practical effect: you can install FairTrack in airplane mode, log a custom meal, hit your macro goals, and never notice the network doesn't exist.

Room migrations: destructive fallback is a trap

Room's fallbackToDestructiveMigration() is tempting during early development — schema changes stop being annoying. But for an app whose entire value proposition is "your data lives only on your device," a silent wipe on a missed migration is unacceptable. There's no server copy to restore from.

So the migration policy is:

Every schema change ships an explicit, versioned Migration in data/Migrations.kt.
The Room schema is exported to app/schemas/ and checked in, so historical schemas are diffable in review.
Destructive fallback is enabled only for downgrades, not upgrades — a missing forward migration fails loudly (crash, visible bug report) instead of quietly deleting a user's weight history. A minimal example of the pattern — adding a column instead of letting Room recreate the table:

val MIGRATION_4_5 = object : Migration(4, 5) {
    override fun migrate(db: SupportSQLiteDatabase) {
        db.execSQL(
            "ALTER TABLE diary_entry ADD COLUMN portion_note TEXT DEFAULT NULL"
        )
    }
}

This is more upfront work per schema change, but it matches the app's actual promise: there's no cloud backup to fall back on, so local data integrity has to be treated as load-bearing.

Why there's no charting library

Statistics — weekly calorie bars, a macro donut, logging streaks — are drawn directly on a Compose Canvas. No Vico, no MPAndroidChart wrapper, nothing pulled from Maven for this.

The reasoning was mostly pragmatic rather than ideological: the chart set is small and fixed (bars, a donut, a streak grid), the styling needs to match the app's Material You theming exactly rather than approximate it through a library's theming API, and a raw Canvas implementation is a few hundred lines total versus a dependency that would otherwise dominate the APK's chart-related surface area. For a small, fixed set of visualizations, hand-rolling them ended up being both smaller and easier to theme consistently than adapting a general-purpose library.

Cloud backup is disabled on purpose

This one surprises people: Android's automatic cloud backup (android:allowBackup / auto backup to Google Drive) is explicitly turned off. The default Android behavior would otherwise back up the app's local database — including diary entries, weight history, and body measurements — to the user's Google Drive without any additional code from me.

That's exactly the kind of silent cloud sync FairTrack is meant to avoid, so it's disabled deliberately, and users get an explicit, user-initiated alternative instead: export the whole diary to a JSON file and restore it on another device manually. Opt-in, visible, and fully under the user's control — the opposite of a background sync job.

Goal calculation: Mifflin–St Jeor, with guardrails

Calorie and macro targets come from the Mifflin–St Jeor BMR equation multiplied by an activity factor, with manual overrides available for anyone who wants to set their own numbers directly. A few things layered on top of the raw formula:

Protein and fat scale with goal and activity level; carbohydrates take whatever's left in the calorie budget, rather than all three macros being independently user-set percentages that can silently sum to something nonsensical.
BMI feedback uses an age-dependent healthy range rather than a single fixed cutoff.
There's a guard against underweight targets — the app won't quietly let a goal calculation land somewhere unsafe without surfacing that. None of this is a substitute for medical advice, and the app says so explicitly (nutrition data accuracy depends on crowd-sourced sources, and micronutrient coverage in particular is uneven).

CI/CD and keeping the signing key out of the repo

A few pipeline details that might be useful if you're setting up something similar:

ci.yml compiles the debug variant on every push and PR.
codeql.yml runs CodeQL static analysis on the Kotlin sources on a schedule and on PRs.
benchmark.yml runs Macrobenchmark-based cold/warm startup timings weekly on an emulator — the trend matters more than any single absolute number.
release.yml builds and signs the APK for GitHub Releases on tag push.
Third-party GitHub Actions are pinned to commit SHAs, not floating tags, and every workflow starts from permissions: {} before opting into what it actually needs. The signed Play Store bundle is built by a separate Azure DevOps pipeline, so the Play upload key never has to exist as a secret inside the GitHub repo at all — a clean separation between "public CI for a source-available repo" and "the credential that can push to production."

One consequence of shipping both a sideloaded APK and a Play Store build: they're signed with different keys, and Android refuses to let one signature replace another. A sideloaded install and a Play install can't update each other — switching sources means exporting your data, uninstalling, and restoring on the other build.

What's next

1.0.1 is the first public release, so the immediate focus is stability and closing gaps in micronutrient coverage.

The license is source-available, not OSI open source: you may read, build, modify and run FairTrack for private, non-commercial use, and contribute back. Redistribution — including publishing it to an app store — requires visible attribution to the project. Commercial use needs written permission. Full terms are in LICENSE.

Repo: github.com/daonware-it/FairTrack
Releases: Latest release

Happy to go deeper on any of the pieces above — the migration strategy, the Canvas chart implementation, or the WorkManager setup behind the fasting timer's persistent notification — if there's interest in the comments.

I Built a Browser Extension to Bring Back the Like/Dislike Badge in YouTube Studio

Daonware — Thu, 25 Jun 2026 12:55:37 +0000

YouTube Studio used to show a small like/dislike badge right next to each video in the content tab. At some point it just... disappeared. No announcement, no reason — it was simply gone.

As someone who likes to keep an eye on how videos are performing at a glance, this was annoying. Opening each video individually just to check the ratio felt like a massive step backwards.

So I did what developers do: I built a fix.

The Problem

If you manage a YouTube channel, you know the content tab is your command center. At a glance you can see views, comments, watch time — but no like/dislike ratio. YouTube quietly stopped showing it.

The numbers aren't gone though. YouTube Studio still loads them internally when you open the page. They're just... not displayed anymore.

The Idea: Intercept, Don't Request

My first instinct was to use the YouTube Data API. But that comes with OAuth flows, quota limits, and a setup process that's anything but seamless.

Then I noticed something while digging through DevTools: YouTube Studio's own frontend was already fetching the like counts via internal youtubei endpoints — it just wasn't rendering them.

That changed everything. Instead of making new API calls, I could simply listen to what the page was already loading and inject the badge myself.

How It Works

The extension has two core scripts:

src/inject.js — Intercepts the internal network responses from studio.youtube.com by wrapping the native XMLHttpRequest. When a response contains video metadata (detected via known field names like likeCount and videoId), it extracts the data and broadcasts it via a custom DOM event.

// Simplified version of the interception logic
const originalOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function (...args) {
  this.addEventListener("load", function () {
    try {
      const json = JSON.parse(this.responseText);
      const videos = extractVideos(json); // walk the response tree
      if (videos.length) {
        document.dispatchEvent(new CustomEvent("ytsr-data", { detail: videos }));
      }
    } catch (_) {}
  });
  return originalOpen.apply(this, args);
};

src/content.js — Listens for those custom events and injects the badge into the correct DOM row for each video. It uses a MutationObserver to handle YouTube's dynamic rendering.

document.addEventListener("ytsr-data", ({ detail: videos }) => {
  for (const video of videos) {
    const row = findRowByVideoId(video.id);
    if (row) injectBadge(row, video.likes);
  }
});

The result: a 👍 92.4% badge appears directly in the content tab, with exact numbers on hover.

Privacy First — By Design

This was a non-negotiable constraint from the start:

✅ Runs only on studio.youtube.com
✅ Makes zero additional network requests
✅ Sends no data to any third-party server
✅ Only reads data from your own logged-in channel
✅ Nothing is stored beyond your local browser session

The extension is essentially a read-only lens on data that was already traveling through your browser.

The Tricky Parts

YouTube Changes Without Warning

Internal endpoints aren't documented. YouTube can rename field keys at any time — and they do. To handle this, I built a debug mode directly into the popup. When enabled, it logs every intercepted payload to the console under a [YTSR] prefix, making it easy to spot which field names changed.

Dislikes Are Not There (Yet)

Here's the honest limitation: YouTube does not include dislike counts in the Studio content endpoint. The extension currently shows like counts only. The "ratio" in the name reflects the roadmap — once I integrate the YouTube Analytics API (which does expose dislikes), the badge will become a true ratio. That requires OAuth per user though, so the UX tradeoff needs careful thought.

MV3 Restrictions

Manifest V3 removed webRequest blocking, which is commonly used for response interception. The workaround here is wrapping XMLHttpRequest from an injected script — which works, but requires careful coordination between the injected world and the content script world via DOM events.

Tech Stack

Layer	Tool
Extension API	Manifest V3 (Chrome, Edge, Brave, Firefox)
Core Logic	Vanilla JavaScript
Build	None — ships as unpacked source
Dev Environment	VS Code
Version Control	GitHub

Deliberately no framework, no bundler, no dependencies. The whole extension is a handful of files.

What I Learned

Building a browser extension that intercepts live page data taught me a lot about how modern web apps load and render dynamic content. The gap between "the data exists" and "the data is visible" is often just a missing render step — and that's a surprisingly powerful place to work.

It also reinforced something I keep coming back to: the best tools solve your own problem first. I built this because I genuinely missed that badge. Every decision — no external requests, no OAuth, debug mode built-in — came from thinking about what I'd want as a user.

Try It Yourself

The extension is open source and ready to install locally:

Clone the repo: git clone https://github.com/daonware-it/yt-studio-ratio
Open chrome://extensions and enable Developer Mode
Click "Load unpacked" and select the folder
Head to YouTube Studio → Content tab

👉 GitHub — daonware-it/yt-studio-ratio
👉 Google Chrome Extension — YT Studio Like/Dislike Ratio

If the badge doesn't appear, flip on Debug Mode in the popup and open the console — you'll see exactly what's happening. And if you run into issues or have ideas, open an issue or drop a comment below. I'd love to hear how it works for you.