B4A architecture has gone a major refactoring in the purpose of better separating the UI layer and the compiler layer.
With this change it is now possible to add a command line builder. I guess that most developers will not use this feature however for developers dealing with large projects with multiple "targets" it can save a lot of time as it will allow automating the build process.
I foresee this leading to a cross-platform IDE GUI as the command line builder could be ported to Mono. (CLI apps are always easier to port to Mono than GUI apps, due to less GUI baggage.)
In order to do a full separation of the CLI compiler and the GUI IDE, I would suggest the following:
Move the license checking code from the GUI IDE to the CLI complier. Have it check for a license in the same directory as the compiler each time it's run. If a license doesn't exist, then ask the user to either purchase a license or move their license into the directory of the CLI complier.
Change from .bal/.bil files to XML. (XML is more "open". Plus, XML is super-easy to create. Would also allow members to share UIs.".)
To make a B4i version work, I'd suggest the following:
[-local-builder "<ip.txt>"] argument. (Local Builder's IP Address would need to be in a text file called "ip.txt".)
[-remote-builder "<login.txt>"] argument. (Login details would need to be stored in a text file called "login.txt", or maybe even included in the license file.)
The future of Anywhere Software is going to be amazing!
I wonder how fast we will get a rip off that will contain the compiler files as embedded resource.
Another IDE is nice, I just wonder how you will work with none core libraries and their methods that you can't see.
Will you jump back and forth to see what options you have or can that be extracted from the xml?
This looks like a good move especially for 3rd party IDEs, thus giving more flexibility to the development process.
Does the new compiler support legacy and rapid build too?