Run onNotification() in JS, even when the app isn't running at all.

[mikelambert]

Make the background listener service start the React JS application (sans Components), and then uses the results of any PushNotification.configure() calls to trigger the JS-based onNotification from the listener service.

This avoids the need to package everything into the Android notification payload to get it to show up, and should hopefully fix a bunch of open issues against this repo.

Note, I haven't explored what's required to get this equivalent functionality working on iOS (and I suspect it may not even be possible at all). But this helps me avoid duplicating functionality on Android and JS by letting me combine it.

I suspect there is additional work that might help combine other native-Android notification processing (RNPushNotificationPublisher and RNPushNotificationBootEventReceiver?) to get them to use JS notification processing. But I don't use them, so they are not in my critical path, and am worried I might break them, since playing with this code is a bit tricky to get right (with threads and the many ways Android notifications can be delivered, etc).

[mikelambert]

This should fix:
#219
#217
#170

Though as you mention in #170 (comment) , I guess it's arguable that you don't want this going through onNotification (and instead prefer this native-Java processing system which can't be customized at all), for the sake of iOS compatibility?

I haven't investigated in detail the options detailed in articles like https://medium.com/posts-from-emmerge/ios-push-notification-background-fetch-demystified-7090358bb66e#.krswqcyl6, but I hold out hope that there's some level of background execution that can work on iOS too, and let library users customize how notifications are processed when the app is not running...

[npomfret]

Thanks for this, I'll take a look at it later.

[logileifs]

@mikelambert I tested your branch but still get no call to onNotification on cold start from notification.

W/System.err(25916): java.io.IOException: INVALID_SENDER
W/System.err(25916):    at com.google.android.gms.iid.zzc.zzb(Unknown Source)
W/System.err(25916):    at com.google.android.gms.iid.zzc.zza(Unknown Source)
W/System.err(25916):    at com.google.android.gms.iid.InstanceID.zzc(Unknown Source)
W/System.err(25916):    at com.google.android.gms.iid.InstanceID.getToken(Unknown Source)
W/System.err(25916):    at com.dieam.reactnativepushnotification.modules.RNPushNotificationRegistrationService.onHandleIntent(RNPushNotificationRegistrationService.java:23)
W/System.err(25916):    at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
W/System.err(25916):    at android.os.Handler.dispatchMessage(Handler.java:102)
W/System.err(25916):    at android.os.Looper.loop(Looper.java:145)
W/System.err(25916):    at android.os.HandlerThread.run(HandlerThread.java:61)

String token = instanceID.getToken(SenderID,
                    GoogleCloudMessaging.INSTANCE_ID_SCOPE, null);

This is the line where the error originates

I noticed this was happening when opening the notification and it has something to do with gcm which makes me wonder if this does not work with local notifications ?

[mikelambert]

That error looks to be due to the Registration Service, which should be unrelated to what I'm doing (which is processing of notifications), though maybe they interact in strange ways.

In the case of my code, you just have to be sure to call PushNotification.configure(...) outside of React.Components, basically called as part of a top-level import, because none of the Components will be initialized in the background thread. Not sure what you're doing exactly, though feel free to link to code/examples of what you're doing and I can take a peek?

[npomfret]

I'm just trying to test this, but need some help. Here's what I've observed so far.

WRT #217 & #219

My app already receives GCM push notifications when in the background, I don't believe this is a bug. Maybe there's a bug where it doesn't understand messages that arrive in a different format, but that's a separate issue I think.

If the app is closed it doesn't receive messages. As far as I can tell from my testing this doesn't address that issue.

WRT #170

