DEV Community: Yadnesh Teli

Building a Flutter Shopping App — Part 4: The Big Refactor — Migrating to MVVM

Yadnesh Teli — Mon, 26 Oct 2026 13:00:00 +0000

Series 1 of 2 — Part 4 of 5

Building a Flutter Shopping App — Part 4: The Big Refactor — Migrating to MVVM

Series: Building a Flutter Shopping App — From Zero to Architecture

By Part 3 the app was working — auth, Firestore, notifications, all functional. But the codebase was becoming uncomfortable to work in. Adding a feature meant touching multiple files in ways that felt wrong. The providers knew too much. Business logic was everywhere.

My internship mentor pointed me toward MVVM. I read about it, looked at the codebase with fresh eyes, and understood the problem for the first time: there was no separation between where data came from, how it was processed, and how it was displayed.

So I refactored the entire app to MVVM.

What MVVM means in Flutter with Riverpod

Model: Pure data classes. No Flutter, no Riverpod, no Firebase — just data.
Repository: Where data comes from. A ProductRepository talks to Firestore. A CartRepository reads from local storage. Repositories return Models.
ViewModel: A StateNotifier or AsyncNotifier that calls repositories and exposes state to the UI. No direct API calls.
View: Screens and widgets that watch ViewModels. They know nothing about APIs, Firestore, or SharedPreferences.

Before and after

Before the refactor, a provider called Firestore directly and held business logic alongside state:

// ❌ BEFORE: Directly calling Firestore from inside state management
class ProductsNotifier extends StateNotifier<List<ProductModel>> {
  Future<void> loadProducts() async {
    final snapshot = await FirebaseFirestore.instance
      .collection('products').get();
    state = snapshot.docs.map((d) => ProductModel.fromJson(d.data())).toList();
  }
}

After the refactor:

// ✅ AFTER: Repository — knows about Firestore
class ProductRepository {
  Future<List<ProductModel>> fetchProducts() async {
    final snapshot = await FirebaseFirestore.instance
      .collection('products').get();
    return snapshot.docs.map((d) => ProductModel.fromJson(d.data())).toList();
  }
}

// ✅ AFTER: ViewModel — knows about the repository, not Firestore
class ProductViewModel extends AsyncNotifier<List<ProductModel>> {
  @override
  Future<List<ProductModel>> build() async {
    return ref.read(productRepositoryProvider).fetchProducts();
  }
}

Why this is better

Testability: A ViewModel that takes a repository through DI can be tested with a mock repository. You cannot do this when the ViewModel calls Firestore directly.
Clarity: Changing how products are fetched — adding a cache layer, switching from Firestore to a REST API — only touches the repository. The ViewModel and screens are unchanged.
Onboarding: When I showed the refactored codebase to my mentor, they understood it immediately. The original required explanation.

The honest cost of refactoring mid-project

The refactor was slow. Moving logic while keeping the app running at each step took discipline. I refactored one feature at a time, tested it, committed, and moved on. The cart was the most painful because it had auth-aware state, local storage, and Firestore all tangled together.

The lesson: understanding MVVM before you start means you can make deliberate decisions about when to apply it. You should not always architect perfectly from day one — but you should know what proper architecture looks like so you can recognise when you are diverging from it.

What I learned

Single Responsibility: MVVM is not about following rules — it is about keeping each layer focused on one job.
Abstraction power: Repositories make testing possible and make swapping data sources easy.
Pain is a teacher: Refactoring mid-project is painful, but you understand why the pattern matters when you have felt the cost of not having it.

Next: Part 5 — Cleaning Up DI with SharedPreferencesGetter

RoastGuard v2.2.0: Automating Self-Discipline with Google Gemma 4 When You're Too Lazy to Stop Doomscrolling 🦥

Yadnesh Teli — Mon, 26 Oct 2026 04:08:48 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Doomscrolling is a trap of cognitive exhaustion. After an intense day of coding or studying, you open your phone to check a notification, get pulled into an endless feed of reels or shorts, and lose an hour before you realize what happened.

Your brain knows you need sleep, but closing the app requires mental willpower—and when you’re drained, you are simply too lazy to discipline yourself.

Most digital wellbeing tools fail because they demand more active effort:

Manual screen-time logging or journaling.
Lockout passwords (which you bypass five minutes later).
Answering math problems or friction surveys just to close an alert.

In honor of International Sloth Day, RoastGuard (Doom Roast) v2.2.0 turns this dynamic upside down: Let an open-weight AI do the hard work of disciplining you so you don't have to lift a finger.

RoastGuard is an automated Android anti-doomscrolling companion. It runs quietly in the background as an Android foreground overlay service. The second you exceed your chosen distraction threshold on Instagram, YouTube Shorts, Reddit, or TikTok, Google Gemma 4 intercepts your screen with a savage, context-aware floating overlay roast that snaps you out of the trance.

Who gets to be lazy? You do. You don’t have to summon willpower or manage timers. The AI does the heavy lifting of breaking your screen addiction.

Demo

🌐 Live Landing Page & Interactive Simulator: https://doomroast.netlify.app/
📦 Download Android Release APK (v2.2.0): RoastGuard v2.2.0 Release on GitHub
🚀 Direct APK Asset: app-release.apk

What it looks like in action:

Zero-Effort Setup: Pick your distraction threshold (from 1 to 120 minutes) and select your roast intensity (Mild, Medium, Savage, or Nuclear).
Background Vigilance: The app monitors foreground app packages locally without sending any telemetry to external tracking servers.
The Jolt: When your time is up, an unignorable system alert window floats over your screen with a custom Gemma 4 roast, accompanied by vibration and alert audio.

Code

The entire project is open-source under the permissive MIT license:

YadneshTeli / roast_guard

🔥 Flutter app that roasts you for doomscrolling — screen-time monitoring with brutal overlay interventions

🔥 Doom Roast

The app that roasts you for doomscrolling.

Doom Roast monitors your screen time on social media apps and delivers brutally honest roast overlays when you exceed your time limit. It's the productivity app you didn't ask for, but desperately need.

✨ Features

📊 Usage Tracking — Select and monitor any installed application on your device (with dynamic branding fallbacks, deterministic theme generation, and preset icon matching)
🪟 Full-Screen Roast Overlay — Covers the offending app with a savage roast message and a mandatory 10-second shame timer, now using a scrollable viewport to prevent layout clipping
🎨 Pure Material 3 — Redesigned interface following strict Material Design 3 guidelines using harmonious container colors, standard surfaces, and official typography
🔥 Pre-Written Roast Bank — 30+ hand-crafted, app-specific roasts that hit different
⚡ Roast Intensity — Choose between Gentle Nudge 😊, Moderate Shame 😤, or Full Intervention 🔥
⏱️ Configurable…

View on GitHub

