Hola, I’m Hieu, a Software Engineer

Channels are great for infrequent events; FFI wins for hot data paths. Bài này chuyển quan sát đó thành một mô hình nhỏ để bạn có thể kiểm thử, đo lường và giữ cho code dễ bảo trì khi app lớn lên. Vấn đề cốt lõi Throughput, types, and when to reach for flutter_rust_bridge. Câu hỏi hữu ích không phải API hay pattern có đẹp riêng lẻ hay không, mà là state nằm ở đâu, boundary nào chịu trách nhiệm khi lỗi xảy ra, và người dùng phục hồi thế nào khi happy path biến mất. Mô hình thực tế Hybrid apps like RustDesk show a hard boundary between UI loop and data loop. Hãy bắt đầu bằng một owner rõ ràng cho behavior. Widget chỉ nên render và phát intent; IO, persistence, permission và retry nên nằm sau một interface nhỏ. Nhờ vậy bạn có seam để fake trong test và một chỗ ghi lại các dữ kiện cần theo dõi ở production. Trong app Flutter, boundary thường có dạng: Widget phát intent như load, submit, refresh hoặc retry. Controller hoặc use case validate intent rồi gọi boundary. Boundary trả v...

Channels are great for infrequent events; FFI wins for hot data paths. This article turns that observation into a small implementation model you can test, measure, and keep boring when the app grows. The problem in one sentence Throughput, types, and when to reach for flutter_rust_bridge. The useful question is not whether the API or pattern looks elegant in isolation. It is where state lives, which boundary owns failure, and how a user recovers when the happy path disappears. A practical model Hybrid apps like RustDesk show a hard boundary between UI loop and data loop. Start with one explicit owner for the behavior. Keep widgets responsible for rendering and user intent; keep IO, persistence, permissions, and retries behind a small interface. That gives you a seam for a fake in tests and a place to record the facts that matter in production. For a Flutter app, the boundary usually looks like this: The widget emits an intent such as load, submit, refresh, or retry. A control...

App Flutter nào rồi cũng đến lúc cần một thứ mà Dart tự nó không làm được. Đọc mức pin. Mở camera. Xin quyền. Giải mã một codec video lạ. Chạy model on-device. Kiểm tra chữ ký bằng một thư viện crypto đã được audit hai mươi năm và chẳng ai định viết lại bằng Dart. Câu trả lời quen thuộc — “dùng platform channel” — chỉ đúng khoảng một phần ba số trường hợp. Flutter có ba cơ chế riêng biệt để rời khỏi Dart, và chúng không phải ba cách hiện thực cùng một ý tưởng. Chúng giải quyết những bài toán khác nhau, và lỗi phổ biến nhất là chọn cái bạn đã biết thay vì cái phù hợp. Nói ngắn gọn: MethodChannel và EventChannel là một hàng đợi tin nhắn bất đồng bộ tới code Kotlin/Swift, đúng thứ bạn cần khi bên kia là một dịch vụ của hệ điều hành . Pigeon vẫn là hàng đợi đó, nhưng phần boilerplate và các hằng chuỗi được sinh ra tự động. dart:ffi thì không phải hàng đợi gì cả — nó là một lời gọi hàm C trực tiếp, đồng bộ, vào một thư viện đang nằm sẵn trong tiến trình của bạn. Bài này đưa một ví ...

Every Flutter app eventually needs something Dart cannot do on its own. Read the battery level. Open the camera. Ask for a permission. Decode an exotic video codec. Run an on-device model. Verify a signature with a crypto library that has been audited for twenty years and that nobody is going to reimplement in Dart. The usual answer — “use a platform channel” — is right about a third of the time. Flutter ships three separate mechanisms for leaving Dart, and they are not competing implementations of the same idea. They solve different problems, and the most common mistake is picking the one you already know rather than the one that fits. The short version: MethodChannel and EventChannel are an asynchronous message queue to Kotlin/Swift code, which is what you want when the thing on the other side is a platform service . Pigeon is the same message queue with the boilerplate and the string constants generated for you. dart:ffi is not a message queue at all — it is a direct, synchro...