I'm trying to navigate to a specific screen when user clicks a notification. I'm using react-native-push-notification and it works great. The problem is, for some reason navigation doesn't happen.
I call this function onNotification, and it's being executed
function onNotificationOpened(notification) {
console.log('navigating')
console.log(NavigationActions)
NavigationActions.navigate('Journal')
}
So 'navigating' is printed on the console, as well as NavigationActions with a function navigate in it. So it's there. But when app opens, navigation doesn't happen and the app stays on the same screen. There's no typo or anything in the screen name. After the app opens I can navigate normally. It doesn't matter if I put navigation there or not, the app still opens on the main screen.
I'm thinking that it could be that navigation does happen, but just a bit prior to app itself opens the main screen. I'm not sure of that of course, it's my guess.
Am I doing anything wrong here?
what you want to do is similar to deep linking,lock at this
,there are some helpful answers.
Try this on your onNotificationOpened function
let isBackground = notification.foreground;
if(isBackground == true){
this.props.navigation.navigate('Journal');
Related
Is there a way to navigate to the scene that the user is currently on? Almost the equivalent of refreshing the component?
I have a reusable component called ProfileScreen, which shows a user's profile. That user, by default, is the logged in user; but it can also be a user that they select on a different screen.
The problem is that if the user is on another user's profile, and tries to navigate (via Drawer) to their own profile, it does nothing. I've tried obfuscating the navigation actions inside of redux functions to no avail.
Right now I'm having it navigate briefly to a "Loading" component before navigating back to the profile scene, but this is far from an optimal solution.
Any thoughts?
Actions.refresh() will do the job
I am using react-native-firebase on a project to implement push notifications. One request came in to make the user navigate to a specific screen whenever one taps on the push notif alert.
react-navigation is being used for the screen navigation.
I use push to mimic an inbox feature in my app.
Can you please suggest the ways this can be implemented?
One solution would be to add the listener on a screen and the perform the navigation since in it will already have the navigation props. But I have too many screens. Another solution would be to have a reference to the root navigator and pass it to the pushnotification controller. But this fails as I use redux and if if I add the config option { withRef: true } , It complains saying that the ref passed is not a function.
Do you have a better way of doing it or indicate to me what am I doing wrong please?
Thanks and Kind Regards,
Avinash
I have a solution for you , you can add a listen in you App.js , save that notification in async storage and then Access that notification object on the same page where you handle the logic of login user if token is present (Checking if user is login you can navigate him to desired page ), there you can navigate user to desired screen ,
Here you can check two things ,
easily access to notification object , detect whether is clicked or received.
easy to user auth , which is must to check on push notification
Hope my answer make sense to you
I'm using a tabNavigator. In the first screen, I simply call the firebase listeners for push notifications and then I do the navigation.
I'm struggling with what I would hope is a simple issue. I have multiple StackNavigators with various screens in each and I'm using a Drawer to move between the main stacks in addition to .navigate. Like this:
Main Stack
Main Screen (entry)
Member Profile
Inbox Stack
Inbox Screen
Message Details Screen
On the message details screen a user can navigate to Profile. So Message Details > Profile. This works great, as it does throughout the app. Navigation in the same stack works great both forward and back. I'm using the standard .navigate to move forward.
this.props.navigation.navigate('MemberProfilePage')
However if I tap the back button - or set a custom back button - the user is taken all the way back to the Main screen. And If I tap on Inbox in the drawer, the screen will still be on the Message Details.
But I really just want to go: Message Details > Profile ... Profile goBack() to Message Details.
I've tried the default goBack(), I've tried dispatching a back action like this:
const backAction = NavigationActions.back({
key: 'ProfileScreen'
})
or
const backAction = NavigationActions.back({
key: null
})
Thanks for any direction.
Edit: the initial suggestion about setting the backButton in Drawer appears to work. But it doesn't solve the problem.
I don't want to be taken back to the initial screen of the current stack. I want to go back to the screen I navigated from which is in a different Stack.
Had the same problem with two navigators and going back always takes you correctly on one, and wrong on the other as it pops to the root of the current StackNavigator.
For me, the solution was to reference the same screen in both stackNavigators, and when you navigate to it from two different navigators, the same screen will be shown, but it will be loaded from different navigator and everything should work fine. Hope this helps.
In your DrawerNavigatorConfig change this props
backBehavior='none' //default is initialRoute
backBehavior - Should the back button cause switch to the initial
route? If yes, set to initialRoute, otherwise none. Defaults to
initialRoute behavior.
https://reactnavigation.org/docs/navigators/drawer#DrawerNavigatorConfig
check if its working ...
I'm developing an iPhone (iOS 5+) app using storyboards. The first screen of the app is a splash/login screen that checks for Facebook credentials and enables you to read and accept Terms And Conditions. In case there are valid stored credentials and the TOC has been previously accepted, this view automatically makes a modal segue (using a cross dissolve effect) to the first "real" application view, a tab bar controller with three tabs.
I'm currently implementing backgrounding and foregrounding logic. The problem is that when pressing the home button and then coming back, the login screen is briefly shown before the correct pre-backgrounding view is restored. (The Default.png of the app is of the login screen background, so it might be either that or a backgrounding-time screenshot of the actual login screen; I haven't tested replacing Default.png yet to tell the difference.)
Why is this? As far as I can tell, backgrounding the app should just take a screenshot of the view that is visible on the screen when, say, hitting the home button, and restore that prior to restoring the actual view functionality when coming back to the foreground. In this case that would be one of the tabs of the tab bar controller. Is the modal segue between the login screen and the tab bar controller the culprit here, or something else?
(I've always felt that the cross dissolve modal segue from the login screen to the first "useful" screen is a bit dirty, since IMHO a modal segue seems to imply that what your segueing to is something you'll later dismiss to get back to the "from" screen. What I'm doing now is just leaving the target of the modal segue visible indefinitely. If that is the problem here, I'd love it if someone would suggest a better method of displaying, transitioning away from and "jettisoning" the login screen.)
OK, turns out this was just a simulator/device discrepancy regarding Default.png. This comment on another question made me think to check. Time to file a bug report.
If I recall correctly, Apple has some old demo code which "remembers" which view a navigation controller was showing before it went into the background.
By way of disclaimer, I haven't worked with storyboards, so I don't know the specifics of doing what you're trying to do.
If it were me, I'd create the view controller or controllers at launch, and then only add the login screen if deemed necessary by the app delegate's logic. Only then, after setting up the view hierarchy, do I present everything.
This accomplishes two things. My login screen only exists and is visible if necessary. Additionally, the login screen won't flash unessecarily. Oh, and as a third benefit, you can present any view you like.
I'd suggest, assuming the aforementioned demo code doesn't work for you, that you'll want to save some sort of reference, tag, or ID of the currently visible view in NSUserDefaults and read that out when setting up your view hierarchy on launch.
I recently implemented navigation in my app using NavigatorIOS in React Native. However, I think I've encountered a problem. Say I have 10 nav buttons on my home screen. Correct me if I'm wrong but I'm assuming (since I haven't done the backend yet) that if I use the first button to navigate to the next screen (let's call it Second.js), wrote/saved some data, and then went back and navigated to Second.js with the second button, that data from before would still be there? If so, is there a way for each button to navigate to a different "version" of the same screen? For example, could each button go to its own version of Second.js so that each button has its own local data in its Second screen, or would I have to make Second1.js, Second2.js, Second3.js, etc.? If the former isn't possible, I'd need a fixed number of nav buttons, plus a lot of memory is wasted with all these new classes that are basically replicas of each other. Thank you!