For a while I've been considering getting an Asus Transformer for its snap-in keyboard and ability to transform into a little laptop/netbook. For certain things however you need a more full-featured desktop OS. You could achieve this by using an online server, or by dual-booting which doesn't seem to be possible currently on the newer Transformer models.
To me the chroot approach seems potentially better than dual-booting because you have Android apps side by side with desktop Linux. I'm an avid user of Linux on the desktop, although I admit there is a lack of good software in some areas. Android would go a long way to filling in these gaps with a huge selection of apps that tend to be simple and user-friendly, especially by Linux standards.
It's interesting to imagine Android as a desktop distro and what further integration of the mobile and desktop worlds would look like. For instance what if Android apps could be run on a Linux desktop as if they were native applications, each with their own icons and taskbar items (kind of like VMware's "Unity mode").
The main concern with the chroot approach is probably RAM. The Nexus 10 has 2GB which is really generous by today's mobile standards, but when you consider that you're running 2 operating systems it's really not very much. Someday soon I bet 4GB will be the norm which would help a lot. For over 4GB I suppose we'll have to move to 64-bit.
How about a dual-booting tablet that runs both Android and Chrome OS? When you attach an external keyboard and boot into Chrome OS it basically becomes a Chromebook. How cool would that be? Quick boot-up time is a frequently touted benefit of netbooks, so this would work out well.
Optimizing the experience based on whether the user is using a keyboard or just the touchscreen seems like a win. Using Chrome OS in the former case and Android in the latter would be an obvious way to accomplish that.
Note: According to a somewhat recent CNET article, Google is actually working on a tablet version of Chrome OS.
A problem that many mobile developers have kicked around at one time or another is how to turn your smartphone into a universal remote. Imagine how great it would be to use your phone to control appliances like televisions, stereos, even air conditioners and space heaters. Many begin by asking a question like "the Droid doesn't have IR built in, does it?" No it doesn't, but as I'll explain it wouldn't even be the best solution if it did.
What follows is an overview of how I'd like to see IR control implemented using smartphones and tablets.
Why IR built into the phone isn't enough
As someone interested in home automation, simply building IR into the phone doesn't do it for me. Sure I'd love having a laugh with my mates at the pub by changing the station on the telly with my mobile, but that's about it. Also I'm not even British.
While most of the implementation I advocate in this article could be repurposed for this kind of built-in use (as I explain at the very end) for every other use case it'd be better to have a standalone IR unit controlled wirelessly, a wireless IR blaster.
- Line of site issues are inherent in IR remotes, but not wireless ones. You have to be in the same room for starters, which is already quite limiting; you also need the correct angle and no obstructions.
- With built-in IR it would be impossible to control multiple appliances, unless they happen to be right next to each other.
WiFi vs. RF
So doing it wirelessly is a slam-dunk, but should we use WiFi or RF? I say WiFi. RF is what we use for radio-controlled cars and garage door openers, and in some ways it's the natural choice for this application. It has some disadvantages though:
- Transmitting RF would require an additional piece of hardware for your phone or tablet.
- RF is not as reliable and is prone to interference.
- WiFi using TCP can be very reliable. Application programmers can handle errors however they want, trying again in 30 seconds for example.
- RF is not readily integrated with modern computer and network infrastructure. Imagine having a few WiFi IR blasters, each with its own IP address. You could scan the network to find them, connect to them via a web interface, and control settings like signal amplification and the device's name. WiFi devices on a home network could also be exposed to the internet and controlled when away from home. All of this is not possible with RF.
- With RF you need to pair transmitters with receivers by frequency so things don't get mixed up. This complicates things significantly.
So what are we transmitting?
Since I've decided on using WiFi, I'm inclined to transmit some kind of digital audio format. This may sound strange, and I won't go too much into why this works, but it's pretty easy to capture IR signals as audio and later convert them back into IR. See this tutorial if you want to learn more about how this works and how to build it.
Using this kind of general representation for the signals means there's no hassle of worrying about different IR protocols. Using digital audio specifically has some more benefits:
- Availability of programming libraries for manipulating digital audio. I built a crude infrared to WAV converter in Java in a weekend. I've been thinking of polishing it a bit and open-sourcing it.
- One can find many resources for assembling the WiFi receiver since it's similar to a multi-room music system, with a few differences. The required amount of buffering memory is much less (IR signals will be only a few KB) and instead of speakers you'd use IR LEDs.
- If you did decide you wanted IR built in to your phone, you could build or buy one of those little attachments (for example this or this) that hooks into the audio jack and use the same converter software for both the built-in and wireless forms.