This was posted last year, but the topic is closed.
Being able to access the page states of pages in webviews (from the rest of the mobile view) is absolutely critical functionality in order for webviews to be usable.
We already have a wrapped app and the fastest path to using the new native mobile functionality it to break our existing mobile pages down and rebuild one part at a time, while leaving the more complex parts (with functionality that can’t yet be rebuilt in native mobile) inside webviews.
This only works if you can access the page states from inside the webview on the outside.
Currently at a standstill with utilizing/testing native mobile without this ability.
@nick.carroll We’d absolutely love to become a major tester/user here at ProLine. We have a massive robust app with BDK we’d like to start porting over. But it’s just not feasible to even approach it if we can’t break it down into parts and rebuild one part at a time (which requires this ability).
Our app has been built up over the last 4 years and native mobile can’t even support all its current functionality (due to lack of plugins). We need to be off BDK yesterday due to all the bugs cropping up with it (and no support), but we need to be able to pass information between the webview page and the view in order to even start the process of switching over.
Will look and see what all would be required to support reading page states. There are a lottt of edge cases when trying to communicate between the web page and the app which is why we started with no communication (except through the database or BE workflow)
Ideally it would work the same way as reusable groups, but it can be more limited. Information just needs to be passed between.
It is very circuitous (and un-performative if user has less than full service) to force data back to the server and then back to the same view the webview it is already in.
I know there’s complexity with going from JS to React, but every major wrapper has been able to do this one way or another.
Long term would we like rebuilt 100% in just Bubble Native? Yes! but it’s just not realistic in the short term until you guys get the native mobile functionality to equal robustness as regular bubble and add plugin support. And even then it would take so much work for an app of our complexity.
We’d love to relaunch with Bubble native in the next 60 days with most aspects of our mobile app still in webview, then rebuild each part carefully in native over the next 12 months or so.
There are tons of use cases for using webviews outside of just for repeating data. Including just not being able to take the time to rebuild what we already have built as a webapp (our situation). This request isn’t related to repeating groups.
Yeah, I agree. We need this to extend and smooth out the transition between existing apps and new ones built directly in mobile. I’ve heard a few others in my circles talking about this, too.
@nick.carroll … second what @aj11 noted, being able to quickly transition to native and supporting webview states as the stepping stone would be greatly appreciated. Thanks!
We are in a position where we have to rebuild our app within the next 30 days. We have everything lined up to do this on Draftbit with webviews and JS calls for the “states”, but we’d still like to avoid this if possible and work with Bubble.
I know you said this is in the current sprint, but will this be launched within the next 30 days? We need to know so we can go ahead and move forward with draftbit in the meantime if not, and revisit Bubble Mobile at a later date.
haha