【问题标题】:Android: Can an Android app have multiple FirebaseMessagingServicesAndroid:一个Android应用程序可以有多个FirebaseMessagingServices
【发布时间】:2017-12-05 17:33:48
【问题描述】:

我正在构建一个库项目,其中有一个 FirebaseMessagingService。 我的应用程序中还有一个 FirebaseMesagingService。我看到的是,每当从服务器发送 FCM 时,只有一个 FirebaseMessagingService 处理它。当我使用 GCM 接收器时,情况并非如此。两个 GCM 接收器都用于接收消息,并且根据消息内容,他们会/不会对此做任何事情。

我怎样才能在 FCM 中达到同样的效果。

【问题讨论】:

  • 你是什么意思..?您想要多个 FirebaseMessagingService?
  • 到目前为止,您找到解决方案了吗?请问你最后用的是什么方法?谢谢!
  • 嘿@Ripityom,我在下面回答。如果解释不清楚,请告诉我。

标签: android firebase google-cloud-messaging firebase-cloud-messaging


【解决方案1】:

您的库清单不应包含 FirebaseMessagingService 子类。将 messa 服务添加到应用程序的清单应该是集成步骤的一部分,即集成 SDK。此外,您应该在 SDK 中提供一个挂钩,应用程序可以通过该挂钩将 FCM 消息负载传递给 SDK。

基本上,如果应用没有自己的 FirebaseMessagingService 子类,它会在清单中添加您的 SDK 的侦听器服务,否则它将在自己的侦听器服务中添加挂钩,将有效负载传递给您的 SDK,SDK 会采取所需的操作

【讨论】:

  • 这个问题涉及FirebaseMessagingService不是 FirebaseListenerServicefirebase.google.com/docs/reference/android/com/google/firebase/… 的文档明确建议使用示例清单 xml 对该服务进行子类化。
  • 我的意思是子类本身,可能对 MessagingService 和 ListenerService 的错字混淆了 fcm 和 gcm 的命名约定并不清楚和抱歉
  • 对,这有点帮助。我已经删除了我的反对票。答案仍然令人困惑-也许您可以添加对推理的解释?类似于 1. 在每个 APK 中,只有 一个 FMS 子类可以接收推送消息; 2.如果你在APK中添加两个库,每个库都有自己的子类,只有一个会收到推送消息; 3. 因此应用程序应该使用自己的子类接收推送消息; 4.库应该提供一个钩子(不是子类),应用程序子类可以在它希望库做它的事情时调用它; 5. 这确保应用程序始终处于控制之中
【解决方案2】:

Android 应用不能将多个 FirebaseMessagingService 作为服务而不是接收器。可以做的是检查两个条件:

  1. 如果应用在其功能中注册了 FCMMessagingService,则在库项目中提供一个方法,该方法可以将消息作为参数,由应用的 FCMMessagingService 接收。

  2. 如果应用程序中没有集成 FCM 功能,则在您的库项目中添加 FCMMessagingService,它可以处理服务器发送的 fcm。

【讨论】:

    【解决方案3】:

    几天前我遇到了同样的问题,在我们的团队中,我们使用了一种稍微不同的方法,其中涉及反射。

    一般来说,我们使用委托类并通过反射提供上下文。

    public class OwnPushService extends FirebaseMessagingService {
    
        private List<FirebaseMessagingService> messagingServices = new ArrayList<>(2);
    
        public GCPushService() {
            messagingServices.add(new AirshipFirebaseMessagingService());
            messagingServices.add(new TLFirebaseMessagingService());
        }
    
        @Override
        public void onNewToken(String s) {
            delegate(service -> {
                injectContext(service);
                service.onNewToken(s);
            });
        }
    
        @Override
        public void onMessageReceived(RemoteMessage remoteMessage) {
            delegate(service -> {
                injectContext(service);
                service.onMessageReceived(remoteMessage);
            });
        }
    
        private void delegate(GCAction1<FirebaseMessagingService> action) {
            for (FirebaseMessagingService service : messagingServices) {
                action.run(service);
            }
        }
    
        private void injectContext(FirebaseMessagingService service) {
            setField(service, "mBase", this); // util method for recursive field search
        }
    }
    

    如果您对详细信息感兴趣,我已经在 Medium 上写了一篇关于这种方法的文章:link

    【讨论】:

    【解决方案4】:

    在这种情况下,您应该将您的LibraryFirebaseMessagingService 设为您的AppFirebaseMessagingService 的父级,并在应用程序的AndroidManifest.xml 文件中仅声明AppFirebaseMessagingService

    例如:

    在您的图书馆中:

    public class LibraryFirebaseMessagingService extends FirebaseMessagingService {
        @Override
        public void onMessageReceived(RemoteMessage remoteMessage) {
             //Your library logic
        }
    }
    

    现在在您的应用中:

    public class AppFirebaseMessagingService extends LibraryFirebaseMessagingService {
        @Override
        public void onMessageReceived(RemoteMessage remoteMessage) {
             if(shouldLibraryHandlethis(remoteMessage)) {
                super.onMessageReceived(remoteMessage);
             } else {
                //Your app logic
             }
        }
    }
    

    现在在您应用的 AndroidManifest.xml 文件中:

    <service
        android:name=".AppFirebaseMessagingService"
        android:exported="false">
        <intent-filter>
            <action android:name="com.google.firebase.MESSAGING_EVENT" />
        </intent-filter>
    </service>
    

    无需在任何AndroidManifest.xml 中声明LibraryFirebaseMessagingService

    【讨论】:

    • 如果所有库都使用这种方法会发生什么,你将如何扩展它们
    猜你喜欢
    • 1970-01-01
    • 2011-06-17
    • 2016-10-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多