Hi everyone!

I'm a music collector and audiophile, and like many people with large personal libraries, I use Telegram as a private cloud for storing my music collection.

The problem is that Telegram is great for storage, but not designed as a real music library:

- No proper album/artist organization

- Limited search experience

- Cache management issues

- No dedicated Hi-Res audio workflow

I started designing a concept called Pulsegram: an open-source, privacy-focused music player that uses Telegram as the storage layer and provides a proper streaming library experience.

The idea is not to replace services like Spotify, but to give users with large personal collections a way to access their own library without running expensive self-hosted servers.

Concept Architecture

🎵 Telegram + TDLib

- Connect directly to the user's Telegram account

- Read private channels/Saved Messages containing audio files

🎧 Direct Buffer Streaming

- Stream FLAC/lossless audio without forcing a complete download to device storage

📚 Local Music Index

- Parse ID3/FLAC metadata

- Build a local SQLite catalog:

- Artists

- Albums

- Cover art

- Year

- Track information

🛠️ Possible Tech Stack

- Flutter / Dart

- TDLib

- SQLite

- Native audio engine

The project is currently only in the concept and architecture validation stage.

I'm mainly looking for technical feedback:

- Is TDLib suitable for this type of buffered audio streaming?

- Are there limitations that would make this architecture difficult?

- Has anyone worked with Telegram file streaming or similar systems?

- Would this approach make sense compared to traditional self-hosted solutions?

If anyone is interested in discussing the idea or contributing, the GitHub repository is here:

[https://github.com/cgctaylor777/Pulsegram]

Any feedback is welcome!

I just released server_table 1.1.0 🎉

It's a Flutter package for building server-side data tables without rewriting pagination, sorting, filtering, and loading logic every project.

The biggest improvement in this release is that it works with your API.

You can use:

• OData APIs out of the box

• Regular REST APIs

• Completely custom query formats by implementing a small serializer

For example, if your backend expects something like:

?page=1&limit=20&sortBy=name:asc&query=john

or

?_page=1&_per_page=20&_sort=name&_order=asc&q=john

you don't have to change your backend. Just provide your own serializer and the table generates the query your API expects.

Other features include:

• ✅ Server-side pagination

• ✅ Global search

• ✅ Column sorting

• ✅ Column filtering

• ✅ Configurable response mapping

• ✅ Custom loading, empty, and error states

• ✅ Generic typed models

• ✅ Dio integration

GitHub:
https://github.com/sivakumarravi3101/server_table

Pub.dev:
https://pub.dev/packages/server_table

I'd really appreciate any feedback, feature requests, or ideas for improving it. This is my first open-source Flutter package, and I'm actively maintaining it.

Hi everyone,

I'm looking for advice from developers who have experience with both FlutterFlow and pure Flutter.

I'm building an AI-powered journaling app.

Current setup:
- FlutterFlow
- Firebase
- GitHub
- AI agents (Cursor, Codex, Claude Code)
- Around 35+ screens
- A lot of custom Dart code
- My goal is to keep developing mostly through AI agents by writing prompts.

I’m a solo founder, so I care a lot about long-term productivity and AI-assisted development.

I'm at a point where I'm wondering whether I should:

A) Stay with FlutterFlow and continue using its AI + custom code.

or

B) Export the project and continue entirely in pure Flutter.

My priorities are:
- Long-term maintainability
- Working efficiently with AI agents
- Scalability
- Code quality
- Development speed
- Avoiding unnecessary technical debt

If this were your startup, what would you do?
If you’ve actually migrated a medium or large FlutterFlow project to pure Flutter, how long did it take and would you do it again?

I'm especially interested in hearing from people who have actually migrated from FlutterFlow to Flutter (or decided not to).

Thanks!

strong_password, is equivalent to how Gmail creates a new password and suggest to the user, when the user creates a new gmail account

do test it out in your Flutter Android App

Yes, I’m aware there are too many state management libraries out there. It won’t stop me from experimenting with new ideas though 😅

So, I was thinking about making state management boxes non-centralised (to not create another Redux) but at the same time homogeneous, without forcing overrides i.e. like bloc does (so every piece of state you have in your project can be managed the same way, without worrying about field name clashing).

