TÌM HIỂU CHI TIẾT VỀ FIREBASE CLOUD MESSAGING (FCM) TRONG FLUTTER

1. Firebase Cloud Messaging (FCM) là gì?

Trong quá trình phát triển ứng dụng di động, ngoài việc hiển thị thông tin khi người dùng đang sử dụng ứng dụng, lập trình viên còn cần có cơ chế gửi thông báo đến thiết bị khi có sự kiện mới xảy ra.

Ví dụ, trong một ứng dụng bán hàng, khi khách hàng đặt hàng thành công, đơn hàng được xác nhận hoặc chuyển sang trạng thái đang giao hàng, hệ thống có thể gửi thông báo đến điện thoại của khách hàng. Người dùng không cần liên tục mở ứng dụng để kiểm tra trạng thái đơn hàng.

Để thực hiện chức năng này, Flutter có thể tích hợp Firebase Cloud Messaging (FCM).

Firebase Cloud Messaging là dịch vụ nhắn tin đa nền tảng do Google cung cấp, cho phép hệ thống gửi thông điệp đến ứng dụng trên các thiết bị được hỗ trợ, chẳng hạn như Android, iOS và Web.

FCM thường được sử dụng để triển khai Push Notification, tức thông báo được gửi từ máy chủ đến thiết bị thông qua hệ thống phân phối thông báo.

Ví dụ, khách hàng đặt một đơn hàng trong ứng dụng. Khi nhân viên cửa hàng xác nhận đơn, Backend có thể gửi yêu cầu đến FCM. FCM tiếp nhận thông điệp và phối hợp với hệ thống thông báo của nền tảng để chuyển thông điệp đến ứng dụng trên điện thoại khách hàng.

Thông báo có thể hiển thị với nội dung:

“Đơn hàng #1001 của bạn đã được xác nhận.”

Khi người dùng nhấn vào thông báo, ứng dụng có thể mở trang chi tiết đơn hàng tương ứng.

Như vậy, FCM đóng vai trò là một dịch vụ trung gian hỗ trợ gửi thông điệp từ hệ thống đến ứng dụng, giúp người dùng cập nhật thông tin mà không cần chủ động kiểm tra liên tục.

2. Tại sao ứng dụng cần Firebase Cloud Messaging?

Nếu không có cơ chế Push Notification, ứng dụng thường chỉ cập nhật thông tin khi người dùng mở ứng dụng hoặc chủ động thực hiện thao tác tải dữ liệu.

Ví dụ, một khách hàng đã đặt hàng và thoát ứng dụng. Sau đó, cửa hàng xác nhận đơn hàng. Nếu không có thông báo, khách hàng có thể không biết đơn đã được xử lý cho đến khi mở ứng dụng trở lại.

FCM giúp giải quyết vấn đề này bằng cách hỗ trợ gửi thông điệp đến thiết bị khi có sự kiện cần thông báo.

FCM được sử dụng trong nhiều loại ứng dụng:

• Ứng dụng thương mại điện tử: thông báo xác nhận đơn hàng, trạng thái vận chuyển hoặc chương trình khuyến mãi.
• Ứng dụng nhắn tin: thông báo có tin nhắn mới.
• Ứng dụng ngân hàng: thông báo biến động hoặc sự kiện tài khoản theo cơ chế bảo mật phù hợp.
• Ứng dụng học tập: nhắc lịch học, thông báo bài tập hoặc thông tin mới.
• Ứng dụng đặt lịch: nhắc cuộc hẹn hoặc thông báo thay đổi lịch.

Tuy nhiên, FCM không bảo đảm mọi thông điệp đều được gửi đến hoặc hiển thị ngay lập tức. Việc phân phối phụ thuộc vào kết nối mạng, hệ điều hành, quyền thông báo, tình trạng thiết bị, loại thông điệp và những chính sách của nền tảng.

