Android Tools 8.0.1, Eclipse and ANT 1.8.1

First, if you are running android tools 8.0.1 from eclipse than everything works fine. Second, to run build using android tools 8.0.1 or higher outside of eclipse you must use ant 1.8.1 or higher. Most Linux version in theri beta/test repos already have compiled ant 1.8.1 binaries to install to run ant 1.8.1 form the command line.

My AndCooperANT set of build is being kept pre-ADT8, the new ADT8 or higher project is named IndianaANT and will be up in days.

Now for some other good news, it appears that ADT 9.0 may be pushed out December 20th as it fixes some minor bug issues. One of the changes is an ant version check in the custom task.

As far as eclipse, it will not have ant version 1.8.1 until very late in the 3.7 testing cycle and I doubt if eclipse 3.6.2 will include ant 1.8.1. Thus, since ADT 8.0.1 runs fine in eclipse without ant being upgraded in eclipse the best option is update your ant install if you run builds outside of your IDE. If you have not switched your build run outside of IDE to ant 1.8.1 you will notice the side effect of 3rd party libs not being included in the dex and that is due to some behavior changes between ant 1.7.1 and ant 1.8.1.

Advertisement

The Philosophy of AndCooperANT

If you visit most android developer forums you find android developers from all areas of development. Some are web developers, some are MS.NET developers, some are java developers, some are JavaEE developers, some are CS students, etc.

Among those many groups there is not a common thread of using a continuous integration build server.  With one exception, if you count the IDE as incremental compiler as the continuous integration server. and why not its small enough to run on a laptop with the android emulator and still have room to run a dev environment dash-board using jetty.

Thus, my philosophy is integrate pmd, checkstyle, classycle, jdepend, javaNCSS, doxygen for native c, jGrouseDoc for javadocs of javascript in assets, and cppcheck reports into one small build system package that is easy to set-up and use along with your favorite IDE for android development.

With some ease of usability in that you should only have four or less files to change per project amounting to less than 6 properties to change per project. Maybe even go further over this next week-end and code a groovy installer that auto-installs everything in a new project with no-mess no-fuss.

Not set as default incremental builder as we want developers to feel that they can run that one target to compile and doc the whole project whenever they want or they can set the whole thing up in their IDE as an incremental builder.

Not all polished all at once but I will get rest of the tools integrated this week and a full common look/feel to the reports that are generated so I can use it my own projects and see where rest of the improvements need to be made.  I did find how to do customizable headers and footers using CSS without having to change or insert new html  elements in the html generated in each report.

If you have not downloaded the corrected add-proguard-release.xml that was corrected from the android dev blog Sept 21st post than visit my github account link at the bottom of this blog and click on AndCooperANT and download that file at the project root folder. Of course no one paid attention to my bug submission yet, maybe I needed to have a bug title that stated Sept21st Dev post wrong?

But, oh well..towards weekend two more alpha and usable releases of AndCooperAnt with me starting to upload zipped copies to github for you to download.

Android TestProject in parent project folder

Okay, time for some more eclipse tricks. Create new project, do not click finish yet!  Uncheck the default location and browser and select the parent project folder and in the address bar of project location type /test and you will see:

Correction: Name Project ParentProjectNameTest, ADT plugin will show an extra project at workspace root(you can ignore that as its not an actual project ..ie its not in file explorer on your SystemOS etc.)

If you use build scripts than the tested.project.dir property will change with the test build script in the test directory as it will be a relative location to the parent project. If you use a different IDE, I am assuming you can do the same trick with the IDE Android plugin you have.

Well, if you are using a DVCS like Git you are already using the do not default location to get all your DVCS stuff in one sub-folder for all projects anyway and thus its just an extension of that technique.

Android Code Samples Complaint

Like I never complain, right? While I appreciate the hard work every Android OS contributor has put in thus far some of the android code samples leave a lot to be desired. Code style mess-ups like if statements without brackets, parameters not finalized, etc. Still using the old test sub-folder in project instead of separate test project way of testing.

I can understand if we are not using modern IDEs.  But are we not using Eclipse, IDEA, NetBeans, etc? Well did we not have time considering that these code samples are supposed to show correct coding techniques?

