Affecting factors:
- requested platforms
- platforms added to the project
- installed SDKs
- if platform is available on system at all (e.g. iOS is not available on linux)
- if it is build or run (should the errors be ignored or not?)
Reality is actually a little more complicated than this:
* We use your automatically detected local IP if you are running on device.
* We use 'localhost' if you are running on a simulator.
But it's hard to fit that in help text, and this is at least closer to
reality than it was before.
For some reason, super-jobs of the actual upload job have a `.current` progress but no `.end` value, and then they are chosen for progress display instead of the actual upload. With this change, we don’t eagerly choose a job for display if it has a `.current` unless it also has a `.end`.
It’s probably also worth examining what is going on with the various values of `.current` of the super-jobs.
If we use `__meteor_runtime_config__.ROOT_URL` directly, as we were
previously, then we end up sending Cordova clients to http:// URLs even
if force-ssl is being used in the app. This is fairly bad on its own
(always sending cordova clients to http:// URLs instead of https://),
but made even worse by the fact that we don't set CORS headers on
force-ssl redirects (that is, the app breaks completely if the client
makes a DDP connection to an http:// URL for a force-ssl app).
Previously, all progress display was turned off after the app’s initial start, so no progress would be displayed on restart due to server code change.
Now, we enable/disable progress display from inside the loop that re-runs the app on change.
Remove the “suppressDisplay” approach to hiding the spinner when there’s an error building the app, because it didn’t work on rebuilds, only the first build. Better to just call enableProgressDisplay(false) and hope for the best like we do elsewhere.
Conflicts:
tools/progress.js
Previously, if there were two parallel jobs like “Starting your app” and “Bundling app,” we’d display just a spinner and no message. Now, we choose a message and display it.
(…due to a server-side code change)
Restarting the server can take a while (30 seconds for one particular app), so it’s nice to at least print when we start doing it. Soon there will be progress displays during it, too (when we add more of them to `meteor run`).
We lose the opportunity to coalesce server restarted messages, as in `Meteor server restarted (x2)`, but adding any sort of progress display also does that.
We intentionally consider a machine without HAXM to be "acceptable"
since HAXM can't be installed on VMs. But we should still let the users
know how to install if if that's what they're missing.
We don't have a way to HCP a changed set of plugins or platforms, so
just exit and ask the user to re-run. There are probably some cases
where we don't have to exit (e.g. if you add the android platform, we
probably don't need to exit out of 'meteor run ios'), but we exit in all
cases for simplicity.