Vì vậy, đối với những thông tin quan trọng như trạng thái đơn hàng, Backend vẫn phải lưu trạng thái thực tế trong cơ sở dữ liệu. Thông báo chỉ nên là phương tiện giúp người dùng biết rằng có thay đổi, không phải nguồn dữ liệu duy nhất để xác định trạng thái của đơn hàng.

3. Firebase là gì và FCM nằm ở đâu trong Firebase?

Firebase là một nền tảng cung cấp nhiều dịch vụ hỗ trợ phát triển ứng dụng, bao gồm xác thực người dùng, cơ sở dữ liệu, lưu trữ tệp, phân tích hành vi, báo cáo lỗi và nhắn tin.

FCM là một dịch vụ thuộc hệ sinh thái Firebase, tập trung vào việc gửi thông điệp đến ứng dụng.

Điều này có nghĩa là ứng dụng không bắt buộc phải sử dụng toàn bộ các dịch vụ Firebase mới có thể sử dụng FCM.

Ví dụ, một ứng dụng Flutter có thể sử dụng Laravel làm Backend, MySQL làm cơ sở dữ liệu và chỉ tích hợp Firebase Cloud Messaging để gửi thông báo.

Trong kiến trúc này, Laravel vẫn chịu trách nhiệm xử lý đơn hàng, kiểm tra quyền truy cập và lưu trữ dữ liệu. Firebase Cloud Messaging chỉ tham gia vào quá trình phân phối thông điệp đến thiết bị.

Cách kết hợp này rất phổ biến vì cho phép lập trình viên sử dụng FCM mà không cần thay thế Backend hiện có.

4. Push Notification là gì?

Push Notification là thông báo được hệ thống gửi đến thiết bị hoặc ứng dụng mà không cần người dùng chủ động thực hiện một yêu cầu lấy thông báo tại thời điểm đó.

Ví dụ, khi một đơn hàng chuyển sang trạng thái đang giao hàng, hệ thống có thể gửi thông báo đến điện thoại khách hàng.

Cần phân biệt Push Notification với việc ứng dụng liên tục gọi API để kiểm tra dữ liệu mới.

Khi sử dụng phương pháp gọi API liên tục, thường được gọi là polling, ứng dụng phải định kỳ gửi yêu cầu đến Backend để hỏi có thay đổi hay không.

Trong khi đó, Push Notification sử dụng hạ tầng phân phối thông điệp của nền tảng để chuyển thông tin đến ứng dụng khi hệ thống gửi thông điệp.

FCM giúp giảm nhu cầu polling chỉ để phát hiện một số sự kiện, nhưng không thay thế hoàn toàn API.

Ví dụ, khi nhận thông báo “Đơn hàng đang được giao”, ứng dụng vẫn nên gọi API để lấy thông tin đơn hàng mới nhất nếu người dùng mở trang chi tiết.

5. Kiến trúc hoạt động của Firebase Cloud Messaging

Để hiểu rõ FCM, cần xác định các thành phần tham gia vào quá trình gửi thông điệp.

5.1. Ứng dụng Flutter

Đây là ứng dụng được cài đặt trên điện thoại người dùng.

Ứng dụng tích hợp Firebase SDK và package firebase_messaging để đăng ký nhận thông điệp, lấy registration token và xử lý thông điệp khi nhận được.

5.2. Backend

Backend là hệ thống quản lý nghiệp vụ của ứng dụng.

Ví dụ, Backend Laravel xử lý đơn hàng và biết khi nào đơn hàng được xác nhận hoặc giao thành công.

Khi có sự kiện cần thông báo, Backend quyết định gửi thông điệp nào và gửi cho thiết bị nào.

5.3. Firebase Cloud Messaging

FCM tiếp nhận yêu cầu gửi thông điệp từ môi trường máy chủ được cấp quyền, xử lý định tuyến và chuyển thông điệp thông qua cơ chế phân phối phù hợp với nền tảng.

5.4. Hệ điều hành và dịch vụ thông báo

