Flutter and iOS app extensions without a second UI stack — hướng dẫn Flutter
Extensions must stay tiny. Share logic via app groups and files. 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
Share extensions, widgets, and shared app groups. 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ế
Do not embed a full Flutter engine in a Today widget.
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ề data có kiểu hoặc failure có kiểu, không trả string chỉ dành cho log.
- UI render tường minh loading, empty, success và failure.
Hình dạng này không phụ thuộc bạn dùng setState, Bloc, Riverpod hay state layer khác. Quyết định quan trọng là ownership, không phải tên package.
Ví dụ tối thiểu
Thử nghiệm nhỏ nhất thường đủ để lộ trade-off:
UserDefaults(suiteName: 'group.com.example.app')Đặt ví dụ sau một interface theo feature, rồi thêm một test cho success và một test cho failure. Nếu ví dụ cần global state mới chạy được thì boundary có thể đang đặt sai chỗ.
Checklist trước khi ship
- Xác định lifecycle: ai bắt đầu, ai hủy, và cái gì sống qua restart?
- Đo kết quả người dùng thấy: frame time, bytes, latency, conversion hoặc thời gian hồi phục.
- Giữ code platform-specific ở edge và ghi rõ yêu cầu OS/SDK tối thiểu.
- Viết empty state và offline/error state trước khi chăm chút polish.
- Log id và timing, nhưng phải redact token, dữ liệu cá nhân và payload đầy đủ.
- Rollout có đường lui: feature flag, staged release hoặc fallback phía server.
Cạm bẫy nên xử lý sớm
Extensions have strict memory limits — fail fast and reopen the main app. Lỗi thường gặp là demo chạy đúng nhưng cancellation, retry, permission, accessibility và hành vi khi upgrade lại bị bỏ ngỏ. Khi app có user thật, đó không còn là edge case. Hãy test ít nhất một thiết bị chậm, một request bị ngắt mạng và một process restart nếu chủ đề này ảnh hưởng lifecycle hoặc storage.
Đánh giá kết quả
Ghi baseline trước khi sửa. So sánh cùng user journey trên cùng nhóm thiết bị, rồi xem cả median lẫn failure tệ nhất mà người dùng nhìn thấy. Một diff nhỏ có rollback rõ thường an toàn hơn rewrite toàn framework. Lưu quyết định và bằng chứng cạnh code để lần upgrade sau không phải tranh luận lại từ đầu.
Đọc thêm các chủ đề liên quan: Home screen widgets with Flutter shells và App Clips and Instant Apps with Flutter modules.