See the entire conversation

If you're wondering how navigation drawers work with gestural navigation, it looks like this. 👇 Apps need to update to DrawerLayout 1.1.0-alpha01 (out this week). You can try this yourself in the #io19 Android app in Q Beta 3
29 replies and sub-replies as of May 10 2019

What a stupid way to use gestures 🙄
We've been burned by alphas recently but would like to (quickly) fix the drawer for Q preview users.
I also have a reflection based implementation which works with compileSdkVersion=P (in a gist). Would that be helpful?
yep! Sounds like something I could land in our main problem spots quickly
Cool, I've been debating whether to actually release it, but it sounds like it would be useful. I'll tidy it up and get it out this afternoon
Check your DM
Do you know if it will work with OEM implementations? Ie Huawei and Xiaomi use the same gesture for back, but they ask you to pull from top to open the drawer. Just wondering...
Yep, as @rohanscloud mentioned in the talk, we are working with OEMs.
Most of gesture based games broke for me. I had to go back to 2 button navigation.
Yep, we need to create some guidance for games. We *think* it will just be: use immersive mode.
...also immersive mode is slightly broken for gesture nav in beta 3. The next beta is far better for games.
The one downside I saw in the I/O app was if you were a couple screens in, opened the drawer, and then swiped back. The underlying content would go back, but it was really hard to see if anything changed because the drawer was still open.
Interesting, sounds like a bug in the I/O app. Thanks for reporting 👍
What should happen in that case? You go back one screen *and* the drawer closes? Or something else?
Yeah, my gut feeling is that we should always close the drawer when going back. /cc @adamwp
That whole paradigm is just weird an unintuitive IMO. I really like how Vivid NG does it (been using it for a few months). Basically, only the bottom of the screen is captured so you get normal interactions with a bit of finger stretch.
It would be nice to have swipe to go back and drawer at the same time but it's a bit weird too. Should ot wait until drawer closes and then go back or go back and close the drawer at the same time? I think that's why drawers were not so popular on iOS. 1/2
I saw 2 patterns on iOS: 1. Swipe always goes back and drawer can be opened only by tapping on a burger icon. 2. Swipe always opens drawer and to go back you have to tap back button on the toolbar. 2/2
Hmmm, the app I mentioned above is much better (for me) then what you're describing. Anything near to the bottom of the screen is system space. Anything up top is app space. It's simple and intuitive.
I think it may be a bit harder to get used to it but yeah - once you make the muscle memory it's pretty cool. Would be useful to be able to invert it horizontally for left handed users.
Definitely! The whole app is completely customizable (those are just the gestures I've chosen). For example, I have Google search as a swipe left.
And you have to be careful when designing the app. You can't have full width scrollable views in the bottom area of the screen, right? So carousels or scrollable bottom navbars have to be padded left/right.
Seems legit at a glance
That's the guidance I gave at the sandbox.
That way if you're expecting left swipe to go back instead of open the drawer, a second swipe does what you wanted it to do in the first place
Eventually we can get everybody unconsciously thinking of the drawer as "half an activity back"
...what if we got rid of the drawer, like... forever?