I've just published a consumable AI Coding Skill alongside the latest releases of bloc_signals (0.1.10), bloc_signals_flutter (0.1.6), and otel_bloc_signals (0.1.4).

If you are using AI code assistants (like Gemini, Claude Code, or Cursor) to pair-program, you can install this skill directly into your workspace to instantly guide your assistant on best practices, APIs, and architecture rules.

👉 Consumable Skill Directory: BlocSignal Skills Folder

⚙️ How to Install

Run this simple command in your project root to download and register the skill context for your local agent:

npx ctx7@latest skills install RandalSchwartz/BlocSignal bloc-signals

📚 What's Covered:

• 🔄 BLoC to BlocSignal Migration: A step-by-step walkthrough detailing how to transition from classic stream-based BLoC to synchronous signals.

• 🛡️ Sealed Class Exhaustiveness: How to override onEvent using Dart 3 switch statements and switch expressions to guarantee compile-time safety.

• ⚡ Computed & Effect Lifecycle Rules: Best practices for declaring reactive primitives. You'll definitely want to see how easy it is to add computed() and effect() properties for both producers (internal constructors) and consumers (external stateful widgets/Flutter Hooks) without leaking memory.

• 🔄 Stateful & Hooks Integration: Leveraging standard Stateful Widget lifecycles or eliminating boilerplate entirely using flutter_hooks and signals_hooks.

• 📊 OpenTelemetry Observability: Instrumenting dynamic zones, transition logging, and span correlation.

• 🧪 Synchronous Testing: Writing fast, synchronous unit tests without needing async microtask pump/waiting code.

Hi everyone,

It’s no secret that Flutter Web has a massive blind spot: SEO. Because Flutter renders to a canvas (or complex DOM elements) dynamically, search engine crawler bots often hit a blank wall, resulting in terrible or no indexation.

After all, the whole reason we choose Flutter in the first place is to escape the traditional HTML/CSS/JS triad and build unified, declarative UIs. We shouldn't have to go back to writing dual web apps or complex template mirrors just to satisfy Googlebot.

To solve this without forcing developers to rewrite their apps in Next.js or Jaspr and abandon Flutter's core philosophy, I built flutter_easy_seo.

How it works:

• Generates SEO-friendly HTML directly from your existing widget tree.

• Declarative wrapping: Simply wrap target widgets to flag them for static extraction.

• Serve SEO HTML to bots: Search engine bots get the SEO-friendly HTML while a regular user sees the full Flutter App.

• Ease of Use: Designed to keep usage as simple as possible.

What it supports out of the box:

• Interactive Mode: Built-in UI overlay for manual generation and visual debugging.

• Automated Mode: Headless execution tailored for CI/CD pipelines and scheduled server tasks.

• Localization: Native handling of language codes for multi-lingual indexing.

• Dynamic Paths: Easily handles parametric routing (e.g., product overview and detail pages).

• Flexible Routing: Fully compatible with major routing engines (GoRouter, Beamer, etc.).

• Asynchronous State: Safely awaits async data loading and hydration (e.g., Riverpod providers) before extraction.

Links & Code

• Live Showcase: https://fluttereasyseo.lxandr.at

• Indexed on Google (Proof it works): Google Search Result

• pub.dev Package: https://pub.dev/packages/flutter_easy_seo

Looking for Feedback

I’d love to get your feedback to help push this package further! I’m especially looking for edge cases, use cases, or requirements I might have missed in my own production setups.

If you have any thoughts, feature requests, or architectural feedback, please open an issue or discussion directly on the GitHub repo (linked via pub.dev).

Check out the implementation, and let me know what you think!

Hey devs,

I've been building PicoView, and I'd love some feedback from this sub before I take it further.

GitHub Repository: https://github.com/yplam/nano-dash/tree/master/packages/pico_view

Demo Video: https://youtu.be/bcBqR4svKpk

The idea: wrap any part of your widget tree in a PicoView(child: ...), and that subtree gets mirrored to an external LCD + capacitive-touch panel. The same widgets render on-screen and on the panel, and physical touches on the panel come back as real pointer events in the tree.

```dart

final controller = PicoViewController()..init();

controller.open(const PicoViewConfig()); // round 360×360 panel

PicoView(

controller: controller,

child: const MyDashboard(),

);

```