Trên Android, FCM thường phối hợp với các dịch vụ của Google để phân phối thông điệp.

Trên iOS, việc phân phối thông báo từ xa liên quan đến Apple Push Notification service (APNs). Vì vậy, ứng dụng iOS cần cấu hình những thành phần Apple tương ứng.

Hệ điều hành có quyền quyết định nhiều khía cạnh của việc hiển thị thông báo, đặc biệt khi ứng dụng đang chạy nền hoặc đã bị đóng.

5.5. Luồng gửi thông báo

Ví dụ, hệ thống muốn thông báo đơn hàng đã được xác nhận.

Quá trình có thể diễn ra như sau:

1. Người dùng đăng nhập vào ứng dụng Flutter.
2. Ứng dụng lấy FCM registration token của thiết bị.
3. Ứng dụng gửi token lên Backend qua API được xác thực.
4. Backend lưu token và liên kết với tài khoản hoặc phiên thiết bị phù hợp.
5. Nhân viên xác nhận đơn hàng.
6. Backend cập nhật trạng thái đơn hàng trong cơ sở dữ liệu.
7. Backend gửi yêu cầu đến FCM bằng thông tin xác thực phía máy chủ.
8. FCM tiếp nhận và cố gắng phân phối thông điệp đến thiết bị.
9. Thiết bị nhận thông điệp và xử lý tùy theo trạng thái ứng dụng.
10. Khi người dùng nhấn thông báo, Flutter có thể điều hướng đến trang chi tiết đơn hàng.

Có thể tóm tắt:

Backend → FCM → Hệ thống thông báo của thiết bị → Flutter → Người dùng

Điểm quan trọng là Backend không nên phụ thuộc vào kết quả hiển thị thông báo để xác định đơn hàng đã được cập nhật thành công hay chưa. Trạng thái nghiệp vụ phải được lưu trong cơ sở dữ liệu.

6. FCM Registration Token là gì?

Registration Token, thường được gọi là FCM Token, là một giá trị dùng để xác định một phiên cài đặt ứng dụng nhằm phục vụ việc định tuyến thông điệp.

Ví dụ, khi ứng dụng Flutter được cấu hình FCM và khởi tạo phù hợp, ứng dụng có thể lấy token thông qua Firebase Messaging SDK.

final token = await FirebaseMessaging.instance.getToken();

print(token);

Đây là ví dụ minh họa cách lấy token. Để chạy được, dự án phải cấu hình Firebase đúng cách và đáp ứng những yêu cầu riêng của từng nền tảng.

Token không phải là mật khẩu của người dùng và cũng không phải access token đăng nhập vào Backend.

FCM Token có thể thay đổi theo thời gian, chẳng hạn khi ứng dụng được cài đặt lại, dữ liệu ứng dụng thay đổi hoặc dịch vụ cấp lại token.

Vì vậy, Backend không nên mặc định token tồn tại vĩnh viễn.

Flutter có thể lắng nghe sự kiện token được cập nhật:

FirebaseMessaging.instance.onTokenRefresh.listen(
  (newToken) async {
    // Gửi token mới lên Backend.
  },
);

Khi token thay đổi, ứng dụng cần cập nhật thông tin trên Backend để hệ thống tiếp tục gửi thông báo đến đúng thiết bị.

Ngoài ra, một người dùng có thể đăng nhập trên nhiều thiết bị, do đó Backend có thể cần quản lý nhiều token cho cùng một tài khoản.

Khi người dùng đăng xuất, ứng dụng cũng cần xử lý liên kết giữa token và tài khoản để tránh gửi thông báo cá nhân cho người không còn đăng nhập.

7. Phân biệt Notification Message và Data Message

FCM hỗ trợ các kiểu thông điệp khác nhau. Hai loại thường gặp là Notification Message và Data Message.

7.1. Notification Message

Notification Message chứa nội dung thông báo như tiêu đề và nội dung.

Ví dụ:

