Handling application lifecycle during edit
Currently AB relies on application recycling to pick-up changes to application artifacts. That might not yield the right behavior immediately, which can create confusion. Specifically, if users make changes in less time than the idle timeout, then the application doesn't recycle and the application is "out of date" with the source until the next recycle.
Let's use this page to outline the correct behavior. The work is covered by
bug 7301.
Desired user experience
- The "start" button means: Make the application run until the "stop" button is clicked. Note that there may be times when the running app fails due to invalid config or ivy.xml, so AB must manage restarts as needed.
- Changes to config take effect immediately.
- Changes to ivy.xml take effect immediately.
Details
For the sake of this discussion, we'll say the application is "enabled" if the user has clicked the "start" button. Otherwise the application is "disabled."
| User action | AB reaction |
|---|
| Change ivy.xml | Stop app. Resolve then compile. Start app, if enabled. |
| Change dependencies with dependencies service | Stop app. Resolve then compile. Start app, if enabled. |
| Change any .config file in the config/ directory | Stop app. Start app, if enabled. |
| Change any file in the java/ directory | Compile. Recycle. |
Where required to stop, "zero stop" must be run before saving the file. The other reactions can be carried out asynchronously (like the current auto-build).
What the user sees regarding application status:
| Status | Start or Stop button | Text status |
|---|
application is enabled
last reaction succeeded | Stop button | Link to the app homepage |
application is enabled
last reaction failed | Stop button | "Not available" link for details |
application is disabled
last reaction succeeded | Start button | URI to the app homepage |
application is disabled
last reaction failed | Disabled Start button | "Not runnable" link for details |
Optimizations
We need to minimize the auto-initiated CLI invocations because (1) they are expensive and (2) there could be many due to auto-save.
- Only run "zero stop" if the application is running. Need an efficient means of determining if the application is running.
- For changes in ivy.xml:
- Only run compile if resolve succeeded.
- Only run "zero start" on an enabled application if auto-build (resolve + compile) was successful.
- For changes in java/:
- Only run "zero recycle" if the VM is running. Need an efficient means of determining if the VM is running (possible today?). Another option would be to set an aggressive idle timeout (5 seconds?) instead of running "zero recycle", but that impacts the entire development experience.