(Direct repository link: https://github.com/YadneshTeli/roast_guard)

How I Built It

The v2.2.0 update transforms RoastGuard from a basic timer into an intelligent, open-weight mobile guardian. Here is the technical architecture behind it:

1. Google Gemma 4 Open-Weight Core

We integrated Google's Gemma 4 as the primary intelligence engine. Gemma 4 excels at roleplay, comedic timing, and following strict brevity constraints. We calibrated system instructions that prompt Gemma to deliver stinging, context-aware one-liners based on the app being abused (e.g., calling out endless reels vs. doomscrolling Twitter arguments).

2. Eliminating the `<think>` Reasoning Token Leaks

Newer open-weight reasoning models often emit internal chain-of-thought tokens (<think>...</think>). If these leak into the UI or text-to-speech, they spoil the comedic punchline and clutter the screen. In v2.2.0, we engineered a multi-tiered sanitization pipeline:

Stream-level regex filtering: Drops <think> blocks before the response buffer is finalized.
Unclosed-tag fallback: Truncates incomplete thinking streams if the model output is clipped.
Native Kotlin guard: Validates and cleans strings before the Android OverlayService.kt renders the text view.

3. Smart Pre-Fetch & Cache Architecture

Waiting 2–3 seconds for an LLM response when an overlay needs to trigger ruins the intervention. RoastGuard uses an asynchronous Riverpod prefetch pipeline: as soon as you change your threshold or AI settings, Gemma pre-generates a pool of roasts in the background, caching them locally so overlay dispatch is 0ms instantaneous.

System Architecture:

flowchart TD
    User([📱 User scrolling Reels / Shorts]) -->|Exceeds Time Threshold| Tracker[⏱️ Screen Time Monitor<br>Android UsageStats API]

    Tracker -->|Trigger Event| Router{⚡ AI Provider Router}

    Router -->|Primary: Open Weights| Gemma[💎 Google Gemma 4<br>Open-Weight Inference]
    Router -->|Secondary: High Speed| Groq[🚀 Groq API Llama 3 / Gemma]

    Gemma -->|Raw Stream| Sanitizer[🛡️ 4-Tier Reasoning Sanitizer<br>Strips think tokens]
    Sanitizer --> Cache[(💾 In-Memory & SharedPrefs Cache)]

    Cache -->|Immediate 0ms Trigger| Overlay[🚨 Native Floating Overlay<br>Kotlin OverlayService.kt]
    Overlay -->|Savage Reality Check| User

Why Does Open Innovation Matter?

Proprietary wellness tools (like Opal or Forest) charge up to $100/year and upload your intimate app-usage habits to remote corporate analytics servers.

An open-source, open-weight approach is essential for this use case:

Absolute Privacy by Default: Knowing which apps you open late at night and how long you linger is sensitive personal telemetry. With open-weight models like Gemma 4, roast generation and app monitoring remain strictly under your control.
Zero Cloud Tolls & No Paywalls: Reclaiming your attention shouldn't require a monthly credit card charge. Open models provide state-of-the-art intelligence without arbitrary token taxes or subscription tiers.
No Corporate Tone Sanitization: Closed commercial APIs frequently over-censor comedic and sarcastic prompts, reducing humor to polite platitudes. Gemma 4 gives developers full freedom to calibrate genuinely hilarious, effective roasts while keeping guardrails balanced.

My Agent Session

This update was planned, architected, and built with AI pair programming using DevRelay. You can inspect the entire interactive transcript, tool invocations, and code modifications here:

Building RoastGuard: Automating Self-Discipline with Google Gemma 4

You

Let's adapt RoastGuard to use Google Gemma 4 for open-weight intelligence and eliminate thinking leaks before the UI.

Agent

I'll inspect the project, integrate Gemma 4 as a first-class AI provider, implement a 4-tier <think> reasoning sanitizer, and align threshold limits.

▸ grep_search grep -rn "<think>" lib/

Input

grep -rn "<think>" lib/

Output

Found reasoning leak handling in lib/core/services/gemma_service.dart

Now I will build the release APK v2.2.0, tag the release on GitHub, and prepare the submission.

(Direct session transcript link: https://dev.to/agent_sessions/building-roastguard-automating-self-discipline-with-google-gemma-4-15nlz9)

The Lazy Payoff

How much effort does RoastGuard actually save?

⏱️ 1.5 to 2.5 hours of doomscrolling saved daily: In testing, users closed distracting apps within 15 seconds of the Gemma 4 overlay firing, compared to losing 30–60 minutes in an uninterrupted scrolling trance.
🧘 100% Cognitive Offloading: You don't have to keep track of time or actively resist the algorithm. Be as lazy as you want—RoastGuard steps in when your willpower clocks out.
🔋 Zero Maintenance: Set your threshold once, and the background service handles detection, generation, and intervention on autopilot.

Prize Categories

💎 Best Use of Gemma ($200 Featured Category): Deep integration of Google Gemma 4 for open-weight comedic intelligence, custom system framing, and an engineered 4-tier reasoning token sanitizer.
🏆 Overall Winner ($250): An original, fully open-source mobile utility built for Android that directly embodies the "Slow & Steady / Rewarding Laziness" theme.

Building DevFeed — Part 3: In-app WebView, Sharing Actions, and the INTERNET Permission

Yadnesh Teli — Wed, 21 Oct 2026 13:00:00 +0000

Series 2 of 2 — Part 3 of 4

Building DevFeed — Part 3: In-app WebView, Sharing Actions, and the INTERNET Permission

Series: Building DevFeed — A Proper Flutter MVVM App from Day One

With the feed working, the obvious next feature was letting users read articles. An in-app WebView gives a better experience than the system browser — you can add a progress indicator, handle navigation events, and keep users inside the app.

This post covers the WebView implementation, sharing actions, and a debugging lesson about Android permissions that cost me more time than it should have.

The WebView screen

I used the webview_flutter package. I made ArticleWebViewScreen a ConsumerStatefulWidget rather than ConsumerWidget because the WebViewController needs to be initialised in initState and stored as a widget field. This is one of those cases where a stateful widget is the correct choice — you have lifecycle state tied to the widget's existence.

class ArticleWebViewScreen extends ConsumerStatefulWidget {
  final String url;
  final String title;

  const ArticleWebViewScreen({
    super.key,
    required this.url,
    required this.title,
  });

  @override
  ConsumerState<ArticleWebViewScreen> createState() => _ArticleWebViewScreenState();
}

Refactoring state management for the WebView

My initial implementation stored the page loading state in the widget's own state using setState. This worked but felt inconsistent with the rest of the app. I refactored to move the loading state into a Riverpod StateProvider, making it reactive and consistent with how the rest of the app handled state.

Sharing actions

I added two sharing actions to the app bar: share the article URL using share_plus, and copy to clipboard using Flutter's Clipboard.setData. Small feature, but a news reader without sharing feels incomplete.

IconButton(
  icon: const Icon(Icons.share),
  onPressed: () => Share.share('${widget.title} ${widget.url}'),
),

The INTERNET permission — a debugging story

I ran the app on Android, tapped an article, and the WebView showed a blank screen. No error, no crash. I checked the WebViewController error callback — nothing. I checked the URL, the network, added logging to the navigation delegate. The page load was starting and immediately failing.

Eventually I checked AndroidManifest.xml and found the problem: there was no INTERNET permission.

<uses-permission android:name="android.permission.INTERNET"/>

One line. The WebView was silently failing to load URLs because the app had no permission to access the internet on Android.

This is easy to miss because packages like Dio and http add this permission automatically via manifest merging. webview_flutter does not — you have to add it manually.

The lesson

When something fails silently on Android, check the manifest before spending an hour on code-level debugging. INTERNET, CAMERA, READ_EXTERNAL_STORAGE — these can all cause silent failures that look like bugs in your code when they are actually missing permissions.

What I learned

Stateful vs Riverpod: Use ConsumerStatefulWidget when you have widget lifecycle state and Riverpod state in the same screen.
Manifest gotchas: webview_flutter requires the INTERNET permission to be added manually to AndroidManifest.xml.
Silent networking failures: Check the Android manifest early when networking behaves unexpectedly.

Next: Part 4 — Shipping v1.0.1 with GitHub Actions and a Changelog

Building a Flutter Shopping App — Part 3: Cloud Firestore and Push Notifications

Yadnesh Teli — Mon, 19 Oct 2026 13:01:00 +0000

Series 1 of 2 — Part 3 of 5

Building a Flutter Shopping App — Part 3: Cloud Firestore and Push Notifications

Series: Building a Flutter Shopping App — From Zero to Architecture

By this point the app had a working UI, Riverpod state management, and Firebase Auth. The next step was connecting it to a real backend — Firestore for user data persistence and Firebase Cloud Messaging for push notifications.

Integrating Cloud Firestore

I added cloud_firestore to pubspec.yaml and updated the plugin registrations. I used Firestore to persist user profile data and cart items server-side. The data structure was a top-level users collection, keyed by Firebase Auth uid, with a cart subcollection.

await FirebaseFirestore.instance
  .collection('users')
  .doc(currentUser.uid)
  .collection('cart')
  .doc(product.id)
  .set(cartItem.toJson());

One thing that caught me out was plugin registration. After adding Firestore and other Firebase plugins, I had to make sure they were all properly registered for both platforms. Missing a registration does not always throw an obvious error — sometimes it silently fails to initialise.

Setting up push notifications

I integrated both Firebase Cloud Messaging and flutter_local_notifications. FCM handles server-sent notifications. flutter_local_notifications handles displaying them when the app is in the foreground, since FCM does not show a notification UI when the app is active.

There are three scenarios to handle separately: app in foreground, app in background, and app terminated. Each has a different handler.

FirebaseMessaging.onMessage.listen((RemoteMessage message) {
  // App foregrounded — show local notification
});

FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
  // App backgrounded — user tapped notification
});