{
  "notification": {
    "title": "Đơn hàng đã xác nhận",
    "body": "Đơn hàng #1001 của bạn đã được xác nhận."
  }
}

Đây là ví dụ phần dữ liệu thông báo, không phải toàn bộ HTTP v1 API Request gửi đến FCM.

Loại thông điệp này phù hợp khi hệ thống muốn hiển thị thông báo trực quan cho người dùng.

Tùy trạng thái ứng dụng và nền tảng, hệ điều hành hoặc Firebase SDK có thể hỗ trợ hiển thị thông báo tự động.

7.2. Data Message

Data Message chứa dữ liệu tùy chỉnh để ứng dụng xử lý.

Ví dụ:

{
  "data": {
    "type": "order_update",
    "order_id": "1001",
    "status": "shipping"
  }
}

Thông điệp này không nhất thiết chứa tiêu đề và nội dung hiển thị.

Ứng dụng có thể sử dụng các giá trị như type, order_id và status để xác định cần thực hiện hành động gì.

Một điểm cần lưu ý là các giá trị trong phần data của FCM được biểu diễn dưới dạng chuỗi. Nếu cần sử dụng giá trị số hoặc Boolean, ứng dụng phải tự chuyển đổi.

7.3. Thông điệp kết hợp

FCM cũng hỗ trợ thông điệp có cả phần notification và data.

Ví dụ, hệ thống gửi thông báo cho người dùng biết đơn hàng đang được giao, đồng thời đính kèm order_id để khi người dùng nhấn vào thông báo, ứng dụng có thể mở đúng đơn hàng.

Tuy nhiên, cách xử lý thông điệp kết hợp có thể khác nhau giữa foreground, background và terminated. Vì vậy, cần kiểm thử trên từng nền tảng thay vì giả định mọi trường hợp đều hoạt động giống nhau.

8. Các trạng thái ứng dụng khi nhận FCM

Khi triển khai FCM, một vấn đề quan trọng là trạng thái hiện tại của ứng dụng.

8.1. Foreground

Foreground là trạng thái ứng dụng đang được mở và hiển thị trên màn hình.

Ví dụ, người dùng đang xem danh sách sản phẩm và hệ thống gửi thông báo đơn hàng.

Trong Flutter, có thể lắng nghe thông điệp khi ứng dụng đang foreground:

FirebaseMessaging.onMessage.listen(
  (RemoteMessage message) {
    print('Nhận thông điệp: ${message.messageId}');
    print('Dữ liệu: ${message.data}');
  },
);

Trên nhiều cấu hình, thông báo nhận khi ứng dụng đang foreground không tự động xuất hiện dưới dạng banner hệ thống như lúc ứng dụng chạy nền.

Nếu muốn hiển thị thông báo trực quan khi ứng dụng đang mở, lập trình viên có thể cần cấu hình quyền hiển thị foreground phù hợp hoặc kết hợp thư viện local notification, tùy nền tảng.

8.2. Background

Background là trạng thái ứng dụng không hiển thị trực tiếp trên màn hình nhưng vẫn tồn tại trong hệ thống.

Khi nhận thông điệp, cách xử lý phụ thuộc vào loại message và nền tảng.

Flutter có thể đăng ký background handler:

@pragma('vm:entry-point')
Future<void> firebaseMessagingBackgroundHandler(
  RemoteMessage message,
) async {
  await Firebase.initializeApp();

  print('Thông điệp nền: ${message.messageId}');
}

Sau đó đăng ký handler trong quá trình khởi tạo ứng dụng:

FirebaseMessaging.onBackgroundMessage(
  firebaseMessagingBackgroundHandler,
);

Đoạn code này cần được đặt trong cấu trúc ứng dụng phù hợp, có import Firebase và cấu hình khởi tạo chính xác.

Đối với Android, background handler có thể được thực thi trong một isolate riêng. Vì vậy, không nên trực tiếp thao tác với giao diện hoặc sử dụng BuildContext bên trong handler.

