-
Notifications
You must be signed in to change notification settings - Fork 41
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
Integration issues with react-native-gesture-handler on Android #264
Comments
Thanks, I’m really pleased you like the Navigation router. It’s great that you’re integrating the Drawer Layout. I planned to give it a go but never got around to it. Let’s tackle the main issue first and see if the secondary one still exists after that. When installing I think it’s not working on subsequent screens because they use different |
I just had another read through the gesture handler guide and I think that wrapping each screen in the HOC should also work. Can you give this a try as well and let me know how you get on? const {welcome,menu} = stateNavigator.states;
welcome.renderScene = () => gestureHandlerRootHOC(<Welcome />);
menu.renderScene = () => gestureHandlerRootHOC(<Menu />); |
I tried the exact same and got a blank screen with a warning
Since the initial screen doesn't load i simplified my App.js to just a single route:
I also tried Edit: I just noticed the comment regarding the installation. I will try that and report the outcome back here. |
Sorry, this should work const {welcome} = stateNavigator.states;
const WelcomeScene = gestureHandlerRootHOC(Welcome);
welcome.renderScene = () => <WelcomeScene />; |
I had followed the normal(non-native navigation libraries) installation procedure already so didn't have to change anything in These were my 2 broad attempts and outcomes. Approach 1:
Outcome: Crashes without opening when i attempt navigating to the inner screen i.e Welcome opens but cannot navigate to Menu from the button link. The app crashes. I don't have my own HOC and instead call the Approach 2
Outcome: My not upto-the-mark(an understatement) java skills has me stuck at integrating the changes you had outlined. In the
I also added the following lines to
I get the following build error
I am guessing i will need to call/instantiate the equivalent of Im not sure how to proceed to completing the build for this approach to check if it works. My understanding is that this approach is akin to integrating
[My personal opinion though is that a |
We should be able to get Approach 1 working. I'll give it a try and see what the problem is |
UPDATE: I tried the following approach which is similar to approach 1 i outlined above:
Outcome
Essentially what i do get is that the HoC approach done this way doesn't seem to work. |
Thank you. I am looking forward to using Navigator since it does tick to most of what i am looking for. Unfortunately a Drawer is one of the primary requirements in my current project. Will not be a showstopper though since i may opt for a JS variant if integration is cumbersome. The Gesture Handler library is quite useful beyond just the DrawerLayout and i suspect is used quite a bit all around. |
I agree. It's v important that the Navigation router works with the Drawer and the gesture handler. Leave it with me |
I've caught up with your efforts. Thanks for trying hard to work out the problem. I've done some investigation myself and there is a problem with using the gesture handler and Navigation router on Android. The gesture handler expects to be inside a So a different solution (I've tried it and it works) is to use the DrawerLayoutAndroid component. It wraps the native DrawerLayout so is probably a better choice for Android anyway. For iOS you can keep using the DrawerLayout component from gesture handler. The import {Platform, DrawerLayoutAndroid} from 'react-native';
import DrawerLayout from 'react-native-gesture-handler/DrawerLayout';
var Drawer = Platform.OS === 'ios' ? DrawerLayout : DrawerLayoutAndroid; Don't forget to remove all the Android changes for the gesture handler installation (HOC's and MainActivity) |
Ok. I had this in mind as a possible solution for Android, though i was thinking of attempting a So, for now i will be going by your suggestion and retaining the gesture handler in IoS and falling back to the shipped Gesture handler though would have been a nice addition since i was planning on using it for static bottom tabs (JS) elsewhere in my app and attempting a swipe-to-change tab interaction. Maybe Thanks for looking into it. I am closing the issue since there is a logical closure to the queries. |
Thanks again for your hard work on this issue and I’m glad you’re happy with the solution. I agree that there should be a 'native' drawer on iOS too. The iOS platform doesn’t have a native drawer, but there should be one for React Native that uses a Do you see why I don’t think a Yes, you can use the I’m not sure if I should raise an issue about using the Navigation router and gesture handler together. I don’t want to because I think it’s a gesture handler bug, not a Navigation router one. You see, I copied the React Native’s Modal code to build the native screens on Android but it turns out that gesture handler doesn’t work with the Modal component on Android. |
IoS should have a native drawer, definitely yes. From what i recall from a cursory reading of the guidelines, they are not keen on having primary elements that are 'hidden' away. They re-direct any feature requests for a Drawer to Tab-based solutions as a viable option or suggest restructuring the solution ground-up to not have any such interact-able hidden elements. Since it was a while ago i am sure the guidelines would have been amended here and there to keep up with the times. React Native does an interesting merge of two varying platforms with varying guidelines for quite a few elements, components and pattens but i guess they can only go so much before the possibilities of bugs to appear increase exponentially. Still not fully convinced regarding the separation of the obvious correlation of a Drawer and a navigation solution. But this is from a zoomed-out perspective and admittedly also from practical usage as seen today. I guess i'll have to agree with you when taken as individualised components in a navigation solution. They do not have a firm presence and theoretically can easily be used for just about anything that has nothing to do with navigation in general. It depends on the perspective ultimately. Very interesting to know about the gesture handler bug you have linked to. I had no clue. In fact this comment is the exact same fix - open a new screen and have a modal popup in it - i accidentally stumbled upon in a recent project(the same project that i am currently doing actually, but using |
I don't think iOS should have a native drawer because, like you say, it's not the recommended UX on the platform. Android and iOS have different primitives. The Navigation router only wraps the underlying native APIs. That's why it only has a TabBar on iOS. However I do think there should be a React Native community Drawer component that uses a UIViewController. |
I think that is a fair comment, come to think of it. Technically they have mentioned installation procedures for broadly two classifications of Android apps:
It may interest the author(s) and maintainers that there is a scenario where it doesn't seem to work and perhaps they may wish to make changes to accommodate navigator solutions such as these. Given some time and a deeper dive into gesture handler/Navigator(so that not all content go over my head in the event of questions or comments ) i may consider opening an issue in the gesture-handler repo sometime in the future. I cannot commit but i see the benefit for sure. A couple of takeaways(from a technical standpoint) that i get is so far is
[essentially gesture handler may need to factor in that certain screens in a native Navigation library may have views that are not necessarily inside a
[Back handlers may react differently depending on the library. How is this to be considered] |
It'd be good if you raised the issue on gesture handler. If you don't feel like creating a new issue you could explain the new scenario in the existing Modal issue. |
Ive opened a new issue at the RNGH repo as well (issue 688): Unable to fully integrate react-natve-gesture-handler with the Navigation library. I guess, depending on the analysis, it may or may not be merged with issue 139: |
Thanks, good job! |
Well, after resolutely refusing to give up due to some slow internet connectivity over the weekend, i was finally able to start out a new React Native project with only the This was because i was getting some issues with the The fresh new install confirmed that these are reproducible issues and not because of any conflicts with other packages. I just wanted to know if it indeed worked for you in the inner screens as you mentioned in one of the comments:
My package.json entries:
Welcome.js:
Menu.js:
Do note that it does work on the initial screen as expected: both the gesture and the tap functionalities. While gestures are important, i intend to have a hamburger menu that would always be the primary navigation artefact intended to be used by people who may not be aware of the gesture capability that also exists as an additional aid. This would require using the if the issue is reproducible can it because of something that needs to be done here in the |
Thanks for the update. It worked for me on the inner screens but I only tried it with the gesture. I didn't try calling |
The Android The way I'm using React Native is that the new screens are rendered in React first and then I start an I'm working on a solution inspired by the I need to do some more testing but I wanted to update you with progress. Here's the new code for the public class SceneView extends ViewGroup {
public SceneView(ThemedReactContext context) {
super(context);
}
@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
getChildAt(0).requestLayout();
post(measureAndLayout);
}
private final Runnable measureAndLayout =
new Runnable() {
@Override
public void run() {
getChildAt(0).measure(
MeasureSpec.makeMeasureSpec(getWidth(), MeasureSpec.EXACTLY),
MeasureSpec.makeMeasureSpec(getHeight(), MeasureSpec.EXACTLY));
getChildAt(0).layout(getLeft(), getTop(), getRight(), getBottom());
}
};
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
}
} |
Thanks for clarifying on why the core issue happens. And for re-opening the issue. The core context ( This explanation does help get some additional insights why the initial scene was adapted differently as well. I can also see how this helps in the relatively easy and predictable handling of the back navigation: the Have not actively used I will try out (no harm in doing so: i am on a fresh install) just to get a feel of the code though i cannot be sure if it will be successful. Regarding the assumption, currently yes. For my current project I have some flexibility so caveats are perfectly fine. I guess if this is a strict requirement for full support for a |
From the DrawerLayout Android doc
Makes things easier because we don't need to worry about HOC |
Just to be clear, the Navigation router doesn't use the |
Thank you. I just did the same and it does work perfectly fine. Ive introduced a few more scenes to verify and the drawer works as expected, both the gesture and programmatic invocation. Please do let me know if i can close this issue or perhaps you may wish to do it after testing. |
Thanks for testing. I've just merged the fix in and closed the issue. I'll do a new release shortly |
Just released navigation-react-native v5.3.1! |
I've released navigation-react-native v6.0.0. The Navigation router now supports the React Native Gesture Handler. I encourage you to upgrade. The NavigationStack renders scenes inside Fragments instead of Activities so you can't use the I wrote a migration guide in the Release Notes. Let me know if you have any questions |
Ok. This does open out a whole lot of possibilities and i will need a re-think of my current in-progress implementation. I am currently on v5.6.1 and will upgrade to v6. I am still in early phases so flexible enough to do an upgrade without thinking too much about breaking changes. Just FYI (and for other readers browsing through), unless i've read it wrong, i am assuming you meant
|
I did mean that, thanks for the correction 👍 |
Applied the fix from over 2 years ago to the SceneView again and it works, #266! Not sure why it didn't work for Fragments back then but it does now, #264 (comment)?
Hey @arunmenon1975 I’ve added support for So here's a import {Platform, DrawerLayoutAndroid} from 'react-native';
import DrawerLayout from 'react-native-gesture-handler/DrawerLayout';
const Drawer = Platform.OS === 'android' ? DrawerLayoutAndroid : DrawerLayout; |
This is great news and perfect timing as well for me. My current project is scoped rather large at the moment: a PWA solution (with Due to some project requirement changes - as recent as the last couple of days - i had to basically go back to using However, |
That's great to hear and thanks for the support. Next.js should replace their router with my Navigation router. The Navigation router is much better suited for Next.js. Next.js is meant to be file-based navigation. One file per page. But its support for nested routes breaks file-based navigation. Take the example of a list of posts with the selected post's comments displayed inline. This should be a single file because it’s a single page. But if you want your routes to be 'pages/post' for the list and 'pages/post/[pid]' for the comments then you have to create two files! If Next.js used the Navigation router you’d have only one file because you can register both routes for the same file. You’d configure a combined route of 'pages/post+/{pid}' so it matches both 'pages/post' and ‘pages/post/3'. |
I agree with the simplicity and ease factors. But i guess Next was also looking at convention-over-convenience probably: a file system based routing from a mental model perspective is easier to understand and also more familiar(for example in an IDE or an OS file explorer) but does come at a cost as you described above. If My reason for using I suspect though that Next(and its user-base) is too invested into its current routing solution to consider immediately changing it. But i also notice that they are very keen in constantly improving the product as a whole so there definitely is a possibility that a future version could have the Also as a side-note, the creator of |
Routing in Next.js is an underwhelming implementation of a nice idea. I wrote about how they can get rid of nested files and still keep their file-based approach |
I am attempting to use
Navigation React Native
as the routing solution for my native app and am liking it quite a bit: performant, simple, intuitive and quite flexible. However, In my early integration attempts (using some of the other core libraries i would be using in my redux-driven app) i find that I have a couple of Android-specific issues when i attempt integration withreact-native-gesture-handler
.Main Issue
The
SideDrawer
seems to work only in the initial screen when an attempt is made to trigger it via a gesture (swipe left/right from the edges, depending on the configuration). When i navigate away to another screen that also has the SideDrawer, it does not work. It does work everywhere when i try to programmatically open/close, regardless of which screen i am on, however.Secondary Issue
Additionally a minor issue was noticed as well. Running back actions, both via an app button and via the hardware back button, seem to flash the side drawer for about a second before navigation. It seems like it is navigating 2 steps instead of 1 with the flashing drawer seeming to visually appear as an intermediary screen.
Note: Everything works perfectly fine in IoS however.
I use the SideDrawer as an HOC, wrapping screens that would require the SideDrawer but have attempted using it normally as well.
The installation docs for
react-native-gesture-handler
has a section dedicated to installation for android apps that use native navigation libraries. Essentially they require wrapping each screen with a dedicated HOC shipped with the library.As far i understand
Navigation
has a single ReactRoot(a recent change) and so, if wrapping is necessary, it can be done at the topmost level. I tried that but It didn't work. I also attempted wrapping individual screens but with no success. Ive used the gesture handler library in other apps, both JS-driven(react-navigation
, no change was necessary) and native (react-native-navigation, with integration of the specific changes required as was documented) and they work fine. My guess is i might perhaps be needing the wrapping of the dedicated HOC shipped with react-native-gesture-handler since, as per the installation docs forNavigation
on React Native, there is specific mention of the use of native APIs for navigation:My current minimal package.json:
The App.js:
The Welcome screen:
The Menu Screen
The text was updated successfully, but these errors were encountered: