本站已进行升级,老用户可以通过找回密码登录。

24h Intel · 90 條

Flutter 24小時情報 GitHub 熱門倉庫與技術資訊

每日彙總 Flutter / Dart GitHub 熱門倉庫,以及 Dev.to、freeCodeCamp、Hacker News、Medium、Reddit 的近期技術資訊,追蹤 24 小時 Stars 增量與社群討論。

更新於 10/30 上午10:086 個來源

GitHub

20 條

Dart 與 Flutter 相關倉庫熱度

Dev.to

12 條

開發者文章與專案分享

Your next Google Play update will be rejected if it still ships Billing Library 7 (Nov 1, 2026)
10/30 上午03:54

Your next Google Play update will be rejected if it still ships Billing Library 7 (Nov 1, 2026)

Emre P.

Not a developer? Read this first. If Play Console shows a warning like "Update to a newer version of Google Play Billing Library" or "We've detected this app uses an unsupported version of Play billing", or an update you uploaded was rejected for its billing library, the fix is in your app's code, not in Play Console. Your app keeps selling in the meantime. If the developer who built the app is no longer around, send me the warning text and I will tell you what it takes, for free: my Billing upgrade project on Upwork. If your app sells anything through Google Play and you have not touched its billing code in a year, check one line before your next release. From November 1, 2026, Play stops accepting new apps and updates that use Play Billing Library 7. That date is the end of the extension window; the normal deadline was August 31. Your live app keeps working. Users can still buy. What breaks is the next update: Play Console refuses it, and you find out on the day you need to ship a fix. Native Android. Open app/build.gradle (or .kts) and look for: implementation("com.android.billingclient:billing:7.x.x") Anything below 8 needs work. If you use billing-ktx, check that line too. Flutter (in_app_purchase). The Billing version comes from the Android plugin, not from your app. Check pubspec.lock for in_app_purchase_android: in_app_purchase_android Play Billing Library inside 0.4.0+8 7.1.1 (blocked after Nov 1) 0.5.3, 0.5.4 8.0.0 0.5.5 9.1.0 (Read from each version's android/build.gradle; check your own lock file, since ^0.4.0 will not move to 0.5.x on its own. 0.5.x is a breaking release, so plan a short test pass.) RevenueCat, Adapty, other SDKs. They bundle a Billing version too. Update the SDK and check its release notes for the Billing version it ships. Play Console. If you are already on an unsupported version, Play Console shows a warning on the Policy status page. That is also where the extension form lived; after November 1 there is nothing left to extend. Most apps that already moved to ProductDetails in Billing 5-7 need small changes. The ones that hurt: querySkuDetailsAsync and SkuDetails are gone. If your code still uses them, this is the bulk of the work: move to queryProductDetailsAsync and ProductDetails, and subscriptions to base plans and offers. Purchase history queries are removed. Use queryPurchasesAsync for active purchases; for refunded or canceled ones, the Voided Purchases API on your server. queryPurchasesAsync(skuType) is removed. Use the version that takes QueryPurchasesParams. The product details callback changed shape. onProductDetailsResponse now receives a QueryProductDetailsResult that also lists products Play could not fetch, with a status per product, so a missing product no longer fails silently. enablePendingPurchases() without parameters is gone. Pass PendingPurchasesParams (enableOneTimeProducts() gives the old behaviour). New and optional: automatic service reconnection (enableAutoServiceReconnection(), removes hand-written retry code) and a sub-response code on failed purchases (for example, insufficient funds), useful for a clearer error message. Aim for 9, not just 8. Billing 8 itself is only accepted until August 31, 2027 (extension to November 1, 2027). The jump from 8 to 9 is small, so if you are touching the billing code anyway, landing on 9 saves you doing this again next summer. After the code compiles, test the boring paths on a real device with a license tester: buy, cancel, pending payment (slow test card), restore on a fresh install, and an expired subscription. Billing bugs rarely show up in the happy path. Nothing happens to the version that is live. You just can't ship the next one until billing is on 8 or later. If you also need to raise the target API (Play now expects API 36 for updates), do both in the same release: the Gradle and AGP bumps overlap. I moved four Flutter apps of my own through this (two on Billing 8, one on 9.1). If you want a second pair of eyes on yours, I do fixed-price Billing 8/9 upgrades (with target API 36 if you need it): see packages and prices on Upwork. Sources: Google Play Billing deprecation FAQ · Play Billing Library release notes · Migrate to Billing Library 8

androidfluttergoogleplaybilling
5 Architecture Decisions That Make Flutter Apps Easier to Scale
10/30 上午12:14

5 Architecture Decisions That Make Flutter Apps Easier to Scale

Ayesha Ahmed

Most Flutter apps don't become difficult to maintain because Flutter can't scale. They become difficult to maintain because architectural decisions that seem harmless during the MVP stage turn into expensive dependencies as the product grows. A screen that directly calls an API works fine when the application has five screens. But when that application expands to multiple user roles, payment flows, background synchronization, and complex business rules, those shortcuts start creating problems. After working on production-oriented mobile applications, I've found that scalability is less about choosing the most popular state management library and more about defining clear boundaries between responsibilities. Here are five architecture decisions that make a real difference. One of the most common problems in Flutter projects is placing API requests, validation, business rules, and navigation logic directly inside widgets. For example: onPressed: () async { final response = await http.post( Uri.parse('$baseUrl/orders'), body: jsonEncode(orderData), ); if (response.statusCode == 201) { Navigator.pushNamed(context, '/success'); } } This approach may work initially, but it tightly couples presentation logic with networking and business behavior. A better approach is to introduce clear boundaries: Presentation Layer ↓ Application / State Layer ↓ Domain Layer ↓ Data Layer ↓ API / Database The presentation layer handles rendering and user interactions. The application layer coordinates state and use cases. The domain layer represents business rules and contracts. The data layer handles API communication, local persistence, and data mapping. This separation makes features easier to test, modify, and reuse. Practical takeaway: A widget should not need to understand how an API request is authenticated, retried, or persisted. Flutter offers several state management options, including Provider, Bloc/Cubit, Riverpod, and GetX. There isn't one solution that automatically makes every application scalable. What matters is whether the selected approach provides predictable state transitions and keeps business logic outside the widget tree. Consider an order submission feature. Its state might include: Initial Loading Success Failure With Cubit, the implementation could look like this: sealed class OrderState {} class OrderInitial extends OrderState {} class OrderLoading extends OrderState {} class OrderSuccess extends OrderState {} class OrderFailure extends OrderState { final String message; OrderFailure(this.message); } class OrderCubit extends Cubit<OrderState> { final OrderRepository repository; OrderCubit(this.repository) : super(OrderInitial()); Future<void> submitOrder(Order order) async { emit(OrderLoading()); try { await repository.createOrder(order); emit(OrderSuccess()); } catch (error) { emit(OrderFailure(error.toString())); } } } The widget observes state and reacts accordingly. The repository remains responsible for data operations. This creates a clearer separation between user interface behavior and business operations. Practical takeaway: Consistent state management patterns across a project matter more than repeatedly switching libraries. An API should not be treated as a collection of HTTP calls scattered across different screens. As an application grows, API integration becomes responsible for much more than sending and receiving JSON. It may need to handle: Authentication and token refresh Request timeouts Network failures Error normalization Pagination Retry policies Response validation A repository abstraction helps isolate those responsibilities. abstract class ProductRepository { Future<List<Product>> getProducts(); Future<Product> getProductById(String id); } The application can then depend on the repository contract rather than a specific HTTP client or backend implementation. class GetProducts { final ProductRepository repository; GetProducts(this.repository); Future<List<Product>> call() { return repository.getProducts(); } } If the backend changes or caching is introduced later, the presentation layer does not need to be rewritten. For applications handling financial transactions, retries also need special attention. Repeating a payment or order creation request without idempotency protection can create duplicate operations. Practical takeaway: Centralize networking behavior and design for failure from the beginning. A mobile application cannot assume that every user has a stable internet connection. This becomes especially important for inventory systems, delivery applications, POS solutions, and field-service tools. A useful offline-capable architecture may look like: Flutter UI ↓ State Management ↓ Repository ├── Local Database └── Remote API ↓ Backend Database The local database supports cached reads and, where appropriate, queued writes. The sy

