Yea I used the beta.zappar.app link and the code @connell has in a button.
I just changed the address to Zappar.com
(Z.device as any).launchWebFrame(“https://www.zappar.com/”, res => {
console.log(“The user has closed the frame”);
});
What I would love to do is play YouTube videos thru this!!!
Steve
You can play YouTube videos through it - just make sure you use the “embed” URL, not the standard one, or it’ll get blocked; YouTube doesn’t like being framed otherwise. Stick this in the launchWebFrame line, for example, and it oughta work:
https://www.youtube.com/embed/rWuKmWKicro
Check it out: scan this…
…and do what the bunny tells you.
Love the bunny!!!
Steve
Ps. got my code to work!!
This would make everyone happy, I reckon. Current behaviour carries on as normal (URLs open on new tabs after a modal confirmation dialog), but for situations where we want to re-use the current tab, we bypass the confirmation. One tap and our customers are taken straight where they want to go.
I get my reduced friction, and @marks’ clients can have their fresh tabs.
Rather than asking for an ETA—it may take time for you to assess the effort on implementing/testing this—could you give us an ETA on the ETA? That modal confirmation is a real pain point for us; every single point of friction costs us sales, so it could be worth us waiting for it to be implemented before we roll out our AR thing.
Better than an ETA @howiemnet I can say it’s now implemented 
We’ve made it available at https://beta.zappar.app from now, and from the lite branded site from next week (we have a policy of not deploying the production versions this late in the week 
). For custom WebAR sites, let the support team know and we can deploy there.
To use the feature, pass "navigate" as the second parameter to launchUrl, like this:
(Z.device as any).launchUrl("https://...", "navigate");
The as any cast is required until we update Studio to know about the new parameter.
Let us know how you get on with it!
@stevesanerd regarding the web frame option, some sites explicitly disable working in iframes (the browser technology we use in launchWebFrame) for security reasons. We do this with www.zappar.com which is why it doesn’t work in your example. If you find a website that you’d like to show in a frame, but which doesn’t work, you will have to ask the website owner to add the URL of the AR site your using to their X-Frame-Options header.
This works so well!!!
If you use navigate with a YouTube link (for me on a Samson s20) it will open it in the YouTube app!!!
Steve
Been testing it this morning. This is ace.
It introduces some interesting new behaviours that are worth being aware of if you use this new feature:
When a user taps your button to go to the target website (or however they do it), there’s a delay of a second or two while the browser sends the request and waits for the target website to respond. This delay is normal on the web; we’re used to those little delays - but if you have audio and/or animations going on in your AR experience, they will carry on playing while the target page loads. This delay makes it seem like the user’s tap was ignored.
I’d say it’s essential that you give the user some feedback to let them know something’s happening: changing text or colour of the button, stopping the audio etc. Exactly what feedback you provide will depend on the context, on your particular AR experience, but you probably do need to let the user know their interaction has been received.
This wasn’t an issue before, as that modal “Launch External Site” dialog was instant and provided the necessary feedback to the user.
After a user has tapped on a button in AR and been taken to the destination URL, they now have a brand new possibility: hitting the Back button in the browser to return to the AR experience in the same tab.
Before, when URLs were launched in a new tab, they had the option to close the new tab and return to the tab with the AR experience on it - which is subtly different: they’d be returned to that “Launch External Website” modal, with the AR paused and blurred in the background. Hitting the ‘X’ would unpause the AR and it’d carry on going as usual.
With the new launchUrl "navigate" parm, they can hit “Back” instead, and the behaviours on iOS and Android are different:
iOS: The AR experience carries on playing any animations and sound; interactive elements still work, but tracking is frozen. Whatever frame the camera feed was showing when they left AR will stay frozen in view, with any tracked AR elements locked to it. iOS/Safari seems to be trying to return you to exactly where you were—in whatever state the AR experience was in—but it’s now lost permission to use the camera/gyro, hence the frozen feed. Refreshing the page resets things, as you’d expect.
Android: The AR experience resets back to the “Launch >” splash screen.
If a reasonable quantity of time has passed before the user hits “Back”, or if they navigate through several more pages and then return all the way back to the AR, I suspect iOS will have dumped the tab’s state and will have to reload it, behaving more like Android.
Arguably the Android experience is slightly better, but neither experience is a show-stopper.
I’m going to look into whether it’s possible to execute code after a return from the launchUrl - I’m guessing that you could, say, follow the launchUrl call with some code to either reset the experience, or pop up a “Reload the page!” message. Need to see what happens; need to see when it executes, and how the behaviour differs with and without this new parm.
More news as and when. It’s fun out here on the bleeding edge, innit : )
I’m going to look into whether it’s possible to execute code after a return from the launchUrl
The answer is no, at the moment.
launchUrl(...) calls are non-blocking, so if you put any code after it, it’ll be executed even while the “Launch External Site…?” dialog is waiting for user input.
I’ve submitted an RFE for a callback to let us know when the dialog is dismissed (whether because the user said “OK” or cancelled the dialog); this’ll allow us to handle things more gracefully, pausing/unpausing animations and/or audio.
This won’t necessarily tidy up the new “reuse current tab” feature, if someone navigates to an external website, followed by navigating “back”; hopefully Zap will be able to find a way to recognise it and handle it.
It could be that on a launchUrl(url, "navigate") call, Zap need to set a state to say “this experience needs resetting”, then call the new URL. Then when the user hits “back”, they’ll land on a fully-reset experience.
Ain’t it mad how something as simple as “a link to another site” can end up being surprisingly complex to implement gracefully…
