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

Populate userInfo on android, update RNCPushNotificationIOS #1516

Merged
merged 22 commits into from
Aug 3, 2020

Conversation

lukebars
Copy link
Contributor

@lukebars lukebars commented Jul 8, 2020

This aligns the object returned by onNotification.

Currently onNotification returns:

{
   "android":{
      "android.intent.extra.ALARM_COUNT":1,
      "autoCancel":false,
      "finish":[],
      "fireDate":1594216704146,
      "foreground":false,
      "id":"2941",
      "largeIcon":"ic_notification",
      "message":"message",
      "notificationId":2941,
      "smallIcon":"ic_notification",
      "title":"hello",
      "userInfo":{
         "screen":"welcome"
      },
      "userInteraction":true
   },
   "ios":{
      "alert":"message",
      "badge":0,
      "data":{
         "id":"6380",
         "screen":"welcome"
      },
      "finish":[
         "Function finish"
      ],
      "fireDate":"2020-07-08T16:59:14.916+03:00",
      "foreground":true,
      "id":"undefined",
      "message":"message",
      "sound":"default",
      "userInteraction":false
   }
}

As you can see iOS returns userInfo as data, and android returns userInfo as userInfo. Also - id is not being correctly populated on iOS.

My proposal would return this object onNotification:

{
   "android":{
      "android.intent.extra.ALARM_COUNT":1,
      "autoCancel":false,
      "data":{
         "id":"9683",
         "screen":"welcome"
      },
      "finish":[
         "Function finish"
      ],
      "fireDate":1594219524047,
      "foreground":false,
      "id":"9683",
      "largeIcon":"ic_notification",
      "message":"message",
      "notificationId":9683,
      "smallIcon":"ic_notification",
      "title":"hello",
      "userInfo":{
         "screen":"welcome"
      },
      "userInteraction":true
   },
   "ios":{
      "alert":"message",
      "badge":0,
      "data":{
         "id":"2593",
         "screen":"welcome"
      },
      "finish":[
         "Function finish"
      ],
      "fireDate":"2020-07-08T17:41:44.910+03:00",
      "foreground":true,
      "id":"2593",
      "message":"message",
      "sound":"default",
      "userInteraction":false
   }
}

This would also allow us to provide data when getting scheduledNotifications, which I would implement little bit later. P.S. currently on iOS alert(title) is wrong, that's because iOS doesn't return notification title. I will raise a PR in RNC repo for that. Naming should be tweaked too (android - title, iOS - alert). Another possible solution would be naming data as userInfo

lukebars and others added 16 commits June 10, 2020 14:26
* dev: (48 commits)
  Release v4.0.0.
  Use SecureRandom and remove `onNotification` call for Scheduled notifications when there is no user interation.
  Update CHANGELOG.md
  replaced java.util.Random with java.security.SecureRandom in RNPushNotification.java
  Remove WAKE_LOCK from documentation. zo0r#1494
  Add `onRegistrationError`.
  Allow override the channel name and description in App. Add the detection of blocked channels.
  Fix notif reference undefined.
  Fix typo.
  Add notification id to iOS if userInfo doesn't exist
  `userInfo` is now populated with id by default to allow operation based on `id`
  "@react-native-community/push-notification-ios": "^1.2.2"
  add docs
  add example button to log scheduled notifications
  bump @react-native-community/push-notification-ios to v1.2.1
  format date for  scheduled notifications object
  map scheduled local notifications to united return object for both platforms
  add missing getters for notification attributes
  change naming of notification params returned on android, return date in unix timestamp as before
  format android getScheduledLocalNotifications return object to match iOS return object
  ...
Fixed version from 4.4.0 to 4.0.0
@lukebars
Copy link
Contributor Author

lukebars commented Jul 8, 2020

cc @Dallas62

@Dallas62 Dallas62 self-assigned this Jul 13, 2020
@Dallas62
Copy link
Collaborator

Hi @lukebars
Missed your PR in tons of notifications 😅
Thanks for this PR, changes looks great!
I will look into it ASAP 😉

@lukebars
Copy link
Contributor Author

@Dallas62 did you manage to look into it?

@Dallas62
Copy link
Collaborator

Will check this this afternoon

@Dallas62
Copy link
Collaborator

Hi @lukebars
What's strange is that there is no userInfo in the iOS return

@lukebars
Copy link
Contributor Author

Hmmm. I'll check that in few hours. Very strange.

@lukebars
Copy link
Contributor Author

lukebars commented Jul 17, 2020

@Dallas62 thing is that iOS returns userInfo as data, so we should choose do we return it as data to keep consistency between this lib and ios one, or should we return it as userInfo. Also we could return both, but that wouldn't make sense..

I could remove userInfo from Android to keep it the same way as in iOS

@Dallas62
Copy link
Collaborator

I will take a close look to this, because it's strange to set userInfo in iOS, use it every where but return it as data.
Busy this weekend, will dig into it on monday.

@Dallas62
Copy link
Collaborator

@Dallas62 thing is that iOS returns userInfo as data, so we should choose do we return it as data to keep consistency between this lib and iOS one, or should we return it as userInfo. Also we could return both, but that wouldn't make sense..

I could remove userInfo from Android to keep it the same way as in iOS

Hi @lukebars

I'm not totally convinced by this kind of "renaming" as an optimal solution, but it's probably the best way to unify Android and iOS actually. So, no problem to remove userInfo from Android and keep it the same way as in iOS.
We should probably check that Scheduled Notification accept userInfo and that there is no mix of naming when the application start in Android.

In the future, I think we should rewrite the API to unify and clean it. Also make a clear documentation. 😄