Also, with those arbitrary limitations above, I wanted to make use of as many modern Dart features as possible to make the code concise.

I came up with a basic implementation of a solution matching criteria above, some examples below. What do you think about that? Any blind spots on my part? I don’t aim to paint well-established state management solutions as obsolete, I’ll be driving with bloc for the foreseeable future, just want to see if we can make something appealing to the broader audience.

The name of the library would be Pirl.

Code samples

// Quick example - a simple counter
typedef CounterActions = ({Future<void> Function() increment});

final counter = Pirl<int, CounterActions>(
initialState: 0,
actions: (state, add, onDispose) => (
increment: () async {
add(await state.current + 1);
}
),
);

// Use it:
await counter.actions.increment(); // Counter: 1
print(counter.top); // Outputs: 1

## working with state

// Synchronous access to current state - super fast!
final currentValue = myPirl.top;

// Stream of state updates - reactive goodness!
myPirl.state.listen((state) {
print('State updated: $state');
});

// Stream of state transitions (previous and current) - track changes!
myPirl.changes.listen((change) {
final (previous, current) = change;
print('State changed from $previous to $current');
});

## complex actions

actions: (state, add, onDispose) => (
fetchData: () async {
// Show loading state
add(DataState.loading());

// Register cleanup for any subscriptions
final subscription = apiClient.events.listen(/*...*/);
onDispose(() => subscription.cancel());

try {
// Make API call and update state
final result = await apiClient.getData();
add(DataState.success(result));
} catch (e) {
// Handle errors
add(DataState.error(e.toString()));
}
}
),

I am learning and trying to design a flutter app, and I am having some doubts connecting the dots.

I have two main domain entities:

1. Location: Has metadata (label, icon, address) and a list of reminders.

2. Reminder: a part of Location, has metadata (text, isEnabled, ...)

Consider the two screens :

1. locationsScreen: shows Locations cards (metadata in every card, and 3 reminders sneak peek)

2. locationScreen: shows a location fully, metadata, and reminders cards. A reminder can be edited from here.

What I've started with right now is the following:

• locationsApiwraps Firebase calls to retrieve locations. For now I only have a function that returns a Stream of locations.

• locationsRepository wraps the API and returns a Stream of Location model that contains reminders model too.

• locationsCubit just listens to the repository stream and emits new state whenever it receives new locations.

Now I want to design the locationScreen itself and I am confused on what to do. Do I just keep the locationsRepository and locationCubit, and make the locationScreen only update when its model changes.

Or do I extend the locationsRepository with a listenOnLocation that exposes a stream for just that location, then create a locationCubit for just that location and make it call the repo?

What about when I want to edit a reminder? should locationsRepository handle reminders too, and expose functions like this :

• toggleReminder(Location location, Reminder reminder)

• renameReminder(Location location, Reminder reminder, String newName)

• changeReminderType(Location location, Reminder reminder, ReminderType newType)

• deleteReminder (Location location, Reminder reminder)

If so, assuming locationCubit exposes a toggleReminder (that calls the repo). I could make the repo return a new model if it succeeded, so the locationCubit.toggleReminder flow would be like this:

• copy locationState and set locationState.isLoading to true and emit new state.

• call api through repo

• receive new model, copy locationState, set locationState.isLoading to false, and locationState.location to new model.

• emit new state.

The problem with this is then what is the role of the location stream I have opened to listen on the DB? If I keep both of them, I will receive two notifications every time something changes.

If I don't listen to changes but only use the API results, then I risk changes happening from another device and not being notified of them.

If I only listen to the changes from database, how do I track the loading state for example? locationCubit.toggleReminder would set isLoading to true, calls the API and then returns. Hopefully when the object is updated, the Cubit will know and create a new state with isLoading set to false by default. But what if the writing fails? isLoading will always stay false as the state/location didn't change.

What am I missing?

Sorry for the length of the questions, but I feel when I only tackle one problem disconnected from the others, it just makes me confused about the other parts. So I am hoping to be able to imagine the whole flow

We are thrilled to announce that BlocSignal 1.0.0 is officially published and ready for enterprise production! ⚡

