Video Toolbox released!
Video Toolbox provides a set of tools to do the simple things you want with videos on your Android phone or tablet: rotate, trim, flip, resize, and convert.
Color Sounds released!
Color Sounds is a music making app, somewhat like the Tenori-on but based on colors. There's also an experimental camera mode for using colors from the environment to create music.
Download the app or see some videos.
Getting started with TaskBomb
This video is an introduction to TaskBomb, my task scheduler app. The video briefly discusses the app's major features and how to automate toggling WiFi and Sync.
Celebrate Diversity
Much has been said about "fragmentation" in the Android ecosystem. Many claim that the diversity of hardware and software is a negative aspect of Android, drawing comparisons to the more homogenous platform Apple has created. To me this is shortsighted. Would it be easier if there was only one type of Android device? In the very short term maybe, but then we'd miss out on the kind of progress that comes when many different types of ideas are given a chance. We should embrace this diversity, and apply these principles in our daily lives.
TaskBomb Released!
TaskBomb is my task-scheduling / automation app for Android. It can theoretically do anything your Android device can do. It gets a little trickier in practice, but it's being rapidly improved. There's already enough functionality to build one great alarm clock. My personal alarm includes waking up to streaming radio (or a backup if that fails), having the volume gently increase, and switching to a playlist of nostalgic songs to get me out of bed if I still haven't after 10 minutes. [1]
With the announcement of Android@Home and the Android Open Accessory API this app comes just at the right time. TaskBomb's unique scheduling system is well-suited for automating things around the house. Imagine a space heater that begins making your bedroom toasty and warm 15 minutes before you wake up to your favorite internet radio station. Meanwhile your curtains slowly open to let the sun fall on your face. You hit the snooze button on your Android phone to delay the music for another 9 minutes while you lay back in the sun like a happy cat. The possibilities are endless.
Learn more about TaskBomb or get it from the Android Market
1. The nostalgic songs thing works by the way. It gets my heart racing and before I know it I'm wide awake. If you try this method, here's a song you might want to add to your playlist.
I wish I could search the Android Market by intent filters.
I was wondering recently what apps out there implemented ACTION_SEND. It would be great if apps in the Android Market listed their intent filters just like they list their permissions. Then there could be a way to filter by these, or I could use a Google site search of the Android Market.
If you don’t know what intent filters are, they’re how apps tell each other what they’re able to do and with what types of files. One example is media players, they often have long lists of file types (mp3, wav, etc.) for which they are able to handle ACTION_VIEW intents, which basically means to open a file.
If it was possible to search the market by intent filters, you could instantly get every app that can play FLAC files, or every app that can edit JPEG images. It would be more precise than relying on the description. Many details are too subtle/inside baseball-ish to make it into app descriptions. This would also greatly benefit developers who are wondering what apps out there could interact with their apps, or even wondering if an app they’re thinking of creating exists already.
Idea: Dual-boot Android/Chrome OS tablet
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.
Idea: Infrared (IR) control from smartphones
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.
App Developers: Be careful with Proguard and Eclipse “User Libraries”
One convenient feature of the Eclipse IDE is that it lets you create "user libraries" to hold jars as well as source, javadocs, etc. This is useful even if you only have one jar in there, since you can update that jar and all the projects that use it instantly use the new jar.
While this is convenient, I've spent way too long fighting with Proguard while it says things like
can't find referenced class com.google.ads.AdView
and suggests
You may need to specify additional library jars (using '-libraryjars'), or perhaps the '-dontskipnonpubliclibraryclasses' option.
when I know good and well the jars are there.
Upon Googling the problem I found many solutions that involve using "-keep public class" and "-libraryjars" along with other such things. The right combination of these allow Proguard to complete and produce the APK, but your app will ultimately fail upon run:
Caused by: java.lang.ClassNotFoundException: com.google.ads.AdView in loader dalvik.system.PathClassLoader
Well, if you're having this problem give this a try:
The Solution
Do you have any "user libraries" in your project? Well get rid of those and replace them with the actual jars, then be amazed that such a silly thing could have been your problem all along. Of course this isn't optimal since if you're using user libraries you probably want them in there. There might be a way to keep them and still use Proguard, but I'm not sure. Either way, I hope I've saved you some time. Happy coding!
Apps vs. Applications: A Paradigm Shift
Apps and applications are in many ways similar, but have different underlying paradigms.
Applications tend to be more complex and feature rich. Jamie Zawinski once remarked that "every program attempts to expand until it can read e-mail." Applications often turn into Swiss Army knives with each providing several, often overlapping pieces of functionality.
Apps by comparison are more like silverware, each with a specific purpose or closely related set of purposes. You'll occasionally find a spork thrown in there, but this tends to be the exception and not the rule. In this sense apps are truer to the old UNIX philosophy:
Write programs that do one thing and do it well. Write programs to work together.
Until mobile apps arrived on the scene, it seemed that we were moving increasingly further away from this ideal. Microsoft Word for instance, an application used by hundreds of millions, ships with more features than most of them would ever want to learn. This complexity comes at a cost. At a certain point adding more features actually makes the average user take advantage of less features. Many people who would potentially benefit from some of the advanced formatting tools in MS Word are hesitant to learn them since they're among hundreds of other unfamiliar features.
Apps are a welcome change from these beasts, both for users and developers. Smaller, cohesive chunks of software are both easier to learn and write. It basically forces you into using good design principles, or at least makes it hard to screw up too badly. It allows for smaller, more efficient teams. It makes the product more maintainable and makes bugs easier to find.
Apps aren't merely applications for small devices, they represent an exciting shift in the software world. In some ways it's a shift back to the UNIX philosophy of "one thing well" that's been around for over 40 years. It's not a new concept by any means, what's new is how mainstream and widespread it's finally becoming.