flutteraiarchitecturemobile
Rejecting Shoes and Selfies: How We Stop Users from Burning Our AI Vision Tokens
10/29 下午11:59

Rejecting Shoes and Selfies: How We Stop Users from Burning Our AI Vision Tokens

Plant Finder

Within 48 hours of launching Plant Finder on Google Play, we checked our backend telemetry to see what users were scanning. We expected to see monsteras, tomatoes, rose bushes, and succulents. When you hand people an app that uses multimodal AI vision to diagnose leaves, human nature takes over: people immediately try to break it. The Hallucination Problem: The AI tries way too hard to find a plant where none exists. The Financial Drain: Every photo of a coffee mug or a carpet burns real money in visual AI tokens. Here is how we tackled adversarial non-plant uploads, protected our bills, and stopped our app from diagnosing shoes. Early on, if our mobile app sent a photo of a brown leather shoe with the prompt "Identify this plant and its health issues," the AI would genuinely attempt to fulfill the request. The result? The model returned: This was disastrous. If a user tested the app on an everyday object as a joke, seeing the AI confidently hallucinate an entire botanical diagnosis destroyed their trust in the product. If it can't tell the difference between a shoe and a ficus, why would a farmer trust it to identify tomato early blight? The Token Cost of Human Curiosity If you have thousands of active users, paying for 18% wasted API calls every single day quickly eats through your operating margins. We were essentially subsidizing people scanning their living room furniture with expensive AI inferences that delivered zero actual value. Step 1: Giving the Model Permission to Say "No" Stage 2 (The Diagnosis): Only if Stage 1 passes should the model extract foliar pathology, soil pH symptoms, and care recommendations. Step 2: Designing a Graceful Rejection UI Instead, we built an explicit rejection handler in our Flutter camera preview screen: Step 3: Preventing Deliberate Token Spam Server-Side IP Rate Limiting: Our cloud gateway tracks upload frequencies per IP address. If an IP exceeds 15 rapid-fire uploads in a 60-second window, requests are temporarily throttled at the network level. What Other Mobile AI Developers Should Take Away Teach your AI to say "I don't know": Models will confidently fabricate answers if your prompt doesn't give them a clear, graceful exit path. Project: Plant Finder Platform: Android (Google Play) Attribution: Designed by Code vairagi

aiandroidflutterdart
Native vs Cross-Platform App Development: What Actually Matters
10/29 下午11:33

Native vs Cross-Platform App Development: What Actually Matters

Saqib Tasneem

The first mistake with a mobile app usually happens before any code is written. This guide looks at native vs cross-platform development, where Flutter fits, and the UX, backend and testing decisions that decide whether a mobile app works. What the full article covers: What App Development on Mobile Actually Involves The First Decision: What Kind of Mobile App Are You Building? Native vs Cross-Platform: The Trade-Off I Actually Look At Why Mobile UX Changes the Development Problem Performance Is Not Just About Speed Where Flutter Fits Into App Development on Mobile Read the full article on our website: Native vs Cross-Platform App Development: What Actually Matters Originally published by Vortex Web Innovate, a US-based software development company in Easthampton, Massachusetts.

mobileflutterandroidios
Adım Adım Çalışma Sürecimiz: Fikirden Yayına 5 Aşama: Production Architecture & Best Practices 2026
10/29 下午11:00

Adım Adım Çalışma Sürecimiz: Fikirden Yayına 5 Aşama: Production Architecture & Best Practices 2026

Nuh Mehmet Demirkol

Adım Adım Çalışma Sürecimiz: Fikirden Yayına 5 Aşama Mobil uygulama ekosisteminde ölçeklenebilir ve sürdürülebilir bir sistem inşa etmek için doğru mimari ve mühendislik disiplini şarttır. Clean Architecture katmanları ile iş mantığını ve UI katmanını birbirinden ayırmak bakım maliyetlerini %60 oranında azaltır. Flutter ile tek kod tabanından iOS ve Android için 120 FPS akıcılık elde edilir. Her kurumsal projede %100 açık kaynak kod, Git deposu ve en az 1 yıllık teknik bakım garantisi sağlanmalıdır. 📌 İlgili Özel Sayfa: Adım Adım Çalışma Sürecimiz: Fikirden Yayına 5 Aşama 🧮 Canlı Maliyet Hesaplama: Mobil Uygulama Maliyet Hesaplama 👨‍💻 Bilgisayar Mühendisi: Nuh Mehmet Demirkol 📞 WhatsApp: +90 507 823 68 11 | Ankara, Türkiye

fluttermobilearchitectureios
AI-Powered Flutter App Development: How to Build Smarter Mobile Apps Without Overspending
10/29 下午09:59

AI-Powered Flutter App Development: How to Build Smarter Mobile Apps Without Overspending

JB codeapp

