Monday, November 12, 2007

Who "learns" APIs anyway?

This is a sort of after thought and comment on my previous post where I "complained" about learning a new API.

Most of my experience with Java has been not in developing application but rather designing APIs and programming platform (for instance MeTA Studio http://code.google.com/p/metastudio/). Where as, whenever I had used other languages (C, C++, Fortran, Python...) it was mostly for application development. Developing good and usable APIs do require fair amount of thinking and design tactics to be put in. Developing pure application on the other hand is, many a times more faster and easier job. A good API need not be "learned", rather it is apparent form it as to what you can do with it. You do not "learn" a good API, rather you cleverly "use" them to build applications.

In that sense probably Android APIs are "pretty good".

Android is out: But am a bit disappointed.

This is a follow up on my earlier article "speculating on Android". Google has finally released the SDK for Android platform and with a first look at the APIs I am not too happy. Not because my main assumption of inclusion of a scripting interface went entirely for a toss, but because Android has a whole new set of Java libraries (APIs) rather than adopting a standard set of Java APIs. Another claim was that development on Android platform would be easy and fast. But with my experience of using Java from mobile to desktop to server has it that a very strong design and object orientation skills have to go in to develop flexible and robust applications. When you have a "good enough" and many times an evolving design it is not really RAD. RAD is what is been offered by initiatives like, pys60 (python on Nokia S60 phones).

After a bit of pondering over the APIs it does some how feel that many of those are needed but are in no way available in Standard Java libraries. One of such aspects is the touch APIs (http://code.google.com/android/samples/ApiDemos/src/com/google/android/samples/graphics/TouchPaint.html).

But here again I fail to understand as to why the standard Java graphics libraries are not used and instead Android's own libraries are used. This to me feels like introducing more confusion than "helping " the people who develop on Java platform. In essence, I simply do not understand the necessity of learning completely new set of APIs for programming on Android and that too in a "write once and run every where" language.

Saturday, November 10, 2007

Mobilis Crashed!

After months of almost daily use of Mobilis, it has crashed and simply refuses to power on :( Have contacted the Encore staff, but will have to wait till trow for their reply.

Tried to open it up and check for any burned stuff .. but have found nothing that "looks bad". Hope that I am able to get it back working soon...

Friday, November 09, 2007

Speculating on Android Platform

Google and a group of 34 other companies announced the Open Handheld alliance this week (http://www.openembedded.org/). They also announced that a SDK for the "open" platform named Android would be made public on Nov 12,2007. I am just trying to speculate what all this platform might constitute:

1. An embedded Linux kernel, probably built and hardened by Google engineers.

2. A scripting language like Python as an interface for programming. other scripting language that would be included is JavaScript. To Some extent this would be like PyS60 (Nokia's Python implementation for S60 phones - http://wiki.opensource.nokia.com/projects/PyS60), however I feel that this will be the primary mechanism of programming on Android platform. I am not sure it they would provide any native programming support; primarily because of two reasons : cross compiling is difficult and time consuming secondly native code is always a security risk.

3. Large set of APIs for supporting Web 2.0 applications. It will probably support all Google data APIs, however I feel that the platform will it self support integration of other Web 2.0 (or 3.0...) apps. This is what I mean by "open'', and not closed to only Google services.

4. Would have some seamless mechanism to access Internet from all kind of networks supported by the device. This is mostly a hardware feature, but felt like mentioning it.

So these are my speculations! Let us see, what Google and its alliance have out of their hats next week. Turn back to this space to see how poorly I faired ;)



(update: Just forgot to mention in point 2 that Java and JavaFX are also strong contenders here, but with Sun Microsystems currently not officially part of the consortium I wonder whether this is really the central part of the platform).