onNotification only gets fired for push notifications (when the app is either in the foreground or background, but not if it isn't running at all). It does not get fired when the user clicks on an alert in the notification center. And it does not get fired when the app sends a local notification.

The only change in behaviour I can see is that when my app sends a local notification then onNotification gets called, but not with the expected local notification, but instead it gets called with the last push notification. So I'm seeing the last push notification over and over again.

In summary, I can't merge this change. I don't fully understand what its for or how to test it. Can you please describe exactly what the expected differences in behaviour are please?

[mikelambert]

Hey there Nick, sorry for the confusion!

Yes, the existing library already delivers notifications to the JS handler when running in the background. But this patch adds support for delivering notifications to the JS handler when the app is closed. I am not sure why it is not working for you in your testing...curious when/how you are calling PushNotification.configure?

It does this by loading all the JS from the ListenerService, but without constructing any UI components. And then attempting to deliver the notifications using the results of any PushNotification.configure(...) calls that happened.

As to the second bit...the "calls onNotification as the result of a localNotification, but using the last push notification" sounds like a bug. I am not sure what's going on here, but can ask a few questions to narrow it down:

• Are you using scheduled notifications or repeating notifications? I have not tested the interactions of those cases.
• Again, where/how are you calling PushNotification.configure? Could it be called from a chain initiated from a triggered localNotification? The behavior of repeated calls to configure({popInitialNotification: true, ...}) has changed, and might cause that. (If we deem this a bug, I can fix this.)
• Otherwise I don't know what is going on, unless somehow local notifications were being delivered through GcmListenerService, which I don't think is supposed to happen from how I understand things.

That said, if you have actual code you are running you can point to (runnable?), that might help me diagnose this better. Push Notifications are kind of a hairy thing to handle, especially with all the JS/Native interactions here, so seeing how things get called in your app might help me diagnose what's wrong. Thanks!

[npomfret]

I'm not using scheduled notifications.

My configure function gets called when the app is ready to receive push notifications. So not immediately basically, but after a couple of seconds.

[mikelambert]

My question is...what determines when it's "ready to receive notifications".

I feel like I'm not able to communicate myself clearly on the special requirements of configure() to receive JS notifications when the app is not running, since you're not clarifying on how your configure is called. Rephrasing, if someone were to require('index.android.js') on your base JS file (without instantiating any of the components, running the constructors, render()s, mounting callbacks, etc), would your configure() still be called? It needs to be at the top-level, as an un-indented line, in some imported JS file, for these JS notifications with an closed-app to work.

Or maybe better, can I see any code? Is it online, or a private codebase?

[npomfret]

Its a private code base. My configure method isn't called as you describe, the app starts up and after a while the configure function is called. I think what you're saying is that it has to be called immediately when the app starts?

[mikelambert]

Correct. The background listener service is loading and running the JS libraries, but it is not initializing any UI components (since there is no Activity created yet, since the user has not opened the app!)

In my case, I do this:
https://github.com/mikelambert/dancedeets-react/blob/master/js/notifications/setup.js

I call init() directly when that code is imported, which sets up an onNotification to handle incoming remote notifications.

Later, when the UI is initialized (and I have a redux store available), I call setup(reduxDispatch), and overwrite the onNotification, along with setting popInitialNotification. This time the onNotification has access to the dispatch, and so can control the UI in response to the user opening a notification. (ie, navigate to the notification item the user clicked on). And the popInitialNotification ensures the opening-notification gets processed now that the UI has been started properly.

[npomfret]

Thanks for the example. Does your app works on iOS? When I change my app to call configure in this way the onRegister function isn't being called.

[mikelambert]

I haven't enabled notifications yet for my iOS app, so I haven't tested this. But my changes only affected a small bit of JS, so didn't think it was necessary.

Again, without code, it is hard to debug your situation. What did you change, exactly? Are you passing an onRegister callback to the first, or second, call to configure()? (Or did you only move your call)? Since I haven't changed any of the iOS code, it basically sounds like you are saying:

"There is a bug with the existing react-native-push-notification code on iOS, where it breaks if you call configure too early in the initialization chain"

And so not broken by this pull request...but triggered on iOS because of the constraints this new pull request places on app code calling configure()?

[npomfret]

That's correct. I'll look into it more today

[npomfret]

Ah sorry @mikelambert , ignore everything I just said. I was using the iOS simulator.

[npomfret]

Ok, so I've changed my code to call configure in index..js, it's very similar to yours. It sets popInitialNotification to false, and then set it to true later when the app is ready to process the notification. I console.log each notification as it gets delivered in onNotification.

Without adding your change I can get push notifications when the app is backgrounded. But not when its killed. I do see the following in the logs though:

10-08 14:10:33.840 19416-19416/? D/ActivityThread: BIND_APPLICATION handled : 0 / AppBindData{appInfo=ApplicationInfo{3263f2a com.pomochat}}
10-08 14:10:33.850 19416-19416/? D/ActivityThread: BDC-Calling onReceive: intent=Intent { act=com.google.android.c2dm.intent.RECEIVE flg=0x10 pkg=com.pomochat cmp=com.pomochat/com.google.android.gms.gcm.GcmReceiver (has extras) }, receiver=com.google.android.gms.gcm.GcmReceiver@303e11b
10-08 14:10:33.856 19416-19416/? D/ActivityThread: BDC-RECEIVER handled : 0 / ReceiverData{intent=Intent { act=com.google.android.c2dm.intent.RECEIVE flg=0x10 pkg=com.pomochat cmp=com.pomochat/com.dieam.reactnativepushnotification.modules.RNPushNotificationListenerService (has extras) } packageName=com.pomochat resultCode=-1 resultData=null resultExtras=null}
10-08 14:10:33.881 19416-19416/? D/ActivityThread: SVC-Creating service: CreateServiceData{token=android.os.BinderProxy@36993ccd className=com.dieam.reactnativepushnotification.modules.RNPushNotificationListenerService packageName=com.pomochat intent=null}
10-08 14:10:33.881 19416-19416/? D/ActivityThread: SVC-CREATE_SERVICE handled : 0 / CreateServiceData{token=android.os.BinderProxy@36993ccd className=com.dieam.reactnativepushnotification.modules.RNPushNotificationListenerService packageName=com.pomochat intent=null}
10-08 14:10:33.881 19416-19416/? D/ActivityThread: SVC-Calling onStartCommand: com.dieam.reactnativepushnotification.modules.RNPushNotificationListenerService@3538982, flags=0, startId=1
10-08 14:10:33.883 19416-19416/? D/ActivityThread: SVC-SERVICE_ARGS handled : 0 / ServiceArgsData{token=android.os.BinderProxy@36993ccd startId=1 args=Intent { act=com.google.android.c2dm.intent.RECEIVE flg=0x10 pkg=com.pomochat cmp=com.pomochat/com.dieam.reactnativepushnotification.modules.RNPushNotificationListenerService (has extras) }}
10-08 14:10:33.940 19416-19449/? E/RNPushNotification: No message specified for the notification
10-08 14:10:33.941 19416-19416/? D/ActivityThread: SVC-Destroying service: com.dieam.reactnativepushnotification.modules.RNPushNotificationListenerService@3538982
10-08 14:10:33.941 19416-19416/? D/ActivityThread: SVC-STOP_SERVICE handled : 0 / android.os.BinderProxy@36993ccd

After applying your PR, the change in behaviour when the app is closed is that the notifications are now being delivered to my js code via the onNotification function. BUT my app doesn't get started - I don't even see the first console.log call from the first componentWillMount. It's as if it's invoking a bit of JS code in my app, but not starting the app. Is that correct? It's not the behaviour I was expecting. I thought it was going to start my app in the background.

So why is onNotification even being called if my app isn't started? I assume that the call to configure, which sets popInitialNotification to false has happened - so theoretically the notification shouldn't be delivered to my app (yet).

In addition, when the app is in the background the notification deliveries get repeated. So the 1st notification received gets delivered once, as expected. The 2nd gets delivered twice, the 3rd 3 times and so on. I backed your changes out and retested agains the current npm version to make sure this wasn't my app being screwy but it behaved as expected.

I've looked at the your change, and it seems innocent enough. I certainly can't see why it's repeat delivering notifications. I assume you didn't notice this in your testing?

[mikelambert]

Great, glad we're getting closer on this.

Yes, your understanding is correct. If the app is not open, a notification will NOT start the app UI. That's impossible to do. What it does do is load the JS, in the background Listener Service. That's why I keep reiterating that any code in UI (including componentWillMount) will not be called on these notifications received while the app is closed. This is the standard Android notification setup...just applied within React Native.

popInitialNotification causes the current activity's (ie, the UI's) current notification to be returned. This is the notification that started the activity, because the user opened a notification (or the notification that was delivered to a backgrounded app that brought it to the foreground). But this should not be the remote notification being delivered to an app (foreground or background, started or unstarted), because that's not associated with the activity/UI.

