As I’m discovering more and more about Appgyver, I’ve run into a big limitation IMHO and that is the lack of flexibility in structuring and controlling the navigation menu (the same applies to the header bar).
As far as I know, the navigation menu and header can be either switched on or off on ALL pages. There is also no possibility of having a UI element (e.g. custom navigation component) stay visible between page transitions, as a possible workaround for this limitation.
I had a glint of hope in resolving this when I discovered it is possible to create custom navigation lists and custom navigation components as explained in the documentation here:
Navigation in Appgyver - official docs
but those navigation components don’t stay visible between page transitions either, which makes me think what is the real benefit in comparison with custom-made components with regular links to pages.
Then we have to put the Safe Area for devices with a Notch into the equation. At the moment it’s not possible to activate the safe area if either one of the navigation menu or header bars have been turned on. This means that if you decide to deactivate the header menu and keep the navigation menu, the Safe Area has no effect, which is not the problem for the bottom part of the page where you have the navigation, but in the top part of the page where the content slides over the notch. A workaround for this is to have an invisible container with a fixed height in the top part of the page that gets visible when an iOS device is detected (which can be done easily with the help of a formula).
I would love to hear from AppGyver gurus if someone has found a way to solve these limitations and if not, I would urge the Appgyver team to do some housekeeping on those basic features before developing new ones.
FlutterFlow e.g. gives you complete control of what do you want to display. Both the NavMenu and HeaderBar can be easily controlled on every single page.
Looking forward to comments and maybe some solutions!
I have no menu so can´t help, but interested in case I need this for a future app.
Advancing the navigation options is a popular feature request for quite some time.
It is mentioned in the latest “monthly update” in the section
Custom navigation components as well.
Personally, I considered to switch the standard navigation off and include a custom made navigation instead. But I decided against, because in regard the the amount of different devices out there, I feel more comfortable with a maintained (even non-flexible) standard.
Thanks for your comments. I read that monthly update but interpreted that changes that were coming are aimed at improving the web navigation components only. Now, when I read it again, it seems you are right, it’s across the board. Looking forward to this. Hopefully they release it before everyone disappears in July
In the meantime, I decided to keep the standard NavMenu and just have it visible everywhere for now. As for the HeaderBar, that one is switched off so I can design my own ones.
For what it’s worth, @Dejan, as the native navigation menus are so incredibly limited, many devs have taken to creating their visual nav systems manually. The thing that seems to frustrate a lot of beginners is a lack of positioning options like “sticky” or “fixed” to make the custom header container “float” at the top of an app page.
Well, there are ways to work around that too if you’re interested in building out your nav UI manually. Boolean (true/false) app variables can help with visibility of custom secondary components in your header/footer and the following tutorial can help with the floating header, for example: How to create a Sticky button? - #7 by Dominik_Greene
Hey @Dominik_Greene. Thanks for steping in and offering your device.
I figured out how to do the fixed menus by using absolute positions and scroll views. It wouldn’t be a problem to create a custom NavMenu and hide them on certain pages, but the thing is, nothing but the out-of-the-box Navigation stays visible between page transitions.
I was hoping that by creating a custom Navigation menu as stated in the Docs (https://docs.appgyver.com/docs/navigation), that that one would behave as the standard one, but this is not the case.
It would be nice to have proper sticky elements, that would stick once they reached a certain position after a scroll, but as we know, this is still also not possible.
One other thing I noticed is that once you put an input field inside a scroll view and bring up the keyboard by clicking on it, the view will not scroll to the input field, but will stay hidden behind the keyboard, forcing you to scroll up so you can see what are you typing in.
Also, the scroll-to function (available from the marketplace) will not work on the scroll view, but only on the whole page, which has to be switched off if you want to have fixed headers and footers.
I’m hoping the Appgyver team will give surprise us soon with these much-wanted features!
Pardon the delay in response, @Dejan.
You’re correct about the scroll-to not working with scroll views. I believe that was even mentioned in the thread I linked because that’s what that developer wanted his sticky button for – snapping back to the top of the page.
As for the not scrolling to the input for mobile keyboard interfaces, I haven’t worked on a mobile app seriously in Appgyver yet, but I might suggest making a pop-up custom modal (container set to 100% width/height, absolute positioning, and a higher z-index than the base page) with the text input at the top of the modal and maybe the bottom half for the keyboard to slide into. That’s how I would experiment with something like this.
And you do need scroll views for modals, by the way, but it does lock scrolling on the base page while visible and, since the modal will take of 100% of the viewport, it won’t matter where the end-user clicks the trigger button in terms of scrolling position…
You can control the modal’s visibility with Bool logic and just connect the input to a text variable. You can even have a Save/Submit/Post-type button in the modal if there’s enough space. Experiment, and happy app-ing.
Thanks @Dominik_Greene that you took time to write these tips. I’ll definitely keep experimenting. For now I was able to hack my way around many limitations, but some of them aren’t solvable till Appgyver makes certain changes under the hood.
Still, it’s pretty amazing what can be done in this framework. I just hope it can be used for production ready apps (that I’m aiming for), instead for prototyping only.
@Dejan Well done. That is one of the, arguably, rather amusing and frustrating things about Appgyver. It might not give you a direct code-based way to implement something, but there’s usually a somewhat convoluted but workable solution using AG’s approach to logic and scripting. That’s how we also did inputs that expand when typing multiple lines in them, and how we did max-length setups: Hacking it.
Really, what we need is third-party plugins. Give us that and most of our issues will be solved regarding limitations – albeit, yes, you would be touching code at that point. Worth it.
Good luck, Dejan.