Bubble’s mobile native release is months away. I’m starting to prepare for it.
I’m thinking of creating a reusable element that I can easily drop into the new native mobile editor.
@josh should I prioritize single page app navigation (show/hide of groups) to custom states or URL params?
Some say URL parameters are not good for native. Will this be true for bubble mobile native?
In Bubble terms… that’s probably a year or two…
This was the premier announcement at bubblecon. I would hope it’s not a year to two away.
I’m optimistic. I hope they’d only make such a big deal if they were confident they could deliver.
Just a heads up, if you use custom states for app navigation, i would recommend still force updating the URL of the app to reflect navigation. Ofcourse without using the ‘go to page’ action, but with the Javascript history.pushState command.
I would recommend this for the following reasons:
Without updating URLs, the native android back button needs to be disabled; the back button is generally used to go back to the previous screen, however in reality it goes to the previous URL. If you use custom states for app navigation that wont work, as the URL never changed.
On both iOS and android, sharing a particular point in the app becomes much more annoying, as you cannot just use ‘this url’ to share the location of the app.
But most annoyingly, Page refreshes will send the user back to the homescreen, or even worse, back to a payment accepted notice/invite screen/ whatever link they used to get on the app at the beginning of their session. This problem is made worse by the fact that searches sometimes get cached/ websockets get severed, and the most reliable way to update searches would be to refresh the page.
I hope that Bubble addresses these issues when working on native app support.
I do prefer custom states to URL parametesr, as using the ‘go to page’ action will trigger all ‘page load’ workflows to run even if you are navigating to current page, which is annoying. It potentially leads to a performance problems, wasted WUs, and more.
Very interesting. I’ve never heard of this. Thanks!
This is gold. Thanks!
I wonder if this is why Zero code says it slows down native app.
I haven’t been able to find a way to use states in a way that remembers “urls” like an actual url paramter would.
People expect a back button to take them to the most previous page. I have no idea how to go to the most previous state, repeatedly.
My main question though, is why url params are bad? Is it simply because of your workflows that will run on page-load, or does it have more to do with workflows that bubble itself decides to run on page-load.
But isn’t this still using “go to page” workflows which bubble strictly advises againsts? I presently use Option-Sets combined with URL paramaters for navigation. To do pretty much anything else in my app, we use conditional parameters. It’s not exactly pretty, but it’s a native app so…sue me ig.
In your workflow explanation, It looks like you’re still altering the URL rather than primarily using states for navigation, insofar as, “set state of Index, state = dashboard”, and then you show // hide groups conditional to that.
I see now, sorry didn’t realize you were trying to do it completely with states.
Tbh I’m probably going to keep using the go to page, unless it’s a night and day difference or bubble simply won’t allow it.
URL based audience segmentation for paid marketing is far too convenient, performs well, works for all devices/browsers/app types, and typically how we scale newer SAAS companies.
For post revenue cash flowing projects the time to split it makes sense I guess if it’ll preform better. I’ll have to play with it on launch to really make a decision but that’s my initial thoughts on it 
completely agree. I really really really don’t want to switch to states. It’s worse in almost every single way except for “page loaded” workflows.
It would be nice if bubble could actually address the page loaded stuff. Most if not all native apps are built with URL params these days,
I agree that if you’re post rev, it could be worth looking into, however, still, for scaling, it’s just not a good idea to only use a single URL.
As pointed out in your other thread, that’s a question for Zeroqode as it is their documentation that is being referenced.
To your point, @drixxon, a lot of mobile-first/mobile-friendly apps are built using URL parameters, and if that’s an issue, it’s news to me after all these years on the platform.
I really like the URL path strategy you outlined here and I am really glad I came across it before getting too far down the custom states path.
I do have one question however, and I apologize if it is a product of my bubble naiveté. Is there a reason why you are using data types instead of option sets to store the navigation paths? I know that option sets can be annoying since you need to redeploy to update any changes but, assuming that I don’t need to make frequent changes to my user navigation, wouldn’t option sets be preferred to minimize the need to communicate with the database on every navigation change?
Anyways, thanks so much for sharing this URL path strategy, it has already saved me from significant future headaches and wasted time.
The database allows for the slug feature for dynamic URLs so they can be deep linked/shared, foward/back working, and URL bar displays as expected. Option sets wouldn’t allow this.
Since the page never actually changes (even though your using go to page, since it’s the same page) you only call the database once for nav items, everything is loaded on the initial.