As far as duplicate notifications, that definitely sounds like a bug. :/ I may have seen something a little similar when operating in hot-reload mode, where (I was guessing) maybe reloads were causing multiple instances of a push handler to be installed. I didn't notice it on a fresh app start/install, or on release mode apps, though.

Just to clarify, when you said the second notification gets delivered twice, what do you mean by "delivered"? The onNotification handler gets called twice? What is your notification handler doing...is it possibly calling PushNotification.configure at all? Trying to see if there are any clues that might help me track this down.

[npomfret]

Exactly, I'm getting repeated calls to onNotification. I've not debugged it to see where they're coming from yet. I don't believe it's reloaded to hot reload (I'm sure I tested that theory at the time). The handler isn't doing anything weird, and the behaviour of it is the same whether or not the app is backgrounded or not - and the repeat calls to onNotification only seemed to happen when backgrounded.

[npomfret]

I think the bug lies in the RNPushNotification constructor, or how it's being called. Inside it calls 3 register methods:

        registerNotificationsRegistration();
        registerNotificationsReceiveNotification();
        registerNotificationsRemoteFetch();

And in turn they add state to the react context. Now this ctor is being called after a push notification is received in RNPushNotificationListenerService.onMessageReceived (which then calls sendNotification) if the app is in the background.

        if (!isRunning) {
            // Run the notification on the JS thread
            RNPushNotification pushNotification = new RNPushNotification(context);
            pushNotification.notifyNotification(bundle);
        }

