Ack! This site is moving to tomhorsley.com since Comcast's efforts to improve their world's worst customer service ranking apparently include terminating web hosting for their existing customers.
Chapter 5 — A Dream Given Form
So what is the system of my dreams?
For starters, it is open ended. I need to avoid specifically tying it to my AardRemote device. I want to devise a plugin scheme which will allow things that haven't yet been thought up to be controlled by this remote. I want it to be truly universal.
As an example of the sort of irritant that exists now: You can get a TiVo app for android, it works wonderfully to control the TiVo and access the information about what programs are currently showing, etc. Unfortunately, it can't control the volume, since the volume has nothing to do with the TiVo. A remote such as a Logitech Harmony can use IR to control the TiVo and the volume on your receiver, but it can't access the network and get the information about current programming.
That's one example, but lots more situations like this crop up all the time.
So there is one part of my dream: An open ended plugin mechanism. (Of course it would also be good if 3rd party developers of things like the TiVo app decided they liked the idea and plugin enabled their apps to work with my remote, but that's a task for the distant future at this point.)
The My Life with Android blog has what looks like a good post on implementing plugins.
As far as the plugins themselves go, it seems likely they should be android services which can be bound to communicate with the main app. See http://developer.android.com/guide/components/bound-services.html. That page also seems to imply that the best communication technique for the kind of services I'm likely to need is to use a Messenger rather than the more complex AIDL. (Not that I actually understand any of this yet, I'm just accumulating links to info I'll probably need to understand someday :-).
Infinitely Configurable UI
Obviously, I can't really make it infinitely configurable without adding an infinite amount of code, but some of the things that seem obvious to implement are:
I could go on and on with specific examples of specific things I've wanted from remotes, but the challenge will be inventing a way to make it possible to do things I can't think of at the moment.
Lots of apps seem to get carried away with themes, but it does seem to make sense for a remote. Maybe you don't like a bright phone screen shining in your face, and you'd like to develop a theme with buttons that are all dim red objects that won't destroy your night vision, etc.
I see apps that provide downloadable themes now, but I'm not entirely sure how they arrange for them to work. This is another topic that will need investigation.
This stackoverflow post seems to indicate that allowing downloadable themes is something the app has to build for itself, there is no standard android mechanism for it.
Meanwhile, when I need a break from learning android programming, I'm working on a set of buttons for my initial “hot wire” theme:
It is kind of unfortunate that android doesn't seem to have support for SVG images, and the external SVG libraries that are available can't seem to render complicated SVG images like this (which should look a bit like a play button made from a glowing hot wire, not merely a red triangle line drawing):
(I include it here because I'm curious how it renders on android browsers - or in firefox, for that matter which seems to render it quite differently than inkscape.)
Seems likely there will be multiple users of the same equipment. If one user generates a particularly nify remote layout on his phone, it should be easy to share that with other users of the same equipment. This might be a good place to learn about the new NFC stuff in Android, but for devices without NFC, some more traditional way to share with (for instance) a web server might make sense.
The other part of sharing would involve allowing proxy access to the actual remote. Since my AardRemote uses bluetooth, only one master device can be connected, but nothing would prevent that master from accepting commands over the network and passing them along. This might be the only way an iPhone or iPad could ever work since there are apparently extreme barriers to using bluetooth RFCOMM in iOS.
Woa! Slow down now...
Another challenge I face at the moment is looking at all the stuff I've just written above and getting daunted by how much work I've just described. I need to focus on one bitty piece at a time before getting overwhelmed by the project I've just envisioned.
In fact, after beating my head against various android walls for a while, I am indeed daunted. I need to work on a less ambitious project for a bit and give the learning curve a chance. Fortunately a good project has just cropped up.