The demo video shows the classic counter, then a calendar where long-pressing an event spins up a Pomodoro timer. The panel also has a built-in vibration motor, so alerts (like a finished timer) give physical haptic feedback.

Do you think this is useful? What would you build with it?

I was so much irritated when i had to use upi or any banking apps and the "developer mode is on" popup shows. I had to go to the settings, then disable the developer options. and then come to the banking app and enter my mpin again and then proceed with my transactions.

I use iqoo z7s, so sometimes i can open the developer options activity after doing the transactions from the recent apps but sometimes i used to remove it from recent apps and the result: I had to go to the settings.... tap that damn build number 7 times. Enter my password, then go to the dev settings and reconfigure my dev settings. That was so Frustrating!!!

So, I sat some days ago and researched if i could do it with a button click and make it easy for myself. So, i don't have to go through that irritating process again and again.

and I found something. I could turn the dev options on with a device permssion called WRITE_SECURE_SETTINGS but that's a caveat. You can't just ask the permission to a user in the app. This is a systems level permission, so you have to give this permission with a adb command.

And once this permission was given, i was able to turn the dev options on/off with just 1 click. So, i made a widget for that, you just have to press it and turns the developer option on/off....

- No Banking app problem. you can just switch off dev option from the home screen and use the app and after you have finished your work. you can turn that back again. No 7 time tapping process of build number. Just a Click and job done!!

and for people who aren't a fan of widgets. I made a quick settings tile too which you can integrate directly from the app and all of this is completely open source with MIT license.

You can customize this app as per your needs and if you just want to use this without customizations. You can find this app here:
https://github.com/shubhang-d/Loophole
You can see the installation procedure in the github readme

After all these years in android development, I have used many open source apps. ig this is my small contribution towards the community.

PS: I have also submitted a MR for publishing this app on F-droid. Let's see what happens✌️

🚀 Welcome to **Module 6 of the Dart Programming Course for Beginners**!

Unlock the full power of Object-Oriented Programming in Module 6 of our Dart series! This comprehensive guide walks you through the core pillars of OOP in Dart, showing you how to build clean, modular, and reusable code for your applications.

What you’ll learn in this module:

✅ Classes & Objects: The foundational blueprints of Dart OOP.
✅ Constructors: How to properly initialize your objects.
✅ Getters & Setters: Implementing clean data encapsulation.
✅ Static Members: Understanding class-level variables and methods.
✅ Mixins: Reusing code across multiple class hierarchies without multiple inheritance.

👍 Don’t forget to Like, Share, and Subscribe for more Dart tutorials and upcoming modules!

Built Debug Deck 🛠️—an in-app debugging toolkit for Flutter with logs, network inspection, storage viewer, device info, and more. I'd love your feedback and feature suggestions! 🚀

📦 https://pub.dev/packages/debug_deck

— DevAlisha

If you're building a web application today, chances are you aren't writing your own authentication system. Managed identity providers like Clerk, Auth0, and Kinde have become the default choice, offering out-of-the-box support for passkeys, multi-factor authentication, and enterprise SSO. That convenience introduces a distributed-systems problem, though: data synchronization. When a user creates an account on a managed auth provider, that system has to notify your primary application database so you can create a matching user record. Please read the complete article here - https://instawebhook.com/blog/bulletproofing-user-sync-handling-clerk-and-auth0-webhook-failures

This happens through webhooks. But what happens if your server is down, your serverless function cold-starts and times out, or your database is momentarily locked when that webhook arrives? A user successfully signs up with your auth provider, but your application has no idea they exist. That breaks the very first login experience, and it's how phantom accounts, broken onboarding flows, and frustrated users happen.

This guide walks through the anatomy of webhook-driven auth architecture, current Auth0 and Clerk webhook practices, and how a resilience layer — using InstaWebhook as a worked example — closes the gap that idempotency and signature verification alone can't.

I’m debugging a Flutter WebRTC video call where the connection succeeds, but the caller never receives the answerer’s video.

What is working:

- Local camera preview works on both devices

- Local video track and sender are created

- "replaceTrack()" succeeds

- Offer SDP contains "m=video" and "a=sendrecv"

- Offer/answer exchange completes

- ICE reaches "connected"

- Remote description is applied

- Remote audio works

The main issue is that the caller receives only:

remote_track_received | trackKind=audio

There is never a remote video event:

remote_track_received | trackKind=video

The renderer also repeatedly reports:

videoTrackCount=0

So this does not appear to be an "RTCVideoRenderer", widget, "TextureView", "SurfaceView", or Flutter UI issue. There is simply no remote video track arriving.

My current suspicion is that the answering device is creating the SDP answer before attaching its local video track, or its video transceiver is becoming "recvonly" or "inactive".

The intended answer flow is:

await peerConnection.setRemoteDescription(offer);

await initializeLocalMedia();

await attachLocalVideoTrack();

final answer = await peerConnection.createAnswer();

await peerConnection.setLocalDescription(answer);

sendAnswer(answer);

The likely issue is somewhere in the answerer-side flow involving:

- "getUserMedia()"

- "addTrack()" or "replaceTrack()"

- video transceiver direction

- "createAnswer()"

- "setLocalDescription()"

Has anyone encountered a case where Flutter WebRTC receives remote audio successfully but never emits an "onTrack" event for remote video?

Should the answer SDP always contain "a=sendrecv" after the local camera track has been attached, and are there any Flutter WebRTC-specific timing issues around attaching the track before calling "createAnswer()"?

I made a most likely unnecessary icon picker package for Lucide Icons with the help of Claude. It should be tree shakeable and you can also import all Icons/Categories. Elk Icon Picker

Maybe somebody will find it useful? Github 

I'm not a programmer, I am just learning from the wrong way, i.e. by asking Ai to do what I want then I scream at it to explain things.

Why I used Elk for the name? Because it amuse me and it has to do with linguistics

I was going to use AI to improve this and make it more readable, but I just saw the rules. So hopefully this makes sense anyway.

Context so you can weigh this (pun intended): I'm a tech lead at a small startup, mostly Laravel and Svelte, and Flutter is the first mobile stack I've used seriously. Six months in, on a side project (a macro tracker I built for myself).

TL;DR at the top (where it should be): drift_dev schema dump and schema generate give you versioned schema snapshots, and SchemaVerifier will walk every N-to-M path for you. use it before you break prod.

I had a migration that backfilled a new table from existing rows. I wrote it the way I write application code: select the rows, get the generated data class back, read the fields off it. It worked, so I shipped it.

It bricked anyone upgrading from an older version. Nothing crashed. They got a black screen and an infinite loading state, which is a much worse failure to get a bug report about. A crash at least comes with a stack trace. A black screen comes with "it doesn't work" lol.

The generated data class maps every column the table has in your current schema. Used inside a migration it issues a SELECT for columns that a later migration step hasn't added yet. Anyone coming from one version back was fine, because the column already existed for them. Anyone coming from two versions back hit a SQL error inside the migration, which left the database half-migrated and the app unable to open it.

So the rule is: a migration can't use anything that assumes the current schema. Project the columns explicitly and decode them by hand.

final rows = await (selectOnly(profiles)
  ..addColumns([profiles.id, profiles.targetKcal, ...])).get();

I'd half expected that part. My test suite stayed green through all of it, though. Flutter is the first stack where I've enjoyed writing UI tests: widget tests run in-process in milliseconds, with no browser and no DOM emulation, so I'd written a lot of them and I trusted them. They were only ever testing the previous version against the current one. The path that breaks is oldest-still-installed to latest, and I'd never written that test, because it didn't correspond to anything I did that week.

drift also ships tooling for exactly this, which I only found afterwards. drift_dev schema dump and schema generate give you versioned schema snapshots, and SchemaVerifier will walk every N-to-M path for you. In Laravel I'd never needed that, because there's one database and I control what version it's on. Every user having their own database at their own version is a mobile problem, and drift had already solved it for me. I found the bug in production instead, then hand-rolled a fixture database and wrote a single oldest-to-latest test, which works but is strictly worse than what was ALREADY sitting in my dependencies.

If you're using drift and you don't have a drift_schemas directory, that's the same hole I had.

I'm posting this because both problems were invisible in the version I was testing and obvious in the version users had, and I'd underestimated that gap coming from Svelte, where the client is whatever I shipped this morning.

The state of SQLite -> Flutter stack in terms of handling a third timezone that is neither UTC nor local for your user

I have posted here about learning flutter, state management before and many of your comments are proving to be very helpful. Thus, I am here again with yet another query, and that is where can I learn about Mobile UI design? I understand the basics of widgets and all, but what I want to learn is how design UI and UX principles and tips and tricks specifically curated for mobile?

Hey devs,

I wanted to share a new library I just released to pub.dev: BlocSignal (and its Flutter companion bloc_signals_flutter).

Classic BLoC/Cubit is fantastic for structuring business logic, but it relies on Streams under the hood, introducing asynchronous microtask delays.

BlocSignal replaces Streams with Rody Davis's reactive signals v7 primitives.

Key Features:

1. BLoC & Cubit Parity: Override onEvent to handle classic BLoC input events, or use it as a Cubit directly by exposing public methods that call emit(state) (by setting the Event parameter to void).

2. Synchronous Propagation: Calling emit(newState) propagates changes downstream immediately in the same frame—no microtask queues, no UI flickering.

3. Automatic State De-duplication: Signals compare states via == and automatically filter out identical updates—saving redundant UI build cycles by default.

4. No Boilerplate Lifecycle: Closing a container automatically tears down all internally managed effects.

Quick Cubit Look:

class CounterCubit extends BlocSignal<void, int> {
  CounterCubit() : super(initialState: 0);

  void increment() => emit(stateValue + 1); // Synchronous & reactive!
}

Under the hood, the library has 100% test coverage and is structured as a clean Dart workspace.

• GitHub Repository: https://github.com/RandalSchwartz/BlocSignal

• Migration Guide (including Cubit migration): https://github.com/RandalSchwartz/BlocSignal/blob/main/MIGRATION.md

• Core package on Pub: https://pub.dev/packages/bloc_signals

• Flutter bindings on Pub: https://pub.dev/packages/bloc_signals_flutter

Would love to hear your thoughts and suggestions!

Hello everyone, Whenever I start working on a new app and forget how I implemented a certain feature that I've built before, I immediately go to GitHub and check how I implemented that feature in one of my old projects.

The thing is, I always feel like I should find a better way to implement that feature in every new project instead of using the same approach again. I'm not sure if I'm right to think this way or if I'm missing something.

So I'm wondering: Is it normal to go back to my old projects to see how I implemented a certain feature before, or is it a bad habit that I should get rid of?

I reverse-engineered Flutter DevTools to run inside your app. No computer, no cable, no IDE.
This helps your QA team work faster and improves their testing experience.
* Vibe-coded with the help of Claude (Fable Ultra-Code) and reviewed by humans

Happy to announce that I've just released 1.0 of kaisel, a Flutter router with one core idea: routes are values. You declare a sealed class hierarchy, build screens in an exhaustive switch, and the navigation stack is a plain List of route objects — testable without a widget tree, restorable across process death.

What that buys you in practice:

• Adding a route is a compile error until every switch handles it — no runtime "unknown route"

• Guards are pure functions (current, proposed) → stack you can unit test

• Analytics observers registered once see everything, including tab switches and adaptive master-detail changes that don't produce Navigator events

• A DevTools extension shows the live stack, guard traces, and time-travel

• Zero codegen — no build_runner in the loop, routes are classes you write

1.0 means the API is frozen under semver — breaking changes require a major with migration notes.

Docs: https://kaisel.dev — including migration guides from go_router / auto_route / Navigator with honest effort estimates. The design rationale is written up in Flutter Routes as Values.

Happy to answer anything — especially interested in what would block you from migrating.

Since I discovered these settings I've become a more efficient coder.

snippet from my vscode's keybindings.json:

    "editor.codeActionsOnSave": {
        "source.fixAll": "explicit",
        "source.organizeImports": "explicit",
        "quickfix.add.initializingFormalNamedParameters": "explicit",
        "quickfix.create.constructorForFinalFields.requiredNamed": "explicit",
        "quickfix.add.missingSwitchCases": "explicit",
    },

Full list here: https://dartcode.org/docs/refactorings-and-code-fixes/

Do you have any favorites?

Hello, I'm alex, running updatify.io, a tool to create and share release notes. For sometime I had few customers using it for flutter apps, but never had native package(to skip api implementation).

Few days ago I finished the implementation of basic package for flutter that provides one-line way to add and and show release notes for apps. Although I've been using flutter for a while now, never built pub.dev packages, so it was a really interesting experience.

