Why Offline-First Still Matters

In an era where virtually every utility app demands a subscription, mandatory Google authentication, and continuous internet connectivity, simple tasks like logging a petrol refill have become unnecessarily cumbersome.

When drivers stop at remote highway petrol stations in Assam or across rural routes, network connectivity is often intermittent or entirely unavailable. An automotive utility that fails to record an odometer reading because it cannot reach a cloud database is fundamentally flawed.

This guiding principle led to the creation of Mileage Tracker — Fuel & Cost, published on Google Play.

1. Architectural Principles

Our design embraced three non-negotiable rules:

  1. Zero-Latency Interaction: The app must open and accept an entry within 2 seconds of the user launching it.
  2. Local-First Data Ownership: All operational records reside on the physical device in SQLite. No tracking pixels, no telemetry SDKs, no third-party ad networks.
  3. Graceful Fault Tolerance: If the device powers off or the OS kills the process mid-entry, transactions must roll back cleanly without database corruption.

2. SQLite Data Model & Indexing

The schema was constructed to support fast chronological aggregation:

sql
CREATE TABLE fuel_entries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  vehicle_id INTEGER NOT NULL,
  odometer_km REAL NOT NULL,
  fuel_liters REAL NOT NULL,
  total_cost REAL NOT NULL,
  price_per_liter REAL NOT NULL,
  is_full_tank INTEGER NOT NULL DEFAULT 1,
  missed_previous_fill INTEGER NOT NULL DEFAULT 0,
  timestamp INTEGER NOT NULL,
  notes TEXT
);

CREATE INDEX idx_vehicle_timestamp 
ON fuel_entries(vehicle_id, timestamp DESC);

Calculating Efficiency Between Non-Contiguous Refills

A common pitfall in mileage applications is assuming that every fill-up follows a complete tank replenishment. If a driver partially fills their tank or misses logging a receipt, naive odometer subtraction produces wildly inaccurate efficiency numbers (km/L).

By maintaining a discrete is_full_tank flag and computing rolling delta windows, Mileage Tracker accurately calculates fuel economy only between verified full-tank anchors, ensuring statistical reliability.

3. State Management with Clean Separation

We structured the Flutter application across three distinct layers:

  1. Domain Layer: Pure Dart entities and business rules (e.g. calculating cost per kilometer, fuel consumption statistics, unit conversions between imperial and metric).
  2. Data Layer: SQLite database provider using sqflite, encapsulating CRUD operations and transactional batching.
  3. Presentation Layer: Responsive UI built with Flutter Material 3, adapting dynamically to system theme settings and varying Android screen aspect ratios.

By decoupling the domain logic from Flutter UI widgets, writing unit tests for stoichiometric or mathematical functions required zero mocking of device contexts.

4. Releasing on Google Play

Publishing a production application on Google Play requires continuous compliance with modern Android ecosystem requirements:

  • Target SDK 34+ Compatibility: Managing granular runtime permissions and predictive back navigation gestures.
  • App Bundle (.aab) Optimization: Leveraging Android App Bundles and ProGuard/R8 code shrinking to keep download sizes under 15 MB.
  • Zero-Crash Record: By eliminating third-party analytics and cloud dependencies, the app maintains a 100% crash-free session rate across thousands of operational hours.

5. Reflections: Technology as an Enabler

Building Mileage Tracker reinforced my perspective on software development: technology is at its best when it acts as an invisible, reliable servant to practical everyday problems. Just like in a chemistry laboratory, precision, simplicity, and clean methodology deliver the most enduring results.