So with each push request that happens when backgrounded, we are adding more and more receivers for RNPushNotificationReceiveNotification. So the react context has increasing number of receivers which explains why I'm seeing more and more repeated calls to onNotification.

Before your change this read

    if (!isRunning) {
        new RNPushNotificationHelper(getApplication()).sendNotification(bundle);
    }

So maybe this is where it's gone wrong? To be honest I'm struggling to follow the code paths and finding it quite confusing.

[mikelambert]

Thanks, great debugging, I think that's exactly what's going wrong. (My assumption of hot-reloading was probably unrelated, and I was probably conflating "reload the code to fix a notification bug" with the second notification I sent after reloading.)

Anyways, I've just pushed a fix in a separate change, which you can take a look at directly. Basically it factors out the deliver-event-to-JS functionality from RNPushNotification.java, so that it can be used by the ListenerService directly, without the accidental installation of handlers (and without the need for the extra Intent communication that existed before).

Hopefully this helps clarify the code a bit, too.

[npomfret]

Ok, great. I've retested and it looks fine - thank you! I'll merge it now.

Forgive me for being stupid, but I'm still a little confused about the purpose of this change. If your app isn't running, and doesn't get started when the notification arrives - what's this change for? What can you do if your app isn't running?

[slestang]

This change, if I understood it correctly, should allow us to add a 'snooze notification' feature to our app.
We will try it today and give feedback.

[mikelambert]

In my case, it allows me to:

• handle incoming notifications with the same code flow, regardless of
  whether the app is not running or backgrounded or foregrounded. Otherwise
  it makes it really difficult to ensure consistent notifications between
  backgrounded and not running instances of the app
• send a data payload to the client, for the client to handle and process
  itself. This lets my client localize the notification for the user based on
  the phone's language, for example

One could also theoretically use this in a chat application, to track
whether the chat message had been delivered to the remote chat client (a la
Whatsapp and Facebook status indicators)

[npomfret]

Hi @ddobby94 @timhonders @jitenderchand1 @JonesN7 @heminm @vikeri @barroslee

This change is in master now. Are you able to try it out before we do a release? (You'll need to change your package.json):

From:
"react-native-push-notification": "2.1.1",

To:
"react-native-push-notification": "[email protected]:zo0r/react-native-push-notification.git",

[chaix-adrien]

"react-native-push-notification": "[email protected]:zo0r/react-native-push-notification.git",
doesn't work for me, but
"react-native-push-notification": "zo0r/react-native-push-notification.git",
do the job.

[chaix-adrien]

Modifications works fine for me.
The onNotification function is called even if the app is killed.

Thanks !

[vikeri]

For me onNotification is only called when I click on the notification. This both works when the app is active and when it is off. When the app is off it starts the app and runs the callback. Was the intention that the callback should run without having to click the notification?

[npomfret]

Yes I forgot about @mikelambert 's point. I had to refactor my app a little to get it to run some js code when it had been killed and a push notification arrived. Basically i needed to invoke the call to configure outside of any of the react-native life-cycle. Just do it in a js file that gets imported by your index.os.js file. Something like this. This change won't work for you if your setup of push notifications is inside a componentWill/Did mount, or any other react lifecycle point.

[codepujan]

@npomfret +1 . It's working . You guys have done a great work. Kudos

[jitenderchand1]

I moved my code to index.android.js file. onNotification callback is working fine but my onRegister function stop working. It is working fine when I use the onRegister callback in componentDidmount

PushNotification.configure({
                onRegister: async (token)=> {
                console.log(token)
 },
requestPermissions:true,
senderID:"31**********",
popInitialNotification:true
}

[igor-bv]

Hi guys!! @npomfret @mikelambert, I changed my package.json to
"react-native-push-notification": "zo0r/react-native-push-notification.git".
Now onNotification handler invokes in any cases when remote PN arrived, BUT...
every remote PN didn't trigger sound and for end-user it looks like app didn't receive PN at all.
Is the idea of your aproach is to receive every remote PN as 'silent' PN and then generate Local PN (when it is reuired to show PN for user)?!

Also, when app closed -> I received PN -> create Local PN -> when I press on Local PN app opens, but onNotification doesnt invoke...

Thanks in advance!

[igor-bv]

Seems like onNotification handler doesnt fires when app closed and user click on the local notification.

[mikelambert]

@jitenderchand1 Sorry not sure what's up there, did you ever figure it out? I have PushNotification.configurecalled directly from an import from index.android.js, and it works ok for me AFAIK. (And yes, I'm using an async function as well)

@bo4a10
It should be the same whether the app is open or closed. My understanding is this: When a notification is received when the app is open, the app's onNotify is called. It is the job of onNotify to construct a local notification if desired. When a notification is clicked to open, onNotify is called again (this time with userInteraction === true).

So if the app is closed, it is still the responsibility of your app to present the local notification. This should be the same as when the app is open, right?

When the app is closed, and the user clicks on the notification, it starts your app with a pending notification. This will not call onNotify automatically, unless you set popInitialNotification in your call to configure (to have it called automatically), or call PushNotification.popInitialNotification() directly (to trigger a call).

[igor-bv]

@mikelambert, thanks for response! Yes, you are right, and I expecting the flow like you are described. I called PN.configure with onNotification handler and popInitialNotification setted to false when import script in index.os file, and then in index.os React Component constructor I call PN.configure with popInitialNotification setted to true... Probably everything like you and @npomfret described here above.

Everything is clear for me except situation when app closed completly, and user will click on local notification that I created after I received remote notification... app just opens, and nothing triggers or 'says' me smth like 'hey, bro, you opened app by clicking on this local push notification'. :)