@lukebars
Copy link
Contributor Author

lukebars commented Jul 20, 2020

@Dallas62 or we could currently use userInfo on both platforms instead of data. Maybe that would be more clear.

@Dallas62
Copy link
Collaborator

Not sure it's better, because this is the name of the attribute of remote notifications.

@lukebars
Copy link
Contributor Author

Ok, sure.
I've raised a PR for getting alertTitle in iOS @rnc, as soon as it's merged I'll push some changes here to keep it straightforward.

@lukebars
Copy link
Contributor Author

Looks good :shipit:

@lukebars
Copy link
Contributor Author

Are we ready for some sort of release?

@Dallas62
Copy link
Collaborator

Hi @lukebars
I'm waiting for feedback from @mathiasmoeller on a fix introduced in this PR. (#1501)
I will re-check it this week and merge ASAP.

@lukebars
Copy link
Contributor Author

Hey @Dallas62, I've noticed a strange behavior on android that comes from handlePopInitialNotification.

When app is launched from killed state / fresh launch, and you schedule a first notification, onNotification fires twice for the first one. Native listener fires only one.

I see that if you comment out this._onNotification(firstNotification, true);, this behavior stops.

Was it intentional to do this or is it a bug?

@Dallas62
Copy link
Collaborator

@lukebars This is strange, I don't see this behavior

@lukebars

This comment has been minimized.

@Dallas62
Copy link
Collaborator

Can you test on the example project (without change expect setting the PR), if his is happening this is probably in the library.

In your code, does Notifications.scheduleLocalNotification(...); is trigger by an event such as button pressed ?

@lukebars

This comment has been minimized.

@Dallas62
Copy link
Collaborator

Can you give the steps to reproduce it on the example project ?

@lukebars

This comment has been minimized.

@Dallas62
Copy link
Collaborator

I don't see any problem, does the log:

console.log('NotificationHandler:', notification);

inside NotifSetup is right ? it's written NotificationHandler

@lukebars

This comment has been minimized.

@Dallas62
Copy link
Collaborator

Dallas62 commented Jul 29, 2020

Yes it's logged twice the notification, but the example Application has the same console.log in NotificationHandler and in the NotifSetup you provided, which explain this behavior

@lukebars
Copy link
Contributor Author

lukebars commented Jul 30, 2020

@Dallas62 Oh I was wrong about that 🤦

I've actually managed to reproduce it now. We're using branch in our projects for analytics and it requires setting intent.

It's easy to reproduce with only a minor change in repo example too: example/android/app/src/main/java/com/example/MainActivity.java:

package com.example;
// Add this:
import android.content.Intent;

public class MainActivity extends ReactActivity {

  // Add this:
  @Override
  public void onNewIntent(Intent intent) {
      super.onNewIntent(intent);
      setIntent(intent); // this is what causes double onNotif call when scheduling one on a fresh launch and clicking it
  }

// Everything else
...

@lukebars

This comment has been minimized.

@Dallas62
Copy link
Collaborator

Dallas62 commented Jul 31, 2020

Hi @lukebars
This change is wrong, the first parameter of .bind() is context. By changing this, the onNotification on the listener will never trigger with the right parameter.

A correct change would be:

  AppState.addEventListener('change', (state) => {
    handlePopInitialNotification(state);
  });

But you will see the same result.

There is a protection to block double trigger based on notification.id. Do you see any id in the notification ?

@lukebars
Copy link
Contributor Author

@Dallas62 eh, my bad.

Both onNotification messages fire with "id": "1".

Looks like if setIntent is configured in MainActivity.java, popInitialNotification is only needed for iOS, because onNotification fires even with listener commented out.

@Dallas62
Copy link
Collaborator

What is strange is that you are talking about double trigger even when you comment this._onNotification(firstNotification, true);

But it's impossible to get onNotification triggered whitout this line. So it can't be trigger twice and only once after removing this line.

@lukebars
Copy link
Contributor Author

Nope. When that line is commented out, it get triggered only once on Android.

Have you tried adding

  @Override
  public void onNewIntent(Intent intent) {
      super.onNewIntent(intent);
      setIntent(intent);
  }

to MainActivity.java ?

Instant double call without any code modification inside the lib.

@Dallas62
Copy link
Collaborator

I'm currently testing it, and I found the reason of that. Making more tests.
popInitialNotification is working fine, this is a problem with onNewIntent inside the library which looks like useless.

@lukebars
Copy link
Contributor Author

That explains everything. Looks like it's doing the same thing as the js initial notif part, only a bit worse. Nice catch 🚀

@Dallas62
Copy link
Collaborator

Yes but it's probably not so easy. on iOS, clicking on a notification when the Application is opened doesn't trigger the current part of "initialNotification", only Android do that

@Dallas62
Copy link
Collaborator

Also, the value of foreground looks not valid.

@Dallas62
Copy link
Collaborator

I think it's good now 😉
Nice investigations !

@lukebars
Copy link
Contributor Author

lukebars commented Aug 3, 2020

@Dallas62 awesome work! Tested it out and it looks really good 🚀

Are we getting close to closing this and releasing it out to the daylight?

@Dallas62
Copy link
Collaborator

Dallas62 commented Aug 3, 2020

Hi @lukebars
I was waiting for your feedback, will take a look today 😉

@Dallas62 Dallas62 merged commit ab8e29f into zo0r:dev Aug 3, 2020
@Dallas62
Copy link
Collaborator

Dallas62 commented Aug 3, 2020

Done ✅

Found the same issue you reported on iOS while testing 😄

Thanks a lot for this PR !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants