Description:
If notification had app_url and was execute inFocusDisplaying(InFocusDisplayOption.none) - notification will be invisible (it's okay) but app will be redirected to url
(your description here)
Environment
Podfile.lock:
- react-native-onesignal (3.2.11):
- OneSignal (= 2.9.4)
- React
react-native info:
React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: (4) x64 Intel(R) Core(TM) i5-4288U CPU @ 2.60GHz
Memory: 192.70 MB / 8.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 8.13.0 - ~/.nvm/versions/node/v8.13.0/bin/node
Yarn: 1.12.3 - /usr/local/bin/yarn
npm: 6.4.1 - ~/.nvm/versions/node/v8.13.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
Android SDK:
API Levels: 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.2, 25.0.0, 25.0.2, 25.0.3, 27.0.3, 28.0.3
System Images: android-27 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.5540.7.32.5056338
Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
npmPackages:
react: 16.6.1 => 16.6.1
react-native: 0.57.5 => 0.57.5
npmGlobalPackages:
react-native-cli: 2.0.1
Is it expected behaviour? If yes - is it possible to disallow redirecting?
Anyone?
i'm having the same issue i think
I think it's just the way it works, which is really unfortunate in iOS
I'm currently trying to figure out how to prevent it from happening.
Currently, if you set the notification with a uri/url (which is normally reserved for tapping on), it will automatically redirect to the screen when the app is open. Which isn't a desired behaviour at all.
were you able to figure anything out? @indapublic
it does it with inFocusDisplaying(1) too
are you using react-navigation?
@DISKONEKTeD Yes. I had custom getActionForPathAndParams for custom url processing.
But I changed my behaviour. Example:
App.js:
import { AppState, AppStateStatus, Linking } from 'react-native';
componentWillMount(){
AppState.addEventListener('change', this.handleAppStateChange);
}
componentWillUnmount() {
AppState.removeEventListener('change', this.handleAppStateChange);
}
handleAppStateChange = (nextAppState: AppStateStatus) => {
switch (nextAppState) {
case 'active':
setTimeout(() => {
Linking.removeEventListener('url', NavigationService.openUrl);
}, 300);
break;
default:
Linking.addEventListener('url', NavigationService.openUrl);
break;
}
};
NavigationService.openUrl looks like:
const openUrl = (event: { url: string }) => {
if (/someregexp/.test(event.url)) {
navigate('MyRoute', {});
}
};
This task on QA at the moment (so I can't say it absolutely working solution), but it working well on my device.
I hope it can help you.
Ah, brilliant, it worked! :)
much appreciated @indapublic
@rgomezp Why it was closed? Issue still reproducible
@indapublic Sorry about that. Do you have the latest SDK version? Probably not related but always good to update. Also, are you seeing this just on iOS? and I think you meant launchURL correct (not app_url)?
If you are creating your own custom url processing function, you can always pass the url through the additional data functionality and then route the user as you see fit.
@indapublic if you tap a notification that has a set url then it will open the URL, this is correct behavior. If you do not want our SDK to open the URL in some cases then you can do what @rgomezp suggests and have a custom URL field in additionalData.
@rgomezp you were right to close this since it鈥檚 expected behavior (not a bug)
@Nightsd01 As I wrote, I hide notification splash so I can't click on it
@Nightsd01 this is still an issue. If launchURL is set, and the app is already open on iOS, then when it receives the push notification it opens the URL immediately without any action by the user.
Very odd experience and wouldn't be expected as a default by the developer or the user.
Paste of verbose logs from the event when the notification is received --> https://pastebin.com/A8V7n0Lz
@rgomezp
The solution with additionalData does not seem to be a real solution in my opinion, it's just a way to avoid the existing issue...
Handling redirect with deep link is way cleaner than using additionalData, so it's a shame we can't use that implementation only on iOS (it's even working on Android...).
I upgraded to
"react-native-onesignal": "^4.0.6"
and it seems to be resolved :) !
Glad to hear it