Hitting the Road

The new Android Market is surprisingly mercenary.  In order to be an official developer, you just need to pay a one-time fee of $25.

I'm not sure how I feel about this.  On the one hand, I tend to enjoy the egalitarian ethos that anyone who writes code is a developer.  One of the few most attractive aspects of the Java ME ecosystem is that anyone can create a JAR and a JAD, throw the up on a webserver, and have people use your stuff.  By setting a barrier to entry in the market, Google seems to risk losing out on some of the messy, fun, seat-of-their-pants programming that often flocks to new platforms.

On the other hand, as a professional mobile developer, I'm used to developer programs with high standards and requirements.  Anyone who wants to distribute BREW apps needs to pay big bucks up front, without any sort of guarantee that the carrier will even permit their applications to be sold, and also pay a fee for every phone for every app that they want to sell.  Similar arrangements are in place for first-tier customers at the major carriers, and in order to have your app strongly visible on the deck, you need to pay big bucks and sacrifice a good chunk of your revenue.  By having a comparatively modest barrier, Google seems to risk letting in the riff-raff.

Altogether, I think it makes sense.  $25 isn't a lot... it's nothing to a company, and the equivalent of a few movie tickets or a really nice meal to a committed individual developer.  It keeps people from spamming the market with "Hello World" applications, giving more visibility to the people who care enough about their apps to make a little sacrifice.

As you've probably gathered by now, I have joined the joyous throng and anteed up.  Earlier this week I uploaded Wheeler, my first public individual submission, under the name of Fifth Column Software.

For those of you who don't already know about it, here's the skinny on Wheeler:
I started work on this a few weeks after the Android Developer Challenge began in November 2007.  It went surprisingly quickly.  I give a lot of the credit to what I've learned in my professional life.  I still remember the projects that I would work on when I was writing in BASIC in elementary school and junior high, which would NEVER END... I started writing something because I thought it was fun, and kept on adding more and more fun things, until it would become so unwieldy that I couldn't stand to do anything more with it.  Now, even for my fun projects, I invest the time up-front to come up with a bulleted feature list, some rough screen sketches, and overall architectural design.  Of course, things aren't set in stone, but I've found that doing this before I start serious coding helps make me brave enough to say "No" to the hundreds of new ideas that will pour in.  I capture the good ones, write them down, and schedule them for Version 2.  And if Version 2 never comes, at least I'll have a complete Version 1, which is more than I used to have for 90% of my projects.

That said, it's critical to have an exploratory phase when kicking off a project, especially when it's on a new platform.  My own experiments and forum-lurking revealed some huge gaps in the early SDK that would make certain things hard or impossible to make.  I expected these to be fixed before shipping, but that still eliminated certain classes of applications from the Challenge.

I've thought for a few years that, if I was a Google engineer, my 20% project would be to create a national Google Maps for bike routes.  Ideally it would work like regular Google Maps, where you could either search an area or ask for directions, but it would show and classify routes appropriately for cyclists.  You'd be able to get directions over trails, see which roads had bike lines or wide shoulders, and what places to avoid.  I thought the challenge would be a great chance to actually make it, and the more I thought about it, the more excited I got about its usefulness as a mobile app.  I could imagine someone taking a week-long touring trip, and when they came across construction they could whip out their Android phone, have it automatically locate them through GPS, then see what safe streets and trails were available nearby to continue their trek.

I learned pretty quickly that, while that kind of information is out there, there's no consistency.  Unlike road information, which is available on a national basis and in data-friendly formats, bike route ratings are variously created and supported by cities, municipalities, volunteer organizations, or individuals; often only exist in printed materials; and have no standards for route ratings.  I flirted with the idea of taking some of the more data-friendly offerings out there and creating a kind of demo application that would do what I wanted, but only be available in a few cities.  I decided against it.  I wanted something that would be widely useful to people across the US or even the world, and wasn't interested in making what was basically a toy - especially since Santa Clara County's own data isn't that great.

But, while poking around for the aborted route mapping idea, I became even more enamored with the possibilities of a always-connected mobile device that could be carried by cyclists.  Honestly, even the iPhone 3G by itself would be useful - just being able to see where you were and what was nearby would be a big improvement over carrying around bulky maps.  And once someone was carrying a phone, you could tailor it to provide them with useful things for their ride.  And once you got them using it during their rides, you could offer more support before and after...

I eventually chose a cluster of features that would offer the biggest usefulness bang for the smallest development time buck.  The centerpiece would show off Google's cool mapping feature.  Customized for cyclists, the map screen would not just show where you were but also track your direction, so on cloudy days you could immediately tell whether you were heading east or west down this particular road.  It would include a timer, similar to what's on a cyclocomputer, so you can keep track of how long your ride has been.  Actually, it would duplicate the features of a cyclocomputer, and add more of its own... why not keep track of how many feet of elevation a rider had climbed?

Since we're collecting all this good data, that opens up some really cool possibilities... well, cool to nerds like myself.  Forget keeping a riding log - the phone remembers everything for you.  You can pull it up and flip through old rides whenever you want, add notes, correct mistakes (like if you forgot to record part of the ride) or add new details (like how windy it was on a particular day).

Let's not forget that we're running on a device with a sweet, big screen, and more CPU power than the computers I learned to program on.  Let's take all that data we have, and add a sweet performance analyzing section!  Draw graphs of your average speed for rides during the past year, or see how many calories you burned during the past month.  Since I'm a liberal Bay Area resident, I also added a feature where you can see how much carbon you have conserved by riding instead of driving a car.

I kept on thinking of more cool stuff, but decided to hold the line there for the initial challenge... it would exercise some of Android's features, and be a complete, hopefully-useful application for people like me.

It came together surprisingly quickly.  I kept running into bugs in the SDK UI, which I dutifully logged and then worked around.  But thanks to my feature plan, I got to a point where everything was working, I was happy with it, and I could focus on debugging it and then say "It is good."  I even had enough time to write an entirely separate application for the contest, though that's another post entirely.

From there on it was mainly a shepherding process.  I upgraded the app from M3 to M5 when the new SDK was released.  I kind of lost interest after the contest was over - with no phones in existence and no additional incentive, I just decided to focus on other things.  But when the G1 came out (and I must admit to being a little surprised that Google really did hit their stated "Second half of 2008" target), I decided to polish the app off again.

Eventually.

Life's been pretty interesting the last few months.

All it took was a weekend, though... a good 48 uninterrupted hours with me, the R1 SDK, and Eclipse.  A good chunk of the time was just making everything compile again.  Google had fixed some bugs, which caused my work-arounds to break, but I'm always happy to take out hacks and do things the official way.  And they had introduced some new bugs, which I dutifully filed and found new work-arounds for.  Ah, the delightful life of the mobile engineer!

The last step was full business.  I took the time to read the disclosures and agreements, and was pretty interested by what I found.  Google does ask for some things that sound kind of scary at first, especially when it comes to payments, but again, compared to most mobile markets out there, it was quite reasonable... and this was pretty much the only one letting individual fishes swim among the schools.

One complaint some major studios have expressed is that the Market currently does not support charging for applications.  This "feature" will be added in the future, but for now, all apps are free.  Personally, selfishly, I don't mind.  I like Wheeler a lot, but I don't see a huge market out there of people looking to spend money on a cycling application for the G1.  I'd much rather 100 people try it and hopefully find it useful, earning me some karma, rather than 10 people buy it and give me a pittance.

That's the end of that chapter.  Not sure yet what the future of Android holds for me... it's been a fun ride so far, and I hope it gets better!