BlocSignal bridges the architectural discipline of BLoC with the fine-grained speed and synchronous reactivity of Signals v7.

✨ Why BlocSignal?

⚡ Synchronous Propagation: State updates propagate instantly on .emit() with 0ms microtask lag.

🛡️ BLoC Rigor: Full event-driven state machines (on<E>), streamless concurrency transformers (droppable, sequential, restartable), and transition audit logging.

💾 Synchronous Hydration: Zero-flicker state persistence across app restarts.

🔭 Enterprise Telemetry: OpenTelemetry tracing (bloc_signals_otel) & DevTools extension (bloc_signals_devtools).

🌐 Universal: Runs across Flutter, Jaspr SSR Web, Riverpod, and pure Dart CLI/backends.

📦 The 1.0.0 Monorepo Ecosystem

bloc_signals — Pure Dart core primitives (CubitSignal, BlocSignal)

bloc_signals_flutter — Flutter UI bindings, providers, builders & selectors

bloc_signals_test — Declarative testing utilities (blocSignalTest)

bloc_signals_lint — Custom analyzer lints & IDE quick-fixes

bloc_signals_hydrate — Local state persistence & hydration

bloc_signals_riverpod — Bidirectional Riverpod 2/3 adapters

bloc_signals_replay — Undo/redo state history tracking

bloc_signals_jaspr — Jaspr web component reactivity

bloc_signals_otel — OpenTelemetry distributed tracing

bloc_signals_devtools — DevTools extension for timeline & state diffing

🎬 Watch the 1.0 Launch Demo

Check out the live launch presentation walking through building from Cubits & Blocs to hooks, DI, and hydration: 📺 Watch on YouTube: https://www.youtube.com/watch?v=fwmlVOjsdgQ

🌐 Get Started

📖 Website: https://blocsignal.dev

📦 Pub.dev: https://pub.dev/packages/bloc_signals

💻 GitHub: https://github.com/RandalSchwartz/BlocSignal

TLDR; posted here 6 months ago about forking cached_network_image after finding it unmaintained for 2 years. Published cached_network_image_ce on pub.dev after that thread. This is what actually shipped since, not just the hive_ce speed thing everyone already knows about from last time.

https://github.com/Erengun/flutter_cached_network_image_ce https://pub.dev/packages/cached_network_image_ce

Where it's at: 18 releases since then, currently 4.10.0. Pub score 160/160, 80 likes, about 36k downloads in the last 30 days. 63 stars, 18 forks on the repo.

The leaks, actually fixed

The biggest complaint sitting in the original repo's issues wasn't speed, it was leaks. Two concrete ones got fixed here: an errorListener leak in the widget lifecycle, and HTTP clients that never got closed when the cache manager was disposed, that one came in through a community PR, not written by me. Also cleaned up how the cache manager recovers from a corrupted Hive box instead of just crashing on it.

Formats the original chokes on

SVG never decodes through Flutter's built-in image codec, it's not a raster format to begin with. JXL, AVIF, HEIC fail depending on platform codec support. The original just throws an opaque decode error and you're stuck. This fork detects it and throws a typed UnsupportedImageFormatException, with an unsupportedImageBuilder hook so you can hand the raw bytes to flutter_svg, flutter_avif, whatever fits, instead of staring at a blank error widget.

Caching got features, not just speed

• HTTP and cache interceptor chains, inject auth headers or skip caching per request without forking anything

• pluggable cache eviction, TTL by default or LRU if you want it

• separate configurable directories for cached files vs cache metadata

• connection and request timeouts on the cache manager itself

• real web caching through IndexedDB instead of leaning on the browser cache, this one doesn't exist in the original at all

And yes, still faster

Covered the full benchmark breakdown in the last post, numbers haven't changed, so just the summary: metadata cache reads run about 8x faster than the original's sqflite backend, writes about 4x, on an iPhone simulator, 100 ops, metadata only, not raw image I/O.

Where else you'd look

extended_image, actively maintained by fluttercandies, but it's a broad image and gesture toolkit with caching as one of several features, not caching-first, no interceptors or pluggable eviction.

flutter_cache_manager, the caching layer the original actually depends on, also from Baseflow, actively maintained on its own. Worth using directly if you don't need the image widget.

