本来是没有这篇文章的计划的，因为之前新项目直接就用上了Flutter2.0空安全，所有的第三方库也升级空安全了，所以之前项目中做消息推送使用的firebase_messaging第三方库也得升级空安全，结果升级完后，各种以前的方法都没了。一脸懵逼，两脸懵逼~
(这就是flutter第三方库的坑，兼容是不存在的，看着不爽直接干掉O(∩_∩)O哈哈~)
本篇文章就直接聊聊在flutter端firebase_messaging的更新使用，想其他的原生端配置呀，推送环境的区分呀以前的文章都有，这里就不一一细说了。
以前的文章参见：
1、推送文章链接，基于firebase_messaging 7.0.3
《Flutter中如何使用Firebase 做消息推送(Notification)》
2、Firebase环境分离链接
《Flutter 中为Firebase提供多个构建环境分离配置》
注：基于firebase_messaging 9.0.0以上版本，因为这个版本后就支持空安全了。
一、Android原生端修改
在7.0.3以前，Android原生端需要注册和配置FirebaseMessagingService，现在都不需要了，全部干掉。
//import io.flutter.plugins.firebasemessaging.FirebaseMessagingPlugin
//import io.flutter.plugins.firebasemessaging.FlutterFirebaseMessagingService
class MaintenanceApplication : FlutterApplication(), PluginRegistry.PluginRegistrantCallback{
override fun onCreate() {
super.onCreate()
Embrace.getInstance().start(this);
// FlutterFirebaseMessagingService.setPluginRegistrant(this)
}
override fun registerWith(registry: PluginRegistry?) {
// GeneratedPluginRegistrant.registerWith(registry)
// FirebaseMessagingPlugin.registerWith(registry?.registrarFor("io.flutter.plugins.firebasemessaging.FirebaseMessagingPlugin"))
}
}
二、Flutter端的变化
大家可以参看pub.dev，不过那个Example确实有点恶心。绕的很~
可以看看这篇文章https://firebase.flutter.dev/docs/messaging/notifications/#foreground-notifications
2.1 在7.0.3以前的话，在Flutter端接收数据有四种方法：
firebaseMessaging.configure(
onMessage: (message) => handleMessage(message),
onLaunch: (message) => startToRedirectByNotification(message, source: 'onLaunch'),
onResume: (message) => startToRedirectByNotification(message, source: 'onResume'),
onBackgroundMessage: backgroundMessageHandler
);
onMessage: 对应应用在前台，不会发出系统Notification，只发送消息，如需系统Notification。则需要手动通过flutter_local_notifications第三方库发送。
onLaunch：系统在被杀掉，既从历史中划掉时，点击Notification后，跳转调用的方法。
onResume：系统在后台时，点击Notification后，跳转调用的方法。
2.2 在9.0.0以后的话，在Flutter端接收数据全部改掉，全部！！！
2.2.1 应用在前台
当应用在前台时，收到消息需要通过FirebaseMessaging中的onMessage，它是一个Stream，我们通过listen监听，它返回的是RemoteMessage对象。同时应用在前台时，也不会发出系统Notification，业务需要的话，需手动发出。(该方法同7.0.3 onMessage)
FirebaseMessaging.onMessage.listen((RemoteMessage message) {
RemoteNotification notification = message.notification;
AndroidNotification android = message.notification?.android;
// If `onMessage` is triggered with a notification, construct our own
// local notification to show to users using the created channel.
if (notification != null && android != null) {
flutterLocalNotificationsPlugin.show(
notification.hashCode,
notification.title,
notification.body,
NotificationDetails(
android: AndroidNotificationDetails(
channel.id,
channel.name,
channel.description,
icon: android?.smallIcon,
// other properties...
),
));
}
});
2.2.2 应用在后台或被杀掉
这时候在9.0.0中就没有onLaunch或者onResume方法了，对应的是onMessageOpenedApp，看这货的名字也知道，应该是点击了Notification，打开App的数据流了。它是一个Stream，也是通过listen监听它，获取相应的数据，并跳转到对应页面。(这一般是应用在后台，并没有没杀掉时调用)
// Also handle any interaction when the app is in the background via a
// Stream listener
FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
if (message.data['type'] == 'chat') {
Navigator.pushNamed(context, '/chat',
arguments: ChatArguments(message));
}
});
当App被杀掉后，onMessageOpenedApp方法就凉凉了，这时候该getInitialMessage方法登场了(对应onLaunch方法)。它会获取最近一次的Remote消息。
// Get any messages which caused the application to open from
// a terminated state.
RemoteMessage initialMessage =
await FirebaseMessaging.instance.getInitialMessage();
// If the message also contains a data property with a "type" of "chat",
// navigate to a chat screen
if (initialMessage != null && initialMessage.data['type'] == 'chat') {
Navigator.pushNamed(context, '/chat',
arguments: ChatArguments(initialMessage));
}
2.3 给ios加点权限
await FirebaseMessaging.instance.setForegroundNotificationPresentationOptions(
alert: true, // Required to display a heads up notification
badge: true,
sound: true,
);
三、遇到的坑儿
以前的标题
现在的标题，还是太年轻了😂
3.1 onMessage和onMessageOpenedApp
坑儿一:
上面说了在监听onMessage，它是一个流。当应用在前台时，Firebase原生端就会通过MethodChannel，发送notification数据，不再发送系统Notification了。然而，实际测试在iOS端，App在前端也会发送系统Notification，如果iOS在监听onMessage流时再次发送本地Notification的话，就会有两条Notification消息，这里我们就得区分对待了，只在Android平台监听onMessage流。
if (Platform.isAndroid) {
FirebaseMessaging.onMessage.listen((event) {
handleMessage(event);
});
}
坑儿二：
因为上面也聊过，onMessage和onMessageOpenedApp实际上是流数据，如果我们需要做操作就需要监听它们。
那么问题来了，比如说在设置页面，我们有控制Notification打开关闭的开关，一般做法无非是打开时，获取firebase token，与后台进行绑定；关闭时删除Firebase token，与后台进行解绑，这样就能收到或者不能收到后台的推送消息了。
但是，我们多开关几次后，也许再次打开时，我们收到后台推送，但是在onMessage里会多次发送本地Notificition。开始很诧异，后来想明白了。
因为之前监听onMessage和onMessageOpenedApp流时，关闭推送没有关闭，造成了会同时有多个监听器在监听流，所以在我们关闭或者解绑fireabse_messaging时，我们需要将监听流的监听器也关闭。
static StreamSubscription? streamSubscription;
static StreamSubscription? onAppOpenStreamSubscription;
static clearStreamSubscription() {
streamSubscription?.cancel();
onAppOpenStreamSubscription?.cancel();
streamSubscription = null;
onAppOpenStreamSubscription = null;
}
initFirebase(){
if (Platform.isAndroid) {
streamSubscription = FirebaseMessaging.onMessage.listen((event) {
handleMessage(event);
});
}
onAppOpenStreamSubscription = FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
startToRedirectByNotification(message.data);
});
}
3.2 onMessage手动发本地Notification库的问题
这里用的发送本地Notification的第三方库为：flutter_local_notifications: 5.0.0+4。这次不是已经升级了版本吗，我认为应该没啥问题。可是测试发现心塞。
坑儿三：
这里有什么问题呢，这个问题主要发生在Android端，iOS没啥问题。
问题描述：App在前台，监听onMessage收到firebase发来的消息后，通过flutter_local_notifications发出本地Notificaiton。这里并没有什么问题。当你退出App，并在历史中kill掉App。在点击通知栏的Notification时，只会打开App，并不会执行onSelectNotification参数配置的跳转方法。
这就尴尬了，我以前没问题的呀，后面就对比了下以前改过的flutter_local_notifications: 2.0.0+1版本。发现了为什么不调用onSelectNotification的问题了。也是需要修改flutter_local_notifications: 5.0.0+4库的Android端源码。
这也是需要改完后，发布到私有的pub.dev上，要不就提issue。
修改路径：flutter_local_notifications-5.0.0+4/android/src/main/java/com/dexterous/flutterlocalnotifications/FlutterLocalNotificationPlugin.java
在initilalize方法中添加如下代码可以解决该问题。
private void initialize(MethodCall call, Result result) {
...
//Add for when app kill can not receive notification Data
if (mainActivity != null && !launchedActivityFromHistory(mainActivity.getIntent())) {
sendNotificationPayloadMessage(mainActivity.getIntent());
}
//end
...
result.success(true);
}
3.3 事实证明使用firebase库如升级打怪
这里碰到的问题是firebase_messaging: 10.0.4的问题，这里要区分iOS和Android端的修改，两边都有问题。
问题重现描述：当App置于后台或者被kill下的情况，后台发出推送，前台收到了系统Notification，点击会响应onMessageOpenedApp或者getInitialMessage方法，并处理应用层设置的逻辑，当我们退出登录也就是Sign out后，在登录结果，发现有重新调用了 onMessageOpenedApp或者getInitialMessage方法。懵逼了~
没得办法，还是得去两端源码中看看是为什么，
坑儿四：(Android端)
修改路径：firebase_messaging-10.0.4/android/src/main/java/io/flutter/plugins/firebase/messaging/FlutterFirebaseMessagingPlugin.java
首先，我这里稍稍聊聊，firebase_messaging库Android端如何缓存Notification的，
它有三级缓存：
1、在FlutterFirebaseMessagingPlugin.java中用全局变量initialMessage缓存；
2、在FlutterFirebaseMessagingReceiver.java中收到推送消息后，使用一个Map -> HashMap<String, RemoteMessage> notifications = new HashMap<>()缓存；
3、在FlutterFirebaseMessagingStore.java中使用SharedPreferences缓存；
每次在onNewIntent和getInitialMessage中都会进行三级缓存取数据，因为缓存问题，会导致重复调用。
解决方案：
因为在Sign Out时，我们会调用firebase_messaging的deleteToken方法，那我们就可以在deleteToken时，将三级缓存清理一波：(在FlutterFirebaseMessagingPlugin.java中修改)
private Task<Void> deleteToken() {
return Tasks.call(
cachedThreadPool,
() -> {
//Add for clear cache
clearFirebaseNotification();
//end
Tasks.await(FirebaseMessaging.getInstance().deleteToken());
return null;
});
}
//clear Cache Notification when deleteToken
private void clearFirebaseNotification(){
//reset initialMessage
initialMessage = null;
//Clear FlutterFirebaseMessagingStore cache
FlutterFirebaseMessagingStore.getInstance().removeAllFirebaseMessage();
//Clear FlutterFirebaseMessagingReceiver.notifications cache
FlutterFirebaseMessagingReceiver.notifications.clear();
}
在onNewIntent方法中，因为另一个问题：App在后台没被干掉，收到推送后打开，然后在kill掉App，再次进入App，依然会重新调用getInitialMessage方法，后面查了下，发现在getInitialMessage方法中，会查找三级缓存，前两个都是null，而SharedPreferences中的缓存还在，没有被清理。
(也是在FlutterFirebaseMessagingPlugin.java中修改)
@Override
public boolean onNewIntent(Intent intent) {
....
//Add 20210729 for Teminated status will open twice getInitMessage()
FlutterFirebaseMessagingStore.getInstance().removeFirebaseMessage(messageId);
//end
...
// Store this message for later use by getInitialMessage.
initialMessage = remoteMessage;
...
}
官方注释是说不要删除SharedPreferences中的缓存，我的业务需求是需要删，大家具体看看自己的业务需求吧。
iOS端修改
问题也就和上面Android是一样的。
修改路径：firebase_messaging-10.0.4/ios/Classes/FLTFirebaseMessagingPlugin.m
在iOS端就没有像Android那样有三级缓存了，它直接接受iOS系统的NotificationCenter打开时发来的消息，
1、直接赋值给了变量NSDictionary *_initialNotification。然后通过onMessageOpenedApp向Flutter端发出消息。
2、如果应用调用了getInitialMessage方法，则会通过copyInitialNotification方法拷贝一份_initialNotification，并将其发出，并将_initialNotification置为空。
if ([@"Messaging#getInitialMessage"isEqualToString:call.method]) {
NSLog(@"Messaging#getInitialMessage");
methodCallResult.success([self copyInitialNotification]);
}
- (nullable NSDictionary *)copyInitialNotification { @synchronized(self) {
if (_initialNotification != nil) {
NSDictionary *initialNotificationCopy = [_initialNotification copy];
_initialNotification = nil;
return initialNotificationCopy;
}
}
return nil;
}
在所以这里的原因也是因为退出登录调用deleteToken，但是_initialNotification变量并不为空，所以在重新登录并绑定Firebase时候调用getInitialMessage方法时候就会得到_initialNotification，并发出Notification。
所以修改就变得很简单了，在deleteToken方法中修改：
else if ([@"Messaging#deleteToken" isEqualToString:call.method]) {
//将_initialNotification置为空
_initialNotification = nil;
[self messagingDeleteToken:call.arguments withMethodCallResult:methodCallResult];
}
四、总结
好了，到此坑坑总算填完，至于还有什么坑，源码已看，还有啥不能填的，尽管来，还有谁~~~~😓
网友评论