A way to slide a vertical menu in from the side, partially over native controls like Map and TextField

Solar2D Composer
#1

Our customers have started requesting this over TabBar, which is getting less popular.

When implementing one as a typical hamburger icon style menu sliding in partially from the side as in the app Mall of Scandinavia, I noticed that some views simply can’t have it sliding in in a good way. You have to shove native controls offscreen or remove them without a nice transition.

I’ve implemented it as a scrollView, partially following the example by Rob Miracle. Overlays won’t work. WebView with a local HTML file seems hacky, and I don’t think local HTML+Javascript is allowed in the bundle?

So the problem I have now is that I want a menu to slide in over a MapView. And it doesn’t seem possible. Is this something the team could consider as a feature request?

I.e. the menu is used for navigating the app with gotoScene, and that then means that it must be on top of everything any scene can create, including native controls.

#2

 Hi @henrik5. This is a request we cannot fulfill.  The native.* objects exist in a different space than Corona’s display.* objects (and widget.*). The later are part of the OpenGL canvas. The native.* objects exist in native space. Native space always sits on top of OpenGL. This is how Apple and Google designed things to work and we have no chance of making it work.

Now all is not lost, it takes a little creativity.  A couple of years ago, we allowed native objects to be inserted into display.newGroups() (which is what powers a scrollView). This has no effect on how things are layered, but when you move a group, native objects move with the group.

You could create a group called “menuGroup” or something sensible and insert your hamburger menu into it, but have it just off screen. Then when you create the native objects for that scene, add them to the menuGroup and position them on the screen. Now have your hamburger button’s press handler move the whole group right or left depending on the state using a transition.to() call. As your menu slides on, the native objects would slide with the menu.  Optionally you could hide the native objects while the menu is showing and show them again when the menu disappears.

This isn’t the most elegant solution, but it works.

Rob

#3

It’s a good solution to shove the current view outside the screen when showing the menu, because you won’t have be concerned about touch propagation or live updates.

It does require the menu to fill the whole screen though for it to not look weird, and that can be a challenge, since a list of 5-6 words in a huge font as the menu will look…questionable.

It may also not be compatible with layouts that have been established in specs or in previous versions, so that you could have to force a second large UI change on the users and the customer.

My current solution is to not have the menu button showing for the map views, but instead show a back button which goes to the previous scene, whichever that may be, and for the views having textfields, I’m hiding them while showing the menu.

Do you know of a mature replacement for the native textfields (that plays nice with keyboards showing/hiding etc)? Edit: I seem to remember a trick where you used an off-screen native textField for expected device interaction and mirrored it to an onscreen newText?

#4

The offscreen textField doesn’t really work that well. If the person tries to edit the text, you have no idea where the cursor is in the field. 

Instead of sliding the native objects off screen  you could just hide them temporarily. I know none of these are optimal.

Rob

#5

 Hi @henrik5. This is a request we cannot fulfill.  The native.* objects exist in a different space than Corona’s display.* objects (and widget.*). The later are part of the OpenGL canvas. The native.* objects exist in native space. Native space always sits on top of OpenGL. This is how Apple and Google designed things to work and we have no chance of making it work.

Now all is not lost, it takes a little creativity.  A couple of years ago, we allowed native objects to be inserted into display.newGroups() (which is what powers a scrollView). This has no effect on how things are layered, but when you move a group, native objects move with the group.

You could create a group called “menuGroup” or something sensible and insert your hamburger menu into it, but have it just off screen. Then when you create the native objects for that scene, add them to the menuGroup and position them on the screen. Now have your hamburger button’s press handler move the whole group right or left depending on the state using a transition.to() call. As your menu slides on, the native objects would slide with the menu.  Optionally you could hide the native objects while the menu is showing and show them again when the menu disappears.

This isn’t the most elegant solution, but it works.

Rob

#6

It’s a good solution to shove the current view outside the screen when showing the menu, because you won’t have be concerned about touch propagation or live updates.

It does require the menu to fill the whole screen though for it to not look weird, and that can be a challenge, since a list of 5-6 words in a huge font as the menu will look…questionable.

It may also not be compatible with layouts that have been established in specs or in previous versions, so that you could have to force a second large UI change on the users and the customer.

My current solution is to not have the menu button showing for the map views, but instead show a back button which goes to the previous scene, whichever that may be, and for the views having textfields, I’m hiding them while showing the menu.

Do you know of a mature replacement for the native textfields (that plays nice with keyboards showing/hiding etc)? Edit: I seem to remember a trick where you used an off-screen native textField for expected device interaction and mirrored it to an onscreen newText?

#7

The offscreen textField doesn’t really work that well. If the person tries to edit the text, you have no idea where the cursor is in the field. 

Instead of sliding the native objects off screen  you could just hide them temporarily. I know none of these are optimal.

Rob