The iPad will not save journalism. Beyond that, I can't really bring myself to care about it. It's tempting to be worried about the trend it represents--the triumph of walled-garden content consumption instead of creative computing--but I already sound enough like a cackling lunatic on a regular basis. And at this point, nothing I say or do is going to make much of a difference anyway, right?
But in no small part I'd also rather not get upset because I feel like it would put me in the same class of lunatic as Gizmodo's Joel Johnson, who responds to critics of Apple's device with what appears to be a complete mental breakdown:
The old guard has The Fear. They see the iPad and the excitement it has engendered and realize that they've made themselves inessential--or at least invisible. ... It all just kills me. It literally makes me sick to my stomach.Uh, yeah, okay there, Sparky. When Cory Doctorow's consumer choices make you physically unwell, it's probably time to step back from the brand identification and stop taking pulls from the crazy juice--although I suspect Johnson is "literally" ill because he's a terrible writer, and not because he's actually nauseous.
Here's a tip for keeping your sanity, kids: maybe the whole argument is a sideshow. Maybe the real trend here is something different. Maybe what we're looking at isn't the Tinkerer's Sunset, but the computing equivalent of the Casio VL-1.
The VL-1, for those who aren't avid readers of electronic music blogs, is an incredibly crappy little keyboard from the 80s. It's two and a half octaves of kitsch, essentially: a cheap, mass-produced synthesizer with a built-in speaker and an LCD that doubled as a calculator. The sound engine was based on the Walsh function, which is a fancy name for what is essentially a square-wave generator. The VL-1 was a toy, although it did find some modest success a few decades later as a sound effect for people who wanted a specific kind of annoying beep.
Casio's little white box didn't just represent the sound of trendy underground electronica bands. It's also a symbol of the time when synthesis--thanks to the wonders of transistors and Turing machines--took two paths. On the one side, the expensive and finicky studio synthesizers with their complicated FM math operators, oscillators, MIDI ports, and modular bays. On the other, throwaway consumer gadgets that are technically synthesizers, but don't offer the kind of patching or playability that a serious instrument does. It's the difference, in other words, between consumer- and professional-grade equipment.
This is largely how I've started to think about the whole walled-garden computing model. It's the VL-1 of information technology. When you look at it that way, why get bother to get upset? Its success won't mean the death of open machines, any more than the Casiotone synths killed off low-end synth hardware. Just as with the VL-1, some creative work will be done on closed systems (see: the famed New Yorker covers) because an artist likes the quirkiness or the feel of it, but serious creatives in any field are still going to need--and can probably buy, for less money--a full-fledged computer.
Likewise, predictions that such simple devices are the "future of computing" are self-evidently ridiculous--like saying that the VL-1 swept in a new musical future via Hallmark's tinny audio greeting cards. Indeed, if you look at the music production landscape today, the state of traditional synthesizers is ridiculously strong, even though they share many of the same "pitfalls" as a desktop OS: complicated user interfaces, intimidating technical specifications, and hackable hardware, to name just a few. The development of pre-programmed, "appliance" synthesis only added to the prestige of modular synths. I think it's not just possible, but even probable that the same will be true for the open computing model that's most common today.
Maybe this is just a way of stroking my own ego ("I'm kind of a big deal. I have many leather-bound books and my apartment smells of low frequency oscillators and shell scripting."), but the more I think about it the more it rings true. In the end, standard open systems tend to win out, both because they're desired by pros (or those who aspire to professionalism) and because closed systems are more expensive to design and maintain over time (after all, we wouldn't have netbooks if not for commodity parts). So let's not hysterically overreact in either direction, but especially let's not make claims for a utopian paradigm shift. There's room for both open and closed devices right now, and if the fate of the post-VL-1 synth is any indication, this is nowhere near the death knell of the computer as we know it. Far from it, in fact.
Here's what I've learned from releasing Underground to the Android Market:
Overall, I've really enjoyed learning the platform and joining the community. I did some other hobby work on Android the other week (wrote a Locale plug-in for detecting headphones and started a utility/plug-in for launching arbitrary custom Intents), and I think it's lived up to my initial impressions of a smart, interesting API design. That said, now that Underground's in decent shape (most of the requested features have been added), I'm taking a break from Android coding for a while to give my hands a rest and concentrate on other hobbies. When I get the urge again, I'm thinking about contributing to the official NPR client--it's not a particularly good citizen on Android, and I think it'd be a good way to get involved with other digital journalists.
Yesterday I did something that I arguably should have done a long time ago: I redirected pretty much every tech blog in existence to localhost on my work laptop, effectively blocking them completely. Previously, I'd done something similar using the BlockSite plugin for Firefox, but it'd been too tempting to route around it in Chrome or IE. Not good enough: I needed them gone completely. Nuke their domains from orbit, it's the only way to be sure.
I took this step in part because I agree with Anil Dash: I want to believe that I'm better than a consumer for a constant drumbeat of materialism. It's ironic that the digital computer--an infinitely-adaptable, do-anything Turing machine--has spawned an entire subculture primarily concerned with packaging those machines into an infinite array of disposable, plastic packages. Maybe I can't always resist buying more crap, but that doesn't mean I should spend my waking hours planning the next splurge.
It's also in no small measure because tech bloggers are, generally, incredibly silly people. (I know: "this food is terrible. And such small portions!" But stick with me.) I've complained here for a long time about the low quality of games journalism. As I started reading more gadget news sites a couple of years ago, gradually it dawned on me that the lack of good material in that one area was just symptomatic of a sector-wide lack of perspective. The whole thing's rotten: the completely interchangeable writers that substitute "snark" for "opinion," the rumormongering, the wafer-thin technical expertise leading to "analysis" that isn't, the constant churn through the hype machine. For me, the result is a kind of low-grade irritation, and I hear that happy people live longer.
My worst nightmare, actually, is that one day mainstream journalism--in its increasingly desparate grope for cash and readers--will model itself on Gizmodo: high turnover of largely forgettable, badly-written posts cadged from press release wire services. I like to call that the "no self-respect or job security" future, personally.
(Which reminds me--Dear mainstream journalism: we need to talk. I know it's hard, enduring this rough patch of reasonable profit margins, compared to the ridiculously exorbitant profits you enjoyed back in Ye Olde 1990s. But whenever some new tech gizmo comes out, every two-bit visionary and "innovation editor" on earth shrieks to the high heavens, insisting that this time Product X will "save the industry" from extinction at the hands of the blogging hordes. It's funny: I could have sworn we already had a way of digitally distributing news to readers on a wide range of technological platforms, including video and interactive graphics and audio clips of elected officials sniping at each other, but I can't seem to find it now. Maybe it's buried under all these browser windows that I've got lying around, left over from Twitbooking and Facetorrenting and all that other stuff the kids are into these days.)
But the sad truth of it is that the tech news deluge works. It's strangely addicting, this gossipy flood of trivia. Indeed, that's the psychological quirk that powers the entire Gawker network--pump out as much content as possible, crank up the volume, and people will find it oddly compelling. I do, at least, to the point where I wasn't very good at stepping away from it. But when I reflected on what I was actually getting out pounding the refresh button, I felt a bit like a rat at the opium feeder bar--mangy, irritable, and poorly-nourished. Prone to metaphor abuse, too, apparently.
So I'm cutting myself off. And with the time I'll gain, I hope to pick up a new hobby, or rekindle an old one. Maybe I'll finally code that pocket synthesizer I've always wanted, or get back into the online bass scene. Maybe I'll finally get past the first chapter of the book I keep starting. Or even get some actual work done! These are strange new times indeed.
As an example of what Android's doing right, it's hard to top Locale.
When I first started using the ADP1, Locale was one of the programs I tried and uninstalled, thinking that it was nice but overkill for my needs. As time went by, my alternatives for settings automation succumbed to either developer neglect or ridiculous feature creep (nonsense like task killers or banner ads), and had to be removed. So when Two Forty Four AM, Locale's developer team, recently released a for-pay 1.0 version, I gave it another shot, and was pleasantly surprised. During the past year, they've refined it into a polished, sharply-focused utility that's well worth the $10 asking price.
Reviews of Android phones often fault the platform for missing some single application that the reviewer has decided they can't live without--a specific Twitter client, for example, which says a lot about the priorities of tech bloggers compared to normal people. In my opinion, though, Locale really does provide the sort of functionality that ought to be a deal-breaker for other platforms, and it's a must-have for Android users. After all, isn't this sort of automation kind of the point of a "smart" phone?
It's officially too cold for words in DC this morning, which means that as of yesterday anything I own with a touchscreen just became utterly useless. Consider this a triumph of frostbite over functionality, brought to you by product designers who live in eternally balmy climates instead of the real world.
At least the Android Dev Phone is usable, if clumsy, thanks to the trackball. People scoffed at the trackball, the menu button, and the chin they rode in on, but those people have to take their gloves off to check their e-mail. Which is not to say that it's any fun using the trackball through a pair of gloves (it's way too small), but it's possible. Gloved typing on the physical keyboard also works surprisingly well. And by surprisingly well, I mean "badly."
The Zune HD, on the other hand, is basically just taunting me. See, it's got a button on the side, the express purpose of which is to directly trigger a screen overlay for controlling playback and volume. I guess it would have been too much to ask for actual buttons to control those things, particularly the commonly-used song skip functions. Of course, these days, even players with physical controls probably run them on capacitive technology anyway, so you still can't use them. I'm pretty sure that's just spiteful.
And then there's the Kindle, which doesn't use a touchscreen at all. Great! Someone gets it! I can read with gloves on, just like an actual book! Here's what they don't tell you about the Kindle, or any e-ink reader: cold temperatures slow the already-slow refresh rate. It goes from being subliminal to seriously annoying as the temperature gets down below freezing. What's that? Paper? What am I, a neanderthal?
At this point, my options are to either go Amish, or move to a place with a milder winter and a functioning public transit system. Frankly, it's a tough call.
When I was doing research for the Audiofile articles, one of the surprisingly discoveries I made was the degree of overlap between audio sampling and other kinds of scientific sensors. In retrospect, it's obvious that the theory behind accurately measuring an audio signal thousands of times a second would be much the same as taking a measurement from something like a temperature, voltage, or orientation sensor. But it takes a moment's thought to make the transition from audio-as-sound to audio-as-voltage (or audio-as-binary-stream), which is the paradigm shift that makes it possible. It's not just a microphone or a speaker--it's an I/O port.
Audio inputs and outputs are everywhere, but they've fallen out of style for digital interconnection, which is why it's so cool when someone uses them in unconventional ways. One of my favorite examples is the re-release of Bangai-O for DS, which lets users trade custom levels through audio files (they sound a bit like picking up the phone on an old modem). That's really clever--particularly since it takes nerve to ignore the console's built-in wireless connection (a good thing, given the way Nintendo has reliably squandered it). Sharing MP3 files over the Internet is cheaper, easier, and longer-lived than any centralized, developer-provided solution could have been. It even degrades gracefully (you could send creations by mail via cassette tape).
Another great use of audio hacking showed up on Make recently, with a point-of-sale system that plugs into a smartphone's microphone jack. You see something like this and you think "well, of course!" It reminds me of the old IR blasters that were available for PalmOS back in the day--plug a stubby, square rectangle into the headphone jack, load up some .wav files, and suddenly you've got a universal remote control. Both inventions play on the realization that almost every device has a high-quality digital sensor with a sampling API and a standard pin configuration, as long as you stop thinking of the headphone jack as "for music only."
Tricks like these are not only fun for digital audio nerds like me, they're also a reminder that audio is a big part of our software heritage. After all, the original sytem hackers were audio people: phone phreaks who exploited flaws in the network signaling to get free long-distance calls. It's been a long time since those days, and since you had to physically place a handset onto an acoustic coupler to go online (that was even before my time, actually), but audio remains a powerful (and evocative) tool for storing, transmitting, and even hiding information. I can't wait to see what people will invent (or revive) next.
Of late it seems to have become fashionable among tech writers to complain about the "fragmentation" of Android hardware, and to blame this for perceived weaknesses in the platform, or to explain away their preference for something else. With several screen sizes, input methods, and UI customizations available, these writers say, Android developers face the insurmountable obstacle of rewriting their code for each new device running the OS.
Take, for example, Crunchgear's John Biggs, who's entirely typical of the tech pundit conventional wisdom. In a post on the size of Apple's App Store, he claims:
In Android's case you have multiple "branches" of the OS for multiple devices. HTC and Motorola have their own UI tweaks and these branches for programmers to recompile for multiple devices. This, obviously, is a big issue for mom and pop shops run by a few developers and even worse for the 14-year-olds out there building apps in their basements.Yeah, all that recompiling would be a real hassle--if it were true. It's not, any more than I have to get a special version of every Windows program to work with my specific model Thinkpad. In fact, the "fragmentation" claim is a myth, and one that's frankly idiotic if you think about it at all. To understand why, let's take a detour into programming metaphor.
As much as anything else, programming is based on metaphors of nested abstractions. Take your browser, for example. The programmers of Firefox don't have to write code that manually changes the electrical current in your network cable or wireless card. Instead, they can take advantage of the layers in the TCP/IP stack and write at a higher level of abstraction--using concepts like packets and ports. Even better, if you're writing a Firefox plugin, you can build on their work at a higher level of abstraction: HTTP page requests. These high-level program calls get translated down through the layers until, eventually, some code somewhere takes care of the actual electrical signaling. But for the programmer, all that is abstracted away. Abstraction is the miracle that makes increasingly complex software development possible.
Programming for Android is no different. In fact, abstraction is a major feature of the platform. Almost all Android software is written in Java (which was originally pitched to programmers as a highly-abstracted, cross-platform language) and compiled to a virtual machine instead directly to ARM code. That's why you can actually run Android applications on Ubuntu without recompilation. Technically, they're hardware-independent by design (the downside being that execution speed--until Google adds Just-In-Time compilation to the Dalvik VM--is relatively sluggish).
Even when it comes to interacting with hardware like the screen or input devices, Android provides libraries and abstractions to handle this kind of thing. One platform has a trackball while another has a d-pad? To an Android program, they both look like identical directional commands. Different screen sizes? There's no need to recompile: programs just ask for a resolution and adjust to fit, or use the platform's excellent XML-based layout kit and let the OS scale UI elements to fit ("wrap_content" and "fill_parent" attributes, combined with a RelativeLayout, can do impressive things). Again, this isn't a new idea. Hardware abstraction layers and flexible layout tools are a given on every modern OS--you didn't think developers wrote windowing and display code all over again for every video card on the market, did you? Of course not.
I'm no big-time developer on par with something like Twidroid or ShopSavvy, but I've had no reports that Underground is having problems running on different Android devices. And I'm not aware of any developer who's complaining about having to compile a completely new build in order to run on new Android devices. They may be fixing isolated problems (cameras in particular can be tricky), or adding code to take full advantage of features like the Motorola Droid's high-res screen. But for 99% of applications, and 99% of developers, it doesn't even enter the picture. Given the design of Android's abstraction layer, the fragmentation myth makes no sense at all. There's no evidence for it. It's literally something that the pundit community just invented out of thin air.
The irony of this myth, of course, is in the rhetorical strategy behind its deployment. When Biggs and his fellow tech pundits typically evoke the "fragmentation" of Android, it's usually in contrast to development for the iPhone, which supposedly has only one hardware configuration to target. Nothing could be further from the truth: after all, the iPod Touch (which accesses the same software as the iPhones) does not have a camera or GPS (the original iPhone also lacked GPS functionality). The iPhone 3GS exposes several hardware features missing from the other models, including video recording, digital compass, MMS, and better 3D hardware. And among the entire range of products connected to Apple's application store, there are at least three variations in CPU speed and architecture.
The iPhone is hardly unified--indeed, it's split by the most of the same distinctions bemoaned on Android, and they're solved by developers in exactly the same way: a robust hardware abstraction layer and careful, defensive programming. To claim fragmentation in either case would be absurd. But for the tech punditry to make that cognitive leap, they'd have to know what they were talking about. If the current state of affairs is any indication, there's little chance of that happening.
Update: In a hilarious coda to this, one of Wired's front-page articles this morning is "Android's Rapid Growth Has Some Developers Worried." "Some" developers, apparently, means three people from two companies, one of which explains in comments that he was misquoted and that "I honestly haven't had a lot of trouble with the fragmentation issue on Android, apart from some differences in the way Android 2.0 handles font sizes vs. earlier versions."
Tech writers: hacks, plain and simple.
I'm not a fan of centralized software distribution in general, but I have to admit that I've grown to enjoy checking on the most recent additions to the Android Market. I'm probably not going to install anything I find there, but it's neat to see what people are working on. Too many days, however, browsing through the "just in" section requires scrolling past screen upon screen of cookie-cutter entries churned out by application mills somewhere: a thousand local TV station website wrappers, ringtones and contact images, individual calculators for obscure engineering functions, keyboard skins, and vast other numbers of useless pseudo-programs.
Indeed, most of these aren't even really "applications" as you'd normally think of them. They're content, or content wrappers. But thanks to the new "mobile app" model, the confusion between program and data is growing. It's hard to imagine that this is a good thing.
But first, some context: sometime between the first and second World Wars, a mathematician named Alan Turing came up with a fairly interesting idea: if you had a machine that read in a string of inputs from a tape, and acted on them in series, you could perform complex mathematical operations mechanically. More importantly, you could build a machine that (if it were first given a set of action codes) would emulate other computing machines. He called this the Universal Turing Machine, and it was kind of a big deal. In gratitude, the British government had him chemically castrated to "treat" his homosexuality, and eventually drove him to suicide. It's not one of the proudest moments in history for Britain, computer science, or humanity in general.
To this day, when discussing programming languages, we say that they are "Turing-complete"--that they're capable of simulating a Universal Turing Machine, and in turn, any other Turing-complete language. Which is pretty cool: if you've ever used an emulator, you've seen a demonstration of a UTM at work. Effectively, it turns a computer from something like a calculator, where its functions are essentially mechanical operations, into something more like a box of Legos: an infinitely-adaptable, reconfigurable toolkit for doing mental work.
Which brings us back to the mobile app store model. In this case, the platform is still a UTM--you can still write emulators and multi-purpose programs for Android--but it's being presented to the user as single-purpose. Applications work in their own little silos, and content is distributed as if it were code, even if there's no technical reason why it has to work this way.
Take, for example, Snaptic's AK Notepad, one of the most popular notepad applications on Android. Desktop users could be forgiven for thinking that a "notepad" is an editor for text files, but AK Notepad is not (it does support a clumsy import-export process, but I can't imagine using it regularly). Instead, it keeps its notes in a proprietary database that no other application can access. Want to switch to another, better tool for jotting down your grocery list (or another, more involved project)? Good luck with that.
And then there are, of course, the multitude of web-site wrappers, like those local news "applications" that have flooded the market. They're nothing but a WebView with a preset URL. They're bookmarks. And in doing so, they've taken a real UTM-type application (the browser) and turned it into a single-purpose tool. It's the equivalent of asking you to download a complete version of Firefox just for a single website. The same logic is at work for the e-book applications, which pack their own reader software for each title--here, at least, the existence of prior standards and alternate distribution portals means that standalone reader software has a chance.
I bring this up not just because it's kind of a shame from a net-neutrality, open-platform, generative-computing standpoint, but also because I feel like it robs people of one of the joys of computing: the feeling that the software is a toolkit, to be applied to any given wad of data depending on the task at hand. One program may be better at text display, another better at formatting, and yet another may provide a no-distraction writing environment. With code and content separate, you can use whichever is best for the current task, and you're not locked into a single tool. The new mobile paradigm fuses the two into a single conceptual blob, and any task becomes limited by a single piece of software. It seems like a tremendous step back for computing.
Or maybe I'm just cranky from the flu, and annoyed to find myself staring at a spammy directory of Fox affiliate stations across the entire midwest where I expected some kind of software. It's hard to say.
Last week, Google sent a cease-and-desist letter to Cyanogen Mod, one of the rebuilt ROM images available for Android phones. Cyanogen was designed to be faster and more stable than the prebuilt images, and incorporated features like SD card partitions and new process schedulers to make that happen. Several of the project's innovations have even made it back into the main Android code. But Cyanogen also distributed closed-source applications like Google Maps in the ROM, so Google has effectively shut it down until the authors can work on a solution.
It's depressing, but Google is legally in the right, and their actions may even have side-benefits for the community (like an uptick in interest for alternative applications). Be that as it may, it's also illustrative of a real advantage that's keeping me on Android for now: the juvenile, terrifying, but ultimately beneficial presence of the XDA Developers board where Cyanogen got its start.
XDA got its start as a modding board for older Windows Mobile phones. The way the ecosystem is set up, it's up to hardware manufacturers to determine whether or not older devices get an upgrade when Microsoft releases a new version of Windows Mobile. Sometimes they do, most of the time they don't, mainly because the upgrade would require a ton of testing for not a lot of profit. XDA sprung up to fill that gap--they dump the ROMs of newer devices, wedge the new software into "cooked" images, and figure out how to get them onto older phones. HTC, the primary manufacturer of Windows Mobile devices and of the original XDA, takes a benevolent view of all this.
Contrast that with, say, Nokia. I think Nokia is awesome, and their phones are fantastic. If their devices were "future-proofed" in the same way, I'd still be using a Nokia now. But the Finnish company is not nearly so tolerant of the homebrew underground--they'd rather sell you a new phone. So when they come out with a new version of S60 that does something important, like upgrading the web browser core, they don't make it available on older phones. And because Nokia keeps much stricter control of the firmware update process, the community can't do it for them. The result (ironic for a company that's proud of its green image) is that consumers who want new features have to buy all-new phones.
So while it is unfortunate that Android homebrew is suffering a legal setback, it's also a reminder of how much these developers contribute to the ecosystem--perhaps not in a front-facing, consumer-accessible sort of way, but as a push for the platform to remain open, hackable, and sustainable. Most consumers probably don't notice that kind of thing, or even know that it exists, but I think it's ultimately a win for them--if only because it keeps developers, who are huge nerds, excited about the platform. It's certainly held my attention.
The default Android homescreen is a generally pleasant piece of software. It's easy to rearrange, hosts widgets for quick access to information, and has a fun parallax effect when you pan between "desktops." Add a handpainted Legend of Zelda wallpaper, and you've got yourself a classy launcher.
That said, I have two minor issues with it. First, if it's killed by the system (say, because the browser is hogging all the RAM), it can take a few seconds to restart itself. Second, it clears the activity stack when you load it, so the Back button becomes useless for multitasking. The Activity Stack/Back button combo is one of the best things about Android: together with the pull-down notification bar and the powerful Intent system, it lets users address incoming events without losing their place. Take, for example, this typical activity path:
A better way would be if there were a way to augment the Home button as a kind of "quick launch" key, one that doesn't destroy the Activity stack. That's what my first Android program, Underground, does. It's not a full Home screen replacement, but a color-coded list of your favorite applications triggered by the Home button for fast, effortless multitasking. Think of it as a subway system for your phone.
I'll be putting it in the Android Market in the next day or so, but in the meantime you can grab the installation package here (don't forget to enable "Unknown sources" in the "Applications" section of your device settings). It's small: less than 50KB when installed. I'm also making the source available, in case anyone feels like tweaking it.
After installation, there won't be an icon in the application drawer. Instead, press the Home key. Android should ask what program you want to use to respond to the event, Home or Underground. Choose Underground to start using it. I also recommend clicking the checkbox to use Underground by default--don't worry, you can still get to the old Home screen, and you can always reset this in the "Manage Applications" section of your device settings.
When you start it for the first time, Underground has three items onscreen: a sample link to the web browser, "add new," and "home." You can choose "home," or press the hardware Home key again, to return to the default Home screen. To put your own favorite applications on the list, choose "add new" and pick one from the list (be patient: it takes a few seconds to find them all the first time). You can also long-press on a list item to change its tag color or to remove it from the list. Most importantly, just tap on an application's name to switch to that activity--Underground will quietly remove itself from the stack, so that the Back button will return you directly to your previous task.
That's all there is! Simple, fast, and effective multitasking in a memory-conscious package, without removing what was already great about Android's Home. I'm not much of a designer, so I've left it pretty simple: bold colors, nice big fonts, and liberal use of the platform's long-press interaction model. But that doesn't mean it couldn't stand some improvement: feel free to leave feedback here in the comments.
Notes on Programming for Android
It's extraordinarily impressive how easy this project was. Granted, it's a Java API, and after a couple of years in dynamic languages it feels like a real regression to go back to strict static typing, no first-class functions, and a million subclasses. And of course, it's not like this was an incredibly ambitious project. But for all that, Google has made working on Android about as simple as it could be. I've particularly grown fond of the XML-based layout tool and the package resource system, which makes it easy to build little chunks of UI (like tagged list cells) and pass them in to the view builders. If only S60 had been this easy!
And of course, it says a great deal about the openness of the platform they've built that I can literally take over from the preinstalled program manager (and that I was able to refer to its source code when I got stuck on a few tricky bits). All in all, it was a great experience, and I'm looking forward to working on a few more Android projects when I get the chance. Suggestions?