joltup / react-native-threads

Create new JS processes for CPU intensive work
MIT License
755 stars 141 forks source link

ThreadManager.startThread causes other modules which using EventEmitter receives nothing. #68

Closed tikkichan4 closed 5 years ago

tikkichan4 commented 5 years ago

In my situation, i am using react-native-threads for some expensive JS statements, and react-native-firebase for pushing notification. After calling ThreadManager.startThread, i cannot receive anything from react-native-firebase event listener. (the event listener is also implemented by EventEmitter too). And i guess react-native-threads causes other modules which using EventEmitter receives nothing too.

Because Notification is one of my core function of the App. So i can only decide to stop using react-native-threads util the issue solved.

Any workaround for this ? Thanks a lot.

Traviskn commented 5 years ago

I'm not sure what event emitter react-native-firebase is using, but you need to use react-native-thread's message passing API (postMessage and onMessage) if you want to have any kind of communication between your worker thread and your main JS process

sertony commented 5 years ago

Same issue happens to me as well, but only on iOS. Android works fine. Need to make a research.

m-tymchyk commented 4 years ago

The same issue happens in App on iOS. RNFirebase publish new Notification to background Thread, based on react-native-threads instead of main App thread.

iskenz commented 4 years ago

Same issue as above, on our team project the worker thread mess up with Firebase notifications and InApp purchases listener. We didn't find a solid solution for this problem so we're trying another approach for doing heavy process stuff. Have anyone found a workaround?

skdev24 commented 4 years ago

@Traviskn Our app is fully dependent on react-native-threads it's giving us hard time for using react native firebase, doing lot of research on native side, but no solution yet, please share some solution, if any app uses react-native-threads than they can't use firebase notification😕

davinctor commented 3 years ago

I find the solution for my use case. The patch is:

diff --git a/node_modules/react-native-firebase/ios/RNFirebase/notifications/RNFirebaseNotifications.m b/node_modules/react-native-firebase/ios/RNFirebase/notifications/RNFirebaseNotifications.m
index 57688df..ca38d65 100644
--- a/node_modules/react-native-firebase/ios/RNFirebase/notifications/RNFirebaseNotifications.m
+++ b/node_modules/react-native-firebase/ios/RNFirebase/notifications/RNFirebaseNotifications.m
@@ -50,6 +50,9 @@ - (id)init {
 }

 - (void)initialise {
+    if (theRNFirebaseNotifications != nil) {
+        return;
+    }
     // If we're on iOS 10 then we need to set this as a delegate for the UNUserNotificationCenter
     if (@available(iOS 10.0, *)) {
         [UNUserNotificationCenter currentNotificationCenter].delegate = self;

This is the fix for react-native-firebase that relates to the notifications module. The root cause is the next: for each js bundle is created a separate bridge and as a result new event emitter. I am still curious why it not showing notification (what is the difference between bundles and JS threads) but the fix avoids multiple theRNFirebaseNotifications module initializations and saved the instance only for the first bridge. The first bridge in my case is for the main app bundle. (I think because it initializes at first by default and other threads created after.) Because it saves the reference for the correct module that relates to the main app bundle it started to work as expected.

Hope it will help.