Inside the gPhone: What to expect from Google Android

http://journal.dedasys.com/articles/2008/01/29/munich-androi...

There are definitely some open questions, but I'm fairly sold on the idea.

However, one has to adhere to an application lifecycle, which was a little different, since we're use to pretending that the application we're writing is the only one on a machine.

The UI isn't programmatic, like Swing, but rather is reminiscent of web programming by defining the UI through an XML file.

The good:

1.Their SDK and emulator are pretty good, even at this early stage (few bugs). Not everything is documented, but at this early stage it is good enough.

2.There is a lot flexibility, many widgets to choose. It is very powerful when you compare to other platforms. Lot's of layouts, lots of things you can use. You almost feel like a kid on the candy store, not knowing what to eat first.

3.You can do UI both programatically or with predetermined descriptors (xml). In large applications this is pretty useful.

4. There is a resource file called R, which get's autogenerated and includes all the resources. Given my experience, (I have a Constants file in very popupal J2ME app my company is doing, that does the exact thing) it would end up with too much stuff into it. Very useful for small applications though. >>>>>>>>>>>>>>>>>>>>>>>

>>>>

>>> The Bad:

1.The API is not elegant as it could have been. Some classes extend other classes, which extend other classes, the result? Something like Gallery,class has over 50 methods, and a bunch of constants.

2. They included everything that is under the sun, making it confusing, as there are 10s of ways to do something. This is a Java problem also, but their API made it worse. (compare it with the pythonic way of thinking as there should be one very obvious and easy way to do something).

3. Too much XML.(which I really disslike). You can describe screens, and UI with XML descriptors, (xml is very lame, something more looking like CSS would have been much better). Even the Manifest is fricking XML. There was absolutely no need for this. Sun's J2ME has the manifset in plain text, which makes it simpler.

4. Wierd namings and terminologies, make it confusing to get started. Events, are called Intents, there icicle, bundle, and all other really wierd naming allover this place. Did they do it purposely, so beginners will be so confused and wont be able to do anything with it?

>>>>>>>>>

So, KISS was defenitetly not the mantra when building the android. It was more "Let's include everything under the sun", so the developers will like it. Well, that's great, but don't give me 10s of way to do something, which are just little variants of each other, and none does the exact thing I want to do.

Since I do Java for living, and Python for fun, I can say that I was slightly disapointed by android. Lot's of power, but not elgant enough to be called a perfect platform.

So, yes, I probably would be developing for it, but not necessary just for fun.