With Google IO 2009 and the introduction of HTML5 and the focus on web programming on andorid everyone was of the opinion that Android Java was on the way out as an application programming language. Now, what if I were to tell ou that there are some Agile methods ot make Android Java as fast in development as web code?
In other words Android Application development using Java is not dead yet. But how? You use a light dependency stack such as Guice and an ORM library and Metawidget UI library. We can get the same development speed as with web code development. Oh oh Google what you unleased, a platform where web code nd java coode are equals on a mobile platform? Nice!
Yes, there somewhat is an ebook coming, hopefully. This is something OEMs like Motorola do ntot know about because I have kept quite about it going thorugh componnents that did not work until I found the right DI, ORM, and UI framework combinations.
Weird title, huh? Okay, let me shed some light. I have worked in the Enterprise and Mobile areas in startups. Although, searching for better code methods does not solve the management problems you still search for them because its what you can control to solve the problems. In Enterprise we have Injection and IoC, Object Relational Mapping(ORM), Object Serialization via XML, and etc.
Now, picutre this. You start with a non AOP injection/inversion container framework such as Guicev2. Remmber, the main benefit of using IoC frameworks is no longer any factory code. It is not that the factory model is wrong in separating the client class from the implementation class its that we have a hidden dependencies that miss testing. Now, that works on small J2MEMIDP 1.0 application, might even work on a small J2ME MIDP 2.0 application But, that will not work on the large Andorid applicatiosn we wnt to have maintainable and manageable within the code development process.
Thus, that fixes the factory model problems. we have similar prolem on the SQL-ORM side in tha tif you use an adequate ORM say AndroSQL, than you have java object classes that match how you use that SQL data in an object oriented way thus reducing the code requried to implement the data relationships and stil avoid the factory model call class problem of having depnencies hidden and thus hidden from testing and etc.
Than of course we come to the UI code. If we use a UI widget framework that autot-inspects back-end code at runtime to do some of the setup than we redcue UI code. Metawidget framework popuplates the UI at runtime and has some Andorid UI widgets.
We do not have suffer through brittle J2me?java code any longer. You see the same move away form the Vendor-Old blood approach into such thngs as Spring, Hibernate, Wicket, and etc. The Android OEMs that understand how much development time can be saved and etc in adopting IoC, ORM, and UI widgets in Androdi Application development wil disrupt th eothers both in the time they can push out handsets and push out new innovative Android Applications that integrate with Mobile Operator Services.
Those OEMs that decide to do just J2me the Andoroid way will be left behind. This is the other motivation behind the AndCooper Android Application Build Tool as to teach thse new techniques we haev to see how brittle it is done the old way and than the new way through code anaylsis, testing, and than a set of wiki notes per projectto follow along with and take notes with.
So how do we detect the Android SDK version so that the AndCoooper build tool can be used if the SDK is updated? Goolge/OHA through the SDK provide us with a ANT target property located in default.properties that is generated by the SDK. Normally, ANT does not support conidiotnal logic to hook into this but if you use a differnet optional task library such as ANTXtras you can integrate with this target property to determine not only the SDK version by adjust the classpaths for the tools and apis such as:
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png)
MobileBytes 