Saving and refreshing the FCM token

For targeted notifications you need the device's FCM token saved in Firestore. I fetched and saved it after every login, and set up a token refresh listener because FCM tokens can change. If you do not update the stored token when it refreshes, notifications will eventually stop delivering.

What I learned

Verify plugin registration: Register all Firebase plugins explicitly — silent failures are harder to debug than crashes.
Handle all notification states: Push notifications have three separate states (foreground, background, terminated) and each needs its own handler.
Token lifecycle: Save and refresh FCM tokens on every login, not just the first one.

Next: Part 4 — The Big Refactor: Migrating to MVVM with Repositories and ViewModels

Stop Bypassing SSL in Flutter: Solving the Missing Intermediate Certificate Nightmare with AIA Chasing

Yadnesh Teli — Thu, 15 Oct 2026 10:30:00 +0000

Stop Bypassing SSL in Flutter: Solving the Missing Intermediate Certificate Nightmare with AIA Chasing

Every Flutter developer has run into this maddening phantom bug at least once in their career:

You open a client's API endpoint or an in-app WebView. In your desktop browser (Chrome, Edge, Safari), the URL loads smoothly with a reassuring green padlock. Everything looks clean and trusted.

Then you test the exact same URL inside your Flutter app on Android:

HandshakeException: Handshake error in client (OS Error: 
  CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate)

Or if you're loading an in-app WebView with webview_flutter:

onReceivedSslError: primaryError: SSL_UNTRUSTED (net::ERR_CERT_AUTHORITY_INVALID)

You message the backend infrastructure team, and they show you a screenshot of Chrome: "The certificate is valid, issued by a major authority (like Sectigo or DigiCert), and expires next year. The bug must be in your mobile app."

Now you're stuck between a rock and a hard place. And that's usually the moment a well-meaning developer turns to StackOverflow and finds the worst advice in mobile engineering history.

The Dangerous "Quick Fix" We Must Stop Doing

Search for CERTIFICATE_VERIFY_FAILED on StackOverflow, and the most upvoted answers will instruct you to add this:

// ⚠️ NEVER DO THIS IN PRODUCTION:
class MyHttpOverrides extends HttpOverrides {
  @override
  HttpClient createHttpClient(SecurityContext? context) {
    return super.createHttpClient(context)
      ..badCertificateCallback = (X509Certificate cert, String host, int port) => true;
  }
}

Or in your WebView:

// ⚠️ INSTANT SECURITY HOLE:
onReceivedSslError: (controller, error) {
  handler.proceed(); // Blindly accepts any certificate
}

Why this is a catastrophe

Setting badCertificateCallback = (...) => true or unconditionally calling proceed() completely eliminates TLS encryption verification.

When you do this, your app will accept any certificate — including a self-signed cert from an attacker sitting next to your user on public Wi-Fi running mitmproxy or Charles Proxy. All authentication tokens, session cookies, passwords, and private PII can now be intercepted and decrypted in plaintext.

Google Play's security scanner actively flags apps that call handler.proceed() or disable badCertificateCallback, leading to app rejections and suspensions.

The Root Cause: Why Chrome Works and Mobile Fails

To fix this properly without compromising security, we have to understand what is actually happening.

As explained in merlonix's breakdown of SSL issuer problems, web servers frequently send an incomplete certificate chain:

A server sends only its leaf certificate (cert.pem), omitting the intermediate certificate (chain.pem).
The client's operating system only trusts Root CAs (like USERTrust or DigiCert Global Root). It has never seen the specific Intermediate CA that signed this leaf cert.

Why does desktop Chrome work?

Desktop browsers implement a feature defined in RFC 5280 §4.2.2.1 called Authority Information Access (AIA):

Chrome parses the leaf certificate's X.509 extensions and finds the caIssuers URI (e.g., http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt).
Chrome quietly makes an HTTP GET request in the background to download the missing intermediate certificate.
It stitches the leaf, intermediate, and root together into a full cryptographic chain and verifies it against the OS root store.

Why does Flutter fail?

Mobile runtimes — specifically dart:io (SecurityContext) and Android's native TrustManager — do not implement AIA chasing by default. They expect the server to provide the full chain (fullchain.pem) in the TLS ServerHello handshake. When the server fails to do so, mobile clients throw unable to get local issuer certificate.

And often, you don't control the server! It might be a third-party payment gateway, an enterprise partner API, an exhibitor portal, or a legacy government service where submitting an IT ticket to update Nginx/Apache takes three months.

Enter AIA Chaser: Automated, Scoped Certificate Chasing for Flutter

Rather than choosing between a broken app and a gaping security hole, I built and open-sourced AIA Chaser (aia_chaser).

AIA Chaser brings desktop-grade Authority Information Access chasing directly into Flutter and Android, without disabling certificate validation.

Key Principles

Cryptographic Integrity First: It never blind-accepts untrusted certificates. If a certificate is self-signed, expired, forged, or belongs to an unlisted host, it is strictly rejected.
Host-Scoped Policies: You explicitly define which hostnames or wildcards (*.example.com) are allowed to chase certificates.
Microsecond In-Memory Cache: Chased certificates are held in an in-memory leaf store. Once validated, subsequent requests hit cache in 1–3ms with zero network overhead.
Persistent LRU Disk Cache: Validated intermediates are stored in an encrypted/private disk cache so cold app restarts don't re-download certificates over cellular networks.
Zero-Latency Prewarming: Validate your mission-critical endpoints during app startup in the background (PrewarmMode.background) so user-facing calls never wait on an AIA fetch.

The Complete Ecosystem

AIA Chaser is modular and published across 4 companion packages on pub.dev:

Package	Pub.dev Score	Role
`aia_chaser`	150 / 160	Core engine, Pigeon IPC platform channel, Android `TrustManager` validator, cache, and diagnostic view.
`aia_chaser_dio`	160 / 160 🎯	Custom `HttpClientAdapter` for `dio` with transparent retry-once resilience.
`aia_chaser_http`	160 / 160 🎯	Drop-in `http.BaseClient` for `package:http`.
`aia_chaser_webview`	160 / 160 🎯	Safe Android `onReceivedSslError` handler for `webview_flutter`.

Quick Start (Less than 10 Lines)

1. Installation

In your pubspec.yaml:

dependencies:
  flutter:
    sdk: flutter
  aia_chaser: ^0.1.0
  aia_chaser_dio: ^0.1.0
  aia_chaser_webview: ^0.1.0

2. Initialize in `main.dart`

import 'dart:io';
import 'package:flutter/material.dart';
import 'package:aia_chaser/aia_chaser.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await AiaChaser.initialize(
    AiaConfig(
      // Pre-validates hosts at startup in background:
      prewarm: PrewarmMode.background,
      hosts: {
        'api.partner-service.com': const HostPolicy.chase(retryOnce: true),
        '*.exhibitor-portal.in': const HostPolicy.chase(),
      },
    ),
  );

  // Installs safe global dart:io overrides
  HttpOverrides.global = AiaHttpOverrides();

  runApp(const MyApp());
}