Guess how long it took to clean up the LunarLander code project using properly set tools to get it to actually run on a device and emulator? Now, I have not completed the text code project yet but it was only one hour.

Yes, I am putting some  at github in the month of July. We have to have more professional code samples. The code samples in the SDK are just as important as the outstanding behind the scenes UI work that is occurring for Android 3.0 release in October.

An Apology to MotoDEV Studio Team

Image via Wikipedia

My intention was to see if I would be able to use the MotoDev Studio for Android  in producing Android Applications for several book proposals that I am submitting to Apress. But due to everal short-sighted decisions that are evidently part of the core MotoDev Studio philosophy I cannot accomplish that feat. Let me explain.

Part of the Android OS Mobile Platform design philosophy has been  applications without limits. Imagine you as the Star Trek Captain character named James(Jim) T Kirk. You do not want to be told by your engineer that you cannot have full power. By limiting the whole MototDev Studio series both in JavaMe and Android to not including CVS and SVN, Mylyn, TPTP and WTP for such things as the Eclipse Memory Analyser Tool to analyse Android heap dumps..Motorola has effectively told mobile developers that  you do not want full power.

That is not to say that the other additions ot MototDev Studio in term sof emulator/device control, code templates, SQLite view(in Android’s case)..are not important additions to making it easier fro first time developers. However, it is too much of a sacrifice to ask that first-time mobile developer that  they give up their right to be able to go to full developmental power for those features. Yeah, it is probably why both my interviews at Motorola both ‘sucked’. I cannot help it, I have a full blown user(in this case user is the mobile developer both beginner and advanced) full power ethics bent and it is somewhat impossible to turn it off.

I am sorry that all that hard work by the MotoDev Studio team cannot be appreciated by those who want both the beginner and advanced mobile developer to have full power at their finger tips in their mobile IDE. Due to the limitations to MotoDev Studio for Android I will not be using it in the development of the Android Programming WebView Web code using Goolge Web Toolkit book. I certainly hope that a ‘re-tooling’ of MototDev Studio addressing  these issues occurs as it would be a huge win for both the beginning developer and the advance developer.

AndCooper 0.1 Alpha Release, Tonight

The Andr0id Java Application Build tool called AndCooper is being released tonight as 0.1 Alpha. Included with this release is a modifid PMD.jar with a very alpha PMD ruleset for Andorid that goes beyond the PMD Android ruleset. No matter what Continuous Integration server you may be running its just simple drop the stuff in and run although you may not get CI-integrated dashboard view yet.

No matter what IDE you might be using you can point or setup a JavaBuilder to point to this set of build scripts and it will auto-generate the code analysis reports every time the project workspace is built by the JavaBuilder of your IDE. Templates for items such as Java.Header, package-summary.html, package-info.java, and etc can be found at root for easy access for new users. Also, included tiddlywiki templates for taking notes and GTD note taking. Also, I have kept the tool IDE agnostic in nature.

Report-wise you can set reports to have your company logo and UML diagrams are included with javadocs. Jdepend reprots also have diagrams in png form when you define the Graphviz Home path.

At this time the build scripts recognize SDKs up to the Android SDK version 3.0 with slight support for OEM add-on APIs so that those jars get added properly to classpaths and etc.

At this time I would like to thank everyone who commented thus far as I did use those comments to refactor the build tool to come up with the 0.1 alpha version.  Hopefully, as we go forward into releases such as 0.2 and 0.3 that will encourage more comments that can be used to refacor AndCooper into better implementations and hopefully at some point maybe even comments from OHA members at some point.

AndCooper JavaDoc Generation

Okay now take a look at this apiviz javadoc generation of an Android class:

Notice anything wrong? look again, there is something wrong in that the proper package name is not shown fo rthe parent Activity class. The Android classes are need for two features in our android development process. One, for IDE code completion. Two, for correct javadoc generation.

Either APIVIZ will allow me to specify the android classes in a path or I will have to switch to UMLGraph. But with UMLGraph I loose the optional being able to do info.java classes to denote both comments and annotations. But either way we wil have automatic UML generation within javadocs.