24小時情報的資料來自哪些管道？

Hey everyone! 👋 I've been reading articles on DEV for a while, and I figured it was finally time to properly introduce myself to the community. My name is Muhammad Uzair, and I am a Senior Flutter Developer and Mobile Engineering Team Lead. I specialize in architecting high-performance, cross-platform applications for both iOS and Android. Over the years, I've focused heavily on building scalable, production-ready mobile applications. My core stack and expertise include: Flutter & Dart: Building beautiful, natively compiled applications from a single codebase. Clean Architecture: I am a big advocate for writing scalable, maintainable, and highly testable code. Backend & AI Integration: Extensive experience working with Firebase and integrating AI capabilities directly into mobile workflows. I strongly believe in giving back to the developer community. I actively contribute to open-source projects on GitHub (including apps like Spotube) and publish Dart packages on pub.dev (like tag_field). I recently put together a brand-new website to showcase my recent projects, case studies, and the mobile engineering work I'm most proud of. I would love for you to take a look, explore my work, and let me know what you think about the design! 🔗 Visit my portfolio at uzairxdev.online If you're also working with Flutter, building mobile apps, or just want to talk about software architecture, drop a comment below or connect with me. I'd love to hear what everyone is building this week! Happy coding! 💻

fluttermobileopensourcecareer

10/05 上午03:16

What is Flutter app development?

Anas Kanafani

Flutter is a framework from Google for building applications that run on mobile, web, and desktop from a single set of code. Instead of building separate apps for iOS and Android, your team can build one app that works on both. This approach can help you reach your users faster and more consistently across different devices. The Flutter documentation states that thousands of organizations use it for production apps. Flutter is an open-source framework, managed by Google, for building natively compiled applications from a single codebase. The Flutter documentation describes it as a way to build apps for mobile, web, desktop, and embedded devices. This means you can write your application once and deploy it to your users on iOS and Android devices, and even their web browsers. The main reason businesses choose Flutter is efficiency. Building one application instead of two separate ones for iOS and Android saves time and reduces development costs. It also means your features and updates reach all your users at the same time. This single codebase helps create a consistent user experience and brand identity, no matter what device a person is using. Flutter is not just for small projects. Its own documentation states that thousands of organizations, from new startups to large enterprises, use Flutter to build apps for hundreds of millions of users. This wide adoption shows that the framework is a reliable choice for serious business applications. 9.4% According to the Stack Overflow Developer Survey, 9.4 percent of professional developers reported extensive development work in Flutter. Flutter works by giving developers a complete toolkit to build user interfaces. Flutter's architectural overview describes it as a cross-platform UI toolkit that allows code reuse across operating systems like iOS and Android. This single-codebase approach is what helps ensure your app's design and user experience are consistent on every device. For release, Flutter applications are compiled directly to machine code, or to JavaScript when targeting the web. The compilation to machine code gives them excellent performance, similar to an app built using the device's native language. This is a different approach from standard web application development, but it allows a single team to support both mobile and web users. During development, Flutter offers a feature called stateful hot reload. This allows developers to make changes to the code and see the results on a test device almost instantly, without losing their place in the app. This speeds up the process of fixing bugs and adding new features. The decision between Flutter and building separate native apps depends on your specific goals. We help you make this choice during discovery, based on your performance needs, budget, and timeline. Flutter is often the best choice when you want to launch on both iOS and Android quickly, or when maintaining a consistent brand and user experience across platforms is a high priority. Building two separate native apps gives you the absolute closest integration with each platform's unique features and design conventions. However, this requires two separate development teams, or one team with two different skill sets, which can increase time and cost. Flutter provides a way to get very close to native performance and feel, but with the efficiency of one team and one codebase. We can build native Android apps, native iOS apps, or a shared cross-platform build. We do not default to one technology. Instead, we recommend the approach that best fits your business goals. For many businesses, Flutter offers the right balance of performance, consistency, and development speed. You can read more in our guides on mobile app development. For a typical custom build, we usually plan for 6 to 12 weeks from the project kickoff to having the application live. The exact timeline for your project will depend on its complexity, such as how many other systems it needs to connect with, how much data needs to be moved from older systems, and whether it needs to work offline for teams in the field. You will not have to wait until the end to see progress. On a custom build, you see a demo of the running software every 2 to 3 weeks. These regular check-ins allow you to give feedback and ensure the project is heading in the right direction, making it easy to adjust course while changes are still simple to make. Once we agree on the project plan, the dates we set become the milestones for payment. You will have a clear schedule of what to expect and when. A successful app is built on a clear and disciplined process. Every project we run includes discovery and scoping, regular demos, user acceptance testing, security testing, full documentation, and support after launch. This structure applies whether the project is large or small. We start by producing a written scope that details what the system needs to do, who will use it, and what it connects to. You approve this docume

fluttermobilesoftwaredevelopmentprogramming

10/05 上午03:07

Hey Dev.to, I'm Aditya, a Laravel dev from India

Aditya Yogi