3. Safe Android WebView Integration

Instead of calling handler.proceed() blindly in onReceivedSslError, let AIA Chaser verify the chain first:

import 'package:aia_chaser_webview/aia_chaser_webview.dart';
import 'package:webview_flutter/webview_flutter.dart';
import 'package:webview_flutter_android/webview_flutter_android.dart';

final controller = WebViewController()
  ..setNavigationDelegate(
    NavigationDelegate(
      // Standard navigation handling...
    ),
  );

// Wire safe AIA verification into Android WebView
if (controller.platform is AndroidWebViewController) {
  AiaWebViewHandler.install(controller.platform as AndroidWebViewController);
}

If the server sends a partial chain, AiaWebViewHandler will:

Intercept SSL_UNTRUSTED.
Extract the leaf cert and chase the intermediate.
Validate against Android's system trust store (X509TrustManagerExtensions).
Only call proceed() if the chain is cryptographically verified.
Otherwise, safely reject the connection and display your custom error UI.

Real-World Production Case Study

We recently deployed AIA Chaser in a production trade-expo companion app (ACREX India).

The event portal (register.acrex.in) hosted real-time exhibitor directories (254 exhibitors) and interactive 3D floorplan WebViews. The server's SSL certificate was missing the Sectigo RSA intermediate certificate.

Prior to AIA Chaser:

The app was intermittently crashing with HandshakeException: CERTIFICATE_VERIFY_FAILED.
In-app WebViews were failing with white screens and SSL_UNTRUSTED.

After installing aia_chaser: ^0.1.0:

On cold boot, both acrex.in and register.acrex.in were prewarmed in the background.
Subsequent API requests and WebViews reported:

  [AiaChaser] Prewarmed acrex.in -> ValidationOutcome.validated (3ms - In-memory cache hit)
  [AiaChaser] Prewarmed register.acrex.in -> ValidationOutcome.validated (1ms - In-memory cache hit)
  <-- 200 https://register.acrex.in/ACREXService.svc/GetSliderList
  <-- 200 https://register.acrex.in/ACREXService.svc/SearchExhibitorNew (254 items loaded)
  ✅ [WEBVIEW PAGE FINISHED] Loaded URL: https://register.acrex.in/hallLayout/...

Zero handshake exceptions, zero insecure bypasses, and 100% data fidelity.

Built-In Diagnostics Widget

Need to inspect what certificates were chased or verify cache hits? AIA Chaser includes a Flutter Material 3 diagnostic inspector:

Navigator.of(context).push(
  MaterialPageRoute(
    builder: (_) => const AiaDiagnosticsView(),
  ),
);

It gives you:

Visual host list with green/red status indicators.
Cache hit/miss counts and probe latency (in milliseconds).
Subject, Issuer, Serial Number, and SHA-256 fingerprint of all intercepted certs.
"Flush Cache" and "Prewarm All" actions for real-time testing.

Conclusion & Community Wisdom

Missing intermediate certificates are one of the most frustrating pain points in mobile development because desktop browsers hide the problem, leaving mobile developers feeling like it's a bug in Flutter or Android.

Bypassing verification with badCertificateCallback = (...) => true is never the answer.

With AIA Chaser, you get desktop-grade TLS resilience while maintaining strict cryptographic security.

GitHub Repository: https://github.com/YadneshTeli/aia_chaser
Pub.dev Package: https://pub.dev/packages/aia_chaser

Give it a star on GitHub, try it in your projects, and never let an incomplete SSL certificate chain take your mobile app down again!

Building DevFeed — Part 2: The Feed, Hacker News API, and Riverpod AsyncNotifier

Yadnesh Teli — Wed, 14 Oct 2026 13:00:00 +0000

Series 2 of 2 — Part 2 of 4

Building DevFeed — Part 2: The Feed, Hacker News API, and Riverpod AsyncNotifier

Series: Building DevFeed — A Proper Flutter MVVM App from Day One

With the architecture in place from Part 1, it was time to build the actual feature — fetching Hacker News stories and displaying them. This post covers the repository implementation, the data fetching strategy, and why AsyncNotifier is the right Riverpod primitive for a feed with pull-to-refresh.

The Hacker News API

The API is public, free, and needs no authentication. The top stories endpoint returns an array of item IDs, and then you fetch each item individually for its details.

// Step 1: fetch top story IDs
GET https://hacker-news.firebaseio.com/v0/topstories.json
// Returns: [34562341, 34560198, ...]

// Step 2: fetch each item
GET https://hacker-news.firebaseio.com/v0/item/{id}.json

If you fetch all IDs and then fetch each item sequentially, loading the feed takes a long time. The fix is Future.wait for parallel fetching.

The repository with parallel fetching

class HackerNewsRepository {
  final Dio _dio;

  HackerNewsRepository({required Dio dio}) : _dio = dio;

  Future<List<ArticleModel>> fetchTopStories({int limit = 30}) async {
    final idsResponse = await _dio.get(
      'https://hacker-news.firebaseio.com/v0/topstories.json'
    );
    final ids = (idsResponse.data as List).take(limit).cast<int>();

    final articles = await Future.wait(ids.map((id) => _fetchItem(id)));
    return articles.whereType<ArticleModel>().toList();
  }

  Future<ArticleModel?> _fetchItem(int id) async {
    final response = await _dio.get(
      'https://hacker-news.firebaseio.com/v0/item/$id.json'
    );
    if (response.data == null) return null;
    return ArticleModel.fromJson(response.data);
  }
}

I used Dio rather than the built-in http package for its interceptors, request cancellation, and cleaner error handling. The repository takes Dio in its constructor for easy testing.

AsyncNotifier vs FutureProvider

Riverpod offers two main options for async state. FutureProvider is simpler — define a function returning a Future, Riverpod handles the AsyncValue wrapping. AsyncNotifier gives you more control — you expose methods like refresh alongside the state.

For a feed with pull-to-refresh, AsyncNotifier is the right choice. The refresh method sets state to AsyncLoading then re-fetches, which drives the loading indicator in the UI.

The feed screen

The FeedScreen watches feedViewModelProvider and uses .when to render the correct UI:

final feedAsync = ref.watch(feedViewModelProvider);

return feedAsync.when(
  loading: () => const CircularProgressIndicator(),
  error: (e, _) => ErrorWidget(e.toString()),
  data: (articles) => ArticleList(articles: articles),
);

The screen has no knowledge of Dio, the API URL, or how articles are fetched. It just renders what the ViewModel provides.

What I learned

Parallelize I/O: Future.wait for parallel item fetching makes a real difference in feed load speed.
Choose the right provider: AsyncNotifier is the right choice when you need to expose methods alongside async state.
Inject HTTP clients: Injecting Dio through Riverpod centralises configuration and makes testing straightforward.

Next: Part 3 — In-app WebView, Sharing Actions, and the Android INTERNET Permission

Building a Flutter Shopping App — Part 2: Firebase Auth, Google Sign-In, and the Account Merging Problem

Yadnesh Teli — Mon, 12 Oct 2026 13:01:00 +0000

Series 1 of 2 — Part 2 of 5

Building a Flutter Shopping App — Part 2: Firebase Auth, Google Sign-In, and the Account Merging Problem

Series: Building a Flutter Shopping App — From Zero to Architecture

Adding authentication to a Flutter app sounds straightforward. Firebase gives you a clean SDK, the docs are good, and there are tutorials showing you how to add a login screen in twenty minutes.

What those tutorials do not show you is what happens when a user signs up with email and password, and then later tries to sign in with Google using the same email address. Firebase throws an error. The accounts are separate. And your user is confused.

That is the problem I spent most of this phase solving.

Setting up Firebase Auth

First the straightforward part. I added firebase_auth and firebase_core to pubspec.yaml, configured the Firebase project, and set up the platform config files. I created a UserModel to hold uid, email, and display name, and an AuthProvider using Riverpod that wrapped FirebaseAuth and exposed methods for login, signup, and logout.

