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.