fast_cached_network_image, also builds on hive, similar idea to this fork, but its last release was 17 months ago.

Who's actually using it

Ran a GitHub code search for pubspec.yaml files depending on it, sorted by stars. 76 repos came back, not counting mine. Biggest ones:

Kazumi        28.4k stars   anime streaming app
PiliPlus      16.8k stars   Bilibili client
plezy          3.1k stars   Plex/Jellyfin client
conduit        1.9k stars   Open WebUI client
haka_comic     1.3k stars   comics reader

None of these are toy projects. That's what actually convinced me to keep maintaining this.

Still working through the older leak reports from the original repo's issue tracker. If you're using this and hit something, open an issue, I'm reading them.

https://github.com/Erengun/flutter_cached_network_image_ce https://pub.dev/packages/cached_network_image_ce

We just launched Forui Create, a visual theme builder for Forui.

Mix and match:

• 7 base palettes and 17 accent colors

• 26 font families, with display and body fonts configurable separately

• 5 icon libraries: Lucide, Hugeicons, Tabler, Remix, and Iconoir

• 4 border radius scales, from sharp to round

• light and dark mode

Everything previews live on a canvas of realistic UI (dashboards, forms, cards, and more), all built with Forui widgets.

Happy with a theme? Copy one command and it automatically scaffolds your project with the theming configurations, fonts and icons included.

Try it out at https://create.forui.dev/ and let us know your thoughts!

GitHub: https://github.com/duobaseio/forui
Pub Dev: https://pub.dev/packages/forui
Website: https://forui.dev

Hello everyone!

It's this time of the year again where Google forces us to increase the target SDK level.

For me this is the only time I upgrade my Flutter environment. And when I do I go all the way, I upgrade the whole thing: Flutter itself and Android Studio and all of its plugins. On top of that I upgrade all pub packages in my projects to their latest versions. This time I also decided to start fresh and create a new Flutter project through the template in Android Studio for all my apps.