Hey everyone 👋 I'm Aditya, a Laravel and Flutter developer from India. This is my first post here, so let me quickly tell you who I am. What I do I've been working with PHP and Laravel for 5+ years, mostly on SaaS products, REST APIs and business web apps. Lately I've been building mobile apps with Flutter too. What I'm working on TrendsWheel: my tech blog where I write about Android, apps, cybersecurity and tech news from India. A Flutter app: it's live on Google Play, and I'm planning to build more on top of it. A few side ideas: small tools and a puzzle game. Let's see which one survives 😄 What I'll write about here Laravel tips from real projects, Flutter things I learn the hard way, SEO and indexing mistakes (I'm learning that one in public right now), and building small products from India. Let's connect If you work with Laravel or Flutter, or you're also building something on the side, say hi in the comments. I'd love to know what you're working on. My blog: https://trendswheel.com Thanks for reading!

introductionlaravelflutterwebdev

10/05 上午01:49

Show DEV: EchoPod — Learn Languages with Real Podcasts, AI Transcripts & Translations

huang lizhuo

I built EchoPod — a Flutter app that turns real podcasts into immersive language lessons. AI Transcripts — every episode gets a word-level transcript with precise audio sync Tap-to-translate — tap any word or phrase to translate it instantly, with support for 150+ languages Real content — learn from actual podcasts (not textbook dialogues), across topics you already care about Offline — download episodes and transcripts for learning on the go Built with Flutter for iOS and Android, using a clean architecture with Riverpod for state management, Drift for local SQLite storage, and a Supabase backend. Transcription runs through Groq API (Whisper large-v3-turbo) with Cloudflare Workers handling the AI pipeline and Podcast Index proxying. I wanted to learn languages through content I actually enjoy — podcasts about tech, culture, and life — not scripted lessons. The closest tools either didn't have transcripts, didn't sync well with audio, or charged a subscription for basic translation features. EchoPod is free on both platforms: iOS: https://apps.apple.com/jp/app/echopod/id6754240584 Android: https://play.google.com/store/apps/details?id=com.clothpath.echopod Would love feedback from the DEV community — especially on the Flutter architecture, the transcript-sync UX, or anything that feels off. Built by ClothPath.

languagelearningflutteraimobile

10/04 下午07:44

Why field apps need offline-first storage, not a better network

PRS CloudTech

Every few months a team asks us to "fix the sync" on an app that works perfectly in the The default way to build a mobile app is to treat the server as the source of truth. The Then you give it to someone collecting data in a basement, a warehouse, a rural clinic or Teams respond by adding retries, then a longer timeout, then a queue bolted onto the Offline-first inverts the relationship. The device's local database is the source of truth The practical consequences: The UI never waits on the network. Reads and writes hit local storage, so the app is as fast in a dead zone as on wifi. Connectivity becomes a status, not an error. "3 items pending" is information. A failed request with a red toast is an interruption. The user's work is never lost. It was written to disk before anything was attempted over the wire. Anyone can cache reads. The difficulty is writes, and specifically conflicts. You need stable IDs generated on the device. If the server assigns the primary key, the You need every write to be idempotent. The device will retry. If a retry creates a You need a conflict rule decided by the business, not the code. Two people edited the You need a real queue, with ordering. If a record is created and then updated while Schema changes. A device that has been offline for three weeks is running the old schema This means local migrations need the same discipline as server migrations — versioned, Offline-first is real engineering effort and it is not always warranted. If your app is The question worth asking is not "could this work offline" but "what does the user lose if For apps where field use is real, we build with a local database as the primary store, The test is simple and worth running before launch: put the device in airplane mode, use the PRS CloudTech builds mobile apps, websites, ERP, CRM and

fluttermobilearchitecturesoftwareengineering

10/04 下午02:30

React Native vs. Flutter vs. Native: Why Cure.fit Rebuilt Its Navigation From Scratch

Ciphemic academia

React Native vs. Flutter vs. Native: Why Cure.fit Rebuilt Its Navigation From Scratch Cure.fit, the Indian fitness platform, had built its app on React Native since day one. Then they hit a wall that kept showing up in the same place: animations. The bottom navigation bar, the kind of UI every user touches constantly, never felt right, and the team traced the problem specifically to React Native's architecture. Their fix wasn't a patch, it was rebuilding the entire bottom navigation layer in Flutter, piece by piece, until the whole experience ran noticeably smoother. A separate, independent benchmark that rewrote the same simple app three times, once native, once in Flutter, once in React Native, measured Flutter's memory footprint at 23MB against React Native's 27MB, with the native version at 14MB, a real, measurable gap between all three, not just a feeling. These two data points capture the actual decision you're making when you pick a mobile stack: not "which one is popular," but how much of that 14MB-to-27MB gap your specific app can afford to give up in exchange for faster, cheaper development. This guide compares all three honestly, what each one actually does under the hood, where the real numbers come from, and how to decide before you've built a year of app on an architecture you'll later have to rebuild, the way Cure.fit did. If mobile fundamentals are still new ground, our Mobile Engineering roadmap covers what this comparison builds on. This post originally appeared on the Ciphemic Academia blog. Native development (Swift/Kotlin, separately for iOS and Android) gives you the best possible performance and full platform access, at the cost of building and maintaining two separate codebases. React Native renders using actual native platform widgets, controlled from JavaScript through a "bridge," letting web developers reuse familiar skills, with real architectural overhead exactly where Cure.fit hit its wall. Flutter draws its own UI from scratch using its own rendering engine, skipping native widgets entirely, which gives it more consistent performance across platforms, at the cost of a less familiar language (Dart) for most teams. If you want one default: start with React Native if your team already knows JavaScript/React, start with Flutter if you're optimizing for consistent performance and don't mind learning Dart, and go native only once you have a specific, measured reason the other two can't satisfy. Before the differences, the shared problem, since this is what every mobile approach is answering: Rendering a UI people can touch and interact with smoothly: all three ultimately have to draw pixels and respond to touch with low enough latency that it feels instant Accessing device capabilities: camera, GPS, push notifications, sensors, every approach needs a path to the platform's native APIs Shipping to both iOS and Android: even "native" development means solving this problem twice, just with two separate codebases instead of one Keeping development sustainable over time: all three need to remain maintainable as a team and a codebase grow, not just work well on day one The real difference is architectural: how each approach gets from your code to pixels on the screen, and that architecture is exactly where Cure.fit's animation problems and the thoughtbot benchmark's memory numbers both originate. What it actually is: building genuinely separate apps for iOS (typically Swift) and Android (typically Kotlin), each using the platform's own UI framework and talking directly to the operating system with no intermediate layer at all. A small example (a button, Swift): let button = UIButton(type: .system) button.setTitle("Checkout", for: .normal) button.addTarget(self, action: #selector(checkout), for: .touchUpInside) Where it shines: Best possible performance: no bridge, no abstraction layer, direct access to the platform's own rendering pipeline, which is exactly why the thoughtbot benchmark found native using the least memory (14MB) of the three Full, immediate platform access: new OS features and APIs are available to native code first, often before cross-platform frameworks catch up Platform-idiomatic UI by default: native components automatically match each platform's look, feel, and accessibility behavior without extra work No framework-layer bugs to debug around: you're working directly with Apple's and Google's own tools and documentation, with nothing else in between Where it struggles: Two full codebases: essentially building and maintaining two separate applications, in two separate languages, which is real, ongoing engineering cost Slower feature development: every feature gets built twice, once per platform, which is a genuine velocity cost most teams feel immediately Requires two skill sets on the team: hiring and retaining both strong iOS and strong Android engineers is a real organizational cost smaller teams often can't absorb Who this suits: apps where performance is genuine

mobileflutterandroidios

10/04 下午01:29

Flutter vs React Native in 2026: What Actually Changed Under the Hood

ZANISS SOFTWARES

Every year someone reopens the Flutter vs React Native debate, and every year most of the takes are stale by six months. This year the underlying tech genuinely moved, so here's what's actually different if you're picking a framework in 2026. React Native's New Architecture is the real story on that side: Fabric replaces the old async bridge with direct native UI manager communication, TurboModules load on demand instead of eagerly, and JSI lets JS call into C++ host objects synchronously. Combined with Hermes precompiling to bytecode, cold starts land around 350ms — a big improvement over the old bridge-era numbers, even if it's still behind Flutter. Flutter's Impeller 2.0 attacks a different bottleneck: shader compilation jank on first paint. Precompiling shaders at build time instead of runtime means Flutter apps hit 120fps with reportedly 0% dropped frames in benchmark testing, and Dart's AOT compilation to native machine code means there's no bridge at all to bottleneck through. Things worth knowing if you're mid-decision: If your UI is animation-heavy (custom charts, gesture interactions, anything gaming-adjacent), the Impeller 2.0 numbers are hard to ignore — this is where the performance gap is largest and most visible to users. If you already have a React/TypeScript team, the retraining cost to Dart is real and often underestimated. Factor it into your timeline, not just your framework comparison spreadsheet. AI coding assistants currently write noticeably better React Native code than Flutter code on the first pass, simply because there's more JS/TS training data out there. Worth knowing if your team leans on Copilot/Cursor-style tooling heavily — this gap is closing but hasn't closed yet. There's no meaningful migration path between the two. Don't pick either as a "placeholder." I wrote up the full 2026 cost and performance breakdown, including real India-market INR pricing by project tier, here: https://zanisssoftwares.com/blog/flutter-vs-react-native-2026 Curious what others are seeing in production with the New Architecture — has Fabric closed the gap enough for your use case, or are you still hitting frame drops on complex screens?

flutterreactnativemobilewebdev

10/04 上午02:35

Vergate: a version gate for Flutter with force update, soft update and maintenance mode

CodeWithRasul

Hi r/FlutterDevs, I just published Vergate, a Flutter package that decides whether the installed version of your app may run. It handles force updates, optional updates and maintenance mode. I built it for my own apps, where I wanted one reusable solution instead of rewriting the same version check each time. What it does Force update: a dialog that cannot be dismissed, driven by min_version Soft update: a banner or dialog, driven by latest_version, with "Remind me later" and "Skip this version" remembered between launches Maintenance mode: an optional from/until window, a live countdown, and an automatic re-check when the window ends Per-platform rules: separate versions and store links for Android and iOS Release notes shown in the update dialog Fail-open: network or parsing errors never lock the user out Re-checks on app resume: users who return from the store get in right away Pluggable data sources Vergate does not depend on Firebase or any specific service. The rules are a small JSON document, and it ships with a few ways to load it: JsonUrlSource: any URL that returns JSON (your own API, GitHub raw, S3) CallbackSource: plug in anything else with a simple async function (I use it for Firebase Remote Config) ItunesLookupSource: reads the latest version from the App Store (soft updates on iOS) FallbackSource: tries several sources in order You can also implement the VergateSource interface yourself. Customization The theme follows your Material theme, so dark mode works out of the box. You can override colors, radii and icons, pass your own texts (including a stringsBuilder for localization), or replace any screen with your own widget. The core VergateController is also UI-free if you want to build everything yourself. Quick start final vergate = VergateController( source: JsonUrlSource(Uri.parse('https://example.com/app-version.json')), ); void main() { WidgetsFlutterBinding.ensureInitialized(); vergate.start(); runApp(const MyApp()); } MaterialApp( builder: (context, child) => VergateGate( controller: vergate, child: child!, ), ); Design notes The gate is an overlay, not a route, so it works above the Navigator and your app's state is never lost. While a force update or maintenance screen is shown, the app underneath is blocked for touch, focus and screen readers. A client-side gate is not a substitute for server-side version checks on security-critical APIs. Limitations (v0.1.0) There is no store lookup for Android, because Google Play has no official API for it. Put the Android version in your own config. The update button opens the store page. Android's In-App Update API is not used. Links pub.dev: https://pub.dev/packages/vergate GitHub: https://github.com/therasuldev/vergate This is the first release, so I'd really appreciate feedback: missing features, API design, edge cases I haven't thought of, or bug reports. Thanks for reading!

fluttermobileopensourcesoftwaredevelopment

10/04 上午12:05

Native iOS vs React Native vs Flutter: Which Should Your App Use?

Ahtisham Hasan Khan

I build native iOS apps, so take my bias into account. But I have also worked in web teams and across a product organization that shipped on several platforms, and the right answer is not always "native". Here is how I would decide if it were my money. Native (Swift / SwiftUI) React Native Flutter Best when iPhone is your main audience Your team already knows React You need iOS and Android with one custom UI Feel on iPhone Most native Close, with care Custom-drawn, consistent across platforms New Apple features Available immediately After libraries catch up After plugins catch up Android Separate build Shared code Shared code Your users are mostly on iPhone. This is true for many consumer apps in the US, UK, and the Gulf, and for creator and productivity tools. The app depends on Apple hardware or system features: camera, widgets, Live Activities, HealthKit, Apple Pay, background audio. CueCam, a teleprompter that follows the speaker's voice while recording, is the kind of product where native matters. You care about polish at launch. App Store users notice when an app feels slightly off. You already have a React web team that will maintain the app. The app is mostly forms, lists and content, without heavy device features. You truly need Android on day one and the budget only covers one codebase. You want an identical, heavily branded UI on iOS and Android. You are building for markets where Android dominates and iOS is secondary. Cross-platform does not mean "build once". You still test on two platforms, go through two store reviews, and handle two sets of platform quirks. If you only needed iOS in the first place, you paid for flexibility you did not use. Launch on the platform where your first users are. For many consumer and creator products that is iPhone. Prove the idea, learn what people actually use, then expand. The backend, the product decisions, and the brand all carry over to Android. Not sure which fits your app? Send me a short description and I will give you a straight answer, even if it is "not native". Is native iOS development more expensive than Flutter or React Native? If you only need iPhone, native is usually not more expensive and is often faster to get right. Cross-platform saves money mainly when you genuinely need iOS and Android at launch. Can I start native on iOS and add Android later? Yes. Many products launch on iOS, validate the idea, then build Android once they know what users want. The backend and product decisions carry over. Which is better for performance and App Store quality? Native Swift and SwiftUI give direct access to every Apple API on day one and the most iPhone-like feel. Cross-platform apps can be very good, but platform-specific features often need extra native work anyway. What do you build with? I build native iOS apps with Swift and SwiftUI. Every app in my portfolio is native. Originally published at iahtisham.com. I'm Ahtisham, an independent iOS developer building native Swift apps. More from me: 🌐 Portfolio and client work: iahtisham.com 💸 AppPriceKit: free App Store subscription prices by country 🧾 JustInvoice: invoice maker for iPhone 📄 ScanIt: document scanner and PDF for iPhone 🌙 NUR: prayer times, offline Qur'an and adhkar, free with no ads 🏢 PrismCode Labs Find me on X @iAhtishamDev · GitHub · LinkedIn · Upwork

iosreactnativeflutterswift

10/03 下午11:48

React Native vs Flutter vs Native: There Is No Universal Best Choice

khg5293

When people start planning a mobile application, one of the first technical decisions is often: Should we build it with React Native, Flutter, or native development? There is no universal answer. Each approach solves a slightly different problem. A useful way to think about them is: React Native: Share much of your application code while still using native platform components. Flutter: Build a highly consistent cross-platform interface using Dart and Flutter's own UI framework. Native: Build separately for each platform using the tools and APIs provided directly by Apple and Google. All three approaches can produce good applications. The better choice depends on what you are building, who is building it, and how much platform-specific control you need. A cross-platform framework tries to let developers share code between platforms such as Android and iOS. Instead of maintaining completely separate applications: iOS codebase Android codebase you may be able to share a large portion of the application: Shared application logic Shared networking code Shared state management Shared UI components while still producing applications that run on both platforms. For a simple example, imagine an application displaying a profile for khg5293. The application needs to: Request profile data Store application state Display the username Handle button presses Navigate between screens Much of that logic is conceptually identical whether the user is running Android or iOS. Cross-platform frameworks try to reuse that work. The tradeoff is that Android and iOS are still different operating systems. Eventually, some applications need to interact with platform-specific behavior. That is where the differences between React Native, Flutter, and fully native development become more important. React Native allows developers to build mobile applications primarily using JavaScript or TypeScript and React. A simplified component might look like this: function UserProfile() { const user = { username: "khg5293", platform: "android" }; return ( <View> <Text>{user.username}</Text> </View> ); } For developers who already work with React on the web, this programming model can feel familiar. You still have: Components Props State Hooks JavaScript or TypeScript That can significantly reduce the learning curve for teams that already have strong JavaScript experience. One of React Native's biggest advantages is ecosystem familiarity. A company may already have developers who know: JavaScript TypeScript React npm REST APIs Frontend state management Those skills transfer reasonably well into React Native development. That makes React Native especially interesting for teams that already build web applications with React. For example, an application might use TypeScript to represent a user: type User = { username: string; platform: "ios" | "android"; }; const user: User = { username: "khg5293", platform: "android" }; The language, tooling, and programming style may already be familiar to the team. React Native can therefore be a practical way to move into mobile development without completely abandoning an existing JavaScript ecosystem. React Native does not make Android and iOS identical. Eventually, an application may need functionality that behaves differently between platforms. For example: import { Platform } from "react-native"; if (Platform.OS === "ios") { console.log("Running on iOS"); } if (Platform.OS === "android") { console.log("Running on Android"); } That is not necessarily a problem. But it demonstrates an important point: Cross-platform does not mean platform differences disappear. Applications that use Bluetooth, background services, advanced camera functionality, notifications, widgets, health data, or other operating-system features may still require platform-specific work. The framework can reduce duplication. It cannot erase the platforms underneath it. Flutter takes a different approach. Flutter applications are written primarily in Dart. A very simple Flutter interface might look like this: import 'package:flutter/material.dart'; class UserProfile extends StatelessWidget { const UserProfile({super.key}); @override Widget build(BuildContext context) { const username = 'khg5293'; return Scaffold( body: Center( child: Text(username), ), ); } } Flutter provides its own extensive widget system for building application interfaces. Instead of relying as heavily on the platform's standard UI components, Flutter gives developers a consistent way to construct and render interfaces across platforms. That can be extremely useful when visual consistency is important. Suppose a designer wants the application to look nearly identical on Android and iOS. With Flutter, the interface can be built from the same widget hierarchy: Column( children: [ Text('khg5293'), ElevatedButton( onPressed: () {}, child: Text('View Profile'),

mobilereactnativeflutterdevelopment

10/03 下午09:53

Be Pragmatic, Not Dogmatic: What I Skip in Clean Architecture (and What I Keep)

mt-laid

When I started building Flutter apps seriously, I followed Clean Architecture to the letter. Every feature got an entity, a model, a DTO, a use case, a repository interface in the domain layer, and its implementation in the data layer. If someone asked me why, my answer was: "Because that's Clean Architecture." That's not a reason. It took me a while to see it. This article isn't against Clean Architecture. The principles behind it are good: separate concerns, keep business logic independent, make code testable. My point is that the folder structure from the tutorials is one way to achieve those principles, not the principles themselves, and in many features you can reach the same goals with much less code. The four decisions I walk through below (entities and models, use cases, repository interfaces, and Cubit vs Bloc) are just examples. They're here to make one way of thinking concrete, and that way of thinking applies far beyond them: to state management, folder structure, how much you test, even which packages you add. Before adding any layer or class, I ask: Can I explain the purpose of this in a few seconds? If I can't, I probably don't need it or at least i don't know why i need it. A layer that only copies data from one class to another, or only forwards a call to the next layer, adds files and noise without adding business value. And noise has a real cost: more code to read, to maintain, and to explain to new teammates. Let's take a simple feature: showing a user profile loaded from an API. features/profile/ ├── domain/ │ ├── entities/user.dart │ ├── repositories/user_repository.dart (interface) │ └── usecases/get_user.dart ├── data/ │ ├── models/user_model.dart │ ├── datasources/user_remote_data_source.dart │ └── repositories/user_repository_impl.dart └── presentation/ └── cubit/ ├── user_cubit.dart └── user_state.dart That's 8 files for one screen that loads one object. Here's what some of them contain: // domain/entities/user.dart class User { const User({required this.id, required this.name, required this.email}); final int id; final String name; final String email; } // data/models/user_model.dart class UserModel extends User { const UserModel({ required super.id, required super.name, required super.email, }); factory UserModel.fromJson(Map<String, dynamic> json) => UserModel( id: json['id'] as int, name: json['name'] as String, email: json['email'] as String, ); } // domain/usecases/get_user.dart class GetUser { const GetUser(this._repository); final UserRepository _repository; Future<User> call(int id) => _repository.getUser(id); } Look at the entity and the model: they have exactly the same fields. And look at the use case: the whole class forwards one call. Neither adds any behavior. The Cubit then calls the use case, which calls the repository interface, which is implemented by a class that calls a data source. Same layers, same folders. Three files are gone: features/profile/ ├── domain/ │ ├── entities/ │ │ └── user.dart │ └── repositories/ │ └── user_repository.dart (the contract) ├── data/ │ └── repositories/ │ └── user_repository_impl.dart └── presentation/ └── cubit/ ├── user_cubit.dart └── user_state.dart What was removed: user_model.dart: merged into the entity, since they had the same fields. get_user.dart: the use case only forwarded a call. user_remote_data_source.dart: the repository implementation now makes the HTTP call itself. // domain/entities/user.dart class User { const User({required this.id, required this.name, required this.email}); factory User.fromJson(Map<String, dynamic> json) => User( id: json['id'] as int, name: json['name'] as String, email: json['email'] as String, ); final int id; final String name; final String email; } // presentation/cubit/user_cubit.dart class UserCubit extends Cubit<UserState> { UserCubit(this._repository) : super(const UserLoading()); final UserRepository _repository; Future<void> load(int id) async { emit(const UserLoading()); try { final user = await _repository.getUser(id); emit(UserSuccess(user)); } catch (e) { emit(UserFailure(e.toString())); } } } Five files instead of eight. No mapping code, no forwarding class, and the boundaries between layers are still there. The behavior is identical, and you can open the Cubit and understand the whole flow in one read. If they have the same fields, you're writing the same class two or three times and maintaining mappers between them. One class is enough. The trade-off, stated honestly: in the lean version, User knows about JSON, so a change in the API format touches your core class. For many apps that's acceptable. It stops being acceptable when: the API shape differs significantly from what your app needs (nested structures, different names, fields y

flutterdartarchitecturecleancode

10/03 下午05:00

How I built a 30MB offline scanner app to stop paying $30/year (and you can use it for free)

Nitesh

As developers, we absolutely hate paying for simple utility tools. I got completely tired of famous scanning apps holding my PDFs hostage behind paywalls and watermarks. So I built Scan Master—a 100% offline, privacy-first document scanner. You can grab it right now from the Google Play Store or see the features here, but I want to talk about why building offline-first apps is so important right now. Table of Contents They force you into crazy $30/year subscriptions. The real challenge: Keeping edge detection 100% offline Zero Latency: You do not have to wait for slow server responses. Quick Data Table & Pros/Cons Feature Scan Master (Local) Legacy Competitors (Cloud) Lightning-fast offline rendering. No automatic cloud sync (intentional by design). But I didn't stop there. I personally fixed a frustrating PDF cropping bug that was breaking on older Android APIs. It runs flawlessly now. I made this tool for myself to solve a personal headache. But seeing thousands of people use it to protect their privacy actually matters more than anything. Frequently Asked Questions Q: Are there any hidden paywalls for high-res exports? A: Never. You can export unlimited clean, watermark-free PDFs. Q: Where can I test this app out? A: You can download it directly from the Google Play Store. Let me know your feedback in the comments!

privacyflutterandroidshowdev

freeCodeCamp

15 條

教學、指南與實踐文章

更新於 10/05 下午06:51

09/24 上午05:01

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

pub.devFluttermobileDart

09/11 下午11:08

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

FlutterDartflutter-awarehandbook

09/03 下午11:40

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

FlutterDartAIflutter-aware

08/27 下午11:34

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

FlutterDartTestingwidget-testing

08/25 上午01:45

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

DartFluttermobileMobile Development

08/22 上午04:45

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

design patternsBehavioral Design PatternDartFlutter

08/19 上午12:05

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

FlutterDartflutter-aware

08/12 上午12:47

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

FlutterDartflutter-aware

08/10 下午10:14

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

FlutterSystem Designmobile app developmentDart

08/08 上午12:05

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

Fluttergeminiflutter-awareDart

08/07 上午12:11

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

Designdesign patternsdesign principlesDart

08/06 上午01:25

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

bluetoothBluetooth Low EnergyFlutterFlutter SDK

07/23 上午06:36

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

gRPCRPCDartFlutter

07/17 上午06:20

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

#Domain-Driven-DesignDartMobile DevelopmentFlutter

07/08 下午11:47

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

Flutterjankdevtoolsperformance

Hacker News

20 條

技術社群討論與專案連結

更新於 10/04 上午06:51

10/01 下午08:13

Show HN: Vynody – Cross-platform music player written in Flutter and Rust

axel10

Article URL: https://github.com/axel10/vynody Comments URL: https://news.ycombinator.com/item?id=49920648 Points: 4 # Comments: 0

09/29 上午01:57

Ask HN: React Native or Flutter when the back end is Node?

rearview

Really confused between React Native and Flutter. I’ve mostly worked with Flutter and a little bit with React Native, but that was quite a while back, so I’m not sure how things stand today. I’m building a project with a Node.js + tRPC backend, so React Native is looking really tempting cause of that Typescript. While researching I've seen mixed reviews about performance in React Native like people saying they've spend weeks finding and managing performance issue which does makes me worry. The app I wanna build doesn't have complex canvas work or crazy animations. For a typical production app, what’s the performance situation with React Native vs Flutter now? Are there any major concerns which I should know before looking in React Native? Comments URL: https://news.ycombinator.com/item?id=49881846 Points: 5 # Comments: 15

09/19 上午02:14

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

09/18 上午07:27

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

09/10 下午09:31

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

09/10 下午03:37

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

09/08 下午05:08

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

09/06 上午08:29

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

09/06 上午02:48

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

09/06 上午01:56

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

08/25 下午07:50

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

08/15 上午11:31

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

08/13 下午04:32

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

08/13 上午07:46

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

08/13 上午03:16

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

08/13 上午01:51

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

08/12 上午02:33

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

08/10 下午09:18

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

08/06 上午12:19

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

08/04 上午06:02

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

Medium

10 條

Flutter 相關文章精選

更新於 10/05 下午06:51

10/05 下午04:48

Flutter Widget Spotlight — Stop Fighting Row Overflow with Tags: Wrap

Shikha

You put a bunch of tags or chips in a Row, and the moment there are a few too many, the screen breaks out in those yellow-and-black… Continue reading on CodeToDeploy »

software-developmentdartflutterapps

10/05 下午04:25

Learn Flutter with Flutter Wizard: Complete Flutter Development Course

Ayushi Agarwal

Continue reading on Medium »

flutter-app-developmentcodingflutterflutter-widget

10/05 下午04:18

How to Add AI Function Calling to Your Flutter App (OpenAI, Gemini, Claude)

Amit Gupta

Let ChatGPT, Gemini or Claude take real actions in your Flutter app, without hand-written JSON schemas. Continue reading on Medium »

llmai-toolsflutterai

10/05 下午02:01

I predicted my phone’s AI speed before I tested it. I was 32% wrong.

Muhammad umer

A two-second test, a prediction pushed to GitHub before the run, and what one laptop can’t tell you about a phone. If you ship an app with… Continue reading on Medium »

llmiosflutterartificial-intelligence

10/05 下午01:41

The Gesture Arena: How Tap, Drag & Scroll Compete

Developer Hub

Stop using Flutter. Start understanding Flutter. Continue reading on Flutter Hub »

dartprogrammingtechnologyflutter

10/05 下午12:36

Flutter Widget Architecture: How I Stopped Using Widgets the Wrong Way

Ravi Savaliya

The widget patterns I changed in real Flutter projects to make UI code cleaner, easier to maintain, and less painful to debug. Continue reading on Medium »

flutterprogrammingarchitecturesoftware-development

10/05 上午10:58

Flutter Cupertino Widgets: Building iOS-Style Interfaces

Nisarg Ratani

Flutter gives developers the ability to build applications for multiple platforms from a single codebase. Continue reading on Medium »

flutter-widgetflutterflutter-cupertinoflutter-ui

10/05 上午10:56

Material 3 in Flutter: Building Modern Apps with Material You

Nisarg Ratani

Flutter has evolved significantly in the way applications are designed. Continue reading on Medium »

material3flutter-widgetmobile-app-developmentflutter-ui

10/05 上午06:20

Building a Duolingo Style Streak Widget for Flutter

Anton Borries

Auto-Updating Homescreen Widgets in Flutter Continue reading on Medium »

iosflutterstreaksduolingo

10/05 上午05:37

What It’s Really Like Building Tech From Africa

Elvis Ngwu

I fell in love with this project in my final year at university. I took a course on HCI (Human Computer Interface), and it changed how I… Continue reading on Medium »

mobile-app-developmentflutteraugmented-realityafrica

4 條

社群日榜討論與資源

更新於 10/05 下午06:51

10/05 上午03:30

I rebuilt fl_nodes, my most popular package, bringing huge improvements and new features

/u/_Wilielmus_

Last year I built a node editor package for Flutter. It was called fl_nodes, and, somewhat unexpectedly, that project ended up getting me my current job. I used it in production, learned a lot about what works and what doesn't when you try to build a serious node-based editor in Flutter, and eventually reached the point where I wasn't happy with the architectural compromises I'd made in V1. So I did what any reasonable person would do: I rebuilt it. From scratch. TBH it shares much of its DNA with the original fl_nodes. The basic API concepts and design decisions that made it so peculiar the first time, the naming of things, the performance optimizations under the hood... all stay the same, just largely improved in usability and flexibility. So today I'm announcing fl_nodes_v2 as a stable 1.x release, for everyone to... I don't know, find something useful to do with it; here you have some suggestions: visual-scripting, workflow-editors, static graph based visualizations, DSP and CAD tools... P.S.: I've finally got a verified publisher profile! 🎉 Resources: GitHub: https://github.com/WilliamKarolDiCioccio/fl_nodes_v2 Live demo: https://williamkaroldicioccio.github.io/fl_nodes_v2/ Pub: https://pub.dev/packages/fl_nodes_v2 Note: I may be moving the repo soon, if it 404s look at https://github.com/ConnectingTheDots-William-K-Di-Cioccio Features in detail: Widget-based node bodies: Arbitrary Flutter widgets can live inside nodes. Element-tree isolation: Nodes retain normal Flutter widget/element semantics. Semantic render state: Selection, hover, dragging, wiring and targets are explicit. Transactional undo/redo: Continuous mutations collapse into meaningful history entries. Node configurations as state machines: Ports, nodes, and the whole node configuration can now respond to runtime parameters changes. Connection validation: Built-in structural validation plus composable application-specific rules. Node definitions: Reusable schemas describe ports, fields, defaults and metadata. Graph serialization: Versioned graph/project persistence with explicit schema boundaries. Clipboard support: Copy/paste preserves internal connections without accidental external wiring. Automatic layout: Graph layout can be integrated without coupling it to rendering. Groups and comments: Organize graphs visually beyond just nodes and connections. Edges/links waypoints: the same thing Unreal Blueprints do, gives you more control on connection paths to keep the canvas tidy. Mini-map and navigation: Navigate large graphs without losing the editor context. More stuff coming: stay tuned particularly if you're interested in customization and animations. REMOVE THIS BEFORE POSTING: probably missed some more awesome features (kidding... look at the package!). Technical details for the nerds: The biggest architectural change from V1 is where node isolation happens. The original fl_nodes isolated nodes at the render-object level. This gave me a lot of control over rendering and performance, but it also meant that node contents weren't really ordinary Flutter widget trees anymore. Silly little 18yo me didn't know that tho, so I kept hitting my head against it for a while, trying to solve a design-decision thinking it was a bug. A node containing a TextField, a ListView, a form, or any other widget relying on normal Flutter element semantics shouldn't have to fight the node editor to behave like a Flutter widget. In V2, the isolation boundary moved from the render tree to the element tree. The graph infrastructure, connections, ports, grid, overlays, interaction geometry, etc., remains under the editor's control, while the actual node body is built as a normal Flutter widget. That means a node can contain ordinary Flutter UI while the editor still retains control over graph-level interaction and rendering. It also lets the application own the node's visual design instead of forcing the editor to define what a node looks like. There are a bunch of consequences hidden behind that seemingly small architectural change: gesture competition between node dragging and controls inside nodes, focus handling, scrolling, keyboard shortcuts, measurements, hit testing, and keeping graph state synchronized with widget state. The other major principle behind V2 is that the graph model doesn't know about Flutter widgets. The graph itself is immutable and serializable. The editor/controller layer handles mutation and interaction, while Flutter is primarily the presentation layer. That separation makes it possible to test a large part of the graph/editor logic without a Flutter rendering environment, and it keeps persistence independent from the widget tree. There's a lot more under the hood, but those are probably the bits most relevant to someone wondering whether this is just another node-editor widget package. submitted by /u/_Wilielmus_ [link] [comments]

10/05 下午05:03

Publishing packages

/u/AkmenZ

Hello, I don't really post much, but I wanted to share a quick thought. I've been a flutter developer for over 3 years, but newer tried to publish a package myself. That is until now. I wanted to see what is involved in the process and was pleasantly suprised of how simple it really is. I think this is definitely one of those things making Flutter stand out as a tool. You can find pretty much anything in pub.dev. My first package is nothing groundbreaking, but it's something I use in pretty much all of my apps, so making it a package is a great way to reuse the code and at the same time share it with the community. This is a customisable pill-shaped navbar that is a very common design in many apps these days (like facebook, instagram etc..). Would appreciate any feedback if anyone would like to check it out. Peace https://pub.dev/packages/clean_pill_navbar submitted by /u/AkmenZ [link] [comments]

10/05 下午04:52

I built a UX audit for Flutter that walks user journeys instead of checking widgets

/u/masanggil1986

A client asked me for a UX review of their Flutter app. The tools I found are good at checking components — button sizes, missing labels. But the client was asking something else: How many steps does it take to do the thing users actually come for? Is what matters most to them the thing the screen puts first? No component check can answer that. In the demo app in the repo, the #1 task is the 6th of 8 tap targets on the home screen, with five controls nobody ranked sitting above it. That isn't a property of any single widget. So I built flutter-ux-journey: You write a journey in Markdown: a goal, the steps, and optionally your priorities — what the app is for, in order It walks those steps inside your app's own process — plain flutter test, no emulator It counts the taps each task takes, and compares your declared priorities against where things actually sit on each screen: order, above the fold, size It also catches flow problems: dead ends, screens you can't back out of, taps that change nothing Every finding carries measured evidence — tap target rects, contrast ratios, semantics labels — and is scored against the goal: the same problem is severity 4 if it blocks the goal, 2 if there's a way around it It doesn't guess what matters. Priorities come from you or your client; the tool shows where the app disagrees with them. Three Flutter semantics things I learned along the way, useful even if you never touch the tool: Semantics rects are in local coordinates — without transforming up the parent chain, nested elements all report (0,0) tooltip: doesn't fill the semantics label; it's a separate field InkWell has a tap action but no isButton flag, so enumerate by action, not by flag Try it without your own app (demo app with six seeded defects, ~2 s): git clone https://github.com/masanggil1986/flutter-ux-journey.git cd flutter-ux-journey/example/ux_demo_app && flutter pub get && flutter test ux_audit/ux_journey_test.dart It's a Claude Code skill, MIT, and adds no package to your app. Real devices aren't verified yet — the README has a section on what it can't see. https://github.com/masanggil1986/flutter-ux-journey Feedback welcome, especially if you've ever had to answer "is our UX good?" for a client or PM. submitted by /u/masanggil1986 [link] [comments]

10/04 下午09:18

How I implemented real-time GPT-4o streaming with Supabase RLS in Flutter (Architecture & Lessons Learned)

/u/DohamaSystems

Hey Flutter devs! Over the past few weeks, I’ve been building a B2B AI mobile starter kit using Flutter, Supabase, and OpenAI's GPT-4o API. Handling real-time streaming responses seamlessly while keeping state, UI, and backend security synchronized brought a few interesting challenges. Here are 3 key takeaways from the implementation: Stream Buffer & Lifecycle Safety: Always check if (!mounted) inside stream iterations (await for (final chunk in stream)) before calling setState or updating local state. Disposing the screen mid-stream otherwise causes memory leaks and unhandled exceptions. Supabase Row Level Security (RLS) for AI Chats: Never let the client query chat tables freely. We locked down the messages table so users can only SELECT and INSERT records where auth.uid() = user_id. Clean Folder Separation: Grouping AI services, Supabase auth wrappers, and UI components into dedicated modules kept the codebase clean and maintainable. To give back to the community, I published a public **GitHub Showcase Repository** with our project structure, environment setups, and Dart code snippets: 🔗 **Showcase Repo:** https://github.com/dohamasystems/flutter_ai_starter_kit Would love to hear how you guys usually manage local state for streaming SSE responses in Flutter! Any feedback or questions are welcome. 🙌 submitted by /u/DohamaSystems [link] [comments]

FAQ