For a year or so, with some large gaps, I’ve been exploring what it is to build (and redesign constantly) an Android app, with a real(ish) purpose rather than a My First App feel. It’s changed my thoughts on lots of things, including UI development in general, and to a lesser extent Java APIs; both for the better mainly.
As an overly-simplified bullet point summary, I find:
- It’s well thought out
- Good use of Generics (in places)
- Most if not all UI and phone features are sub-classable
- Excellent Eclipse integration.
Nothing’s perfect though
The learning curve has been fairly steep, there’s no doubt. What seems like a simple task (e.g. drop-down from a list of choices) can turn into a lot more classes and handlers than first expected, especially if you don’t want to build something like one of the tutorials.
The developer documentation has been helpful, but in places (some examples particularly) it’s really quite out of date, and with little or nothing to indicate this (until you find randomly ages later that xyz has been deprecated in version 2.2).
The application lifecycle definitely has taken (and still does) a lot of thought, even if it does make sense after a while.
New Android versions
This was all for 2.2, really. A lot of advances have come in 2.3, then 3.x too, I’m lead to believe.
In fact I’m looking forward to version 4.0, aka Ice Cream Sandwich – though the rate of progress seems a little, well, manic. Hope they don’t end up going down the J2ME spiral..
Being a audio-obsessive can make life a bit difficult. Whilst iTunes is great for a lot of people, being closed-source and without a linux version, it’s already a fail for others. Whilst improving it’s also sorely lacking in several areas including performance and tagging. But this isn’t a post about iTunes…
For some years I’ve been a fan of Quod Libet, a lesser-known open-source music player and manager, based on Python and GStreamer for Linux and Windows (Mac builds are possible, allegedly). It’s fast, has by far the best searching of any audio program I’ve ever seen, lots of plugins, and most importantly just does The Right Thing almost every time, whether it’s support for localisation, editing multiple songs, configurable views, smart playlists, volume correction, and so on.
It’s not until some time later (early 2010 I think) that I tentatively submitted my first patch to improve the ReplayGain support and configurability, a subject close to my heart and anyone that’s put on a diverse playlist and wondered why despite best efforts some songs are still louder than others.
Since then I’ve become a semi-regular commiter to the project on which I’ve spent a surprising amount of free time (not least because Python is not my first language). The focus has mainly been on new or improved plugins, but some core bugfixes and a little (dodgy) translation too, as well as taming the ever-growing issue triage and feature requests list.
that open-source thang
It has been very satisfying to finally contribute to the open source community, and to a upcoming project used daily by thousands (here are some usage stats for Debian alone), and the GTK and desktop app Python experience is great. But mainly, it’s an amazing piece of software, that even after almost five years of use turns up some surprises. Try it out, you too may fall in love…Posted by nick on Sept. 17, 2011 at 1:54 p.m.. It's all of 320 words
So we all know grown-up development projects need unit testing, and lots of it. In the LAMP world PHPUnit is almost the de-facto solution, with xUnit heritage to make people mumble supportively about best practices and cross-domain expertise (currently working in a Java-heavy environment).
Perhaps less known is the automation of code coverage analysis. Thanks to one of the several gems xdebug has to offer, this can be integrated into the unit testing fairly easily. Watch your versioning though, we had to pull newer ones than CentOs 5.3 had to offer.
The configuration / command line arguments are fairly key but something like:
$ phpunit —coverage-html ~/workspace/project/tests/coverage \
—colors —verbose ~/workspace/project/
With any use of external libraries (eg PEAR) we found it necessary to exclude those directories (eg /usr/share/) explicitly else coverage of those libraries was generated too, which is hardly the point. Beware also of symlinks confusing it a little.
The output, though a bit oldschool, is easy enough to drill down into, and seeing red lights turn to green is a surprisingly good motivation for developers to add more test, or better still, think about exactly what isn’t being tested fully.
Static Code Analysis
Also worth mentioning while we’re there is one of the static code analysis tools: at work I’ve set up phpcs with some luck. Its tab support is far from perfect (a tab, apparently, is a fixed amount of spaces that you’ve forgotten to convert) but other than that it can have its uses, and great for enforcing coding standards in a larger dev team.Posted by nick on Aug. 30, 2010 at 6:17 p.m.. It's all of 267 words