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.

Sign up for GitHub

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

Jump to bottom

InAppMessageClickHandler action inconsistency between iOS and Android #1012

Closed
carloscuesta opened this issue Jun 29, 2020 · 4 comments
Closed

InAppMessageClickHandler action inconsistency between iOS and Android #1012

carloscuesta opened this issue Jun 29, 2020 · 4 comments
Labels
Enhancement / Feature Reproducible

Comments

@carloscuesta
Copy link
Contributor

carloscuesta commented Jun 29, 2020 •
edited by sync-by-unito bot

Description:

I'm adding support of deeplinking through In-App Messages

As explained in the docs this could be easily done using the InAppMessageClickHandler

Screenshot 2020-06-29 at 17 49 35

I don't know if this has been fixed on newer versions of the Native SDKs (since I'm using the 3.6.4 version of the library)

However I found that the action that comes to the callback of the addEventListener has different naming conventions on iOS and Android, see:

iOS

Screenshot 2020-06-29 at 17 43 56

Android

Screenshot 2020-06-29 at 17 33 51

Environment

  • react-native-onesignal: 3.6.4

Thanks!
@rgomezp
Copy link
Contributor

rgomezp commented Jun 29, 2020

Howdy,
Thank you for bringing this up. We will make it consistent across both platforms.

mikechoch added a commit that referenced this issue Jun 30, 2020
@mikechoch
iOS native has not yet released, but this is a fix for after
e46b7d4 
* Fix is related to the `NSDictionary` param keys not matching Android
  * This is consistent now and determined not from the bridge method but the actual native code
  * `[action jsonRepresentation]` will be used to generate the `NSDictionary` and will be passed to react that way
* This should also be done across other wrappers no already doing this and it fixes the react native issue #1012
@mikechoch mikechoch mentioned this issue Jun 30, 2020
Merged
@carloscuesta
Copy link
Contributor Author

carloscuesta commented Sep 16, 2020 •
edited

Hey @rgomezp I'm a little bit confused I want to upgrade the react-native-onesignal package and the iOS underneath but I don't know if this issue was addressed. I could see on the iOS release notes that this has been fixed but the PR #1013 is still open ?

@rgomezp
Copy link
Contributor

rgomezp commented Sep 17, 2020

Howdy,
Yeah so we still have to merge the PR in this repository as well. We will get this fix in before the next release.

rgomezp pushed a commit that referenced this issue Oct 27, 2020
@mikechoch @rgomezp
iOS native has not yet released, but this is a fix for after
c6fd101 
* Fix is related to the `NSDictionary` param keys not matching Android
  * This is consistent now and determined not from the bridge method but the actual native code
  * `[action jsonRepresentation]` will be used to generate the `NSDictionary` and will be passed to react that way
* This should also be done across other wrappers no already doing this and it fixes the react native issue #1012
Jeasmine pushed a commit that referenced this issue Dec 8, 2020
@mikechoch @Jeasmine
iOS native has not yet released, but this is a fix for after
50d99ee 
* Fix is related to the `NSDictionary` param keys not matching Android
  * This is consistent now and determined not from the bridge method but the actual native code
  * `[action jsonRepresentation]` will be used to generate the `NSDictionary` and will be passed to react that way
* This should also be done across other wrappers no already doing this and it fixes the react native issue #1012
@rgomezp
Copy link
Contributor

rgomezp commented Dec 23, 2020

Howdy,
This was merged and released. Thanks for your patience.

Enjoy!

@rgomezp rgomezp closed this as completed Dec 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Enhancement / Feature Reproducible
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@carloscuesta @rgomezp