Ngoài ra, hệ điều hành có thể giới hạn việc xử lý nền để tiết kiệm pin và tài nguyên. Không nên coi background message là một cơ chế thực thi công việc luôn được bảo đảm.

8.3. Terminated

Terminated là trạng thái ứng dụng không còn chạy.

Trong một số trường hợp, người dùng nhấn vào thông báo có thể khiến ứng dụng được khởi chạy và mở nội dung liên quan.

Flutter có thể kiểm tra thông điệp đã mở ứng dụng bằng getInitialMessage().

Tuy nhiên, khi ứng dụng bị người dùng buộc dừng hoặc hệ điều hành áp dụng những hạn chế đặc biệt, việc nhận và xử lý thông điệp có thể bị ảnh hưởng.

Do đó, cần kiểm thử trên thiết bị thật, đặc biệt với Android và iOS.

9. Điều hướng khi người dùng nhấn thông báo

Một tính năng phổ biến là mở đúng màn hình khi người dùng nhấn vào thông báo.

Ví dụ, thông điệp có dữ liệu:

{
  "type": "order_update",
  "order_id": "1001"
}

Khi người dùng nhấn vào thông báo, ứng dụng có thể đọc order_id rồi điều hướng đến trang chi tiết đơn hàng.

Trong Flutter, hai cơ chế thường được sử dụng là:

• FirebaseMessaging.onMessageOpenedApp: Xử lý trường hợp ứng dụng được mở từ background thông qua thông báo.
• FirebaseMessaging.instance.getInitialMessage(): Kiểm tra thông điệp đã khiến ứng dụng được khởi chạy từ trạng thái terminated.

Khi xử lý điều hướng, cần kiểm tra dữ liệu trước khi sử dụng.

Ví dụ, nếu thông báo chứa order_id không hợp lệ hoặc người dùng không có quyền xem đơn hàng đó, ứng dụng không được bỏ qua bước kiểm tra quyền truy cập.

Thông báo chỉ nên cung cấp thông tin để xác định nội dung cần mở. Quyền truy cập thực tế vẫn phải được Backend xác minh.

10. Gửi thông báo từ Backend như thế nào?

Trong hệ thống thực tế, Backend thường gửi thông điệp bằng Firebase Admin SDK hoặc FCM HTTP v1 API.

Ví dụ, khi Laravel xác nhận đơn hàng, Backend có thể tạo yêu cầu gửi thông điệp đến FCM.

Một payload minh họa của FCM HTTP v1 API:

{
  "message": {
    "token": "FCM_REGISTRATION_TOKEN",
    "notification": {
      "title": "Đơn hàng đã xác nhận",
      "body": "Đơn hàng #1001 của bạn đã được xác nhận."
    },
    "data": {
      "type": "order_update",
      "order_id": "1001"
    }
  }
}

Trong ví dụ này, FCM_REGISTRATION_TOKEN là giá trị minh họa, cần thay bằng token thực tế của thiết bị.

Để gửi yêu cầu, Backend phải xác thực bằng cơ chế được FCM HTTP v1 hỗ trợ, thường thông qua tài khoản dịch vụ và OAuth 2.0 access token.

Không được nhúng thông tin xác thực máy chủ hoặc khóa riêng của service account vào ứng dụng Flutter, vì ứng dụng phía người dùng có thể bị phân tích và trích xuất thông tin.

Việc gửi thông báo phải được thực hiện từ môi trường máy chủ đáng tin cậy.

11. Topic Messaging là gì?

Ngoài việc gửi thông điệp đến một registration token cụ thể, FCM còn hỗ trợ Topic Messaging.

Topic là một chủ đề mà nhiều phiên ứng dụng có thể đăng ký nhận thông điệp.

Ví dụ, ứng dụng có thể có topic store_news dành cho thông báo tin tức cửa hàng.

Khi Backend gửi thông điệp đến topic này, FCM có thể phân phối thông điệp đến các thiết bị đã đăng ký.

Trong Flutter:

await FirebaseMessaging.instance.subscribeToTopic(
  'store_news',
);

Khi không muốn tiếp tục nhận thông điệp của topic:

await FirebaseMessaging.instance.unsubscribeFromTopic(
  'store_news',
);

Topic phù hợp với các thông báo chung, không mang tính riêng tư.

Không nên sử dụng topic công khai để gửi dữ liệu cá nhân hoặc thông tin chỉ dành cho một tài khoản, vì cơ chế đăng ký topic phía client không phải một hệ thống phân quyền bảo mật.

12. Cách tích hợp FCM vào Flutter

Quá trình tích hợp FCM thường gồm nhiều bước, không chỉ cài đặt một package.

Bước 1: Tạo hoặc chọn Firebase Project trên Firebase Console.

Bước 2: Đăng ký ứng dụng Android, iOS hoặc nền tảng cần hỗ trợ trong Firebase Project.

Bước 3: Cấu hình ứng dụng Flutter với Firebase, có thể sử dụng FlutterFire CLI.

Bước 4: Thêm các package cần thiết, chẳng hạn:

flutter pub add firebase_core firebase_messaging

Bước 5: Khởi tạo Firebase khi ứng dụng bắt đầu.

Ví dụ với tệp cấu hình được FlutterFire CLI tạo ra:

import 'package:flutter/material.dart';
import 'package:firebase_core/firebase_core.dart';

import 'firebase_options.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );

  runApp(const MyApp());
}

MyApp là widget gốc của ứng dụng, được định nghĩa riêng trong dự án.

Bước 6: Cấu hình quyền thông báo phù hợp.

Bước 7: Lấy FCM Token và gửi lên Backend.

Bước 8: Đăng ký các handler để xử lý thông điệp.

Bước 9: Cấu hình Backend gửi thông điệp qua FCM.

Bước 10: Kiểm thử các trường hợp foreground, background, terminated và những tình huống bị hạn chế bởi hệ điều hành.

Đối với iOS, cần cấu hình thêm APNs và những capability liên quan trong dự án Apple. Đối với Android, cần lưu ý quyền thông báo trên các phiên bản hệ điều hành mới.

13. Quyền nhận thông báo

Không phải ứng dụng nào cũng có thể tự do hiển thị thông báo mà không cần sự cho phép của người dùng.

Trên iOS và những phiên bản Android có cơ chế quyền thông báo runtime, ứng dụng cần yêu cầu quyền phù hợp.

Ví dụ:

final settings = await FirebaseMessaging.instance
    .requestPermission(
  alert: true,
  badge: true,
  sound: true,
);

print(settings.authorizationStatus);

Kết quả có thể cho biết quyền đã được cấp, bị từ chối hoặc thuộc trạng thái khác tùy nền tảng.

Ứng dụng nên giải thích rõ lý do cần quyền thông báo và tôn trọng lựa chọn của người dùng.

Nếu người dùng từ chối, ứng dụng vẫn phải cho phép họ sử dụng các chức năng chính không phụ thuộc vào Push Notification.

14. FCM có thay thế được REST API không?

FCM và REST API phục vụ những mục đích khác nhau.

REST API thường được sử dụng để ứng dụng chủ động gửi yêu cầu đến Backend, chẳng hạn lấy danh sách sản phẩm, xem chi tiết đơn hàng hoặc cập nhật thông tin tài khoản.

FCM được sử dụng để hệ thống chủ động gửi thông điệp đến ứng dụng khi có sự kiện.

Ví dụ, khi đơn hàng chuyển sang trạng thái đang giao hàng, Backend có thể gửi FCM để thông báo cho khách hàng.

Sau khi khách hàng nhấn vào thông báo, Flutter gọi REST API để lấy thông tin đơn hàng mới nhất.

