24h Intel · 81 条
Flutter 24小时情报 GitHub 热门仓库与技术资讯
每日汇总 Flutter / Dart GitHub 热门仓库，以及 Dev.to、freeCodeCamp、Hacker News、Medium、Reddit 的近期技术资讯，跟踪 24 小时 Stars 增量与社区讨论。
GitHub
20 条Dart 与 Flutter 相关仓库热度
chen08209/FlClash
更新于 07/22 06:32
localsend/localsend
更新于 07/22 06:32
spotiflacapp/SpotiFLAC-Mobile
更新于 07/22 06:09
Predidit/Kazumi
更新于 07/22 06:00
AppFlowy-IO/AppFlowy
更新于 07/22 06:25
flutter/flutter
更新于 07/22 06:46
bggRGjQaUbCoE/PiliPlus
更新于 07/22 01:32
KaringX/karing
更新于 07/22 02:48
KRTirtho/spotube
更新于 07/22 05:39
echo-loop/Echo-Loop
更新于 07/21 23:05
hiddify/hiddify-app
更新于 07/22 06:11
ente/ente
更新于 07/22 06:45
bagisto/opensource-ecommerce-mobile-app
更新于 07/22 03:36
KaringX/clashmi
更新于 07/22 06:06
ImranR98/Obtainium
更新于 07/22 03:29
Sle2p/AniCh
更新于 07/22 01:45
Chevey339/kelivo
更新于 07/22 01:42
simonoppowa/OpenNutriTracker
更新于 07/22 04:36
venera-app/venera
更新于 07/22 03:02
jiangtian616/JHenTai
更新于 07/21 22:10
Dev.to
12 条开发者文章与项目分享
Who is Ottoman Coder?
Ottoman Coder — Muhammad Usman
Muhammad Usman, known online as Ottoman Coder, is a Flutter/mobile founder-builder in Islamabad, Pakistan. He ships production iOS and Android products from architecture through release. Portfolio: ottomandeveloper.github.io/portfolio GitHub: @OttomanDeveloper Email: ottomandeveloper@gmail.com Phone / WhatsApp: +92 317 7794553 What Ottoman Coder does Ottoman Coder is Muhammad Usman’s Flutter/mobile engineering brand: iOS and Android applications, mobile architecture, Firebase and REST integrations, connected-device experiences, and release-ready delivery. Legend TV — streaming for Urdu-first audiences in Pakistan, India, and Saudi Arabia. LifeLink — crisis support and self-tracking with Google Gemini Pro, Flutter, BLoC, and Firebase. AlcoPass — a connected breathalyzer companion using BLE hardware, Flutter, BLoC, and Firestore. Based in Islamabad, Pakistan, Muhammad works with founders and product teams remotely. Start with the portfolio, email ottomandeveloper@gmail.com, or call/WhatsApp +92 317 7794553. This page refers to Muhammad Usman’s software engineering identity. Ottoman.js / Ottoman is an unrelated open-source Object Data Modeler for Couchbase and Node.js. See the Ottoman.js documentation and Couchbase Labs repository. Furniture businesses and other similar names are separate entities. The reliable combination is Muhammad Usman + Ottoman Coder + Flutter/mobile + Islamabad + OttomanDeveloper.
The Sand in the Oyster: Why Riverpod Was Needed, and Why You Don't Need It Any More
Randal L. Schwartz
The Invisible Grain of Sand Natural pearls do not form because an oyster feels creative. They form because an irritant—a sharp, microscopic grain of sand—lodges inside the shell. Unable to expel the foreign particle, the mollusk secretes layer upon layer of lustrous nacre to insulate itself from the pain. In Flutter state management, Riverpod was the original pearl. For years, it stood as one of the most brilliant, ambitious, and widely adopted architectural solutions in the Flutter ecosystem. But few developers today remember the exact mechanical flaw—the sharp grain of sand deep inside Flutter’s rendering pipeline—that necessitated Riverpod in the first place. Almost every Flutter engineer learns that Provider was built on top of InheritedWidget. Far fewer engineers realize the fundamental defect lurking inside dependOnInheritedWidgetOfExactType: The Flutter framework provides no mechanism to unlisten, unsubscribe, or deregister a dependency once registered. When state is read conditionally (for example, behind an if branch in a widget’s build method), that widget's underlying Element remains permanently registered in the ancestor's _dependents map until the element is completely unmounted from the tree. Long after the condition turns false, that widget continues to rebuild on every ancestor state change. This single mechanical dead-end was the catalyst that drove Rémi Rousselet to abandon package:provider and build Riverpod outside the widget tree entirely. And today, understanding that history illuminates why BlocSignal represents the next natural evolution of Flutter state architecture: restoring InheritedWidget to its pure, intended role as a scoped dependency injector, while delegating state propagation to self-pruning push-pull reactive signals. Here is the full story—from the core framework pull requests that sparked the revolution, to why you no longer need Riverpod's out-of-band complexity today. To understand why Riverpod had to exist, we must trace Flutter's historical commit log back to May 2019. At the time, Rémi Rousselet’s package:provider was rapidly becoming the community standard for state management, ultimately earning an official endorsement from the Google Flutter team at Google I/O 2019. But as developers built larger apps, they hit an intractable wall: how do you automatically clean up resources (autoDispose) when a widget stops needing them? In InheritedWidget, you couldn't. flutter/flutter#33213 (May 2019) Rémi opened a pull request to Flutter core titled: "Expose InheritedWidget subscription cancelation" His goal was straightforward: give InheritedElement an overridable hook so an ancestor could be notified when a dependent element unregisters or stops listening to its state. Ian Hickson (Hixie), then Flutter’s tech lead, reviewed the pull request and closed it without merging: "I think we should close this PR... until we have a stronger reason to make any changes to the framework for this." Ian Hickson (Hixie) Hixie pointed out that Flutter's element reconciliation relies on extreme mechanical simplicity. Adding cancellation hooks and re-evaluating dependencies every frame would add overhead to the hot build loop. He recommended that if packages required dynamic subscriptions or stream lifecycles, they should vend builder widgets or Streams rather than altering InheritedElement. flutter/flutter#106546 & #106549 (June 2022) Three years later, in issues discussing the architectural divergence between Provider and Riverpod, Rémi explicitly reflected on that rejection: "This difference is the reason why I had to basically stop developing package:provider and instead start working on package:riverpod, as package:provider couldn't keep using the context syntax while supporting autoDispose which is a core feature for numerous commonly requested enhancements." Rémi Rousselet Quoting Hixie on why dependencies are never cleared between builds: "This was an intentional performance optimization - by not having to clear the dependencies each frame, we can avoid a lot of work." Ian Hickson (Hixie) flutter/flutter#140742 (December 2023) By late 2023, the Flutter team authored a formal design document titled "Conditionally listen on InheritedWidgets", acknowledging what package authors had known for half a decade: conditional reads in InheritedWidget cause unavoidable ghost rebuild cascades and prevent resources from being released. The grain of sand was never removed from Flutter core. To see why this was fatal for package:provider, look under the hood of Flutter’s framework code in framework.dart. When a widget calls context.dependOnInheritedWidgetOfExactType<T>(): @override InheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object? aspect }) { _dependencies ??= HashSet<InheritedElement>(); _dependencies!.add(ancestor); ancestor.updateDependencies(this, aspect); return ancestor.widget; } Inside InheritedElement: @protected void setDependencies(Element depe
"Not registered" but it is: 4 real cases before the Sept 30 deadline
Emre P.
The September 30 deadline for Play package name registration is three days away. Most apps were registered automatically, and my earlier post covers how to check yours. This post is about the other situation: Play Console says one thing, the release page says another, and you are not sure what to believe. These are four real cases I ran into in the last week, from the Play Help Community and from a client. Each one looked like a Google bug. Most of them were not. What they saw: A Flutter app. The package showed as registered under Android developer verification, but creating the app in Play Console failed with "already in use". Why: The package name was com.example.hello_flutter. That is the Flutter template default. Thousands of projects ship with it, and Play does not accept apps under com.example at all. Fix: Change the package name. If the app was never published, you lose nothing: In android/app/build.gradle (or build.gradle.kts), change applicationId to something unique, like com.yourname.appname. namespace can stay as it is. If you use Firebase, add a new Android app with the new package name and download the new google-services.json (or run flutterfire configure again). Your Firebase project and data stay the same. Register the new name under Android developer verification, then create the app in Play Console with it. After the first release the package name can never change, so pick one you are happy with. What they saw: The developer had two certificates for the app. Neither one appeared as an option for registration. Why: Eligibility is based on known installs per signing key. From Google's help page: A key with over 50% of known installs has priority. If no key passes 50%, every key with 50 or more installs is eligible. Under 50 installs, it is first come, first served. This app was also preinstalled on a manufacturer's devices. That build can easily count for most of the installs. If the manufacturer signed it with their own key, the eligible key belongs to them, not to the developer. Fix: Find out who holds the key used for the preinstalled build. Then open a case from the Help page inside Play Console with the package name, the SHA-256 fingerprints of both certificates, and a note that one build is a manufacturer preinstall. With the deadline this close, open the case today instead of waiting for forum replies. What they saw: The package showed as registered, but the production release failed with an "unregistered package name" error. This one I could not solve from the outside, but there are three things worth ruling out before your ticket sits in a support queue: Same account. The package has to be registered in the same Play Console developer account that owns the app. Not in a separate Android Developer Console account, and not in another Play account. Same key. Compare the certificate you registered with the app signing key under Test and release → App integrity. If you registered the wrong one (for example the upload key instead of the app signing key), Play may treat the release as coming from an unregistered key. Fresh release. If you registered after creating the release draft, discard the draft and create a new release. An old draft does not always pick up the new state. A related case from the same week: a developer who used Internal app sharing got the same kind of error. Internal app sharing builds are signed with a different key, and the fix was to register that key as an additional key for the package. If all of this checks out, the problem is on Google's side. Open a case from the Help page inside Play Console and attach two screenshots: the one showing "Registered" and the release error. What they saw: A client of mine. We had checked her app together, confirmed it was registered and closed the order. Then she wrote back: "It says Package not registered." Why: Nothing was wrong. On the Android developer verification page there is a filter menu, and one of the options is literally called "Package not registered". She was reading the filter's label as the status of her app. How to actually check: Select the "Package not registered" filter. If the list is empty (0 apps), you are fine. Open Package names. The status column should say Registered. I am including this case because it is the most common one, and it causes real panic three days before a deadline that says "removed from Play". Google's wording is clear: apps not registered by September 30 "will be removed from Play". Identity verification for installs outside Play also starts in Brazil, Indonesia, Singapore and Thailand on the same day, and goes global in 2027. So this topic is not going away. [ ] Package name does not start with com.example [ ] Registered in the same account that owns the app [ ] Registered certificate matches the app signing key in App integrity [ ] Extra keys (Internal app sharing, builds outside Play) added [ ] New release created after registration [ ] "Package not registered" filter shows 0 apps
Vibe coded an AI level designer where agents plan and algorithms build using IBM Bob 2.0
Mohammad Rafaquat Alam
Describe a level in plain words and play it a minute later. Live demo: https://neuro-level-designer.vercel.app Code: https://github.com/raf-xtgt/neuro-symbolic-level-designer Making 2D isometric levels is slow. You slice spritesheets by hand, tag every tile (floor? wall? walkable?), paint the map tile by tile, then write loader code. Asking an AI to "just generate the map" fails too: raw tile grids drift, use tiles that don't exist, and give you maps you can't walk through. I split the work so AI only does what needs judgment. Everything that must be exact is plain code. 1. Data Ingestion. Upload any isometric spritesheet. Algorithms detect the tile size and slice every sprite. Four AI agents then inspect each tile in parallel (boundary, classification, collision, entity), each answering in a strict schema. A harmonizer merges their answers in code and only asks the AI again where the agents disagree. The result is an asset catalog, cached so the same sheet costs nothing next time. 2. Level Planning. A Topology Agent turns your prompt into a room graph (rooms, directions, corridors, enemies, style), never raw tiles. Algorithms build the exact isometric grid, place the player, zombies and exit, dress the rooms, and seal the level with a hedge. A validator checks the level is playable: a path from spawn to exit exists and every room is reachable. If a check fails, structured errors go back for a new layout or a new plan, in a self-healing LangGraph loop. 3. Execution. An AI agent designs zombie behavior per room (patrol, guard the exit, wait until you're near), as data, never code. Compilers write a standard Tiled map, templates generate typed Flame (Dart) code, and a verification engine runs 6 checks, including dart analyze on the generated code. Then you press Try Out and play it in the browser, or download the bundle for your own Flame game. Flutter web + Flame, FastAPI, LangGraph, Pydantic structured output, OpenCV. The backend runs on Cloud Run and the frontend on Vercel. I built it for the IBM Bob 2.0 Hackathon. One orchestrator session wrote the architecture and a precise prompt for each task. A coding agent implemented each task, and I reviewed it with tests and browser checks. IBM Bob built the first five tasks: the map and tileset compilers and the first playable game. After my Bob credits ran out, I continued with Claude Code using the same workflow. Every prompt is in the repo under bob_sessions/. Try it: https://neuro-level-designer.vercel.app
👋 Hello DEV!
Pratham Ukey
Hey everyone! I'm Pratham, an MCA student and aspiring backend developer. I'm currently learning Java, Spring Boot, PostgreSQL, and DSA, while building projects to improve my skills. Right now, I'm working on Stanza — an AI-powered swipe-based news app. I'll be sharing what I build, what I learn, and probably a few things I break along the way. 😂 Looking forward to learning from everyone here! 🚀
5 Flutter App UI Kits & Templates Worth Exploring in 2026
DevCraftify
Building a Flutter app from scratch means spending considerable time on onboarding screens, navigation, authentication UI, forms, and responsive layouts before you even reach your application's core features. A well-structured Flutter UI kit can reduce that initial development work. Whether you're building a food subscription app, chat platform, salon booking system, or e-commerce application, here are five Flutter templates worth exploring in 2026. Eativo is a Flutter UI kit designed for tiffin services, meal subscription platforms, and food delivery applications. It includes 30+ screens covering onboarding, tiffin center discovery, subscription plans, checkout, favorites, and subscription tracking. Key features: BLoC state management Light and dark themes Google Maps UI integration Clean, customizable project structure It's a useful starting point for developers building food subscription applications without designing every screen from scratch. ChatFlow provides a customizable messaging interface for developers creating chat and communication applications. The template includes chat lists, conversation screens, communities, archived chats, media viewing, and audio/video call interfaces. Its modular UI makes it suitable for developers who want to customize the messaging experience and connect their own backend. Beauty Book is designed for salon, spa, barber shop, and beauty service applications. With 25+ screens, it covers service discovery, stylist profiles, appointment booking, special offers, treatments, and user profiles. It uses BLoC for state management and Hive for local storage, with both light and dark themes. If you're looking for a general-purpose collection rather than an industry-specific template, ProKit by Iqonic Design is worth exploring. It offers a large collection of Flutter screens and app UI kits across categories such as e-commerce, fitness, food delivery, education, and entertainment. It's particularly useful when you want access to multiple application design patterns in one package. FluxStore WooCommerce takes a different approach. Instead of providing only reusable UI screens, it's designed to connect a Flutter mobile application to an existing WooCommerce store. It includes shopping, cart, checkout, payment, and product management integrations. For developers working with WooCommerce-based businesses, this can reduce the need to rebuild existing e-commerce functionality. Before purchasing any Flutter template, check: Architecture: Is the code organized and maintainable? Screen coverage: Does it include the application flows you actually need? Customization: Can you easily modify colors, typography, and layouts? Backend support: Is it a UI kit or a functional application with backend integration? Documentation: Can another developer understand and extend the project? A template should help you build faster without making future development more difficult. This is a quick overview of the available options. For a more detailed comparison covering Flutter versions, technical stacks, individual features, pricing, and application use cases, read the complete article: Best Flutter App UI Kits & Templates in 2026 — Full Guide on DevCraftify Originally published on DevCraftify.
David Stark: Top High-Paying Roles
David Stark
👋 Hello Architects & Elite Engineers, The market is shifting. We are seeing a surge in MOBILE roles this week. We don't do "Easy Apply". Our internal gatekeeper just processed 200+ verified remote jobs from our partner network. To get these jobs, you must pass the architecture audit. Here are the Top 5 roles worth your time today.** 👇 Software engineer 🏢 Sticker Mule | 💰 Competitive | 📍 Remote Could you walk us through your experience with this tech stack? Tech Stack: .stickermule.com Sticker Mule is building the Internet's most lucrative commerce... 👉 Apply & View Full Salary Full-Stack Product Engineer - Agentic First 🏢 Wonderdog | 💰 Competitive | 📍 Remote Could you walk us through your experience with this tech stack? Tech Stack: .com/ Wonder Dog is a preventative health platform for dogs. We send licensed ve... 👉 Apply & View Full Salary Lead Developer — Rebuild, Modernize, & Scale (Social Good SaaS, Remote) 🏢 Track it Forward | 💰 Competitive | 📍 Remote Could you walk us through your experience with this tech stack? Tech Stack: .trackitforward.com We are looking for a lead developer to do a greenfield rebui... 👉 Apply & View Full Salary Senior Shopify Developer 🏢 Sanctuary Computer Inc | 💰 Competitive | 📍 Remote Could you walk us through your experience with this tech stack? Tech Stack: We are hiring a contract-based Senior Shopify Developer to contribute to ou... 👉 Apply & View Full Salary Senior DevOps / DevEx Engineer 🏢 Revenuecat | 💰 Competitive | 📍 Remote Could you walk us through your experience with this tech stack? Tech Stack: . Since graduating from YC’s S18 batch we’ve grown into the default monetization platfor... 👉 Apply & View Full Salary 👉 View the full board of 50+ New Jobs here 🛑 Stop doing 7-round HR interviews. We hold direct contracts with hiring CTOs for high-ticket roles. Accept the architecture challenge, get your Instant AI Score, and bypass HR completely. 👉 Take the CTO Challenge
Designing a 12-Seat Voice Room: WebRTC/SFU, Server-Authoritative Coins, and Moderation
Fah Swe
Social voice rooms look simple: a grid of 10–12 mic seats, a chat strip, some gift animations. Underneath, they combine three hard problems — real-time media, money, and trust & safety. Get any one wrong and the room either lags, leaks money, or turns toxic. This post walks through a practical design for a multi-seat voice room: how to route audio, how to keep a virtual-coin economy honest, and how to build moderation into the architecture instead of bolting it on. With WebRTC you have three topologies: Mesh (P2P): every participant sends to every other participant. With 12 speakers, each client uploads 11 streams. Mobile uplinks and batteries give up fast. Fine for 1:1 or 3-person calls, not for rooms. MCU: the server decodes and mixes all audio into one stream per listener. Clients are cheap, but the server burns CPU on decode/mix/encode and you lose per-speaker control (volume, mute indicators, active-speaker detection on the client). SFU (Selective Forwarding Unit): each client uploads one stream; the server forwards packets to subscribers without decoding. This is the sweet spot for voice rooms. Open-source options include LiveKit, mediasoup, and Janus. A voice room naturally splits participants into publishers (people on mic seats) and subscribers (the audience). Only seated users get publish permission; everyone else is receive-only. That means a room with 12 seats and hundreds of listeners still has at most 12 upstream audio tracks. Practical tips: Opus with DTX (discontinuous transmission) cuts bandwidth when a speaker is silent, which is most of the time in a 12-seat room. Audio levels / active speaker events from the SFU drive the "speaking ring" animation around seats; don't compute it on each client from raw audio. Tokens, not trust: issue short-lived access tokens from your backend with explicit grants (canPublish, canSubscribe, room name, identity). When a user takes a seat, mint a new token or update permissions server-side. Never let the client decide it can publish. Scale by room, not by user: pin a room to one SFU node where possible; for very large audiences, cascade or relay to edge nodes. The seat grid is shared state: who is on seat 3, is seat 7 locked, is seat 5 muted by the host? Treat it like a tiny multiplayer game: RoomState { roomId, ownerId, mode, passwordHash?, seats: [ { index, userId|null, locked, mutedByHost } x 12 ], admins: [userId], version } All seat changes (take, leave, lock, mute, kick) go through the backend as commands. The backend validates permissions, applies the change atomically (e.g. a Redis transaction or a row lock), bumps version, and broadcasts the new state over your signaling/data channel. Clients render state; they never mutate it locally except for optimistic UI that gets reconciled. When a seat is lost, revoke publish permission on the SFU as well — UI state and media permissions must agree, or a kicked user can keep talking. Gifting is where money lives, so the rule is absolute: the client never computes balances. It sends intents; the server decides. A safe gift flow: Client sends SendGift { giftId, qty, toUserId, roomId, idempotencyKey }. Server looks up the gift price from its own catalog (never trust a price from the client). In one database transaction: check the sender's balance, debit sender, credit receiver (often in a different unit, e.g. coins → "diamonds" or points), and write immutable ledger rows. Commit, then publish a GiftSent event for animations and leaderboard updates. Design details that save you later: Double-entry ledger: every movement has a debit and a credit row. Balances are derived or cached, but the ledger is the source of truth. Auditing and dispute handling become queries, not archaeology. Idempotency keys: mobile networks retry. Without an idempotency key, a flaky connection turns one gift into three. Integer minor units: store amounts as integers; no floats. Leaderboards from events: hourly/daily/weekly rankings can be Redis sorted sets fed by GiftSent events, rebuilt from the ledger if needed. Keep them eventually consistent — the ledger stays strongly consistent. Payment webhooks: coin purchases should be credited only after a verified payment-provider webhook or receipt validation, not when the client says "payment succeeded." Rate limits and anomaly checks: cap gifts per second per user and flag unusual patterns (new account + large transfers) for review. Voice is harder to moderate than text because it is ephemeral. Build layers: Role model: owner → room admins → seated speakers → listeners. Encode it in the token grants and in the backend command checks. Host tools: mute seat, remove from seat, kick from room, lock seat, password-protect room, toggle chat or gift effects. Each action is a server command that updates both room state and SFU permissions. Text chat filtering: run messages through a filter service before broadcast; let listeners filter the chat view (all / messages / gifts) so gift spam doesn'
Deferred Deep Links in Flutter: Complete Integration Guide
LinkTrail
Flutter's go_router or uni_links-based setup gets you clean routing once a link actually reaches the app. That's the easy 90%. The part that quietly doesn't work by default on either platform is a new install: user taps a link, has no app, goes through the store, installs, opens — and Flutter boots to your normal initial route with zero memory of the link. This is the complete guide to wiring up both the direct and deferred cases in a Flutter app with LinkTrail, covering the Dart side and the native config both platforms still require underneath it. Direct link — app is already installed. Both iOS and Android hand the link to the native layer (Universal Link / App Link), and it needs to be routed into Flutter through a platform channel. Deferred link — app is not installed. Neither OS delivers anything on first launch — there's no event to catch, on either platform. Resolving it means matching against a server-side record from a signal captured at tap-time, which is a different mechanism from link routing entirely, not a Flutter-side gap. Flutter doesn't remove the native setup — it just needs to happen once, in each platform project, same as a fully native app. # pubspec.yaml dependencies: linktrail_flutter: ^1.1.0 flutter pub get android/app/src/main/AndroidManifest.xml <activity android:name=".MainActivity" android:exported="true" android:launchMode="singleTask"> <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="links.yourapp.com" /> </intent-filter> </activity> Serve assetlinks.json at https://links.yourapp.com/.well-known/assetlinks.json with your release-key SHA-256 fingerprint — a debug-keystore fingerprint here is the single most common reason this works in dev and silently fails in production. In Xcode, add the Associated Domains capability to the Runner target: applinks:links.yourapp.com Serve apple-app-site-association at https://links.yourapp.com/.well-known/apple-app-site-association, Content-Type: application/json, no redirects: { "applinks": { "details": [ { "appIDs": ["TEAMID.com.yourcompany.yourapp"], "components": [{ "/": "/*" }] } ] } } Both files need to exist and be correct before anything on the Dart side matters — if they're wrong, the OS never hands your app anything to resolve in the first place. import 'package:linktrail_flutter/linktrail_flutter.dart'; import 'package:flutter/material.dart'; Future<void> main() async { WidgetsFlutterBinding.ensureInitialized(); await LinkTrail.configure(apiKey: 'YOUR_LINKTRAIL_API_KEY'); runApp(const MyApp()); } class _MyAppState extends State<MyApp> { StreamSubscription<LinkTrailLink>? _linkSub; @override void initState() { super.initState(); // Fires for a link tapped while the app is already installed — // whether it was running in the background or launched cold by the tap. _linkSub = LinkTrail.linkStream.listen((link) { _routeFromLink(link); }); } @override void dispose() { _linkSub?.cancel(); super.dispose(); } } @overridevoid initState() { super.initState(); _linkSub = LinkTrail.linkStream.listen(_routeFromLink); // Resolves once, only on the first launch after install. // Safe to always call — it completes with null on every later launch. LinkTrail.getFirstOpenLink().then((link) { if (link != null) _routeFromLink(link); }); } linkStream is your ongoing listener for the app's lifetime; getFirstOpenLink is a one-shot future you check once at startup. Mixing them up — say, only checking getFirstOpenLink and never subscribing to the stream — means links stop working the moment a user has the app installed, which is a bug that's easy to miss in testing if you only ever test on a fresh install. void _routeFromLink(LinkTrailLink link) { switch (link.path) { case '/product': final id = link.params['id']; context.go('/product/$id'); break; case '/invite': final ref = link.params['ref']; context.go('/onboarding?referrer=$ref'); break; default: context.go('/home'); } } (Swap context.go for your router of choice — Navigator, auto_route, whatever the rest of the app already uses. The resolution logic above doesn't care.) Deferred linking is resolved natively under the hood even in a Flutter app, so test per-platform, not just once: Android direct: app installed, tap a link, confirm linkStream fires. Then background the app and tap again — confirm it still fires, not just on cold start. Android deferred: uninstall completely, tap the link, install via Play Store, open. Confirm getFirstOpenLink resolves. iOS direct: send yourself the link via Messages (not Safari's address bar — that doesn't trigger a Universa
I built a wellness app that is designed to be closed
Vikas Sahani
Most wellness apps earn more the more often you open them. That one fact explains a lot of their design: the streak you are afraid to break, the 9 pm notification, the red badge, the "you missed yesterday" screen. I wanted the opposite. An app that helps for a minute and then has no reason to pull you back. So I built AsanaPals, an offline Android app where five animal companions help you move, rest, energize, get unstuck or breathe. No account, no scores, no streaks, no reminders. This post is about the engineering side: how you make "it never phones home" a property of the build instead of a promise in a privacy policy. "No streaks" is easy to write and hard to keep if your revenue depends on daily active users. So the model decision came before the rest: Paid once on Google Play. No subscription, no ads, nothing sold inside the app. All five companions and every moment are included. If the app earns nothing from your time, there is no incentive to manufacture reasons for you to come back. Every technical decision below follows from that. On Android, an app without the INTERNET permission cannot open a socket. Not "chooses not to": cannot. That is a much stronger guarantee than careful code, because it also covers every dependency you pull in. The catch: plugins can bring the permission with them. video_player and url_launcher both declare network permissions for paths I do not use. So the release manifest strips them from the merged result: <!-- android/app/src/release/AndroidManifest.xml --> <uses-permission android:name="android.permission.INTERNET" tools:node="remove" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" tools:node="remove" /> <uses-permission android:name="android.permission.WAKE_LOCK" tools:node="remove" /> WAKE_LOCK goes too. ExoPlayer declares it for background playback, and nothing in the app plays in the background, so it is stripped rather than shipped unused. Debug and profile builds keep INTERNET, because Flutter's tooling attaches to the Dart VM over the network during development. Only release is locked. A tools:node="remove" line protects you until a dependency does something unexpected in the merge. So a Gradle task reads the merged release manifest, the one that actually ships, and fails the build if INTERNET survived: // android/app/build.gradle.kts abstract class VerifyNoInternetPermissionTask : DefaultTask() { @get:InputFile abstract val mergedManifest: RegularFileProperty @TaskAction fun verify() { val manifest = mergedManifest.get().asFile.readText() val declaresInternet = Regex( """<uses-permission\b[^>]*android:name\s*=\s*"android\.permission\.INTERNET"""", ).containsMatchIn(manifest) if (declaresInternet) { throw GradleException( "Release merged manifest declares the INTERNET permission, which breaks the " + "true-offline guarantee. Adding network capability must be a deliberate, " + "recorded decision.", ) } } } androidComponents { onVariants { variant -> if (variant.name == "release") { val verifyTask = tasks.register( "verifyReleaseNoInternetPermission", VerifyNoInternetPermissionTask::class.java, ) { mergedManifest.set(variant.artifacts.get(SingleArtifact.MERGED_MANIFEST)) } tasks.named("check").configure { dependsOn(verifyTask) } // Every release build runs it, not only `check`: the App Bundle // and the APK, however they are built. tasks.matching { it.name == "bundleRelease" || it.name == "assembleRelease" } .configureEach { dependsOn(verifyTask) } } } } The App Bundle and the APK both depend on the check, so it runs whether the release comes from my release script, a plain flutter build, or the IDE. I tested it the only way that counts: I put INTERNET back into the release manifest and ran a release build. It failed with the message above. The error message is deliberate. Whoever hits it next (probably me, in six months) learns that network access is a product decision, not a dependency bump. There is also a source-level half that runs with every flutter test: tests that fail if the strip lines are removed, if the main manifest ever grants INTERNET, or if the check is ever unhooked from the release builds. Some promises are about code, some are about copy. Both are tested in plain Dart: No network clients. A guard test scans lib/ and fails on any import of package:http, package:dio or package:google_fonts. Fonts, video, audio and art are bundled instead. Nothing for sale inside. A pricing guard fails on billing code and on trial, premium, upgrade or subscription copy. No pressure language. A copy guard fails on streaks, XP, levels, scores, badges, unlocks and "you missed" in UI strings. Rejecting them ("no streaks
Choosing an Android Stack That Survives Release Day
Uray Febri
For choosing an android stack that survives release day, the useful Managing Context Window Limitations In Ai is visible here: A phone, laptop, and build blocks arranged for choosing and releasing an Android stack. When a development team starts a new mobile project, the conversation almost immediately turns to technology choices. Engineers debate whether to write native code in Kotlin, maintain legacy Java systems, or adopt Flutter for cross-platform delivery. Too often, the decision rests entirely on personal preference, general industry hype, or surface-level feature comparisons. This approach creates severe vulnerabilities later in the project lifecycle. Teams encounter silent build failures, unexpected dependency conflicts, and frustrating compilation errors just weeks Audit Macos System Data Before Deleting scheduled store deployment. The primary question is how a technical team should choose between Kotlin, Java, and Flutter, and then keep the resulting Android build, dependencies, and release path reliable from day one to launch. The answer lies in evaluating architectural constraints early, maintaining strict visibility into the Gradle dependency graph, and testing the final Android App Bundle rather than an idealized debug build. This guide establishes a rigorous decision framework, walks through a real dependency conflict investigation, outlines dependency injection boundaries, configures optional services safely, and establishes a definitive release checklist for production. Selecting a foundational technology requires mapping architectural constraints against real project realities. The three primary paths for Android development carry distinct trade-offs regarding language features, platform depth, maintenance overhead, and compilation targets. When teams attempt to choose without an explicit framework, they frequently discover mid-development that their chosen stack cannot support vital platform APIs or cross-platform targets without rewriting core modules. The following decision matrix evaluates native Kotlin, legacy Java, and Flutter across critical operational dimensions. This table provides a baseline for weighing architectural constraints against team capabilities without relying on arbitrary scoring numbers or fake precision. Evaluation Dimension Native Kotlin Legacy Java Flutter Trade-Off Summary Language Modernization Null safety, coroutines, extension functions, modern idioms. Verbose syntax, older language level, requires heavy boilerplate. Dart language with sound null safety, async/await, modern syntax. Kotlin and Dart offer rapid developer velocity; Java incurs ongoing maintenance debt. Platform Depth & APIs Direct, day-one access to new Android SDK features and Jetpack libraries. Full access to older Android SDKs, but modern Jetpack libraries require Kotlin. Indirect access via platform channels or official federated plugins. Native Kotlin provides immediate alignment with platform evolution. Multi-Platform Scope Android-first, with growing Kotlin Multiplatform capabilities for logic. Android-only unless paired with fragmented multi-platform libraries. Single codebase targeting Android, iOS, web, and desktop environments. Flutter trades native platform nuance for cross-platform code reuse. Build & Tooling Overhead Standard Gradle setup, Kotlin compiler plugin tuning, Jetpack tooling. Mature Gradle setup, highly stable, but lacks modern compiler optimizations. Flutter SDK, Dart VM, pub package manager, separate Gradle bridge. Flutter introduces a secondary build ecosystem alongside Android tooling. Team Familiarity Impact Low friction if the team knows modern Android or JVM ecosystems. Extremely high familiarity for legacy maintenance, low for modern features. Requires learning Dart and widget trees, even for experienced native devs. Training time varies based on whether engineers transition from JVM or web backgrounds. Using this matrix prevents teams from choosing a stack based solely on popularity metrics. If an application requires deep, low-level hardware integration and immediate adoption of upcoming Android system APIs, native Kotlin remains the most direct route. If an enterprise team maintains millions of lines of stable Java code with strict compliance requirements, forcing a rewrite is often riskier than maintaining the legacy stack. If a business needs identical user interfaces on both iOS and Android with a modest engineering headcount, Flutter provides a cohesive architecture that outweighs native UI duplication. Once a technology stack is selected, the build system becomes the primary gatekeeper of project health. Gradle manages dependencies, compiles code sources, and bundles assets into deployable packages. However, adding third-party libraries without inspecting the dependency graph is a common path to catastrophic build failures. Dependency resolution engines automatically select version increments when transitive conflicts occur, which can s
Building a Zero-Telemetry Android Vault: Flutter, Encrypted SQLite, and Why We Ditched Cloud Sync
Asiv
When building personal finance software, standard engineering advice says: "Spin up Supabase, plug in Plaid for automatic bank scraping, and charge $12/month." We rejected that premise entirely when architecting MyneWallet. Handling money data requires extreme operational discipline. If your remote server stores a user's transaction ledger, you are one zero-day exploit, misconfigured S3 bucket, or sub-processor breach away from exposing their entire financial identity. Here is the engineering breakdown of how we built an offline-first, zero-telemetry financial vault in Flutter—handling decimal currency math without floating-point errors, deterministic envelope allocation, and client-side web verification. The Core Constraint: Zero Network Permissions The cleanest way to guarantee data privacy is architectural, not legal: No Firebase SDKs. No Mixpanel, Segment, or analytics beacons. No network requests carrying payload figures. Every ledger write, balance reconciliation, and category balance calculation runs strictly inside an on-device SQLite database encrypted with SQLCipher. [User Device] Handling Currency Math Without Floating-Point Traps In financial software, standard IEEE 754 floating-point operations (0.1 + 0.2 = 0.30000000000000004) are unacceptable. Over multi-year ledgers with thousands of line items, floating-point rounding errors compound into balance drift. To guarantee precision, all monetary values in our SQLite database are stored as 64-bit Integers representing minor units (cents): Dart const Money(this.minorUnits); Money operator +(Money other) => Money(minorUnits + other.minorUnits); String toFormattedString(String currencySymbol) { The Envelope Allocation Engine Under a True Zero-Based Budgeting (ZBB) model, every single unit of income must be assigned a job before the month begins: 💡 The Core Equation: To Assign = Unallocated Cash − Total Assigned Envelopes When income arrives, our deterministic Auto-Assign engine allocates funds through a three-stage priority pipeline: Fixed Monthly Obligations: Rent, utilities, debt minimums. Sinking Fund Targets: Amortized monthly allocations for annual commitments. Flexible Spending: Groceries, personal allowances, dining. If a category overspends, the ledger flags the exact variance and prompts the user to reallocate from another envelope, keeping the core ledger balanced to zero. Client-Side Web Companion & Open Methodology Alongside the mobile app, we built 10 standalone client-side financial calculators that run in the browser without cookies, tracking scripts, or server requests: Web Suite: https://thebrinklabs.com/tools/ Formulas & Verification Gates: https://thebrinklabs.com/methodology Every formula, rounding rule, and mathematical test case is published openly, allowing users to verify our math directly in their browser's Network tab before downloading the mobile app. Conclusion & Open Discussion Google Play: https://play.google.com/store/apps/details?id=com.thebrinklabs.mynewallet.expensetracker Architecture Docs: https://thebrinklabs.com/ How are other indie developers handling local encrypted storage and offline state management in Flutter? Let's discuss in the comments below!
freeCodeCamp
15 条教程、指南与实践文章
How to Build a Dart Package Analytics Tool with the pub.dev API: Beyond the 30-Day Window
Oluwaseyi Fatunmole
When I published my package on pub.dev, the first few days were exciting as the number of downloads climbed. 201 downloads in a few days! Then something strange happened. The number dropped: 120, then
How to Implement LEGO Architecture in Flutter [Full Handbook]
Atuoha Anthony
Almost everyone has snapped two LEGO bricks together at some point, even without owning a single set as an adult. You press one brick down onto another, feel it click, and it holds. You likely never o
How to Use Skills in Agentic Flutter Development: A Handbook for Devs
Atuoha Anthony
One of the biggest misconceptions about AI-assisted development is that using AI means giving up the engineering experience you've built over the years. It doesn't. You can take the architecture patte
How to Test Flutter Apps: Unit, Widget, Golden, and Integration Tests Explained
Gidudu Nicholas
The first time I was asked "what's your test coverage?" in a technical interview, I didn't have a good answer. I had shipped a couple of real Flutter apps by then. They worked and users were using the
Mobile Background Execution: iOS Background Modes, Android WorkManager, and Background Services in Dart
Oluwaseyi Fatunmole
Every mobile developer eventually hits the same wall: the app works perfectly when the user is looking at it. But the moment they press the home button, everything stops. A sync that should have compl
Chain of Responsibility Design Pattern: Decoupling Complex Business Rules, One Handler at a Time
Oluwaseyi Fatunmole
Every system, at some point, ends up with a function that nobody wants to touch. It starts small: a simple validation check, an if statement here, another there. Then requirements grow and more condit
How to Work with Material and Cupertino Decoupling in Flutter [Full Handbook]
Atuoha Anthony
Earlier this year, I published Decoupling Material and Cupertino in Flutter, which covered what was then a preview feature: Flutter's plan to separate the Material and Cupertino design libraries from
How to Automate Flutter Releases with Fastlane and GitHub Actions for Firebase App Distribution, Google Play, TestFlight, and App Store Connect
Atuoha Anthony
Picture this: it's 4pm on a Friday, and your team has just merged the last feature for the sprint. But your product manager asks for a new build on TestFlight by the end of the day so the client can r
Flutter Frontend Systems Design: How to Think Like a Senior Engineer in the AI Age
Jesutoni Aderibigbe
Systems design has always been treated as a backend problem. Ask a group of Flutter engineers what systems design means, and most will describe server architecture: load balancers, databases, and micr
How to Test AI Features in Flutter [Full Handbook]
Atuoha Anthony
You've spent two weeks building an AI assistant. The streaming chat looks beautiful, the system prompt is tight, and safety filters are configured. You demoed it to the team, and everyone was impresse
A Deep Dive into Behavioral Patterns: The Visitor Design Pattern and its Clean Operations Across Complex Object Structures
Oluwaseyi Fatunmole
There's a problem that shows up in almost every growing software system, and most developers don't even realize they're hitting it until the damage is already done. You have a set of objects: differen
Bluetooth Low Energy in Flutter: A Handbook for Devs
Nikheel Vishwas Savant
Most Flutter tutorials stop at network calls and REST APIs. The moment you need to talk to a physical device, a heart rate monitor, a smart bulb, a fitness tracker, an industrial sensor, or your own c
From RPC to gRPC: Understanding Remote Procedure Calls, Protocol Buffers, and Modern Distributed Systems Communication
Oluwaseyi Fatunmole
Every application, at some point, needs to talk to another system. A mobile app talks to a backend. A backend service talks to a payment gateway. An authentication service talks to a user service. A d
The Observer Design Pattern Handbook: Event-Driven Architecture & Domain-Driven Design in Dart
Oluwaseyi Fatunmole
Every application, at some point, has to deal with a fundamental challenge: something happens, and several other things need to react to it. A user logs in, and the app needs to save a token, cache th
How to Fix App Jank: A Practical Guide to Profiling Flutter Apps with DevTools
Gidudu Nicholas
Flutter makes it fast to build beautiful UIs. That speed is one of the framework's greatest strengths, but it also creates a subtle problem: performance issues are easy to introduce and difficult to f
Hacker News
20 条技术社区讨论与项目链接
Show HN: I compiled FreeRDP into a Flutter app so my phone can do RDP and SSH
neil_thomas
Hi HN, I'm the developer. XConnect is an SSH/SFTP client for iOS and Android that also has a real RDP client built in, so one app covers my Linux and Windows machines when I'm away from my desk. No account needed: tap "Continue Offline" and everything stays on the phone. I built it because fixing things from my phone meant switching between an SSH app, a file app and Microsoft's RDP app, and on a small screen the switching was the worst part. What it does: - SSH and Telnet, with a key row for phone keyboards (Esc, Tab, arrows, sticky Ctrl/Alt, one-tap Ctrl-C/D/L/Z) and multiple sessions. - RDP (iOS for now). FreeRDP 3 is compiled into the app, so the phone speaks RDP directly, with no gateway or relay. Trackpad or direct-touch mode, pinch to zoom, two-finger right-click and scroll. Hardware keyboards are forwarded by scancode. - SFTP, jump hosts (ProxyJump-style, for both SSH and SFTP), and 14 built-in scripts you can run on a server with one tap. - An optional AI agent with your own API key (OpenAI-compatible endpoints, Anthropic, or Ollama on your LAN). It runs commands on the host and asks before anything that looks destructive. It does nothing until you configure it. Some technical details: the native RDP core sends Dart one event per frame (connected / bitmap / resize / error / disconnected), in the same binary format my desktop app's RDP helper uses. Dart applies the updates to an RGBA framebuffer and paints it with decodeImageFromPixels. SSH is dartssh2 and the terminal is xterm.dart. Scripts run as heredocs, because my first version joined the lines with "; " and put the whole script behind the shebang comment. Credentials: passwords and private keys are stored in the iOS Keychain / Android Keystore. Sync is optional. Records are encrypted on the device with AES-256-GCM before upload, with a key derived from your account password (PBKDF2, then scrypt per record). To be upfront: login currently sends that password to the server over TLS, so this is not zero-knowledge yet. [Switching login to a separately derived auth hash is next on my list.] The app is closed source. I know that's a hard sell for something that holds SSH keys, so ask me anything about how credentials are handled. Not there yet: RDP on Android, port forwarding on mobile (the desktop app has it), passphrase-protected keys, keyboard-interactive 2FA, and mosh. Pricing: SSH, Telnet, SFTP, scripts and one jump host are free. Pro ($8/month, $68/year, or $88 one-time) adds RDP, the AI agent, sync and unlimited jump hosts. The same account also works in the desktop app for Windows, macOS and Linux. iOS: https://apps.apple.com/us/app/xconnect-ssh-rdp-client/id6810... I'd love feedback, especially from people who manage servers from their phone. What's missing? Comments URL: https://news.ycombinator.com/item?id=49758100 Points: 4 # Comments: 0
PPPlayer – An open-source music player built with Flutter
lucasveneno
Article URL: https://ppplayer.com Comments URL: https://news.ycombinator.com/item?id=49748159 Points: 3 # Comments: 1
I ported a VB6 game to Flutter and generated all 14 art themes
lioil
Article URL: https://apps.apple.com/cz/app/kirian/id6774868017 Comments URL: https://news.ycombinator.com/item?id=49643435 Points: 3 # Comments: 0
Kelivo: A Flutter LLM Chat Client. Support Mobile and Desktop
xbmcuser
Article URL: https://github.com/Chevey339/kelivo Comments URL: https://news.ycombinator.com/item?id=49639819 Points: 2 # Comments: 0
Arch Linux on a OnePlus 12R, Powered by Denial Wayland and Flutter Compositor
dazhbog
Article URL: https://www.reddit.com/r/mobilelinux/comments/1w80kvt/arch_linux_on_a_oneplus_12r_powered_by_the_denial/ Comments URL: https://news.ycombinator.com/item?id=49607677 Points: 1 # Comments: 0
Show HN: CocoCut – A zero-cloud, 1-second video diary engine built with Flutter
xcc3641
Article URL: https://cococut.app/en Comments URL: https://news.ycombinator.com/item?id=49582167 Points: 2 # Comments: 1
DartNative: Beyond the Limits of React Native and Flutter
iosephmagno
Hi React Native and Flutter devs! We’re launching DartNative, a cross-platform framework for Dart that aims to deliver a truly native look and feel on iOS and Android. Would love to hear what you think. https://x.com/iosemagno/status/2096288716721356974?s=46 Comments URL: https://news.ycombinator.com/item?id=49579471 Points: 1 # Comments: 0
GoEven – Free, ad-free group expense splitter built with Go, gRPC, and Flutter
Xainpro
Article URL: https://goeven.app Comments URL: https://news.ycombinator.com/item?id=49578979 Points: 2 # Comments: 0
Show HN: Flutter Starter A production-ready Flutter app boilerplate
Harish_0089
Article URL: https://github.com/GeekyAnts/flutter-starter Comments URL: https://news.ycombinator.com/item?id=49432329 Points: 3 # Comments: 0
Flutter_scene 0.21.0 runs 3D apps with Flutter GPU and Impeller
chem83
Article URL: https://xcancel.com/antibot/captcha Comments URL: https://news.ycombinator.com/item?id=49307343 Points: 1 # Comments: 0
Flet: Build cross-platform apps in Python, on top of Flutter
theanonymousone
Article URL: https://flet.dev/ Comments URL: https://news.ycombinator.com/item?id=49283154 Points: 1 # Comments: 0
Flutter 3.47
gumby271
Article URL: https://flutter.dev/blog/whats-new-in-flutter-3-47 Comments URL: https://news.ycombinator.com/item?id=49280061 Points: 207 # Comments: 214
I built a local 3D marketplace with pizza-style tracking in Flutter
Nearnook_dev
Article URL: https://play.google.com/store/apps/details?id=com.lahoucintiyar.nearnook&hl=en_US Comments URL: https://news.ycombinator.com/item?id=49277267 Points: 1 # Comments: 0
Openhare: AI-powered desktop SQL client. Cross-platform. Built with Flutter
thunderbong
Article URL: https://github.com/sjjian/openhare Comments URL: https://news.ycombinator.com/item?id=49276189 Points: 4 # Comments: 0
FieldFleet – self-hostable field operations built with Flutter and Supabase
iguardo
Article URL: https://taskfleetai.github.io/fieldfleet/ Comments URL: https://news.ycombinator.com/item?id=49262555 Points: 3 # Comments: 0
Flutter desktop apps can draw to multiple windows now
matthewkosarek
Article URL: https://www.youtube.com/watch?v=yXj6HGTgKX0 Comments URL: https://news.ycombinator.com/item?id=49243250 Points: 2 # Comments: 0
Denial WM: New Wayland Compositor with Flutter Directly Embedded
mikece
Article URL: https://www.phoronix.com/news/Denial-WM-Compositor Comments URL: https://news.ycombinator.com/item?id=49184965 Points: 4 # Comments: 0
Rejourney Flutter Analytics in Beta: Session Replay for Flutter GPU and Impeller
mrr7337
Article URL: https://rejourney.co/engineering/2026-08-01/flutter-sdk-open-beta Comments URL: https://news.ycombinator.com/item?id=49162055 Points: 1 # Comments: 0
I made Squirrel game with Flutter and Flame
dmvvilela
Article URL: https://danvilela.com/squirrel-up Comments URL: https://news.ycombinator.com/item?id=49137413 Points: 5 # Comments: 0
Kaisel – Routes as Values. Dart 3 Native Router for Flutter
TheWiggles
Article URL: https://kaisel.dev/ Comments URL: https://news.ycombinator.com/item?id=49135985 Points: 58 # Comments: 11
Medium
10 条Flutter 相关文章精选
Which Plugin Is Breaking Your Flutter Android Build? Meet android_build_doctor
Zain ul Abideen
One command checks Java, Gradle, AGP and Kotlin against your Flutter version, finds the plugins blocking AGP 9, explains Gradle errors in… Continue reading on Medium »
Idea to mobile mockup in two hours
Danielle H
A stakeholder-ready mobile mockup, built and deployed before your next status update Continue reading on Medium »
Flutter Provider vs InheritedWidget
Ahmed Aly
In Flutter, InheritedWidget is the low-level mechanism used to efficiently share data with widgets lower in the widget tree. Continue reading on Medium »
I Put a 3D Earth Inside a Flutter App
Ankit Mehra
I have built a lot of Flutter interfaces over the years but most of them follow familiar patterns: lists, cards, dashboards, animations… Continue reading on Medium »
Riverpod: StateNotifier vs Notifier
Ahmed Aly
Both StateNotifier and Notifier are used to manage state and contain the logic that changes that state. Continue reading on Medium »
Altman and Amodei Tell the UN They’ll “Slow Down AI” — Top 10 AI & Flutter News September 27, 2026
Blur Brah Lab
Claude / Anthropic Continue reading on Medium »
What Really Happens When a Widget Rebuilds?
Gichira
Three trees, one misunderstood method, and the truth about setState() Continue reading on Medium »
Benchmarking view_model Against Flutter's Architecture Samples
wenjie
I maintain view_model, a Flutter state-management package built around a simple idea: everything is a ViewModel, with automatic lifecycle… Continue reading on Medium »
What Really Happens When a Widget Rebuilds?
Developer Hub
Stop using Flutter. Start understanding Flutter. Continue reading on Flutter Hub »
How I Build and Ship Production Android Releases in Flutter
Rafli Ramadhan
Every time I finish building a new feature set and all my tests pass, I prepare for that exciting moment: shipping a fresh build to users… Continue reading on Medium »
社区日榜讨论与资源
How a rejected 2019 Flutter PR forced Riverpod to leave the widget tree
/u/RandalSchwartz
Most of us know Provider was built on InheritedWidget, but I recently revisited the exact mechanical reason Rémi had to abandon it to create Riverpod. It comes down to a fundamental design choice in dependOnInheritedWidgetOfExactType: the Flutter framework never unregisters a dependency once registered. If you read state conditionally behind an if check, that element stays locked in InheritedElement._dependents until it unmounts. Even after the condition flips to false, that widget keeps rebuilding on every single ancestor change forever. In May 2019, Rémi opened PR #33213 to add an unlisten hook to InheritedElement. Hixie closed it to avoid adding overhead to the hot reconciliation loop. Because Provider had no way to know when widgets stopped listening, autoDispose was impossible—forcing Rémi to hoist state completely out of the tree. Looking back, it’s wild how much of the state management wars over the last five years really just came down to working around that one framework limitation. Did you ever run into those conditional "ghost rebuilds" in Provider back in the day? submitted by /u/RandalSchwartz [link] [comments]
I ended up building an audio fingerprinting package for Flutter
/u/hirdayashrestha
After working on hAudiotagger for a while, I kept running into a slightly different problem. Reading metadata is useful, but metadata isn't always trustworthy. Two files can have completely different filenames, missing tags, different containers, or even different encodings and still contain the same recording. For example: 01 - Unknown.mp3 Track_17.m4a song_copy.flac The Song (Remastered).mp3 Comparing their filenames or tags doesn't really help if the goal is figuring out whether the underlying audio is the same. So I built haudiotagger_fingerprint for that part. It generates perceptual audio fingerprints and lets you compare them by the actual audio content: final a = await HaudioFingerprint.fingerprint('song.mp3'); final b = await HaudioFingerprint.fingerprint('song_copy.mp3'); final similarity = await HaudioFingerprint.similarity(a, b); The fingerprints are Chromaprint-compatible, so this is in the same ecosystem as fpcalc / AcoustID rather than a simple file hash. The idea is that two byte-for-byte different files can still produce fingerprints that are very similar when they contain essentially the same recording. It currently supports: MP3 FLAC Ogg Vorbis WAV AIFF M4A / AAC / ALAC and runs on Android, iOS, Linux, macOS, Windows and Web. The interesting part for me was getting the whole thing into Rust, while still making it usable as a normal Flutter package. Web support also works through WASM. I'm mainly thinking about use cases such as: finding duplicate tracks in a local music library detecting copies that were renamed finding re-encoded versions of the same recording cleaning up large music collections matching recordings when metadata is missing or unreliable I deliberately kept it separate from hAudiotagger rather than making the metadata package itself depend on fingerprinting. If you only need metadata, you shouldn't have to pull in fingerprinting as well. There is also an optional integration between the two packages, so if both are installed, fingerprinting can be accessed through Haudiotagger directly. I'm curious how other people handling local music libraries approach this problem. Do you normally rely on filename + metadata, file hashes, Chromaprint, or something else? Pub.dev - haudiotagger_fingerprint GitHub - Source submitted by /u/hirdayashrestha [link] [comments]
I built a Flutter package where pinch-to-zoom makes text longer instead of bigger
/u/No-Examination-3876
A while ago I saw a demo by Natko Hasic of a journal app where pinching the list didn't scale the text, it revealed more of it. I couldn't stop thinking about it, so I built it as a Flutter package. Pinch out and each entry grows from a title to a summary to the full text. Words already on screen slide to their new positions and new words fade in around them. Pinch in to skim again. A few things that were harder than expected: - Gestures: ListView's drag recognizer wins the arena before a scale recognizer sees the second finger, so I ended up tracking raw pointers. - Keeping your place: as entries above your fingers grow, everything gets pushed away. I fixed it with a custom sliver that corrects the scroll offset during layout, so the item under your fingers doesn't move at all. - AI summaries: the three versions don't have to be exact word subsets. Shared words slide, and rephrased ones cross-fade. It also supports tapping a single entry, trackpad/web pinch, keyboard shortcuts, screen reader actions, reduce motion and RTL. MIT licensed. - Live demo (runs in the browser): roshendz.github.io/semantic_zoom - pub.dev: pub.dev/packages/semantic_zoom - GitHub: github.com/Roshendz/semantic_zoom It's 0.1.0, so I'd really appreciate feedback on the API, especially from anyone with a real use case (notes, health timelines, inbox-style apps). What would you change? submitted by /u/No-Examination-3876 [link] [comments]
hiblob — I made deterministic avatars from any string
/u/Sad_Cranberry_927
I got tired of gray circles for user avatars, so I built a package that generates a little blob creature from any string email, username, whatever. Same name always gets the same blob, forever. const Hiblob(name: user.email, size: 64) I gave them 12 shapes, 16 expressions, mouths, glasses, blush — all decided by the name. I also added optional animation, and an SVG export since I sometimes need avatars on the server side. No assets, no network, pure Dart. pub.dev: https://pub.dev/packages/hiblob GitHub (MIT): https://github.com/igu1/hiblob Would love some feedback! 🙌 submitted by /u/Sad_Cranberry_927 [link] [comments]
FAQ