[mikelambert]

I'm not sure. That situation is unrelated to the changes I've made, and you'd have that problem with any notification that triggers your app to open. And yes, popInitialNotification should handle it. And it works for me, doing exactly what you described above.

My only suggestion would be to dive in and start logging/debugging. In particular, what is returned to getInitialNotification's callback in component/index.android.js, and where do things break down on the passing-up to onNotification? Of if nothing is returned, then dig into the java: What happens inside RNPushNotification.java's getInitialNotification, and what does it return? Is there any problems handling the Intent...what intent-filters are listed for your AndroidManifest.xml's MainActivity, etc.

[igor-bv]

ok, thanks for help @mikelambert, I'll investigate it deeper.
btw, one more question: should end-user see remote notifications now(with your changes) or they are don't appear in status bar anymore and end-user can't see them(we can catch them just in onNotification)?

I asked because when PN module in my package.json was in 2.0.1 version - remote notifications appears in status bar with sound and so on (they were visible for end-user), but when I checked out to master version of PN module(for closed app purposes) I can catch remote notification just in onNotification handler.

Hope that your answer will help me to understand on what point something went wrong, just on clicking on local notifications event or somewhere in global configs of the module.

Thanks in advance!

[mikelambert]

My personal usage of this library is to process remote notifications, and then produce actual local notifications with all the necessary field.

Previously, I believe if you passed all the necessary fields in the remote notification that were necessary for display, then the remote notification would have been presented to the user. (This was never documented here though, I only found it when digging in to the code...) This would have happened for app-loaded or app-closed scenarios, from what I understood. Is this what you observed? (Or did you only see this behavior work for app-loaded scenarios, in which case I'm confused?)

But yes, it's possible I broke the old undocumented behavior, since I don't use it.. :/

[igor-bv]

Hi @mikelambert. Seems like I found solution for my issue...
popInitialNotitifaction doesn't override when I initialize PN.configure at second time(in Component constructor) because PN.isLoaded property setted to true after first initializing(for closed app PNs).
/react-native-push-notification/index.js line 78.

I dont think it must be so, but my solution is to set PN.isLoaded = false before initialization of PN module in component constructor...

[mikelambert]

Ahh thanks for debugging, though I'm a bit confused as to what's actually not working here. (I'd like to ensure we fix it, if there's a bug...)

In my pull request, I had actually split out the code into both this.isLoaded (which installed handlers) and this.hasPoppedInitialNotification (which ensured we only popped a single time).

With isLoaded==true, as long as you haven't already passed popInitialNotification before in your first call, it should still look at popInitialNotification in your second call to determine whether to pop and call your onNotification.

So I'm confused as to what line of code inside the configure() call is being run when you manually set PushNotification.isLoaded=false, that allows your code to work?

[npomfret]

Is it related to this recently merged PR #242 ?

[igor-bv]

Guys, I'm really sorry! :)
@mikelambert, your last message saved situation. I found that I havn't got this part of code this.hasPoppedInitialNotification in index.js of the module. And I found that another dev replaced index.js file on his own modified file before building app...
Now I fixed this and onNotification fires everry time remote notification arrived or I pressed on local notification when app completely closed. So, seems like now everything works as you and probably I expected to work :)

