Use case scenario
This would happen if you do a new build after adding a module, made a change to a
strings.xml file or something else caused the app to be outdated, needing a fresh build.
Steps to reproduce
1. Use a fairly big Alloy app, e.g.:
git clone https://github.com/aaronksaunders/alloy_fugitive.git
2. Build it (in Simulator) with LiveView:
ti build -p ios --liveview
3. Open a new terminal window
4. Build it with or without LiveView:
ti build -p ios --liveview
5. Notice the existing app in Simulator reloading constantly.
6. Notice the console showing the Alloy compile of our second build triggering a lot of reloads (see attachment).
Workaround
Killing the active session in our first terminal window doesn't help. This doesn't kill the actual LiveView server. Killing the iOS Simulator or the app running in it does work, but it would be good to not require this extra step and prevent users to see all the flickering and console horror going on.
I'm unclear how this is a valid bug. The first build sets watchers on all the files, while in a second terminal you're building the project again which means many files will be changing. Each change would signal the LiveView server to reload the app. This seems to be an invalid use-case. The proper method when a full app rebuild is needed is to stop the app in the first terminal, thereby stopping the LiveView server. Then, rebuild the app, which would restart the LiveView server and re-set the watchers.
[~skypanther] I understand *why* it happens, but in daily use it's something I run into too often, e.g. when I have an app with LiveView running in iOS Simulator and then I want to do a build to Genymotion or to an iOS device. This almost always crashes the app running in iOS Simulator because it can't handle all the files being changed. I agree it's not a bug, but there's room for improvement in the dev flow.