Can you please explain what each of the Host and Protocol options does? In terms of functionality, performance, recommendations etc.
I only know Host > localhost is for Simulator and should not be used if using physical device.
Hi!
Good question.
Here is an overview:
Tunnel - If you are using the tunnel host, all the traffic between your computer and the phone you are testing on will be sent through a server in the cloud. This means that your phone and your computer can be on different networks and they can still connect to each other. Though certain heavy duty corporate firewall configurations or similar can prevent the tunnel from working.
This is the default option because it works in the most cases.
The downside of the tunnel option is that it can take a long time for data to go all the way to the cloud and then to your phone (or vice versa).
The tunnel is implemented using a service called ngrok right now, though we may swap that out in the future for something else.
LAN - LAN will use your LAN to communicate between your computer (where your code is) and your phone. This should work in most cases when your phone and computer are connected to the same wifi (or hardwired somehow into the same ethernet LAN).
This is really nice because its meaningfully faster than tunnel option and in some ways simpler.
The downside is that you have to have your phone and computer on the same wifi network which is sometimes tricky. And sometimes (in more situations than tunnel), it won’t work because of network configuration even if you have your phone and computer on the same network.
localhost - localhost will only work if you are using the iOS simulator so the (virtual) device and your computer are literally on the same machine, so localhost will work. It’s fast and reliable but only works in that one scenario (I’m not even sure if it works in Genymotion). It is automatically engaged if you choose open in simulator, so you should rarely if ever need to manually choose this option.
In general, try to use the LAN option, and if it doesn’t work, fall back to the tunnel option. We’re working on making the software smart so that it will choose the best connection it can make but that’s not done yet.
The protocol options you probably don’t need to mess with at all unless you are sending links around by e-mail or text message.
exp:// links use a custom protocol that the Expo iOS and Android client apps are configured to handle. This works reliably well when opening on phones except that in some contexts, exp:// links won’t be understood as links and won’t get highlighted/linkifed.
Recently, Apple and Google have embraced using http(s):// links for more things and have added ways for apps to register to handle specific URLs, and have pushed developres to use those. In addition to almost always being properly linkified in any context, the other nice properties of this are that: if you don’t have the app on your phone, the link will naturally fall back to opening a sensible page in the browser – and this naturally creates a canonical URL that spans native apps and the web.
One case where https:// links don’t work that well is when you are serving code from your computer, since the way that apps register to handle by URLs is basically by domain – with something sort of like a regex. So when you are using crna/xde/exp, we don’t want to have to send the code through Expo’s servers necessarily, and so the software typically uses the exp:// protocol then.
The http redirect is just a hacky way to get exp:// links properly linkified. It sends an http link that will redirect immediately to an exp link.
You generally don’t need to mess with this setting but that’s the background and history.
1 Like
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.