Mobile applications are moving away from being basic. People are wanting to use smart search, personalised recommendations, instant chat, voice commands and much more. These are made possible using AI. Using Flutter, businesses can create smart apps for Android and iOS, using a single codebase. However, there are some costs associated with implementing AI within your application. You don’t need a high cost AI packed application to get good results. In this guide we will look at how to utilise Flutter and AI to create smart apps, whilst keeping the development costs low. Traditional mobile applications will have a lot of rule based logic. By using AI within your application you can add more intelligence by understanding requests, providing responses, identifying patterns and providing personalisation. For example: An e-commerce application can provide recommendations. A customer support application can provide answers to frequently asked questions. A productivity application can provide document summary. Features like: Chat assistants – Provide answers to customers and help them navigate through the application. Smart search – Help users to find relevant information using natural language search. Personalised recommendations – Recommend products/services/content based on user preferences. Voice – Allow users to search, navigate and make requests using voice. Document summary – Summarise long documents into short useful information. Image recognition – Identify objects or extract information from images. Using tools like Firebase AI Logic, Gemini models and Flutter AI Toolkit developers can add AI services into their Flutter applications. When deciding which features to add, make sure they actually help fix a problem for your users. Creating separate Android and iOS applications can add extra development time and duplicate code. Flutter can help reduce costs by allowing developers to create a cross platform application. This means you can create both an Android and iOS application using a single codebase. By using Flutter, you can: Use one code base – Most logic and UI can be used within both Android and iOS. Quick UI – The widget based structure makes it quick to create a consistent UI. Easy to maintain – Many bugs and features can be fixed/added to one code base. Prototyping – Quickly create prototypes to test your products and create minimum viable products. However, depending on the application there will still be additional costs involved. For example, integrating with specific platforms, testing, security and complex features. How much you save will depend on what your application requires and how experienced your team are. One of the main mistakes businesses make is adding too many AI features. Instead identify what the main issue is for your users and pick one or two features to help. For example: Type of Application AI Feature Benefit E-commerce Recommendations Improve product discovery Customer Support Chat Assistant Answer frequent questions Education Personalised Learning Assist Personalised learning Healthcare Admin Document Summary Reduce manual information processing Productivity Voice Commands & Summary Simplify repetitive tasks Business Management Smart Search Find information/records quickly Using the Flutter AI Toolkit, developers can create chat interfaces. Features include streaming, voice, multimedia and function calls. For example, within your business application you could add a chat assistant that helps users find customer records. If function calls are correctly set up, the assistant can ask for information from only approved services within the application. However, you will still need to implement authentication, authorisation, validation and security. Tip – Pick a feature that will help you achieve a goal. For example reducing response times, increasing search success or helping users complete tasks quicker. Where you decide to run your AI can have a big impact on your application. There are three common options: With Cloud AI, you make a request to a service. The service will process and respond. This can be useful for complex text generation, detailed summaries, chat assistants and complex models. Advantages: Strong models available Centralised model management Less dependent on users device Disadvantages: Usually requires internet connection May incur ongoing costs Extra care needed with sensitive information Response time will vary depending on connection and service. With On Device AI, the data is processed locally on a supported device. This can be useful for image recognition, simple text processing and some offline experiences. Advantages: Can be more available offline Less data sent to a service Reduced data usage on supported tasks Disadvantages: Model size can be limited by device capabilities and memory Planning required for model distribution and updates Battery usage and performance needs to be tested Not all tasks can be done locally to a good standard. With

aiflutterprogrammingandroid
How I got a Flutter web app (CanvasKit) indexed by Google with static SEO shells
10/29 下午09:18

How I got a Flutter web app (CanvasKit) indexed by Google with static SEO shells

Rakibul Hasan

Flutter web is great for building an app once and shipping it everywhere. It's not great for SEO. With the CanvasKit renderer, everything is drawn onto a <canvas>. If you open "view source" on a Flutter web page, all you get is a nearly empty index.html and a script tag. Google can render JavaScript, but rendering is queued and slow on a large app. Many other crawlers and the link preview bots (WhatsApp, Facebook, X) don't run it at all. I ran into this building TypeorDrop, a free online file converter. It has 150 tool pages, like /convert-jpg-to-pdf or /merge-pdf. Every one of them needs its own title, description and indexable text, or it will never rank. There are packages for this (flutter_prerender, esen_seo) and paid prerender services. I wanted the SEO text to come from the same database column the app already renders, with no new dependency in the Flutter app, so I wrote a small build step instead: static SEO shells. A shell is a copy of Flutter's built index.html, generated at deploy time, one per route. Each copy gets: a unique <title>, meta description and <link rel="canonical"> Open Graph and Twitter card tags JSON-LD: SoftwareApplication, plus FAQPage when the tool has FAQ items real body text: H1, intro, how-to steps, features, supported input and output formats, FAQ, related tools and related articles The Flutter bootstrap stays the same. A crawler reads the HTML. A person's browser loads Flutter, which draws the app on top. The same URL serves the same HTML to everyone. Nothing switches on user agent, which would be cloaking. build/web/ ├── index.html ← homepage shell ├── convert-jpg-to-pdf/index.html ← shell for /convert-jpg-to-pdf ├── merge-pdf/index.html ├── ... ├── main.dart.js ← shared by every shell └── sitemap.xml The most important rule: the shell text should match what users see. If the hidden HTML says one thing and the app shows another, you're asking for trouble with search engines. So the text doesn't live in the generator. Each tool row in the database has an seo JSON column (h1, intro, steps, features, FAQ, related tools). The API returns that column to the Flutter tool page, which renders the how-it-works, features, formats and FAQ sections from it. At deploy time, the same column is exported to a temporary JSON file and the generator reads it. When I edit a FAQ answer, the app and the shell both change on the next deploy. The pricing shell and the homepage's popular-tools list go one step further: the generator reads them from the same Dart constants the app uses. The real script is longer and has tests (77 across the SEO and blog generators, all offline with mocked HTTP). This is the shape of it: # runs after `flutter build web --release` # tools = JSON export of active web tools, including the seo column TEMPLATE = pathlib.Path("build/web/index.html").read_text() for route, tool in tools.items(): # e.g. "convert-jpg-to-pdf" html = stamp_head(TEMPLATE, title, description, canonical) # replaces <title> + meta description; adds og:*, twitter:* and # <link rel="canonical"> just before </head> html = replace_seo_block(html, seo_block(tool)) # fills the <div id="seo-content" class="visually-hidden"> placeholder # (outside the Flutter host element): h1, intro, how-to <ol>, features, # formats, FAQ, related tools/articles + SoftwareApplication & FAQPage JSON-LD html = replace_footer(html) # plain-HTML footer with real links write(f"build/web/{route}/index.html", html) # then: sitemap.xml (lastmod = each tool's updated_at), robots.txt, # and the homepage shell (Organization, WebSite, ItemList of popular tools) A few rules live in the generator too: titles stay at 60 characters or less with the brand last, descriptions land between 120 and 160 characters, and duplicate titles or descriptions print a warning. <body> By default, Flutter takes over <body> and your shell content ends up under the canvas or gone. I use a custom flutter_bootstrap.js that mounts Flutter into a dedicated element: _flutter.loader.load({ onEntrypointLoaded: async (engineInitializer) => { const appRunner = await engineInitializer.initializeEngine({ hostElement: document.querySelector('#flutter-host'), }); await appRunner.runApp(); }, }); The #seo-content block sits outside #flutter-host, and nothing removes it after boot. It's hidden with a standard visually-hidden class, not display:none: .visually-hidden { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } Two fallbacks come almost free: No JavaScript: a <noscript> style block turns the shell into a normal visible page. Flutter fails to load: if the app hasn't painted after 20 seconds, the static page is shown instead of a blank screen. Also make sure <base href="/"> is set. Otherwise /convert-jpg-to-pdf/index.html look

flutterseowebdevpython
Migrasi targetSdk 36 untuk Flutter dan React Native: Checklist Sebelum 1 November
10/29 下午09:17

Migrasi targetSdk 36 untuk Flutter dan React Native: Checklist Sebelum 1 November

Wahyu Andika Putra

