14 releases later, and Andronos (my Sonos controller for Android) is actually looking pretty good. My 1337 gui skills have been at work, and in my own opinion, the application has been styled somewhat nicely. Basic functionality is present:
- Detect and list available zones
- Group zones together
- Playlist management
- Browse music
- Browse radio stations
- Volume control, both individual and group volume
I’ve also managed to add some more special features:
- Quickplay list – I use it for starting my favorite radio without having to navigate the browsing structure
- Indexing and freetext search
- Last.fm integration – covers are fetched automatically if none existed locally, and extra info (tags and play count) can be retrieved. Also, it’s possible to love a song using last.fm
All the features of the regular controller which I normally use are done, so I’m more or less ready to drop my iPhone. Now begins the hard part of adding new valuable features – most of them are not particularly easy to implement:
- Faster – the Android platform is pretty nice to work with, but Andronos is not exactly as fast as the native controller. Caching can add some performance, but in the end, I’ll probably have to do some pretty low-level optimizations all over the place
- Cover browsing – it should be possible to browse the music archive based on a list of covers
- Rhapsody and Pandora – probably not hard to do, but neither of the two are available in Denmark. Help is appreciated here – I don’t quite know how yet, but if you’re interested, please contact me.
- Dynamic playlists – Andronos should be able to dynamically create playlists based for example on loved songs, previously played songs, and so on. Also, it should be able to select music based on a general category (party, relaxing, cooking, whatever)
I’ll probably think of more features to add, but it should be enough for now – there should also be something left for Sonos to do when they get around to making a supported controller for Android.
And then to something a little different, but related. Someone asked me today if I had an opinion of mobile development with Android. Having worked with Android for a couple of my pet projects, there are some things I’ve noticed, and here are some of them, in no particular order. Hopefully, I’ll get time to elaborate on them later on.
- As a Java programmer, nothing really beats having your normal environment, in my case Eclipse, and all the standard libraries. Need UPnP? Download a library. Need last.fm integration? Download a library. Need raw network access? Download a library using JNI. (in the last case, be prepared to fiddle around with Make-ish files, but it can be done). No need to learn a new language or new basic tools, you just have to learn a new API.
- It can be a little hard to drop all the fancy patterns and design principles, but it’s often necessary to get acceptable performance. Object allocation and garbage collection is pretty expensive, which is the complete opposite of the regular Java VM, so you have to be careful, and that can hurt in a number of ways (think maintainability, API design, testability)
- The declarative UI approach works pretty well, but the Eclipse plugin does a pretty bad job of rendering the UI, so in most cases, you have to fire up the app on either an emulator or a phone to get a real look at the UI. A simple thing: Why are styles not rendered in the plugin?
- The UI does have a number of bugs and undocumented features. Drawables are probably the worst I’ve met. They can be defined in XML, and can be used for eg background gradients, button borders, and much more, but they are truly trial-and-error
- Android Market works pretty nicely, in principle, at least. I wouldn’t have been able to create Andronos if I’d had a turnaround time of a month for each release. Of course, Andronos is a little special, because Sonos systems can be configured in so many different ways, and I do not have one of each player model, but still. Being able to get a bug report, fix the bug, and release a new version in a matter of 10 minutes is pretty cool.
- A couple of things about Android Market, though: Why can’t I see the comments in a regular browser, and why can’t I reply to the comments?
- Fortunately, Andronos is pretty flexible in the layout, so it runs without any serious problems on both small and large screens. However, this can easily become a problem if you haven’t defined the UI in device-independent units, and even then, you might be forced to having different layouts for different devices. I’m guessing Apple will have to cope with this too, now that the iTablet (I forgot its name) is out
- I can see why root access is something you don’t want to give out to everybody, but couldn’t there be some way of getting partial root access? For example, if I want to send an ICMP packet, I need write access to the network device, but I can’t get that. Why?
- Error handling could be better when an application crashes. I’ve installed a custom exception handler which emails me stack traces, but couldn’t this just be built-in?
- The Android API itself is at points somewhat strange. Why do I sometimes need to bitwise add flags to a component? Why must I always remember to call super? Most of the time, it’s just like doing Swing, and I can live with that. The API could be more “modern”, however, and not use inheritance quite as much as it does.
- Testing isn’t as easy as it could have been (and with Andronos, it’s even harder, because most functionality only makes sense when connected to a Sonos device), but that’s at least in part because GUI testing has never been easy. Just learn to separate UI logic from “business” logic, and then the business logic can be tested as you would normally do it.
- Most importantly, and this outweighs any disadvantages Android might have: The platform is open, there’s an active community, there’s lot of open source, and you’re not forced into anything
That’s it for now. And no new releases tonight (but that’s probably just because I’ve been musically cultural tonight).