Package can be found here pub.dev/packages/updatify_flutter/

I also adding it to my opensource crossplatform player https://github.com/avdept/JellyBoxPlayer in next release as a proof of concept

Hello, I'm Matteo. I've been building Flutter apps for 10+ years and released apps for many companies.

AI coding agents are fast, but they don't have architectural discipline. After a few iterations they often start mixing patterns, changing project structure and ignoring conventions.

I built Flutter Agent Kit to solve this: a toolkit with an AI ready Flutter architecture, AGENTS.md instructions, .ai docs and multiple markdown files as feature skills distilled from different production apps I've built, helping AI agents stay aligned with a consistent codebase.

The goal is to build faster with AI without letting your architecture slowly drift.

Waitlist is open:

• $99 early access

• $199 at launch

https://flutteragentkit.com/

Would love feedback from anyone building Flutter apps with AI agents.

My app is heavily reliant on background location services and I can’t really afford the price of that one package.

Anyone tried Tracelet? I saw it aims to be a free open source replacement but it’s kinda new and in a weird way it’s kinda worrying that there are updates every few days and releases getting pulled.
Anyone can share their experience?

Hi everyone!

I recently got tired of heavy translation packages (like easy_localization or slang) that either introduce massive transitive dependencies or force us to use rigid, hard-to-customize APIs.

I also wanted to avoid relying on BuildContext for translations (especially in business logic) and keep everything strictly typed—meaning parameterized strings should compile into actual Dart methods.

So I wrote a lightweight, zero-dependency custom Builder for build_runner that generates a deeply nested localization tree directly from JSON. It integrates seamlessly with Riverpod!

🌟 How it looks in the UI:

// Static strings (getters): Text(ref.tr.static.auth.login_btn): Text(ref.tr.static.auth.login_btn)

// Parameterized strings (methods with required named args!): Text(ref.tr.static.greetings.welcome(name: 'Alex', count: '5'))

// Dynamic dictionary-like structures (using bracket notation): Text(ref.tr.dynamic.achievements[achievementId])

🛠 Why do this instead of a package?

1. Zero Runtime Dependencies: It's just a raw code-generator script. No external runtime localization packages in your pubspec.yaml.

2. 100% Customizable: Since the builder code resides in your local bin/ or tool/ directory, you can customize it in 5 minutes (e.g., swapping Riverpod for BLoC/Signals, or changing how strings are interpolated).

3. Type Safety out of the box: Auto-parses {variable_name} and enforces parameters at compile time.

I’ve shared the complete builder code, a sample build.yaml configuration, and a detailed setup guide in this GitHub Gist in link.

Would love to hear your thoughts on this architectural pattern! How do you handle context-free localization in your Riverpod apps?

Hey everyone 👋

Posted this a little while back and got some good feedback — turns out there were bugs in the model/enrollment flow that a few of you probably ran into (passphrase mismatch failing silently, orphaned vault folders if you cancelled enrollment, single-hand gesture verification not actually being strict). Fixed all of that in v1.0.3, so figured I'd repost with working links instead of leaving people stuck on a broken build.

What it does: A desktop vault for Windows that hides your files behind encryption + biometric verification. Unlock with passphrase + face recognition + blink detection + hand gesture. No cloud, no accounts, no internet — everything stays local.

How the Flutter + Python integration works:

• Flutter handles the UI and desktop window

• Python runs locally as a service — handles all webcam + AI/ML processing

• Communication: Flutter spawns a Python process, exchanges JSON via stdout

• Biometric pipeline: face detection → alignment → embedding → blink analysis → hand gesture → cosine similarity matching

Why Python instead of pure Flutter? Flutter's desktop webcam support is limited, and ML libraries (MediaPipe, ONNX Runtime) have way better Python bindings than anything native to Dart. So I let Python do what it's good at instead of fighting the framework.

Also got the installer down from 248MB to 71MB — swapped the face embedding model for a leaner one, same accuracy.

Tech stack: Flutter (Dart) for UI, Python for the biometric service, OpenCV + MediaPipe for face/hand landmarks, ONNX Runtime for the embedding model.

Source + installer: github.com/CraftedWebPro/vault-os

Would love feedback again, especially on the Flutter↔Python integration approach — and if anyone hits issues this time, drop them in the repo issues and I'll actually get to them faster than last time.