Migrasi targetSdk 36 untuk Flutter dan React Native: Checklist Sebelum 1 November Informasi Audit & Rilis: Tanggal Terbit: 29 Oktober 2026 Tanggal Revisi Terakhir: 29 Oktober 2026 Tingkat Kompleksitas: Advanced / Production Critical Sumber Primer: Google Play Console Developer Policy & Android 16 SDK Guidelines (developer.android.com) Mulai 31 Agustus 2026, Google Play memberlakukan aturan bahwa setiap update aplikasi wajib menargetkan minimal Android 16 (targetSdk 36), dengan batas toleransi perpanjangan waktu (extension window) terakhir yang akan resmi ditutup pada 1 November 2026. Aplikasi Flutter maupun React Native yang masih menargetkan targetSdk 34 atau lebih rendah akan dicekal dari penelusuran perangkat Android modern dan ditolak saat submission update di Google Play Console. Artikel ini memberikan panduan teknis langkah-demi-langkah, mitigasi breaking changes Edge-to-Edge display, serta checklist verifikasi build siap rilis. Google Play menerapkan siklus tahunan kepatuhan targetSdk guna menjamin keamanan memori, privasi pengguna, dan konsistensi UI di ekosistem Android. Bagi developer di Indonesia, tidak melakukan migrasi ke target API 36 sebelum 1 November membawa risiko fatal: Pencekalan Visibilitas: Pengguna perangkat Android 15 dan Android 16 tidak lagi dapat menemukan atau mendownload aplikasi Anda di Play Store. Penolakan Bundle Release: File .aab baru yang diunggah ke Google Play Console akan langsung ditolak sistem dengan error: Your app currently targets API level 34 and must target at least API level 36. Regresi UX Tampilan: Android 16 memberlakukan kebijakan Enforced Edge-to-Edge secara baku, yang menyebabkan status bar dan navigation bar menimpa elemen interaktif (floating buttons / input form) jika tidak diadaptasi dengan benar. Dalam pengujian lab rekayasa kami, migrasi aplikasi Flutter (v3.24+) dan React Native (v0.76+) memerlukan pembaruan serentak pada compileSdk, targetSdk, dan dependensi NDK. [Proyek Mobile (Flutter / RN)] │ ▼ [android/app/build.gradle] ──► Ubah compileSdk = 36 & targetSdk = 36 │ ▼ [Edge-to-Edge Enforcing] ──► Adaptasi WindowInsets & Safe Area │ ▼ [Foreground Service Check] ──► Deklarasi atribut android:foregroundServiceType │ ▼ [Verifikasi via ADB / CLI] ──► Audit Bundle (.aab) & Lolos Review Play Console build.gradle Flutter Buka berkas android/app/build.gradle: android { namespace "com.andikadev.mobileapp" compileSdk 36 defaultConfig { applicationId "com.andikadev.mobileapp" minSdk 24 targetSdk 36 versionCode 104 versionName "2.4.0" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" } buildTypes { release { signingConfig signingConfigs.release minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } } build.gradle React Native Buka berkas android/build.gradle dan sesuaikan build script variables: buildscript { ext { buildToolsVersion = "36.0.0" minSdkVersion = 24 compileSdkVersion = 36 targetSdkVersion = 36 ndkVersion = "26.1.10909125" kotlinVersion = "1.9.24" } } Pada Android 16 (API 36), aplikasi secara otomatis dirender dalam format Edge-to-Edge. Konten aplikasi Anda akan berada di balik status bar dan navigation bar transparan. Pastikan seluruh root view Anda dibungkus dengan widget SafeArea dan atur System UI Overlay: import 'package:flutter/material.dart'; import 'package:flutter/services.dart'; void main() { WidgetsFlutterBinding.ensureInitialized(); SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge); runApp(const ProductionMobileApp()); } class ProductionMobileApp extends StatelessWidget { const ProductionMobileApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( theme: ThemeData( useMaterial3: true, scaffoldBackgroundColor: const Color(0xFFF8FAFC), ), home: const Scaffold( body: SafeArea( top: true, bottom: true, child: DashboardScreen(), ), ), ); } } Gunakan pustaka resmi react-native-safe-area-context: import React from 'react'; import { StyleSheet, View, Text } from 'react-native'; import { SafeAreaProvider, useSafeAreaInsets } from 'react-native-safe-area-context'; export default function App() { return ( <SafeAreaProvider> <MainContainer /> </SafeAreaProvider> ); } function MainContainer() { const insets = useSafeAreaInsets(); return ( <View style={[styles.container, { paddingTop: insets.top, paddingBottom: insets.bottom }]}> <Text style={styles.heading}>Target API 36 Production Ready</Text> </View> ); } const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: '#0f172a', paddingHoriz

androidflutterreactnativeplaystore
Flutter WebRTC calls that never connected: three bugs, three fixes
10/29 下午08:46

Flutter WebRTC calls that never connected: three bugs, three fixes

Frank Milvus

For two weeks, every 1:1 audio and video call in our Flutter app failed the same boring way: the caller saw "Calling…", the screen flipped to "Ended" about a second later, and the callee's phone never rang. The client logs looked fine. The peer connection reached have-local-offer and then closed. The temptation is to pick one suspect and start there. We spent the first evening on the relay server, which was genuinely broken — and fixing it changed nothing, because two other bugs sat in front of it. This is the story of all three, plus the small traps that were still waiting after them. have-local-offer, then silence Worth stating precisely, because it narrows the search: The app created an offer, set it as its local description, and sent it. The backend accepted the WebSocket message without an error. No answer ever arrived. After a timeout, the client tore the call down. That rules out most of WebRTC theory — codecs, SDP munging, permissions — and leaves one question: did the offer actually reach the other side? It did not. The app signals calls over the WebSocket. Each event carries a call_id, and the backend looked up a CallSession by that id before relaying. The problem is what call_id contains: the conversation id. The client never creates a call session at all — the table exists, the endpoints exist, and nothing calls them. So the lookup returned None for every offer, answer and ICE candidate, and the handler returned early: Call 42 not found Every event was dropped. The call closed immediately after have-local-offer, which is exactly what the symptom looked like. The fix was to stop looking for a session and route by membership instead: resolve the participants of the conversation, reject a sender who is not a member, and relay the event to everyone else. The wire format did not change. call_id still means the conversation id; the backend re-prefixes the event type (offer → call_offer) and relays any type verbatim, including ones it has never heard of. Two side benefits fell out of the change: A new signalling event no longer needs a backend deploy to work. The dead CallSession/CallParticipant models became obvious — including an endpoint that used a model it never imported, which only surfaced as a NameError. A test now pins that path. The lesson: when a lookup fails on an id, check whether both sides agree on what the id identifies. call_id was a naming lie, and it cost a week. With routing fixed, calls still failed — but now only sometimes. Office Wi‑Fi worked. Mobile networks did not. That is the classic signature of symmetric NAT: direct peer-to-peer connectivity fails, and everything has to go through a relay. We had a relay. It was simply unreachable. The TURN server ran on a machine behind NAT, published through a port-forwarding tunnel. Two things were wrong with that, and only one is obvious: The relay advertised its own container address as the relay candidate, so clients were handed an address that does not exist outside that host. Even with the address fixed, a single forwarded port cannot carry TURN. A relay is not one connection: each allocation gets its own UDP port for the peer. The tunnel maps one port; the relay needs a range. And STUN through that tunnel reports the tunnel as the client, so the whole candidate dance is meaningless. The fix was to move the relay to a host that owns a public IP and configure it for the outside world. The settings that mattered, with the real values redacted: listening-port=3478 external-ip=<public-ip> # without this: a private address is advertised min-port=<first-relay-port> max-port=<last-relay-port> # a dedicated UDP relay range, firewall-open denied-peer-ip=<private-range> # one line per range: loopback, link-local, RFC 1918 no-multicast-peers Three operational details that are easy to miss: The DNS record must be DNS-only. If the relay hostname sits behind an HTTP proxy or CDN, the proxy answers the UDP/TCP traffic and the relay never sees it. Open the whole relay range in the host firewall, not just the listening port. Keep the kernel's ephemeral port range away from the relay range. Otherwise the kernel can already hold a port the relay wants to bind, and allocations fail intermittently — the worst kind of failure. The relay is also restricted so it cannot be used as a door into the host's private networks (the denied-peer-ip lines above). A relay reachable from the internet is a feature; a relay that will happily forward to the host's own loopback sockets is a vulnerability. The lesson: "peer-to-peer works on my network" is not a test. Try a mobile network, and treat a missing relay as an untested code path. Now calls connected — while both apps were open. Minimise one, lock the phone, and the call again reached nobody. This one is architectural, not a typo. The app closes its WebSocket when it goes to the background, deliberately: an idle socket on a sleeping phone is a battery and reconnection problem. But a call offer is

flutterwebrtcshowdevwebdev
A Hebrew & Gregorian date picker for Flutter
10/29 下午08:10

A Hebrew & Gregorian date picker for Flutter

blimyp

If you've ever built a Flutter app for a Hebrew-speaking or Jewish audience, you've probably needed users to pick a date — and see the Hebrew date along with the Gregorian one. Flutter's built-in showDatePicker only knows the Gregorian calendar, so I built hebrew_date_picker: a Material-style date picker that shows both calendars side by side. Every day cell shows the Gregorian day and the Hebrew day in letters (12 / א׳) The month title shows the Hebrew months it covers (September 2026 / אלול–תשרי תשפ״ז) The header shows the full Hebrew date of the selected day Tapping the month title opens a year grid with both Gregorian and Hebrew years A range picker for selecting start and end dates Optional marking of Yamim Tovim dependencies: hebrew_date_picker: ^0.5.0 The simplest way is a ready-made form field: HebrewDateFormField( firstDate: DateTime(2020), lastDate: DateTime(2030), decoration: const InputDecoration( labelText: 'Date', suffixIcon: Icon(Icons.calendar_today), ), validator: (date) => date == null ? 'Pick a date' : null, onChanged: (date) => print(date), ) Or open it as a dialog: final DateTime? date = await showHebrewDatePicker( context: context, initialDate: DateTime.now(), firstDate: DateTime(2020), lastDate: DateTime(2030), ); With CalendarMode.hebrew, each page is a whole Hebrew month: showHebrewDatePicker( context: context, initialDate: DateTime.now(), firstDate: DateTime(2020), lastDate: DateTime(2030), calendarMode: CalendarMode.hebrew, ); For dates far from today, open the picker on the year grid: showHebrewDatePicker( context: context, initialDate: DateTime(1990, 1, 1), firstDate: DateTime(1900), lastDate: DateTime.now(), initialDatePickerMode: DatePickerMode.year, ); Hebrew dates are calculated with kosher_dart, and the calendar grid is built on table_calendar. 📦 pub.dev ▶️ Live demo 💻 GitHub / hebrew_date_picker hebrew_date_picker A Material-style Flutter date picker that shows the Hebrew (Jewish) date alongside the Gregorian one: every day cell shows the Gregorian day and the Hebrew day in letters (e.g. 12 / א׳), the month title shows the Gregorian month and the Hebrew months it covers (e.g. September 2026 / אלול–תשרי תשפ״ז), the header shows the full Hebrew date of the selected day (e.g. א׳ תשרי תשפ״ז), tapping the month title opens a year grid with the Gregorian and the Hebrew years (e.g. 1990 / תש״נ–תשנ״א), so far-away dates are a couple of taps away, a range picker selects a start and an end date, with the Hebrew dates of both in the header. ▶ Try the live demo — no installation needed. Hebrew dates are calculated with kosher_dart and the calendar grid is built on table_calendar. Installation dependencies: hebrew_date_picker: ^0.5.0 Usage As … View on GitHub Feedback, issues and stars are very welcome! 🙏

dartflutteropensourceshowdev
Mobil Yazılımcı Arıyorum: Lisanslı Bilgisayar Mühendisi Çözümü: Production Architecture & Best Practices 2026 (29.10.2026)
10/29 下午04:00

Mobil Yazılımcı Arıyorum: Lisanslı Bilgisayar Mühendisi Çözümü: Production Architecture & Best Practices 2026 (29.10.2026)

Nuh Mehmet Demirkol

Mobil Yazılımcı Arıyorum: Lisanslı Bilgisayar Mühendisi Çözümü Mobil uygulama ekosisteminde ölçeklenebilir ve sürdürülebilir bir sistem inşa etmek için doğru mimari ve mühendislik disiplini şarttır. Clean Architecture katmanları ile iş mantığını ve UI katmanını birbirinden ayırmak bakım maliyetlerini %60 oranında azaltır. Flutter ile tek kod tabanından iOS ve Android için 120 FPS akıcılık elde edilir. Her kurumsal projede %100 açık kaynak kod, Git deposu ve en az 1 yıllık teknik bakım garantisi sağlanmalıdır. 📌 İlgili Özel Sayfa: Mobil Yazılımcı Arıyorum: Lisanslı Bilgisayar Mühendisi Çözümü 🧮 Canlı Maliyet Hesaplama: Mobil Uygulama Maliyet Hesaplama 👨‍💻 Bilgisayar Mühendisi: Nuh Mehmet Demirkol 📞 WhatsApp: +90 507 823 68 11 | Ankara, Türkiye

fluttermobilearchitectureios
The four colors from my first prompt are still in my app. Almost nothing else is.
10/29 下午02:56

The four colors from my first prompt are still in my app. Almost nothing else is.

Cesare Bramante

The four brand colors I wrote in my first prompt in January are still in my app today, to the exact hex code. Almost nothing else from that first sketch survived: not the logo, not the font setup, and certainly not the way I handled five languages. This episode is about the visual identity and the language of the app, and about the AI's role in both. It's the part of the project where I disagreed with the AI the most. In the previous episode I told how one rule in the data model fixed the direction of the whole spec. My first prompt didn't just describe the app. It listed fourteen colors, each with a name and a job: Primary #E040FB, a bright purple, for the main buttons; Secondary #7C4DFF, an electric violet, for links and active states; Accent #FF4081, neon pink, for notifications and social elements; Accent #40C4FF, bright cyan, for status indicators; then backgrounds, text colors, success, warning and error. Today the theme file of the app has the same four codes. It even keeps custom colors named after my January descriptions, translated into English: primaryVibrantPurple, secondaryElectricViolet, accentNeonPink, accentBrightCyan. Some things changed: a different red for errors, the dark backgrounds, and a lime green added later for public events. In August, during a redesign, the AI proposed a calmer look: one single accent color and warm neutrals. It applied it. I looked at it for a day and reverted it. Neon colors read better in both light and dark mode, and the neutral version looked flat. I wrote it down as a product decision not to reopen, because I knew the next session would propose it again. The AI was right about one thing, though. My brand purple on a white background has a contrast ratio of 3.2, below the 4.5 recommended for text. Links moved to a darker violet. The purple stayed for buttons and highlights, where it works. The same January prompt chose the font: Atkinson Hyperlegible, a typeface designed to be easy to read for people with low vision. I wanted an app that anyone could read at a glance, outside, on a small screen. It's still there, but only for titles. In the August redesign the body text moved to Inter, which is denser and works better in lists and small labels. And here is the honest part. The app uses Atkinson and Inter. The website uses three other fonts. A printed flyer I made in August uses yet another family. Three type systems for one small product. The only thing they really share is the logo. If I started again, I would decide one type system for everything on day one, the same way I decided the colors. The first logo, from January 22, was three intertwined circles with a small lime star in the middle. Circles of friends overlapping. I liked it, and I used it in the first test builds. I dropped it after the very first builds for testers, before the public release, and redid it. The new one is a map pin with an orbit around it: a place, not a group of people. Looking back, the logo changed direction before I could say it in words. The app moved from "who" to "where" in the drawing first. I wanted Italian, English, Spanish, French and Romanian from the first prompt, because I knew who I wanted to reach. It still turned out to be the hardest part of the identity, for reasons that had nothing to do with translation. The AI dropped a language. On February 18 the master prompt listed the supported languages as "Italian, Spanish, French, German". Romanian had disappeared and German had appeared. The work plan of the next day set English as the main language and enabled Italian, Spanish and French. Nobody had asked for German. I only noticed because I reread the list. The first screens weren't translated at all. In February the texts were written directly inside the widgets, in Italian: "Sono qui", "Mi piacerebbe". The spec then said every fixed string must go into FlutterFlow's language panel. That worked for labels, but not for everything: messages in snackbars, dialogs and custom code don't live in that panel. So for a while I made a rule: whatever isn't in the panel stays in English, as a common language. In July some screens showed Italian buttons next to English labels. I reversed the rule and translated everything. Today the app has 264 texts in five languages in the language panel, about 145 more translated field by field inside pages and components, and twelve custom code files that carry their own translation tables. The text of the permission requests lives in yet another place. "Five languages" turned out to mean four different places to keep in sync. A language audit found the leaks. An audit in August found sentences where one language had leaked into another: "Bienvenido par" (Spanish with French inside), "Pas besoin di rester" (French with Italian inside), and French that switched between formal and informal "you" across nineteen strings. Some of the best decisions were about words, not code: Concept Italian English Spanish French Romanian Wish Vorre

aidesigni18nflutter

freeCodeCamp

15 條

教學、指南與實踐文章

How to Build a Dart Package Analytics Tool with the pub.dev API: Beyond the 30-Day Window
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
How to Implement LEGO Architecture in Flutter [Full Handbook]
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
How to Use Skills in Agentic Flutter Development: A Handbook for Devs
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
How to Test Flutter Apps: Unit, Widget, Golden, and Integration Tests Explained
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
Mobile Background Execution: iOS Background Modes, Android WorkManager, and Background Services in Dart
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
Chain of Responsibility Design Pattern: Decoupling Complex Business Rules, One Handler at a Time
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
How to Work with Material and Cupertino Decoupling in Flutter [Full Handbook]
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
How to Automate Flutter Releases with Fastlane and GitHub Actions for Firebase App Distribution, Google Play, TestFlight, and App Store Connect
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
Flutter Frontend Systems Design: How to Think Like a Senior Engineer in the AI Age
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
How to Test AI Features in Flutter [Full Handbook]
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
A Deep Dive into Behavioral Patterns: The Visitor Design Pattern and its Clean Operations Across Complex Object Structures
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
Bluetooth Low Energy in Flutter: A Handbook for Devs
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
From RPC to gRPC: Understanding Remote Procedure Calls, Protocol Buffers, and Modern Distributed Systems Communication
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
The Observer Design Pattern Handbook: Event-Driven Architecture & Domain-Driven Design in Dart
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
How to Fix App Jank: A Practical Guide to Profiling Flutter Apps with DevTools
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 條

技術社群討論與專案連結

Building a Flutter IoT app for real-time hydration monitoring in football teams [video]
10/28 下午08:01

Building a Flutter IoT app for real-time hydration monitoring in football teams [video]

Harish_0089

Article URL: https://www.youtube.com/watch?v=FBWaoS4QXsw Comments URL: https://news.ycombinator.com/item?id=50272231 Points: 1 # Comments: 0

Build a Flutter Phone Dialer with Call History
10/21 下午10:38

Build a Flutter Phone Dialer with Call History

lautarolobo

Article URL: https://lautarolobo.xyz/blog/flutter-phone-dialer-call-history/ Comments URL: https://news.ycombinator.com/item?id=50181804 Points: 1 # Comments: 0

Show HN: TutorLoom, an open-source multi-tenant LMS (Django, React, Flutter)
10/21 下午10:22

Show HN: TutorLoom, an open-source multi-tenant LMS (Django, React, Flutter)

madhukarah

Article URL: https://github.com/pacewisdomhq/TutorLoom Comments URL: https://news.ycombinator.com/item?id=50181517 Points: 2 # Comments: 0

Moonswing – A Desktop Environment for Linux in Flutter
10/20 上午04:09

Moonswing – A Desktop Environment for Linux in Flutter

matthewkosarek

Article URL: https://github.com/miracle-wm-org/moonswing Comments URL: https://news.ycombinator.com/item?id=50157418 Points: 1 # Comments: 0

Streaming a coding agent's UI in Flutter: what broke and how we fixed it
10/16 下午04:55

Streaming a coding agent's UI in Flutter: what broke and how we fixed it

narayanahari

Article URL: https://getpullrequest.com/blogs/streaming-agent-ui-in-flutter Comments URL: https://news.ycombinator.com/item?id=50115889 Points: 1 # Comments: 0

A Linux desktop environment in Flutter
10/14 下午09:13

A Linux desktop environment in Flutter

matthewkosarek

Article URL: https://github.com/miracle-wm-org/moonswing Comments URL: https://news.ycombinator.com/item?id=50087239 Points: 1 # Comments: 2

Genkit Dart 1.0: Build production-ready agentic apps with Dart and Flutter
10/11 上午09:09

Genkit Dart 1.0: Build production-ready agentic apps with Dart and Flutter

khalidkhair

Article URL: https://flutter.dev/blog/announcing-genkit-dart-1-0 Comments URL: https://news.ycombinator.com/item?id=50038795 Points: 4 # Comments: 0

Moonswing: A Linux Desktop Environment Built in Flutter
10/09 下午10:53

Moonswing: A Linux Desktop Environment Built in Flutter

matthewkosarek

Article URL: https://github.com/miracle-wm-org/moonswing Comments URL: https://news.ycombinator.com/item?id=50021374 Points: 2 # Comments: 1

PomoPlan – Local-first Pomodoro, task, and habit tracker in Flutter
10/08 下午10:22

PomoPlan – Local-first Pomodoro, task, and habit tracker in Flutter

bentamara

Article URL: https://play.google.com/store/apps/details?id=com.pomoplan.pomoplan&hl=en_US Comments URL: https://news.ycombinator.com/item?id=50006163 Points: 2 # Comments: 0

10/08 下午04:09

Ask HN: Preferred state management for enterprise Flutter in 2026?

nmdemirkol

When scaling Flutter mobile apps to enterprise level, what state management approach (BLoC, Riverpod, Signals, etc.) have you found most maintainable over time? Interested in experiences regarding testability and onboarding. Comments URL: https://news.ycombinator.com/item?id=50003115 Points: 2 # Comments: 0

Friday – A voice-activated personal AI companion built with Flutter
10/07 下午11:34

Friday – A voice-activated personal AI companion built with Flutter

ddhruv2424

Article URL: https://github.com/dj2313/jarvis_assistant Comments URL: https://news.ycombinator.com/item?id=49994302 Points: 2 # Comments: 0

Show HN: Vynody – Cross-platform music player written in Flutter and Rust
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: 5 # 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

Show HN: I compiled FreeRDP into a Flutter app so my phone can do RDP and SSH
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

I ported a VB6 game to Flutter and generated all 14 art themes
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

Kelivo: A Flutter LLM Chat Client. Support Mobile and Desktop
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

Show HN: CocoCut – A zero-cloud, 1-second video diary engine built with Flutter
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

Medium

10 條

Flutter 相關文章精選

Building a Mobile App with AI: Week 2 — AI Is Your Partner, Not Your Boss
10/30 上午07:17

Building a Mobile App with AI: Week 2 — AI Is Your Partner, Not Your Boss

Saliha Kansiz Yazici

Better Context, Better Code, Better Decisions: Practical Lessons from Building WordBloom with Flutter and ChatGPT Continue reading on Medium »

artificial-intelligenceflutterprogrammingsoftware-development
Your next Google Play update will be rejected if it still ships Billing Library 7 (Nov 1, 2026)
10/30 上午03:55

Your next Google Play update will be rejected if it still ships Billing Library 7 (Nov 1, 2026)

Emre P.

Not a developer? Read this first. If Play Console shows a warning like “Update to a newer version of Google Play Billing Library” or… Continue reading on Medium »

google-playflutterandroidbilling
Understanding Android Home Screen Widgets in Flutter
10/30 上午03:36

Understanding Android Home Screen Widgets in Flutter

Crescent Sambila

Since you develop apps with Flutter, the first thing to understand is that an Android home screen widget is different from a Flutter… Continue reading on Medium »

flutter-app-developmenton-screen-widgetflutternotifications
El botón rojo de las tiendas: cómo pedir una revisión acelerada cuando producción se rompe
10/30 上午03:06

El botón rojo de las tiendas: cómo pedir una revisión acelerada cuando producción se rompe

Hector Veitia

Cuando una versión rota llega a producción, el código se arregla en minutos; lo que tarda es la tienda. Continue reading on Medium »

android-developmentsoftware-engineeringmobile-app-developmentios-development
Beyond HTTPS: What Mobile Engineers Need to Know About Certificate Pinning
10/30 上午12:41

Beyond HTTPS: What Mobile Engineers Need to Know About Certificate Pinning

Sharanya Bharghavi

Certificate pinning for Flutter, Android, and iOS developers — what it protects, where it belongs, and how to ship it safely. Continue reading on Medium »

mobile-developmentdevsecopscybersecuritynetwork-security
React Native vs Flutter (2026): Which Should You Choose?
10/29 下午11:41

React Native vs Flutter (2026): Which Should You Choose?

EchoInnovate IT — Engineering

React Native vs Flutter: which should you choose in 2026? Continue reading on EchoInnovate IT »

cross-platformprogrammingreact-nativeflutter
Your Flutter App Works. But Is Your Code Ready for Production?
10/29 下午11:26

Your Flutter App Works. But Is Your Code Ready for Production?

DevCode

Your Flutter app runs without errors. The screens look beautiful, buttons respond to taps, and your API requests return the expected data. Continue reading on Stackademic »

mobile-app-developmentflutter-app-developmentflutterprogramming
Flutter State Management: Provider vs GetX vs BLoC vs Cubit vs Riverpod Which Should You Choose ?
10/29 下午10:24

Flutter State Management: Provider vs GetX vs BLoC vs Cubit vs Riverpod Which Should You Choose ?

Yuvanraj Arumugam

A practical comparison of five popular Flutter state management approaches to help you make an informed decision for your next application. Continue reading on Medium »

mobile-app-developmenttechnologyprogrammingflutter
The UI reads only from local: connecting Drift to Flutter screens with Riverpod
10/29 下午09:21

The UI reads only from local: connecting Drift to Flutter screens with Riverpod

KEVIN ZIYADA ASERU

Your users’ answers are saved on the phone. So why does the screen still wait for the network? Part 3 of Built for Us. Continue reading on Medium »

mobile-app-developmentoffline-firstflutterdart
Stop Guessing Why Your Flutter Web App Is Slow: Profile It
10/29 下午08:31

Stop Guessing Why Your Flutter Web App Is Slow: Profile It

Wartelski.

Before you optimize another widget rebuild, measure. Continue reading on Medium »

dartperformanceflutterflutter-web

Reddit

13 條

社群日榜討論與資源

10/30 上午12:54

Showcasing WelkUI : A comic-inspired, bold UI library for React & Flutter (160/160 Pub Points, 40+ Components)

/u/Noob_Master_007

Hey everyone! I got tired of building apps that look like every other generic material/tailwind dashboard, so I spent the last few months building WelkUI : an open-source UI library with a literal plot twist. It brings hand-drawn energy, uneven corners, bold outlines, and playful animations to your interfaces without breaking responsiveness or accessibility. The Cool Part: I built it natively for both ecosystems. You can completely match your web app's style with your mobile app. Flutter Edition: 40+ widgets, deeply analyzed with a perfect 160/160 score on pub.dev. React Edition: 30+ components, fully typed with strict Next.js client boundary support. Get Started: Live Previews & Interactive Docs: ui.welkdock.com Flutter Docs: ui.welkdock.com/flutter GitHub: https://github.com/welkdock/welkUI-flutter Everything is mobile-first, respects reduced motion, and is ready to install in one line (npm i or flutter pub add). I’d love to hear your feedback on the aesthetic! What widgets or components should I build next for the comic collection? submitted by /u/Noob_Master_007 [link] [comments]

10/29 下午02:05

Flutter Developers: Best Ad Network for a Kids' Educational App? Looking for Safe Ads and Good Revenue

/u/saddamsk0

Hi everyone! 👋 I'm an indie developer working on kya ds educational application, a kids' educational app built using Flutter. The app helps children learn alphabets, numbers, colors, shapes, drawing, and more. I want to monetize my app while ensuring that all ads are child-friendly and comply with Google Play's Families Policy. I'd appreciate advice from Flutter developers who have experience monetizing kids' apps. My questions: Is Google AdMob the best option, or are there better alternatives for Flutter apps targeting children? How can I ensure that only child-appropriate ads appear in my app? Which ad formats are best for kids' educational apps? How should I configure child-directed ad treatment and other safety settings in Flutter? Which ad network offers better earning potential for users primarily from India? What is the best approach to maximize revenue without compromising children's safety or learning experience? I'm looking for a solution that's free to integrate, suitable for a Flutter app, compliant with Google Play policies, and offers reasonable earning potential. If you've monetized a kids' app, I'd love to hear about your experience, recommended ad networks, Flutter packages, and implementation tips. Thanks in advance! 🙏 submitted by /u/saddamsk0 [link] [comments]

10/29 下午05:30

Which bug-reporting products do you use for Flutter-based apps?

/u/Chance-Ad-39

submitted by /u/Chance-Ad-39 [link] [comments]

10/29 下午02:50

How do you automate Flutter app testing and product demo recordings?

/u/No_Dealer21

Hey Flutter devs! I'm looking for tools to automate Flutter app testing and record professional product demos without manually navigating through every screen. Ideally, something that can automate taps, navigation, form inputs, and record the entire flow. What tools or workflows are you guys using? Any AI-powered solutions? Would appreciate recommendations from anyone who's done this! submitted by /u/No_Dealer21 [link] [comments]

10/30 上午07:06

I've create a network analyzer for flutter

/u/Fit-Development-6842

Hii! For anyone who might be interested, I've developed https://github.com/RiccardoCherchi/flutrace It's a network analyzer (similar to the one you get with Flutter's built-in Network Inspector), but done a little better. Even though it has improved a bit over the last 3 years, I've always found the native analyzer quite clunky, with a somewhat ugly UI, and also inconvenient because every time you restarted, everything was lost and you had to reopen the link, etc. etc... That's why I decided to "slop" together a tool that would allow me to have a decent analyzer without having to proxy everything through Burp Suite just to inspect some basic HTTP requests 😂 Let me know what you think! Of course, PRs from humans and not are more than welcome. It's MIT licensed, do whatever you want with it. There are no contributing guidelines and, obviously, I won't be actively maintaining it (except maybe every now and then, just for fun), so you might as well fork it instead. submitted by /u/Fit-Development-6842 [link] [comments]

10/29 下午03:41

Need suggestions for improving network debugging in Flutter

/u/Luffy-SR

Hi everyone, I'm working on a Flutter network debugging tool called Netoscope, and I need some advice from experienced Flutter developers. https://pub.dev/packages/netoscope I'm trying to improve how network requests and responses are inspected during development, especially when working with Dio, HTTP, GraphQL, WebSockets, and other protocols. I'm looking for help with these questions: What is the best approach to capture network traffic from different clients in a Flutter app? How can I reliably detect duplicate API requests and potential N+1 request patterns? What is the recommended way to redact sensitive data before storing or displaying network logs? Are there any Flutter-specific limitations I should consider when implementing a network inspector? I'd appreciate any suggestions, best practices, or examples. Thank you! submitted by /u/Luffy-SR [link] [comments]

10/29 下午12:16

Don't add a library, generate the code instead for your graphql!

/u/graphlinkdev

Hey, I just shared the first video tutorial as how you can use graphlink for generating graphql clients. I will not be long, here is the link of the full video https://youtu.be/78LYiuWLKIU The video explains, on a plain dart project how you can use graphlink cli tool (glink) to generate a fully type, null-safe optimized graphql client that works with all backends. The generated code can be used on any dart project, flutter or Jaspr. I will be adding more videos and going deeper in how you can create custom graphql client, handling subscriptions, file uploads, caching and more. Stay tuned. #dart #graphql #graphlink #flutter #jaspr submitted by /u/graphlinkdev [link] [comments]

10/30 上午07:21

Any criticism to this video on Flutter and React Native?

/u/peetyo5k

submitted by /u/peetyo5k [link] [comments]

10/30 上午07:01

You don't need a library for your graphql client, GENERATE IT.

/u/graphlinkdev

Hey, I just shared the first video tutorial as how you can use graphlink for generating graphql clients. I will not be long, here is the link of the full video [https://youtu.be/78LYiuWLKIU\](https://youtu.be/78LYiuWLKIU) The video explains, on a plain dart project how you can use graphlink cli tool (glink) to generate a fully type, null-safe optimized graphql client that works with all backends. The generated code can be used on any dart project, flutter or Jaspr. I will be adding more videos and going deeper in how you can create custom graphql client, handling subscriptions, file uploads, caching and more. Stay tuned. \#dart #graphql #graphlink #flutter #jaspr submitted by /u/graphlinkdev [link] [comments]

10/29 下午12:15

You don't need a library for your graphql client, GENERATE IT.

/u/graphlinkdev

submitted by /u/graphlinkdev [link] [comments]

10/29 下午01:14

Deepseek for mobile game dev

/u/Frosty-Article-9635

I’m a mobile dev experimenting with DeepSeek for game development — mostly small games, currently looking at a tiny 3D kids’ game and some Flutter/Flame prototyping. I’m not asking “is DeepSeek good?” in general. I want real experiences from people who’ve actually used it for mobile game work — code generation, debugging, game logic, prototyping, build/test loops, etc. Specifically curious about: · Which model/version you use (Flash vs Pro, API vs chat) and whether it matters for game code. · What it’s good at: scaffolding, gameplay loops, state machines, UI, shaders, physics, save systems? · Where it fails: outdated engine APIs, hallucinated functions, broken mobile/platform code, performance-unaware suggestions? · Workflow: do you use it chat-style, spec-driven, agentic tools, or just autocomplete? · Debugging: can it actually fix build/runtime errors, or does it loop? · Cost/token burn for realistic game projects. · Anything you wish you knew earlier before using it for mobile games. If you’ve used it with Flutter/Flame, Unity, Godot, or native mobile, I’d especially like to hear which engine and what worked or didn’t. submitted by /u/Frosty-Article-9635 [link] [comments]

10/29 下午01:03

I built another Flutter app: FanCAD, a 2D CAD application.

/u/Smooth_Constant_8170

I’ve been experimenting with AI-assisted development and decided to build a CAD application from scratch using AI. The project is called FanCAD. It’s still a work in progress, but I thought it would be interesting to share. GitHub: https://github.com/sjjian/FanCAD submitted by /u/Smooth_Constant_8170 [link] [comments]

10/30 上午04:21

I built a Christian Bible app – just shipped a full redesign (Flutter)

/u/Efficient-Repair5016

Hi! I'm a student in Norway and I've been building Koinos alone: a Bible app with reading plans, a church finder with service times, an AI you can ask faith questions, and a small community. Version 1.2.0 is a full redesign. It's built with Flutter + Firebase and runs on iPhone, iPad, Mac and Windows. I'd love honest feedback on the design. And if you have an Android phone, I need a few testers for 2 weeks before the Play Store launch – comment or DM me. koinos.faith submitted by /u/Efficient-Repair5016 [link] [comments]

FAQ

常見問題