Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[🐛] Bug Report Title - setBackgroundMessageHandler is delayed by 5-6s on IOS #5367

Closed
babyrusa opened this issue May 27, 2021 · 5 comments
Labels
help: needs-triage Issue needs additional investigation/triaging. type: bug New bug report Type: Stale Issue has become stale - automatically added by Stale bot Workflow: Waiting for User Response Blocked waiting for user response.

Comments

@babyrusa
Copy link

babyrusa commented May 27, 2021

Issue

Describe your issue here
Issue: setBackgroundMessageHandler works but it's only responded 5 or 6 seconds after the push notification shown on IOS device. The Push notification delivers very fast however the background handler responds way slower. I wonder this is a common issue.
I'm using

"@react-native-firebase/app": "^11.5.0",
"@react-native-firebase/messaging": "^11.5.0",

I have Headless in my index.js and AppDelegate.m file.
My send notification function (I've tried with different headers values too, However, the issue still persists)

function sendNotification(title, body) {
  const message = {
    data: { title, body },
    notification: {
      title,
      body,
    },
    token: <token>,
    apns: {
      payload: {
        aps: {
          contentAvailable: true,
          priority: "high",
        },
      },
      // headers: {
      //   "apns-push-type": "alert",
      //   "apns-priority": "10",
      //   "apns-topic": <bundleID>,
      // },
      
    },
    android: {
      priority: "high",
    },
  };

My AppDelegate.m file

#import "AppDelegate.h"
#import "RNFBMessagingModule.h"

#import <React/RCTBridge.h>
#import <React/RCTBundleURLProvider.h>
#import <React/RCTRootView.h>
#import <Firebase.h>
#ifdef FB_SONARKIT_ENABLED
#import <FlipperKit/FlipperClient.h>
#import <FlipperKitLayoutPlugin/FlipperKitLayoutPlugin.h>
#import <FlipperKitUserDefaultsPlugin/FKUserDefaultsPlugin.h>
#import <FlipperKitNetworkPlugin/FlipperKitNetworkPlugin.h>
#import <SKIOSNetworkPlugin/SKIOSNetworkAdapter.h>
#import <FlipperKitReactPlugin/FlipperKitReactPlugin.h>'

static void InitializeFlipper(UIApplication *application) {
  FlipperClient *client = [FlipperClient sharedClient];
  SKDescriptorMapper *layoutDescriptorMapper = [[SKDescriptorMapper alloc] initWithDefaults];
  [client addPlugin:[[FlipperKitLayoutPlugin alloc] initWithRootNode:application withDescriptorMapper:layoutDescriptorMapper]];
  [client addPlugin:[[FKUserDefaultsPlugin alloc] initWithSuiteName:nil]];
  [client addPlugin:[FlipperKitReactPlugin new]];
  [client addPlugin:[[FlipperKitNetworkPlugin alloc] initWithNetworkAdapter:[SKIOSNetworkAdapter new]]];
  [client start];
}
#endif

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  if ([FIRApp defaultApp] == nil) {
      [FIRApp configure];
    }


 // in "(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions" method
// Use `addCustomPropsToUserProps` to pass in props for initialization of your app
// Or pass in `nil` if you have none as per below example
// For `withLaunchOptions` please pass in `launchOptions` object
NSDictionary *appProperties = [RNFBMessagingModule addCustomPropsToUserProps:nil withLaunchOptions:launchOptions];

  // [END register_for_notifications]

#ifdef FB_SONARKIT_ENABLED
  InitializeFlipper(application);
#endif

  RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
  RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
                                                   moduleName:@"appname"
                                            initialProperties:appProperties];

  rootView.backgroundColor = [[UIColor alloc] initWithRed:1.0f green:1.0f blue:1.0f alpha:1];

  self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
  UIViewController *rootViewController = [UIViewController new];
  rootViewController.view = rootView;
  self.window.rootViewController = rootViewController;
  [self.window makeKeyAndVisible];
  // [RNSplashScreen show]

  return YES;
}

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}




// [START refresh_token]
- (void)messaging:(FIRMessaging *)messaging didReceiveRegistrationToken:(NSString *)fcmToken {
    NSLog(@"FCM registration token: %@", fcmToken);
    // Notify about received token.
    NSDictionary *dataDict = [NSDictionary dictionaryWithObject:fcmToken forKey:@"token"];
    [[NSNotificationCenter defaultCenter] postNotificationName:
     @"FCMToken" object:nil userInfo:dataDict];
    // TODO: If necessary send token to application server.
    // Note: This callback is fired at each app startup and whenever a new token is generated.
}
// [END refresh_token]


@end

@babyrusa babyrusa added help: needs-triage Issue needs additional investigation/triaging. type: bug New bug report labels May 27, 2021
@mikehardy
Copy link
Collaborator

Indeed, this has been an area of quite some difficulty, it was a 2second delay and now is 8 seconds, not 5-6 ;-):

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t) (8 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{

#4144 - without this, messages were dropped as they went from native/obj-c to JS. Why? If you can't tolerate the delay we'll need your help diving in to find out why and we would love a fix that did not involve simply waiting until we were sure the JS area was ready.

@mikehardy mikehardy added the Workflow: Waiting for User Response Blocked waiting for user response. label May 28, 2021
@babyrusa
Copy link
Author

babyrusa commented Jun 2, 2021

@mikehardy does this delay also happen with onMessage()? I just noticed some bugs in my app but I'm unsure if this is my code or not.

@mikehardy
Copy link
Collaborator

Unsure, I'm out this week so fastest answer is to consult the code, same as I'd do, but without waiting until I can get to it next week

@stale
Copy link

stale bot commented Jul 13, 2021

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

@stale stale bot added the Type: Stale Issue has become stale - automatically added by Stale bot label Jul 13, 2021
@stale
Copy link

stale bot commented Aug 3, 2021

Closing this issue after a prolonged period of inactivity. If this is still present in the latest release, please feel free to create a new issue with up-to-date information.

@stale stale bot closed this as completed Aug 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help: needs-triage Issue needs additional investigation/triaging. type: bug New bug report Type: Stale Issue has become stale - automatically added by Stale bot Workflow: Waiting for User Response Blocked waiting for user response.
Projects
None yet
Development

No branches or pull requests

2 participants