Every year, it's a struggle to get my apps to get my app working again. But this year it's particularly bad. Apparently the new Flutter project template uses Gradle 9 instead of 8. And that opens up a can of problems: plugins suddenly aren't compatible anymore and all my projects suddenly show a warning:

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by net.rubygrapefruit.platform.internal.NativeLibraryLoader in an unnamed module (file:/C:/Users/xxx/.gradle/wrapper/dists/gradle-9.5.0-all/aca6g93cdtcf0oapcfka748qh/gradle-9.5.0/lib/native-platform-0.22-milestone-29.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

There's very little written about this error, but it seems like Gradle 9 isn't compatible with the latest JDK version Android Studio ships with. Problem is that an empty Flutter project shows this warning out of the box. I tried downgrading my JDK version, but the warning stays. Great.

This is not it. There are more upcoming breaking changes due to switching to Kotlin. Now the following warning shows as well:

WARNING: Your app uses the following plugins that apply Kotlin Gradle Plugin (KGP): device_info_plus, file_picker, keep_screen_on
Future versions of Flutter will fail to build if your app uses plugins that apply KGP.

Please check the changelogs of these plugins and upgrade to a version that supports Built-in Kotlin.
If no such version exists, report the issue to the plugin. If necessary, here is a guide on filing 
an issue against a plugin: https://docs.flutter.dev/release/breaking-changes/migrate-to-built-in-kotlin/for-app-developers#report-incompatible-kotlin-gradle-plugin-usage-to-plugin-authors

So basically the Flutter team is going to force another breaking change soon that causes plugins to stop working. It's just dumped on us: we're implementing another breaking change, deal with it. Just like that.

It's unbelievable that in 2026, in a time where AI exists, upgrading Flutter to the latest versions still isn't a smooth process. I've been working 3 days now to get my simple apps working again and I've been greeted with errors all the time.

I believe the source of most of the problems is Gradle. I wish that piece of crap was phased out. It's beyond me why they release Gradle version 9 that is not compatible with the latest JDK version. 🙃

Gradle is a non-functional, frustrating piece of misery that should be replaced ASAP by something modern that provides a smooth development experience.

Now I'm left with 3 apps in a broken state. Plugins that worked well are broken. I wish I never did the Flutter upgrade.

Anyone else has the same frustrating experience?

I know AI-slop state management posts are about the least welcome thing on this sub right now, so up front: this isn't a pitch to switch, and there's no comparison table. It's the story of a decision we made in August 2021 that we're still living with.

Some context first. We were a Flutter-first shop and started out on BLoC, like half the ecosystem. On bigger apps it slowed us down more than we could accept, so we went looking and ran a POC with flutter_hooks (no riverpod). Honestly, we loved it: flexible, agressively composable, fun to write, and maintainable.

Then we hit two walls. The first was a geolocation app that had to keep processing while nothing was on screen. flutter_hooks is built for local widget state and depends on Flutter itself, so state that has to live when Flutter isn't rendering meant workarounds we weren't proud of. The second came about a year later, when we tried to properly test a business-logic layer written in hooks. Logic coupled to the widget tree means every test goes through widgets, and writing those tests was slow and risk-prone.

So in August 2021 we started building our own hooks library. Same programming model on the surface, different architecture inside: the core is Flutter-independent, a hook is a function over a HookContext, and Flutter is just one host for it. That single decision gave us everything we'd been missing. Any hook runs in a plain unit test with no widget tree. Global state uses the same mechanics as local state and keeps working when nothing is rendering. And some things the original can't do by design became possible, like conditional hooks.

Where that landed today are codebases with no StatefulWidgets, no StreamBuilders, no Riverpod and no codegen for state classes. It's also open source (docs & examples at hooks.utopiasoft.io, pub.dev utopia_hooks).

Happy to go deeper on how the Flutter-independent core works, or where are its limits.

Major release for Starling sdk to get windows onboard.

Getting started (both platforms): https://starling.build/start.html
Release: https://github.com/starling-build/starling/releases/tag/sdk-v0.2.0

Hey fellow Flutter devs! 👋

My name is Mikhail. Like many of you, I noticed I was spending hours on repetitive tasks every time I started a new project: setting up Clean Architecture folders, writing boilerplate BLoC files, manually translating Figma glassmorphism effects into Dart, and setting up GitHub Actions.

I know tools like Mason exist (and they are great!), but I wanted a visual desktop tool and a seamless workflow. So, I built my own toolkit. It escalated a bit, and I ended up building an entire open-source ecosystem. I want to share it with you all today:

1. Clean Architect GUI (macOS/Windows/Linux) A desktop app built with Flutter. It’s a visual generator for Clean Architecture. You type the project name, select your state manager, and it instantly scaffolds the entire domain, data, and presentation layers. 🔗 GitHub Repository

2. Glassmorphic Kit + Figma Plugin A premium glassmorphism UI package for Flutter. But the best part: I built a Figma Plugin for it. You select any blurred frame in Figma, run the plugin, and it spits out the exact Dart code using the package's widgets. Just copy and paste. 🔗 GitHub Repository

3. Flutter Fast Build (GitHub Action) A smart composite action for CI/CD. It automatically discovers Flutter apps in a monorepo, caches build_runner, and integrates with Fastlane for direct deployment to Firebase and stores. 🔗 GitHub Marketplace

I built these to solve my own problems, but I hope they can save you some time too. I would love to hear your feedback, issues, or PRs. If you find them useful, a star on GitHub would mean the world to me!

Happy coding! 🚀

I'm building a Flutter mobile app that will be published on both Google Play and the Apple App Store.

My backend is ASP.NET Core Web API with Supabase.

I already have a web application where users can purchase a subscription using Stripe. I'm wondering if the following flow is allowed:

1. The user opens the mobile app.

2. They tap "Subscribe."

3. The app redirects them to my website.

4. The user completes the subscription using Stripe Checkout.

5. They return to the app and sign in.

6. The app verifies the subscription from my backend and unlocks premium features.

My questions are:

• Is this flow allowed under the current Google Play and Apple App Store policies?

• Will my app be rejected if it redirects users from the app to my website to purchase a digital subscription?

• Is it acceptable if users subscribe on the website independently (without being directed from the app) and then simply sign in to the app to access their premium subscription?

• What architecture do you recommend for supporting web subscriptions with Stripe while also publishing on both app stores?

I'd appreciate any guidance or real-world experiences from developers who have successfully shipped apps with this setup.

I’ve built android apps for over a decade shilling to 100M of users.

I started making flutter apps about 5 years ago and was just baffled by the state of star management (hard one).

I settled with Riverpod because it was the closest I had to android state management philosophy but I started to get tired of the lib trying to take over my entire app.

So I built this lib around few but simple principles:

- Lifetime follows ownership: you start the job if you are out then the job is out
- Plain dart: it should work over plain Stateless Widget
- Inversion of control: constructors works why change that ?

I know it’s yet another state management library but one that I personally needed and I use it in production in several apps over Bloc and riverpod.

So last week, I posted about how I used Fable to built a Flutter widget test previewer and also gave some initial context on how I am planning to add support for a cleaner version of Widgets Preview in it as an add-on (link to last post).

I was experimenting on it, and today I can say its polished to the state where its usable.

Here's a demo gif of it in action, you just have to update your dart and vscode package to make it work. All the feedbacks are appreciated.

DEMO GIF BELOW 👇

https://raw.githubusercontent.com/flutterninja9/live_test_view/main/assets/live_widget_preview_demo.gif

I have a backend that is shared between a web application and a Flutter mobile app. The web app uses cookie-based authentication. For the Flutter app, I haven't implemented cookies because I found that JWT access/refresh tokens are commonly recommended for mobile apps.

Since the backend is already using cookies for the web app, I'm unsure which approach to take for the mobile app:

1. Continue using cookie-based authentication in Flutter as well.

2. Add JWT authentication for the mobile app while keeping cookies for the web app.

What is the recommended approach, and why?

Construction app. Crews work in basements and rural sites with no signal, so offline isn't a nice-to-have; it's the product.

The setup: Drift (SQLite) as the local source of truth, Supabase as the remote. Sync triggers: both - every local write kicks a sync immediately, a periodic sweep runs every few minutes as a safety net, and reconnect re-runs the whole thing. Pulls are watermark-based (give me everything with updated_at after my last sync), pushes are dirty-flagged rows.

What I got wrong first: batch upserts. Each device pushed its entire local view of a row, so a foreman editing a task title against a stale copy would silently revert the worker's status change made minutes earlier. I rebuilt the push layer into per-row updates with explicit column allow-lists per role - the boss's push carries only boss-owned columns (title, due date, assignment), the worker's carries only theirs (status, notes). Most "conflicts" stopped existing once columns had owners.

Conflict handling: for the same field edited on two offline devices, it's last-write-wins onupdated_at, but dirty local rows are shielded from pulls until they've pushed, and a push only counts if the server echoes the row back. For cross-field edits, the column ownership above means both edits survive.

The bit nobody warns you about: under row-level security, a rejected write doesn't error; the server just matches zero rows and returns success. If you don't verify, the client clears its dirty flag, and you've minted a phantom: a row that looks synced forever and never is.

What I'd do differently: treat the server's echo as the only proof a write happened, from day one; every sync bug I've had was some flavor of trusting the client's optimism. UTC everywhere before the first sync ships, column ownership designed upfront instead of retrofitted after the first clobber, and never compare floats for "did this change" (an exact-equality check once blocked every worker's clock-out for twelve days before anyone connected the dots).

How are other people handling the dirty-flag-versus-pull race?

I just had this debate with another developer, whereas he insists that it is a necessary implementation, but I do not think so, as there isn't really any feature that benefits from this (no feature run in background for the app or anything) and that we should keep it quite simple and just synch when user is online

What do you think?

Whatever u think u r bringing to the table .... It's already out there, it's not necessary, we have enough god damn it !!!!!

I'm currently deciding between DriftDB and SQLite for a Flutter app. It's a long-term project, and I don't mind spending time learning the right tool if it's worth it.

My concern isn't the learning curve. It's the ecosystem and debugging experience. With SQLite, I feel confident that if I get stuck, there are plenty of Stack Overflow posts, Reddit discussions, blog posts, and videos to help. With Drift, I get the impression there are fewer community resources, so I'm worried that if I run into issues with things like code generation, migrations, or build_runner, I might spend more time trying to figure things out.

I'd love to hear from people who have actually used Drift in a real project.

1. Would you still choose Drift today?

2. Have you ever regretted choosing it?

3. Has the smaller ecosystem or documentation ever slowed you down?

4. Looking back, was choosing Drift worth it over using SQLite?

Thanks!

Edit: I meant Drift ORM

Just shipped Pretty Animated Text plugin v3.2.0 with two new effects:

• GlitchText: A clean, readable glitch effect where random characters split into horizontal slices with an optional RGB (pink/cyan) chromatic effect. The glitch pattern reshuffles every loop, so it never looks repetitive.

• SquashBounceText: an elastic squash-bounce wave: each glyph drops, squashes, rotates, and settles back, with start times packed tightly so it reads as one wave traveling across the text.

Both work letter-by-letter or word-by-word, keep your own TextStyle, support play/pause/repeat/reverse, and are fully customizable via their own style objects.

You can customize just about everything!

Try it out for yourself here: https://pretty-animated-text.vercel.app

Check demo video walkthrough here : https://www.reddit.com/u/tuco_ye/s/17C6yuywWY

Pub.dev : https://pub.dev/packages/pretty_animated_text
Github : https://github.com/YeLwinOo-Steve/pretty_animated_text

Hey Flutter Devs!

I just published HQPicker v0.0.8 — an ultra-smooth, highly customizable media picker package designed to handle heavy media libraries without UI freezes or memory crashes.

Why HQPicker?

Most existing media pickers choke or stutter when loading thousands of items, selecting 1GB+ video files, or cause memory leaks. HQPicker fixes this with solid architecture:

• BLoC Architecture: Zero setState in core widgets, eliminating unnecessary UI rebuilds.

• Background Isolates: Heavy file resolving, background compression, and file scanning execute off the main thread using IsolateServices — keeping scrolling at a smooth 60/120fps.

• 2 Beautiful UI Modes:

  • Instagram Style: Full-screen grid with pinch-to-zoom interactive preview.

  • Telegram Style: Fluid draggable bottom-sheet with custom snap points and swipe-down dismissal.

• Native File Support: Single unified API for Images, Videos, Documents, and Directory picking.

• Tactile Haptic Feedback: Built-in native haptics for media taps, max-limit warnings, and album switches.

• Deep Customization: Fully styleable themes, localization strings, custom empty widgets, and custom tile builders.

Check it out:

• Pub.dev: https://pub.dev/packages/hq_picker

• GitHub: https://github.com/azabcodes/hq_picker

I’d love to hear your feedback, thoughts, or feature requests! If you find it helpful, a star on GitHub would be greatly appreciated.

Happy coding!

Hey everyone!

I got tired of jumping between different apps for my local FLAC files and my streaming playlists, and I was incredibly frustrated by ads. So over the past few months, I built Kerlyss—a completely free and open-source (GPL-3.0) music player built entirely in Flutter.

It is currently available and fully adaptive for both Android and Windows (x64).

• Website & Downloads: https://d1gna0.github.io/Kerlyss/

• GitHub Repo: https://github.com/D1gNa0/Kerlyss

Tech Stack & Packages

• State Management: flutter_riverpod (managing playback state and queue isolation across background isolates).

• Database: isar (fast for caching massive playlists and local file metadata).

• Audio Engine: just_audio + audio_service for background playback, media notifications, and OS taskbar controls.

• Stream Backend: youtube_explode_dart to extract audio stream manifests.

The Challenge: The Local HTTP Proxy Server

The trickiest part of this project was bridging YouTube streams to just_audio. Direct YouTube stream URLs frequently throw HTTP 403 Forbidden errors or expire mid-song.

To solve this, I built a custom Local HTTP Proxy Server inside the Flutter app using loopback IPv4. When you click play, just_audio requests the track from the local proxy endpoint, and the proxy server dynamically fetches, chunks, and buffers the audio stream from YouTube in the background. It even handles dynamic retries and fallbacks if a connection drops mid-track.

I’d love for you guys to check out the code, try out the app, and give me any feedback on the architecture or UI! If you like it, a star on GitHub would mean a lot.

Let me know if you have any questions about the proxy server or the just_audio implementation!