I got JDevelper running a local Web Service this weekend. The program was a simple one from the Book Java Web Services. It basically gives you the time in both string and Epoch format. The excercise was useful so that we can use JDeveloper to test our framework. One of the very helpful tools with JDeveloper will be http protocol stream analyzer. This analyzer shows both the http and SOAP protocol streams. As we develop our framework, we can run it in JDevelop and verify it works before porting to an Android platform. The analyzer will be highly useful in debugging WS message exchanges.
I have written a WS client to talk to the Amazon site using JDeveloper. I got an id and security key. I spent all day Sunday tring to get it to work. Apparently Amazon has updated there security and now requires that you use both an access id and the security key. In the past you only needed an access id. The problem is that most of the code on web does not work. I have made all of the changes and I think it is now correct. My last stumbling block is the requirement for a new module called "org.apache.commons.codec.binary.Base64". I found the module on the apache server and downloaded it. I did not know how to build it into JDeveloper but I got on "OverflowStack" blogsite and asked how to install. A helpful programmer gave me the necessary instructions. I will try again on Tuesday 2/16.
Overall my impressions of Android are good. There is a ton of help out on the web. The tools are somewhat buggy. I was never able to get motodev to work. I was also unable to unistall it as well! I switched to eclipse. After downloading a couple of times I finally got it to work. The problem with eclipse is that they did not use Microsoft's InstallShield. InstallShield binds a release into a single package and the program will not install the application unless it has all the necessary files and resources. There is no install with eclipse. You just download 160MB of data and run eclipse.exe.
The architecture of Android is different. Most of the architectural decisions were based on the assumption of limited handset resources -- processor speed, memory availibility and network performance. Once you get used to the architecure its ok. I think the architecture will change dramatically over the next couple of years. Handsets are getting very very powerful and most of the limitations that exist now will no longer be an issue in two or three years. The OS will most likely evolve to a more unix like structure. Just my opinion.