Như vậy, FCM hỗ trợ thông báo sự kiện, còn REST API cung cấp dữ liệu nghiệp vụ chính thức.

Hai công nghệ này thường được kết hợp thay vì thay thế cho nhau.

15. Những lỗi thường gặp khi triển khai FCM

Một lỗi thường gặp là ứng dụng không nhận được thông báo vì chưa cấu hình Firebase hoặc APNs đúng cách.

Lỗi thứ hai là chưa được cấp quyền thông báo nhưng lập trình viên lại mặc định thông báo sẽ xuất hiện.

Lỗi thứ ba là Backend sử dụng token đã hết hạn hoặc không còn hợp lệ.

Lỗi thứ tư là chỉ kiểm thử khi ứng dụng đang foreground mà bỏ qua background và terminated.

Lỗi thứ năm là đặt thông tin xác thực gửi FCM ở phía Flutter, tạo nguy cơ lộ quyền gửi thông điệp.

Lỗi thứ sáu là cho rằng gửi thông điệp thành công đến FCM đồng nghĩa với việc người dùng chắc chắn đã nhìn thấy thông báo.

Lỗi thứ bảy là sử dụng FCM làm nơi lưu trạng thái nghiệp vụ thay vì lưu dữ liệu vào Backend.

Để hạn chế những vấn đề này, ứng dụng cần có quy trình quản lý token, kiểm thử trên thiết bị thật, xử lý quyền thông báo và thiết kế Backend phù hợp.

16. Bảo mật và quyền riêng tư khi sử dụng FCM

FCM Token cần được quản lý cẩn thận vì token được dùng để định tuyến thông điệp đến một phiên ứng dụng.

Backend cần xác thực người dùng trước khi liên kết token với tài khoản, đồng thời có cơ chế xóa hoặc vô hiệu hóa những liên kết không còn phù hợp.

Không nên đưa mật khẩu, thông tin thanh toán hoặc dữ liệu cá nhân nhạy cảm vào nội dung thông báo.

Nguyên nhân là thông báo có thể xuất hiện trên màn hình khóa hoặc được xử lý bởi các thành phần của nền tảng.

Ngoài ra, cần hạn chế tần suất gửi thông báo để tránh làm phiền người dùng và nên cung cấp tùy chọn quản lý những loại thông báo không thiết yếu.

17. Kết luận

Firebase Cloud Messaging là dịch vụ hỗ trợ gửi thông điệp đến ứng dụng trên nhiều nền tảng, được sử dụng phổ biến để xây dựng chức năng Push Notification.

Trong Flutter, FCM có thể được tích hợp thông qua Firebase SDK và package firebase_messaging. Ứng dụng cần quản lý registration token, quyền thông báo và các trạng thái nhận thông điệp.

Backend giữ vai trò quyết định khi nào gửi thông điệp và gửi cho đối tượng nào. FCM thực hiện chức năng phân phối thông điệp, còn hệ điều hành và ứng dụng quyết định việc xử lý, hiển thị theo những điều kiện tương ứng.

Điều quan trọng là FCM không thay thế cơ sở dữ liệu, REST API hoặc cơ chế xác thực. Nó là một thành phần bổ sung giúp ứng dụng chủ động thông báo các sự kiện đến người dùng.

Khi triển khai FCM, lập trình viên cần chú ý đến quyền riêng tư, quản lý token, bảo mật thông tin xác thực và những giới hạn phân phối thông báo của từng nền tảng.

18. Tài liệu tham khảo

• Firebase Cloud Messaging: https://firebase.google.com/docs/cloud-messaging
• Firebase Cloud Messaging trong Flutter: https://firebase.google.com/docs/cloud-messaging/flutter/client
• Nhận thông điệp trong Flutter: https://firebase.google.com/docs/cloud-messaging/flutter/receive
• FCM HTTP v1 API: https://firebase.google.com/docs/cloud-messaging/migrate-v1
• Package firebase_messaging: https://pub.dev/packages/firebase_messaging