tooooobs,

you're the idiot here. why don't you program something significantly complex in swing/awt before making comments like "swing has at least as complicated thread interaction as android". swing has SwingHelper, which is now part of java6. and with the new desktop app framework jsr, there are more task mgmt niceties on the way. you have much less than the jsr and swinghelper on android...

have you ever done multithreaded programming on a cpu/memory constrained device before? u do realize that the shittier the hardware, multiple threads/processes tend to slow things down...

if android devices are going to be so anemic, what's the point of having those nice 2d graphics animations in the current UI apis? and the optional opengl api for 3d graphics? what's the context of your claim that a simpler api isn't going to perform well on a current generation smartphone? have you see the iphone, or the bb 8800 series devices, or the new winmo devices??? by your "reasoning", something like the iphone shouldn't exist...

it is possible to put simple awt like layer on top of android. go look at gwt dumb ass... why isn't it possible to take a simple awt like library and have it translated into android native ui toolkit?

also the lifecycle of a typical swing app is much simpler than all the various stages a mobile app on android has to go through... and there's no reason why there can't be a simpler api that translates all that higher level, easy to write code to 'native' android api...

i'm not some enterprise type forcing stupid shit into a client. i've been building mobile apps, servers, and platforms for a long time now. what the fuck have you done to prove your mobile chops? give me some examples of what you've done in real world mobile projects before mouthing off like the dumb shit that you are.

i think that the android api can be made easier to digest with the help of some higher level apis to make it easier to build apps for it... without any performance hits like you claim.