I just finished my first Android app, Locale Music Plugin. I don’t expect to do much more mobile development, nor do I have any breakthrough ideas or conclusions, but it was a fun little side project, and I collected a few thoughts along the way.
First, the good. Android didn’t invent online app stores or self service publishing, but it does them well. I’m excited that I can consume and publish software (and media!) immediately, friction-free, anywhere and any time. Policy questions notwithstanding. I’m also happy I was alive beforehand, so I know how it used to work and why I should be thankful.
Android is a great example of the software-ization of our lives. For many of us, our smart phone is a personal utility belt, a daily magic wand. Much has been made of this, but for people who write code, it’s a Good Thing. One of the benefits espoused by the open source movement is scratching your own itch. As software reaches into more parts of our daily lives, we’re able to scratch more and more itches. That’s great for us hackers, and when we give that code back – even if we charge for it – it’s good for other people too.
I was also pleasantly surprised by the development tools. Android is a big platform with a big developer surface area: OS, SDK, APIs, new conceptual models, emulators and on-device debugging, packaging, online store and services, miscellaneous hardware inputs and outputs, and a multitude of devices. I didn’t try out everything, but I did use the core toolchain from end to end, and it was smooth and solid.
Naturally, though, it wasn’t all rainbows and ponies. A couple aspects struck me as particularly exciting, but when I pushed, I found them unfinished, all the more disappointing for showing me what could have been…but wasn’t.
First, modularity and reuse. Android apps are composed of activities, which can be reused by other apps via intents. Like so many frameworks before, this is intended to allow interoperability, expecially between apps that may not know anything about each other.
I like this. The catch is that designing for reuse, Steve Yegge style, takes time and effort, so most Android apps don’t. Unfortunately, the platform requires you to build on mechanisms that do allow reuse by default, which means many apps can be reused even though they never intended to and don’t support it well. In my case, the offending app was Google Music, but it’s just an example.
Second, storage and UI. I love that the primary storage is a relational database, WinFS style, instead of a filesystem. I was even more excited to find UI widgets that connect to it automatically. Just hook up the columns and presto, instant UI, no code necessary! Sadly, out of the dozens of built-in UI elements, only three do this. Why oh why didn’t they follow through on this wonderful idea? Hat tip to Kevin Gibbs and others for noticing this well before me.
Regardless, the good outweighed the bad. I had the full experience, even if it wasn’t a deep dive, and I enjoyed it. Thanks for a great platform, Android team!
re: binding ui to data … crazy, that’s what held me up for a few days.
also, side projects are awesome!
Cool! Did you test out the Locale integration with Tasker as well?
via plus.google.com
hmm! i didn’t, but i should. thanks for the nudge!
via plus.google.com
It should “just work” but worth a shot. Tasker also has a free APK download for testing which is nice when you’re using the emulator.
via plus.google.com
i just published another app, Locale Headphone Buttons Plugin, which simulates pressing a headphone or headset button. i use it to automatically restart whatever was playing last when I plug in my headphones. much nicer than pressing power, unlocking the screen, navigating through the player app, and pressing play again!
Cool post!
I think it’s interesting to think about the fact that when I’m working with a UI framework, I want it to be even more opinionated than other things I’m working with. One way of thinking about this is that given that a UI framework is fundamentally completely flexible (since you can ultimately just manipulate pixels and a tight loop to accomplish anything you might want), there’s by definition an unlimited number of ways to do anything. But there are probably a few ways which pay off in the long term if you follow some standard model, due to the utilities others have built when they’ve navigated this open forest in the past. And thus, my desire to do things the “right” way is the highest with UI frameworks, versus, say, working with Python code or writing a Java web app: I want the path through the forest with the most rest stops.
From your (and my) experience with Android, it seems like the “path of greatest encouragement” for UI development on Android, i.e. the most opinionated way of doing things, is both not documented clearly enough, and has not been enhanced or improved enough.
(Then again, I’m not an Android expert– there could be many things I’m missing.)
via plus.google.com
interesting point! i definitely agree. i wonder if that just shows that we’re not UI designers, and we’re happy to defer to their accepted wisdom. if someone expected us to use highly opinionated tools for writing infrastructure and backends, we might balk. then again, that is kind of what we did with app engine, so maybe we wouldn’t.
btw, i just published another app, http://snarfed.org/locale_headphone_buttons_plugin, which simulates pressing a headphone or headset button. i use it to automatically restart whatever was playing last when I plug in my headphones. much nicer than pressing power, unlocking the screen, navigating through the player app, and pressing play again!
via plus.google.com
Very cool write-up, thanks for sharing! My experience with Android coming from the RoR world is that the toolchain is good and shares some similarities with web frameworks such as RoR.
I will have to try your app soon with my newly upgraded Verizon Droid!
+1ed this.
via plus.google.com