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.
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.
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 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. 
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.
1. The nostalgic songs thing works by the way. It gets my heart racing and before I know it I'm wide awake. I try to only use it when I really need it, like the Philadelphia Flyers and Kate Smith. If you try this method, here's a song you might want to add to your playlist.
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.
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.
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.
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
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:
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!