Refactoring the auth screens

I also refactored the login and signup screens at this stage to improve responsiveness. The original versions had hardcoded padding values that broke on smaller screens. I switched to MediaQuery-based padding and updated all error messages to be human-readable rather than showing raw Firebase error codes.

Adding Google Sign-In

Google Sign-In itself is not complicated. You use the google_sign_in package to get a GoogleSignInAccount, exchange it for a credential, and pass that to Firebase.

final googleUser = await GoogleSignIn().signIn();
final googleAuth = await googleUser?.authentication;
final credential = GoogleAuthProvider.credential(
  accessToken: googleAuth?.accessToken,
  idToken: googleAuth?.idToken,
);
await FirebaseAuth.instance.signInWithCredential(credential);

That is the happy path. The unhappy path is where it got interesting.

The account merging problem

Here is the scenario. A user signs up with email and password. Later they tap Sign in with Google, pick the same email address. Firebase throws a FirebaseAuthException with code account-exists-with-different-credential.

Firebase treats email/password and Google as two separate sign-in providers. The same email address can have multiple providers linked to it, but they are not automatically merged when you sign in from a new provider.

My solution was to catch this exception, sign the user in with their existing email/password credential, and then link the Google credential to their account. After this they can sign in with either method.

try {
  await FirebaseAuth.instance.signInWithCredential(googleCredential);
} on FirebaseAuthException catch (e) {
  if (e.code == 'account-exists-with-different-credential') {
    final existingUser = await FirebaseAuth.instance
      .signInWithEmailAndPassword(email: email, password: existingPassword);
    await existingUser.user?.linkWithCredential(googleCredential);
  }
}

Making the cart and favourites user-aware

With auth in place, I updated the cart and favourites providers to be scoped to the current user. Cart data was now stored under a user-specific key in SharedPreferences. When the user logged in, their previous cart was restored. When they logged out, it was cleared.

I also handled migration from the old global storage format to the new user-scoped format so existing users would not lose their data.

What I learned

Account merging is explicit: Firebase Auth multi-provider account merging is not automatic — you have to handle it explicitly.
Scope state to user ID: Always scope state to the current user when building apps with authentication.
User-facing errors: Error messages in auth flows matter more than in most other parts of an app.

Next: Part 3 — Integrating Cloud Firestore and Push Notifications

SolSpot: An Open Model Scores the Sky, So You Can Close the Screen 🌿

Yadnesh Teli — Sun, 11 Oct 2026 06:20:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Remote workers, software engineers, and creators spend an average of 9+ hours a day bathed in unnatural 6500K LED screen glare. This locks our vision at a fixed 24-inch focal length, suppresses natural melatonin timing, and triggers chronic burnout.

Most "wellness apps" make this worse by demanding more screen time: logging calories, reviewing biometric graphs, or scrolling meditation libraries.

SolSpot is built around one core philosophy: Make the screen the shortest part of the experience.

SolSpot is an anti-burnout natural light optimizer. Instead of keeping you glued to a monitor, it evaluates hyper-local atmospheric conditions (solar irradiance, blue-light ratio, UV risk, cloud cover, and wind chill) to discover your personal Peak 20-Minute "Touch Grass" Window of the day.

When your window arrives:

The 20-Minute Golden Window: Identifies the exact minutes when natural outdoor blue-light photons synchronize your circadian cortisol rhythm without erythema (sunburn) risk.
Gemma 2 Sensory Micro-Quest: Before you step outside, Google's Gemma 2 synthesizes a 60-second mindfulness quest tailored to current weather (e.g., "Step outside, face 45° away from direct sun, close your eyes for 30 seconds and let the photons warm your eyelids. Put your phone in your pocket.").
Grass Mode: A tranquil, full-screen lock screen with a 20-minute countdown, rhythmic 4s/4s breathing circle, and procedural nature wind audio that instructs you: "Phone Face Down. Eyes to the Horizon."

Demo

Live Deployed App: https://solspot.onrender.com
API Health: https://solspot.onrender.com/api/health
Interactive Experience:
- Dynamic Solar Trajectory Arc rendering the sun's elevation from dawn (6 AM) through solar noon to dusk (8 PM).
- One-click "Activate Grass Mode" meditative full-screen immersion with procedural audio synthesis via Web Audio API.
- Local session streak tracking and collectible "Natural Light Pioneer" milestone badge.

Code

The complete source code is open source and hosted on GitHub:

YadneshTeli / Solspot

🌿 SolSpot — The Anti-Burnout Natural Light Optimizer

Hacktoberfest Open-Source AI Challenge: Week 1 — "Touch Grass" Submission
Tag: #hf26challenge
Target Prize Categories: Best Use of TabPFN (Prior Labs) ($200) & Best Use of Gemma (Google) ($200)

💡 What We Built & The Problem

Remote workers, engineers, and creators spend an average of 9+ hours a day bathed in unnatural 6500K LED screen glare. This suppresses natural melatonin timing, elevates chronic stress, and leads to screen burnout.

Most health apps demand more screen time: tracking food, counting reps, or reading lengthy meditation guides.

SolSpot is designed with one core philosophy: Make the screen the shortest part of the experience.

SolSpot analyzes hyper-local atmospheric and solar data (GHI irradiance, direct blue-spectrum light, UV index, cloud filtering, and thermal indices) to pinpoint your personal Peak 20-minute "Touch Grass" Window of the day.

When your window arrives, SolSpot launches Grass Mode…

View on GitHub

