About two years ago, at XDC 2015 in Austin, Philippe Casgrain from LightSpeed did a bonus presentation on the benefits of Continuous Integration when building projects with Xojo. Coincidentally, we at Xojo had decided just days before that we needed to move away from manual builds and automate as much of our build process as possible to keep up with the increasing complexity and number of our frameworks (later that summer we would be going from 3 to 8). After the presentation, we heard from several developers asking when the limitations of automated builds would be addressed and because we were working on our own process, it gave us an excellent place to try out new things while ironing out the wrinkles.
Challenges
The foremost issue that we had to fix was that the original protocol was designed so that it required you to close the IPCSocket to get your command to run. That meant there was no longer a connection on which the IDE could send any kind of response. It also meant that dealing with issues required making multiple connections.
The second was that there were many things that raised dialogs when something went wrong, which meant that an unattended IDE could get “stuck” waiting for user input which would never come. We’d heard that developers would have their systems take a screenshot if an hour had passed with no activity so they could figure out what had gone wrong, but that can be a huge waste of time if you’re waiting on a build.
Solutions
The new protocol (which was beta in 2016r4 and officially released in 2017r1) addresses both of these problems. The new protocol uses JSON for the command format and the IDE can send back all kinds of information including (but not limited to):
* Script syntax errors
* Script runtime errors
* IDE version conflicts
* Missing assets
* Compile errors
All of these things are returned to your calling script so you can take appropriate action. Because this is truly a two-way protocol now, you can also send data back to your script, like if you wanted to return the path of the built app back to your build system.
We’ve also been working to make anything that would normally show a dialog to the user gets sent back to the app communicating with the Xojo IDE. As far was we know, all but one was caught, and a fix for it has been submitted for 2017r2.
If you’d like to see the new IDECommunicator protocol in action, look in the Examples folder next to the IDE: Examples > Advanced > IDE Scripting > IDECommunicator > v2 > IDECommunicator-Tester.xojo_binary_project
For documentation and more information refer to the doc page here: IDE Communicator
Just a note for those of you who have already been using the IDECommunicator project (or something similar) for controlling your builds, when updating to the new protocol make sure you don’t include a QuitIDE command in the script you initially send to the IDE. Doing so will cause the IDE to quit before you get a response which would present as a false positive. I suggest waiting until you do get a response and then issue a separate QuitIDE command at the end.