This post originated from an RSS feed registered with Java Buzz
by Fred Grott.
Original Post: Why AndCooper Build System for Android Java Applications
Feed Title: ShareMe Technologies LLC-The Mobile Future
Feed URL: http://www.jroller.com/shareme/feed/entries/rss
Feed Description: A Weblog about Java programming and digital convergence on mobile devices in such areas as P2P and collaborative technology.
With increasing daily interest from RIM, SonyEricsson, Nokia, and Motorola I probably should layout my thesis for the need for the AndCooper Android Java Applications Build System. At some point the complexitiy of Java SE on mobile and the need for more feedback loops among team members presents the need for a more powerfull build system.
The challenge is finding a way to limit the build script changes in such a way that you have a powerfull workflow system in which you can change the workflow by project without breaking the complex build system scripts. In this way AndCooper becomes your build system engineer without the expense of actually having such a person on the development team.
How do we do this? No matter what point you are in Android Java Application development you are still producing an artifact. If it is a qa test report, the compile task and or debug tasks are still executed. Thus, our workflow system could be based upon those artifacts. For example, I could use the antlion project's artifact definition to define the build system entry-point-tasks into something like apk-production, apk-debug-emulator, apk-debug-adp-device, jar-build-lib and etc.
Than it becomes somewhat easier to change workflow as you only have to change the artifact file. Of course there are some other little tricks.
For example, you can map a copy of the logcat output to the traces.txt file. Why do that? Remember, the profiling commands only trigger a buffer output of 64k at a time. Thus, if we take advantage of knowing that the traces.txt file is rotated and go in and change some files to allow the stdio output mapping to automatically happen and for the traces.txt file to be roated at a higher number than 4 than we can match up the graphical display of that traces.txt information with our log statement information which eliminates the need for a Fiel Appender on the log framework side.
Thus, we not only have an apk artifact in the workflow to process, we also have that traces.txt set of files as artifacts to process. And its sub-artifact in that the entry-point-artifact as far as the beginning AndCooper build task would be apk-debug-emulator or apk-debug-adp task.
Some other tricks are to have the individual reports qa tasks run only if something is there and use something like the qalab framework as the hub to amass the reports together into one comprehensive report-hub package of information.
Previous Topic