(Direct repository link: https://github.com/YadneshTeli/Solspot)

System Architecture:

flowchart TD
    User([👤 User]) -->|Opens App| UI[🖥️ SolSpot Web UI\nVanilla CSS Glassmorphism]
    UI -->|Local Coordinates| API[⚡ FastAPI Backend on Render]

    API -->|Free Solar Metrics| OM[☀️ Open-Meteo API\nGHI, UV, Temp, Clouds]
    OM -->|Hourly Atmospheric Vectors| TabPFN[🧠 Prior Labs TabPFN\nZero-Shot Tabular Transformer]

    TabPFN -->|Circadian Curve| Best[🌟 Peak 20-Min Window]
    Best -->|Weather Context| Gemma[💎 Google Gemma 2 2B-IT\nSensory Micro-Quest Engine]

    Gemma --> UI
    UI -->|Engage Grass Mode| Lock[🌿 20-Min Fullscreen Horizon Timer]
    Lock -->|Local Session Log| Storage[(🔒 100% Private LocalStorage)]

How I Built It

SolSpot is powered by two complementary open-source AI pillars:

1. TabPFN (Prior Labs) — Zero-Shot Tabular Foundation Model

Atmospheric chronobiology is tabular data: solar zenith angle, Global Horizontal Irradiance ($W/m^2$), UVB index, cloud cover %, ambient temperature, and wind speed.
Instead of trying to force an LLM to predict tabular curves or manually tuning hyperparameters across classic tree models, we used Prior Labs' TabPFN (tabpfn>=9.1.0). TabPFN is a transformer pretrained on synthetic tabular datasets that performs instantaneous zero-shot in-context learning. We feed hourly atmospheric vectors directly into TabPFNRegressor to evaluate circadian daylight scores across the day in milliseconds:

from tabpfn import TabPFNRegressor

# Zero-shot tabular evaluation across hourly atmospheric vectors
model = TabPFNRegressor(device="cpu", n_estimators=4)
model.fit(X_circadian_calibration, y_wellness_scores)

# Predict circadian daylight score curve for the entire day
hourly_scores = model.predict(todays_hourly_matrix)

2. Google Gemma 2 (2B-IT) — 60-Second Sensory Micro-Quest Engine

Once the window is computed, Google's Gemma 2 generates concise, grounding outdoor prompts calibrated to the temperature, cloud cover, and solar angle. It specifically prompts for non-visual senses (smell, skin thermal perception, distant horizon eye relaxation) and explicitly directs the user to close or pocket the screen.

3. Open-Meteo & Zero-Tracking Architecture

Solar radiation and UV data are fetched from Open-Meteo's open solar API without API keys or tracking IDs. All streak progress is persisted in local storage.

Why Does Open Innovation Matter?

In a world where big-tech wellness apps monetize your GPS tracking and charge subscription fees for generic advice, an open-source approach fundamentally changes the paradigm:

Local Privacy by Default: You shouldn't have to upload your real-time geolocation or daily routine to an ad-targeting server just to know when to take a walk. Open models and open APIs run privately on your own device.
Zero Cloud Tolls & Offline Resilience: In the backcountry, on a hiking trail, or in a park with patchy cellular reception, closed cloud APIs fail or introduce latency. Open weights like Gemma 2 and local tabular models like TabPFN run in dead zones with zero per-token API charges.
Specialized Tabular Intelligence: LLMs are often misapplied to tabular problems. Prior Labs' open foundation model proves that specialized open transformers deliver vastly superior accuracy for scientific atmospheric data without black-box cloud lock-in.

My Agent Session

This project was planned, scaffolded, and built with AI pair programming using DevRelay. You can explore the full session transcript here:

Building SolSpot: Anti-Burnout Natural Light Optimizer with TabPFN and Gemma 2

You

use devrelay mcp and fetch week 1 challenge and suggest what to build

Agent

Analyzed Week 1 'Touch Grass' challenge requirements. Scaffolds SolSpot: an anti-burnout daylight optimizer using Prior Labs TabPFN for zero-shot tabular circadian curve regression and Google Gemma 2 for outdoor sensory micro-quests.

(Direct session link: https://dev.to/agent_sessions/building-solspot-anti-burnout-natural-light-optimizer-with-tabpfn-and-gemma-2-zc42sg)

Building DevFeed — Part 1: MVVM Architecture Before Writing a Single Screen

Yadnesh Teli — Thu, 08 Oct 2026 13:00:00 +0000

Series 2 of 2 — Part 1 of 4

Building DevFeed — Part 1: MVVM Architecture Before Writing a Single Screen

Series: Building DevFeed — A Proper Flutter MVVM App from Day One

When I started DevFeed, I had just finished the painful MVVM refactor of the shopping app. I knew what proper architecture looked like. I knew the difference between a repository and a ViewModel. I had felt the cost of not having that separation.

So this time I set up the entire architecture before I wrote a single screen.

DevFeed is a Hacker News reader app built as a Flutter MVVM practice project during my internship. This series documents how I built it — from a properly structured first commit all the way to shipping v1.0.1 with a GitHub Actions release workflow.

Planning the architecture first

Before opening the first Dart file, I mapped out the layers:

Model: ArticleModel to represent a Hacker News story — id, title, url, score, author, and comment count.
Repository: HackerNewsRepository responsible for fetching stories from the API. Returns a list of ArticleModel.
ViewModel: FeedViewModel using Riverpod AsyncNotifier. Calls the repository, exposes AsyncValue state to the UI.
View: FeedScreen that watches the ViewModel. Renders loading, error, and data states. No API knowledge.

This is the same structure I eventually reached in the shopping app. The difference in development experience because of starting with it is the main story of this series.

The first commit: full scaffold

The first commit was a full scaffold — all 35 files. Models, repositories, ViewModels, screens, widgets, routing, theming, and a basic test file. Nothing was fully implemented but the skeleton of every layer was in place.

This approach felt strange at first. You write a lot of boilerplate before you can see anything on screen. But it paid off immediately when I started filling in implementations — because I always knew exactly which file to open and what it should contain.

Riverpod AsyncNotifier setup

I used AsyncNotifier for the feed ViewModel. AsyncNotifier is the right choice when your state is the result of an async operation — it handles loading, error, and data states out of the box.

class FeedViewModel extends AsyncNotifier<List<ArticleModel>> {
  @override
  Future<List<ArticleModel>> build() async {
    return ref.read(hackerNewsRepositoryProvider).fetchTopStories();
  }

  Future<void> refresh() async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(
      () => ref.read(hackerNewsRepositoryProvider).fetchTopStories(),
    );
  }
}

go_router for navigation

I used go_router from day one. In the shopping app I had used Navigator.push directly, which scattered navigation logic across screens. go_router centralises routing in a single config file and supports declarative navigation, deep links, and route guards. Adding a new route later was a two-line change instead of a hunt through multiple screens.

What starting right feels like

The most noticeable difference compared to the shopping app was the absence of confusion. When I needed to add a feature, I knew where it should go. When I needed to fix a bug, I knew which layer was responsible.

The shopping app taught me what MVVM is. DevFeed taught me what it feels like to work in a well-structured codebase. You need both lessons.

Next: Part 2 — Building the Feed: Hacker News API, AsyncNotifier, and Parallel Fetching

Building a Flutter Shopping App from Scratch — Part 1: Scaffolding Models, Providers, and Screens

Yadnesh Teli — Tue, 06 Oct 2026 13:00:00 +0000

Series 1 of 2 — Part 1 of 5

Building a Flutter Shopping App from Scratch — Part 1: Scaffolding Models, Providers, and Screens

Series: Building a Flutter Shopping App — From Zero to Architecture

Every Flutter developer I know has at some point just started writing code without thinking too much about architecture. I was no different. When my internship mentor gave me a shopping app to build as a learning project, I opened VS Code and started typing.

This post covers what I built on day one — the models, providers, and screens — and why I made the choices I made, even if some of them turned out to be wrong.

The project brief

A standard e-commerce shopping app. Products, categories, a cart, a favourites list, and user authentication. Nothing groundbreaking, but enough to force you to think about state, data flow, and UI structure.

At this point in my Flutter journey I had a basic understanding of widgets and StatefulWidgets. I had read about Provider but not really used it properly. I did not know what MVVM was.

Starting with models

The first thing I did was define my data structures. A product has a name, price, image URL, and category. A category is just an id and a label.

class ProductModel {
  final String id;
  final String name;
  final double price;
  final String imageUrl;
  final String categoryId;

  ProductModel({
    required this.id,
    required this.name,
    required this.price,
    required this.imageUrl,
    required this.categoryId,
  });
}

Clean enough to start with. At this stage I was not thinking about fromJson or toJson — that would come back to bite me later when I integrated Firestore.

Building the providers

I used Riverpod for state management. I created providers for products, categories, cart, favourites, and search. Each was a StateNotifier that held a list and exposed methods to add, remove, and filter items.

The cart provider looked reasonable at first. But there was a problem I did not see yet — it had no concept of the current user. The cart data was global. If two users logged in on the same device, they would share the same cart. This is the kind of issue you only discover when you try to add authentication.

Setting up screens

I built three screens: HomeScreen, CartScreen, and FavouritesScreen. The HomeScreen had a product grid, category filters, and a search bar with debounce. The CartScreen showed cart items with quantities. The FavouritesScreen was a responsive grid of saved products.

I also added Device Preview at this stage, which turned out to be a good decision. It caught several responsive layout bugs early without needing to switch simulators.

What I got right

Using Riverpod from the start: Even my naive providers were easier to manage than raw setState.
Separating models early: Gave me a consistent data layer before I understood the full architecture.
Adding Device Preview early: Surfaced layout bugs while they were still cheap to fix.

What I got wrong

Global user state: Cart and favourites providers had no concept of the current user — state was global.
Leaking business logic: Business logic was leaking into the UI layer — screens called provider methods with too much knowledge of storage internals.
Tangled data sources: No repositories. API calls, local storage reads, and state updates were all tangled inside the same providers.

What is coming next

In Part 2 I add authentication — Firebase login, signup, Google Sign-In, and the surprisingly tricky problem of merging accounts when a user signs up with email and then tries to log in with Google using the same address.

Next: Part 2 — Adding Firebase Auth, Google Sign-In, and Account Merging

My Flutter Internship Learning Journey: Two Projects, One Progression

Yadnesh Teli — Mon, 05 Oct 2026 13:03:33 +0000

Intro Post

My Flutter Internship Learning Journey: Two Projects, One Progression

A Dev.to blog series about learning Flutter the hard way — and then the right way.

I am an MCA student based in Mumbai, currently doing a Flutter developer internship. Over the past few weeks I built two Flutter apps as part of my learning journey. On the surface they look similar — both are Flutter apps, both deal with real features, both use Riverpod. But the way I approached them could not have been more different.

The first project, a shopping app, started with zero knowledge of proper Flutter architecture. I just started building — models, providers, screens — figuring things out as I went. Halfway through, I realised the codebase was becoming hard to manage. So I stopped and refactored the entire thing to MVVM with repositories and viewmodels. It was painful but I learned more from that refactor than from anything else.

The second project, DevFeed — a Hacker News reader — is where I applied everything I had just learned. I set up MVVM from the first commit. I never had to do a big painful refactor because the architecture was right from day one. It shipped to v1.0.1 with a changelog and a GitHub Actions release workflow.

These two projects together tell a story I think a lot of Flutter beginners will relate to. So I am writing about both, as two parallel series.

What the two series cover

Series 1 — Building a Flutter Shopping App: From Zero to Architecture

This follows the shopping app from scratch. You will see me build it the naive way, hit the walls, and then migrate to proper MVVM. If you have ever written Flutter code that became a mess and wondered how to fix it, this series is for you.

Series 2 — Building DevFeed: A Proper Flutter MVVM App from Day One

This follows DevFeed from the first commit. No big refactor needed — because the architecture was planned upfront. This series shows what it looks like when you apply the lessons from Series 1 before you start writing features.

Beyond the Basics: Deep Dives & State Management Alternatives

Following both projects, I also explore alternative paradigms that broadened my engineering toolkit: GetX, Flutter BLoC, Supabase as a Firebase alternative, implicit & explicit animations, and GraphQL.

Who this is for

Flutter beginners who are learning by building real projects
Students doing internships who want to write production-quality code
Anyone who has built a messy Flutter app and wants to understand MVVM
Anyone curious about what a real learning-in-public journey looks like

The tech stack

Flutter & Dart
Riverpod for state management
Firebase Auth, Firestore, FCM
MVVM architecture with repositories and viewmodels
GitHub Actions for CI/CD automation

How to follow along

I will post both series in parallel, alternating weekly. Start with Series 1 Part 1 and Series 2 Part 1 simultaneously — they set up the contrast that makes the whole journey make sense.

Let us get into it.

DartBox Buddy: Running Flutter On-Device with a Local Gemma 4 AI Tutor for My Friend

Yadnesh Teli — Mon, 05 Oct 2026 04:32:27 +0000

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

What I Built

A close friend of mine has wanted to learn Flutter for months. They had great app ideas—little personal tools, habit logs, and clean interfaces—but every time they sat down to start, reality hit them like a wall:

The Setup Monster: First came downloading gigabytes of Android Studio, fighting Gradle daemon memory errors, configuring Java home variables, and waiting 10 minutes for an initial build. By the time the emulator booted, their creative momentum was completely gone.
The Layout Maze: When they finally got code running, Flutter layouts proved deceptively tricky. Misunderstanding Row vs Column constraints, getting mysterious black-and-yellow striped overflow errors, and not knowing why an element vanished caused endless frustration.
The Closed AI Trap: They tried pasting questions into cloud AI assistants, but web playgrounds only produced browser mockups, closed APIs demanded $20/month subscriptions, and personal daily habit ideas were being shipped to third-party corporate servers.

I realized what my friend needed wasn't another thick tutorial or a heavy laptop IDE. They needed a playful sandbox right in their pocket: an app where they could experiment with layouts on the subway, see changes instantly on a real touch screen, and have a patient, private mentor guiding them through every mistake.

DartBox Buddy is an on-device Flutter development studio and AI tutor that runs entirely on a mobile phone.

With DartBox Buddy, you can open any .dart file on your phone, tap Run, and watch it compile and mount as an interactive, live native Flutter widget in under 100 milliseconds—with zero project setup, no laptop, no command-line tools, and no internet connection required.

Sitting beside you in the editor is an on-device AI mentor powered by Google Gemma 4 E2B running via LiteRT-LM. When a layout breaks or a compiler error occurs, Gemma analyzes the AST on your phone, explains the visual hierarchy in plain English, and auto-repairs code before mounting it on screen.

To solve my friend's layout struggles from day one, DartBox bundles 6 Progressive Layout Lessons:

Centering & Text: Center, Container, padding, and decoration basics.
Padding & Margins: Visualizing inner space vs outer margin boundaries.
Row & Column Alignment: Mastering mainAxisAlignment and crossAxisAlignment.
Stack & Positioned: Layering badges, floating tags, and overlapping cards.
Scrollable Card Feed: Constructing lists with ListView, Card, and ListTile.
Interactive State: Connecting taps to layout updates using StatefulWidget and setState.

Bundled lessons are read-only templates: editing any lesson automatically forks a custom copy into "My Scripts" so original reference lessons are never overwritten.

Demo

User Workflow

┌────────────────────────────────────────────────────────┐
│  DartBox Buddy Studio (On-Device Mobile Engine)        │
│                                                        │
│  [Code Editor] ──(Compiles in <100ms)──> [Live Widget] │
│        ▲                                       │       │
│        │                                       ▼       │
│   Auto-Repair <── [On-Device Gemma 4] <── [Errors/AST] │
└────────────────────────────────────────────────────────┘

My Friend's Reaction

When I handed the phone to my friend and opened Lesson 3 (Row & Column Alignment), their first question was:

"Wait, where's the laptop? How is this running without Android Studio open?"

Within five minutes, they had changed the button padding, flipped the alignment from spaceEvenly to spaceBetween, and used the Gemma AI Tutor to ask why their text wasn't centered. For the first time, learning Flutter felt as fast and playful as playing a mobile game.

Code

📂 GitHub Repository: https://github.com/yadneshteli/dartbox
📜 License: MIT
🤖 AI Model Used: Google Gemma 4 E2B LiteRT-LM (Open-weight, Apache-2.0)
📦 Built With: Flutter, flutter_eval, flutter_gemma, LiteRT

# Clone and run locally
git clone https://github.com/yadneshteli/dartbox.git
cd dartbox
flutter pub get
flutter run

How I Built It

DartBox Buddy connects two cutting-edge open technologies:

1. The On-Device Flutter Runtime (`flutter_eval` + `dart_eval`)

The host app runs standard Flutter compiled for Android. When the user edits code, DartBox passes the source string to the on-device Compiler with flutterEvalPlugin, producing platform-agnostic EVC bytecode in memory. The RuntimeWidget mounts the bytecode as a live widget tree with interactive touch gestures and state management (setState).

To ensure my friend wasn't restricted to basic containers, we bridged essential Flutter layout and styling primitives into the dynamic runtime:

Layout: Flexible, Wrap, SingleChildScrollView for scrollable, wrapping feeds.
Styling: BoxDecoration, BorderRadius, BoxShadow, and LinearGradient for sleek card designs.
Controls & Inputs: NavigationBar, Checkbox, Switch, and OutlineInputBorder for interactive components.

2. The On-Device AI Engine (`flutter_gemma` + LiteRT-LM)

Inference runs locally using the flutter_gemma package backed by LiteRT-LM. We deploy gemma-4-E2B-it.litertlm (an Apache-2.0 open-weight model from the LiteRT community).

flowchart TD
    A["Friend edits layout in Editor"] --> B["CompatChecker (Allowlist & Linter)"]
    B --> C["dart_eval Compiler"]
    C -->|Success in <100ms| D["Live Interactive Widget"]
    C -->|Compile Error| E["On-Device Error Console"]

    E --> F["Gemma 4 E2B Tutor (On-Device via LiteRT)"]
    F -->|System Prompts + Widget Hierarchy| G["Explain Error / Layout Hint"]
    G --> H["Self-Healing Repair Loop"]
    H -->|Repaired Code| C

3. Mobile Ergonomics & Developer Experience

Writing code on a touch keyboard requires deliberate tooling:

One-Tap Symbol Bar: Instant access to {, }, (, ), ;, :, =>, quotes, and brackets without toggling keyboard layers.
Undo & Redo: Directly integrated UndoHistoryController on the mobile toolbar.
Debounced Auto-Save & Safe Navigation: Code automatically saves after 1.5s of inactivity and via PopScope on back navigation.
Error-to-Line Navigation: Tapping any compiler error in the on-device console automatically jumps the cursor to the exact error line.
Script Management: Local duplicate, rename, delete with confirmation, and clipboard code paste/import.

4. Benchmarks & Verification

Tested on a OnePlus 13R (Qualcomm Snapdragon 8 Gen 3, 16 GB RAM):

Bytecode Compilation Time: 85 ms (average for 150-line layout scripts)
Warm Recompile Time: < 15 ms (using in-memory AST cache)
Automated Test Suite: 16 passed tests (100% pass rate across compiler units, all 6 bundled layout lessons, bridge widgets, and the multi-turn Gemma auto-repair loop)
Analyzer Health: 0 errors, 0 warnings with flutter analyze
Packaging: Standalone debug APK verified and built cleanly in 68s.

Why Does Open Innovation Matter?

This project was built to prove why open-source AI is transformative for learning and mobile development:

100% Offline Independence: Learning shouldn't stop when you lose Wi-Fi. By packaging Google's open-weight Gemma 4 E2B model (.litertlm) directly onto the device, the tutor runs in airplane mode, on trains, or in remote spots with zero network latency.
Complete Data Sovereignty & Privacy: The friend's personal thoughts, draft widgets, and habit data never leave the phone. There is no tracking, no logging, and no telemetry sent to a remote API.
Zero Ongoing Costs: Cloud LLMs impose steep per-token pricing or monthly subscriptions. Open-weight models democratize access—once installed, millions of tokens of guidance cost exactly $0.00.
Deterministic Closed-Loop Compilation: Unlike generic cloud chatbots that hallucinate outdated syntax, DartBox pairs Gemma with an on-device compiler (dart_eval / flutter_eval). When Gemma suggests or generates a layout, DartBox compiles it in memory. If a syntax mismatch is detected, it feeds the error back to Gemma for an instant self-healing repair turn before the user even sees it.

My Agent Session

We saved the AI agent session transcript from our architectural build and test verification using DevRelay:

Building DartBox Buddy with On-Device Gemma 4

You

Build DartBox Buddy: an on-device Flutter runner and local Google Gemma 4 AI tutor for my friend learning Flutter layouts without laptop setup.

Agent

Designing 100% offline architecture: local bytecode compilation via flutter_eval, on-device Gemma 4 E2B inference via LiteRT-LM, debounced auto-save, and self-healing auto-repair loop.

▸ run_command flutter test

Input

$ flutter test

Output

All 16 tests passed cleanly! Bytecode compilation, bundled lessons, and Gemma repair loop verified.

Direct Transcript Link: DevRelay Agent Session #543

The agent session covers designing the 100% offline runtime architecture, extending flutter_eval with layout bridges, implementing the 3-turn Gemma auto-repair loop, and passing all 16 automated tests.

Prize Categories

Featured Category: Best Use of Gemma ($200)

DartBox Buddy enters the Best Use of Gemma category. The project features Google's open-weight Gemma 4 E2B model (gemma-4-E2B-it.litertlm, Apache-2.0) running natively on-device via LiteRT-LM.

Gemma serves as an on-device tutor and autonomous code repair engine:

Visual Hierarchy Explanation: Deconstructs Flutter widget trees and explains layout rules in plain English without cloud latency.
Self-Healing Auto-Repair: Automatically catches compiler errors, feeds AST error diagnostics into an on-device 3-turn repair loop, and outputs corrected code that compiles and mounts live.
Local Privacy: Ensures all user code, draft widgets, and learning conversations remain 100% local on the device.

Thank you to DEV, Google, and the Hacktoberfest organizers for this challenge!

DEV Community: Yadnesh Teli

Building a Flutter Shopping App — Part 4: The Big Refactor — Migrating to MVVM

Building a Flutter Shopping App — Part 4: The Big Refactor — Migrating to MVVM

What MVVM means in Flutter with Riverpod

Before and after

Why this is better

The honest cost of refactoring mid-project

What I learned

RoastGuard v2.2.0: Automating Self-Discipline with Google Gemma 4 When You're Too Lazy to Stop Doomscrolling 🦥

What I Built

Demo

What it looks like in action:

Code

YadneshTeli / roast_guard

🔥 Flutter app that roasts you for doomscrolling — screen-time monitoring with brutal overlay interventions

🔥 Doom Roast

✨ Features

How I Built It

1. Google Gemma 4 Open-Weight Core

2. Eliminating the <think> Reasoning Token Leaks

3. Smart Pre-Fetch & Cache Architecture

System Architecture:

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

Prize Categories

Building DevFeed — Part 3: In-app WebView, Sharing Actions, and the INTERNET Permission

Building DevFeed — Part 3: In-app WebView, Sharing Actions, and the INTERNET Permission

The WebView screen

Refactoring state management for the WebView

Sharing actions

The INTERNET permission — a debugging story

The lesson

What I learned

Building a Flutter Shopping App — Part 3: Cloud Firestore and Push Notifications

Building a Flutter Shopping App — Part 3: Cloud Firestore and Push Notifications

Integrating Cloud Firestore

Setting up push notifications

Saving and refreshing the FCM token

What I learned

Stop Bypassing SSL in Flutter: Solving the Missing Intermediate Certificate Nightmare with AIA Chasing

Stop Bypassing SSL in Flutter: Solving the Missing Intermediate Certificate Nightmare with AIA Chasing

The Dangerous "Quick Fix" We Must Stop Doing

Why this is a catastrophe

The Root Cause: Why Chrome Works and Mobile Fails

Why does desktop Chrome work?

Why does Flutter fail?

Enter AIA Chaser: Automated, Scoped Certificate Chasing for Flutter

Key Principles

The Complete Ecosystem

Quick Start (Less than 10 Lines)

1. Installation

2. Initialize in main.dart

3. Safe Android WebView Integration

Real-World Production Case Study

Built-In Diagnostics Widget

Conclusion & Community Wisdom

Building DevFeed — Part 2: The Feed, Hacker News API, and Riverpod AsyncNotifier

Building DevFeed — Part 2: The Feed, Hacker News API, and Riverpod AsyncNotifier

The Hacker News API

The repository with parallel fetching

AsyncNotifier vs FutureProvider

The feed screen

What I learned

Building a Flutter Shopping App — Part 2: Firebase Auth, Google Sign-In, and the Account Merging Problem

Building a Flutter Shopping App — Part 2: Firebase Auth, Google Sign-In, and the Account Merging Problem

Setting up Firebase Auth

Refactoring the auth screens

Adding Google Sign-In

The account merging problem

Making the cart and favourites user-aware

What I learned

SolSpot: An Open Model Scores the Sky, So You Can Close the Screen 🌿

What I Built

Demo

Code

YadneshTeli / Solspot

🌿 SolSpot — The Anti-Burnout Natural Light Optimizer

💡 What We Built & The Problem

System Architecture:

2. Eliminating the `<think>` Reasoning Token Leaks

2. Initialize in `main.dart`

1. The On-Device Flutter Runtime (`flutter_eval` + `dart_eval`)

2. The On-Device AI Engine (`flutter_gemma` + LiteRT-LM)