A week of the android sdk
Well, a work-week.
It's a pretty crap api. All that really nasty XML and pre-compiled resources: maybe it makes sense if you're really resource constrained, but I can't see how that's an issue for the future. The whole XML stuff is a pretty annoying too: it's a horrible language and its hard to write and harder to debug. Repeatedly I see claims that it's all about 'good practice to separate view from logic'. Sure it is, but you don't need to learn some fucked up shitty language to do that, you can just do it in programming language too. And I can't see how XML is any easier to learn than the tiny bit of code you need to do it programatically. If you dig hard enough you can work out how to avoid it, but it's a constant battle with the documentation.
I think XML is only popular because many people have only learned how to use a rock as a tool and to them every problem looks like a nut that needs smashing.
A lot of the api is similarly infused with short-sighted decisions [such as the pre-compiled resource id stuff].
Which means ... the api's are constantly changing to cover up earlier mistakes. I'm not sure exactly what the fragment stuff is about for example; it seems to be important for a reason but i'm not sure what yet (but such things are usually the way when encountering a new toolkit). It also means the documentation is a bit over the place and old api's aren't clearly marked as deprecated even if 'the new way is not to use them' as are any third party resources. Stack overflow has been invaluable to sort the chaff from the wheat.
Still, even with the weird api's and broken cut-down Java runtime, it's pretty easy to create fairly slick responsive applications. They've gone some way of hiding the 'complexity' of multi-threaded applications (which is needed to make this a reality) and introduced it to neophyte programmers who probably would have shied away from it - even though all modern toolkits provide similar levels of support. I always preferred threading vs callbacks (it's a lot easier to maintain state in local variables and for loops vs callbacks and callback 'user data'), and the fact it scales cleanly on multi-core hardware is just a bonus.
Compared to HTML5 that looked like arse (we hadn't even thought about styling it yet), limited user interaction, and all sorts of platform problems. In android we had a slicker interface with less time. It took a bit more code but not much (and it was simple java) - and it already had decent styling and proper user interaction. And well, in HTML5 it was still just a web page ...
One just has to compare 'youtube' from the browser (any browser) and the android youtube application. It's like comparing apples and oranges, it really is. And if that's all google can come up with - with all the experience and almost almost infinite resources - what hope does anyone else have?
If I was mozilla i'd be shaking in my boots - i'm surprised google haven't come out with a browser plugin or standalone 'ARE' (android runtime environment) yet. As a TV/flat surface toolkit/runtime, it's strides ahead of HTML5. Strides.
The only thing programming in HTML5 gives you is ubiquity - or at least the hope that most people on most hardware will be able to run some version of your application. It's still just a hope.
If only ...
The real pity with android that it isn't using a proper JVM and a full Java SE environment (minus the toolkit). I guess when it was conceived the hardware was pretty minimal but that isn't the case now let alone in the future.
The other pity is that many of the applications are using the same web model for revenue - i.e. spying on users for fun and profit. I wonder how sustainable this revenue model really is globally: developers get a pittance and most of the money goes to a handful of giant multi-national corporations who siphon it away from the country and avoid paying their fair share of taxes.
Sure a few 'hit the jackpot' and make a good living, but that sounds too much like everyone is playing a casino. And clearly casino's are really just a tax on stupid people - the house is the only real winner. Always.
Well i'm still not sure what I will hack on now I have an android machine. I might look at porting jjmpeg or something, but probably only do it properly if I will use it for work. The utter shit-house video players available on the android market (based on FFmpeg clearly for the most part, usually without source) could be a driving factor, but I don't personally need another video player and doing it alone would only be for the novelty value and to learn about the problems one faces in such environments.
I've also been keeping an eye out on the rhombus tech/all-winner A10 stuff. And thinking about getting one of these to play with. I have some other motives for that too - I bought a cheap Kogan dual-tuner DVR, but it's been a pretty crappy experience - the software is shit, the remote stops working if it gets humid, and it keeps rebooting itself (I did find out about getting an RMA but just couldn't be fagged with all the hassles of having to ship it back with the proviso 'you have to pay for it if we can't find a fault' - at the time the faults were intermittent, then the remote didn't work for a couple of months, now it's working again but it's rebooting with a hdd plugged in). For 100$ I may as well just throw it in the bin, or open it up and poke at it for some entertainment. I don't use it myself, but it was a present and i'm a bit pissed off that it's just such junk (what I should have expected I guess).
But for now it's a wonderfully warm autumn day, I need to mow the lawn, and there's cold beer in the fridge. Hacking can wait.