Perfect job @mikelambert . Sorry and thank you a lot for help again. :)

@npomfret, my 'issue' was not related to #242. I don't use unregister() method - I have no need for it. thanks.

[npomfret]

@zo0r i think we're ready for a release.

[zo0r]

@npomfret published! Drop me an email to [email protected] if you want npm access too.

[stu60610]

Hi All, I've follow your steps to get the push message when app is completely closed, and when I pressed on notification, the app start and call onNotification successfully, but the notification object's message & data are all undefined.(like #161) Did I miss something to setup?

[chirag04]

@mikelambert our build started failed when updating from v2.1 to v2.2 of this lib. Turns out this commit breaks it for us. (Note we are building RN from source).

Below the the log. Would you have any idea?

:react-native-push-notification:compileReleaseRenderscript UP-TO-DATE
:react-native-push-notification:generateReleaseBuildConfig UP-TO-DATE
:react-native-push-notification:generateReleaseResValues UP-TO-DATE
:react-native-push-notification:generateReleaseResources UP-TO-DATE
:react-native-push-notification:mergeReleaseResources UP-TO-DATE
:react-native-push-notification:processReleaseManifest UP-TO-DATE
:react-native-push-notification:processReleaseResources UP-TO-DATE
:react-native-push-notification:generateReleaseSources UP-TO-DATE
:react-native-push-notification:incrementalReleaseJavaCompilationSafeguard UP-TO-DATE
:react-native-push-notification:compileReleaseJavaWithJavac
:react-native-push-notification:compileReleaseJavaWithJavac - is not incremental (e.g. outputs have changed, no previous execution, etc.).
/Users/chirag/Desktop/qsi/comlink/node_modules/react-native-push-notification/android/src/main/java/com/dieam/reactnativepushnotification/modules/RNPushNotificationListenerService.java:12: error: cannot find symbol
import com.facebook.react.ReactApplication;
                         ^
  symbol:   class ReactApplication
  location: package com.facebook.react
/Users/chirag/Desktop/qsi/comlink/node_modules/react-native-push-notification/android/src/main/java/com/dieam/reactnativepushnotification/modules/RNPushNotificationListenerService.java:59: error: cannot find symbol
                ReactInstanceManager mReactInstanceManager = ((ReactApplication) getApplication()).getReactNativeHost().getReactInstanceManager();
                                                               ^
  symbol: class ReactApplication
Note: /Users/chirag/Desktop/qsi/comlink/node_modules/react-native-push-notification/android/src/main/java/com/dieam/reactnativepushnotification/helpers/ApplicationBadgeHelper.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
2 errors
:react-native-push-notification:compileReleaseJavaWithJavac FAILED

FAILURE: Build failed with an exception.

[kanerogers]

@chirag04 I am having the same issue. Did you get any fixes?

[robcalcroft]

I can receive remote notifications fine even from cold start but onNotification isnt called in the background.

[jmeiss]

Me neither. Do you still have the issue?

[nonameolsson]

@jmeiss @robcalcroft did you solve this? Here is my issue, is it the same? https://youtu.be/NwcBsameqQ0

[vvavepacket]

@mikelambert

I have a question regarding your setup(reduxDispatch)

My situation is, so react native app is closed, and when a notification comes in, the notification kicks in, but it can't execute the payload which is navigating thru different UI screens by dispatching some actions.. I noticed that when the app is closed and a notification is received, the UI is not initialized, so those dispatch actions that were sent from onNotification were ignored.

So, when the user tries to click the notification, my current behavior is it launches the app and points to the default screen. How can we re dispatch, or reexecute the actions that was received? I tried looking in your repo https://github.com/mikelambert/dancedeets-react but I could'nt find any part of the code calling setup(reduxDispatch)

Also, what is the logic or the right way to implement it? I was thinking of storing the dispatch received when the app is closed into some sort of queue, and then when the app launches by clicking the push notification, the queue gets run and anything on it is re-dispatch again. I might sound complicating things, what is your approach for this?

[anton96]

@vvavepacket Did you solve your issue?