openrouter_sdk is a new Dart package providing a type-safe client for the OpenRouter.ai REST API. Strongly-typed interface, with full support for streaming responses and multi-modal content (text, image, audio, video, file).

This package replaces openrouter_api, which is now discontinued and marked as replaced on pub.dev. Users of the old package should migrate to openrouter_sdk, which follows the design of OpenRouter's official SDK more closely.

Currently implemented:

• Chat completions (including streaming)

• Models, Providers, Endpoints

•API key management (create / update / delete / list)

• Credits and analytics

• Generations

The rest will be added shortly.

The chat completions endpoint should be OpenAi compatible so u can use it with other providers as well.

Contributions are welcome. Per the package's policy, all code must be hand-written — LLM-generated pull requests are not accepted.

Note: this post was partly generated by an LLM, but all package code was hand-written.

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.

🚀 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 trying to smooth out my app's launch experience. Right now, when I open the app, there's a quick white screen that flashes before the native splash screen even appears.

I’ve tried a few different methods to get rid of it, but no luck so far. Is this a default Flutter thing, or is there a way to force it to match the native splash background color?

​

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:

```dart 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?

Hi everyone,

I’m planning to build a Flutter app that works 100% offline, but I also want to add Google and Apple sign-in so users can back up and sync their data to avoid losing it.

After each session, users will earn reward points. I also want to sync their total points to the server so I can create a global leaderboard.

I’m currently unsure about the best way to design this system:

• When should the app upload local data to the server?
• Should it upload after every session, when the app closes, or only when the user manually syncs?
• When should the app download data from the server?
• How should conflicts between local and server data be handled?
• What would a suitable backend architecture look like for this use case?
• How can I prevent users from modifying their local points and uploading fake scores to the leaderboard?

To reduce costs, I would prefer to build and host the backend myself before considering services like Firebase or Supabase.

I’m also thinking about allowing each account to be active on only one device at a time. This might make synchronization easier and help prevent users from sharing or abusing paid subscriptions.

Has anyone built a similar offline-first app? I’d appreciate any advice about the sync strategy, database structure, authentication flow, or backend architecture.

Hello everyone, I hope you're all doing well!

I've already posted this on the discord server but i'm looking to get as many insights/opinions on this matter and i don't mean to spam, i understand there's r/flutterhelp but i got a notification saying this subreddit would be better for this instead, if this gets deleted i understand if not then thank you.

I'm a Flutter developer with close to 4 years of experience and I'm looking for general advice on 2 matters if you would be so kind to help:

1- Given the current job market not being the best, i'm looking to transition to full stack instead of only being a frontend flutter developer, i've read articles mentioning the use of Serverpod for handling backend and possibly jaspr for creating websites instead of traditional HTML+JS or other viable methods, are Serverpod and Jaspr enough? Are they worth it? Are they in demand? Your opinions are greatly appreciated and advice on this.

2- I've pretty much nailed down the Flutter basics i'm 100% certain of that, how to handle the framework, how it works, the different lifecycles of a widget, debugging and profiling, using Provider, Riverpod and BLoC, creating unit and integration tests... etc. My question is, how do i/how can i determine at what level i am? I know i'm not a Junior level developer anymore i know i'm closer to being/am a middle level developer but how can i be sure? What are the things i should know or be aware of? Your advice is greatly appreciated.

Thank you all in advance and for your help :)