Here’s the first demo of a very cool shirt that’s connected to an app on my Android device (source code and plans will be released soon!).
The Challenge: Build and release an app that required less than 12 hours of work.
The Result: NYC Subway Status for Android
I’ve been beating the drum lately on the need to build things very quickly. I’ve found that despite loads of thinking and planning, often you don’t discover most of the real problems with your idea until you’re knee deep in development. Building something in a brief time period is meant to short circuit the process and avoid analysis paralysis.
Working this way, though, can be very stressful. You’re having to cut corners, to make compromises, and to eliminate functionality in order to meet your deadline. However, working like this also forces you to simplify your ideas and focus on the core user experience which can lead to a simpler, more refined final product. Sometimes it’s better to do one feature well than to cram in three or four features.
The result of this latest personal challenge is the NYC Subway Status app for Android. It was built in a few hours and does one thing very well — tells you if the NYC Subway lines are running smoothly, encountering delays, or scheduling maintenance. Here are some screenshots of the app in action.
You can install the app for free just by searching on the Android Market. Alternatively, you can scan in this barcode on your phone.
UPDATE: Version 1.0.3 now released!
So for the past few months, I’ve been working with food writer Michael Ruhlman on the Android adaptation of his cookbook “Ratio”. Well pop some bubbly, cause the app is now live in the Android Market! Search for it on the Android Market or scan this barcode:
One of the speakers was Sarah Kaufman from the MTA, highlighting the hard work they’re doing right now to help bring MTA information and data to the developer community. Check out the MTA data sets currently available including the new GIS information about subway entrances and exits.
Sarah’s talk reminded me of something I’ve been wanting to do for a long time — create a simple calculator to figure out how much money to put on a MetroCard. The MTA vending machines make it easy to put an exact dollar amount on a card, but it doesn’t make it easy to figure out how to add 4 rides or 8 rides to a card. It’s not a hard problem, so I took 30 minutes last night and made a simple web page that figures this out for you. It should work on iPhone and Android, so check it out.
Finally, I should add that I made this in 30 minutes, so it’s probably got bugs, but who cares? It’s usable. It’s a released product. It’s more important to get something out there and get feedback than to linger in development forever trying to make it “perfect”. Let me know what you think.
Yesterday I was riding the subway in NYC and saw something I had never seen before — a print advertisement for Google maps.
In true Google fashion it was a simple ad with a clear message saying you could use Google Maps on your phone. BUT THERE WAS NO QR CODE. C’mon Google, you clearly missed an opportunity here to show people the power of bar codes and you just dropped the ball entirely. There are so many other aspects of your business that are promoting bar codes — the launch of Android and the G1, your own open source bar code reader, and your in depth education about bar codes when trying to sell print advertisement.
Yet when you’ve finally given the opportunity to demonstrate the power of bar codes, test them in a public mass market environment and start collecting real data about how people are or are not using them, you just didn’t even take the chance.
I’m really disappointed.
I’ve been dabbling lately with Google’s Android platform for mobile development. While there aren’t any announced devices for the marketplace yet, it’s an extremely open platform, and one of the simplest mobile platforms to develop for that I’ve encountered.
The Android SDK still isn’t “officially” released yet, which means there are lots of undocumented quirks in the system and a few inconsistencies. Some of them you can figure out through trial and error. Some are just annoying. I recently managed to triumph over one of these quirks and thought I would share the fruits of that labor. In this case, it’s specifically how to add a contact, phone and email address into the built-in Address Book using Google’s Contacts ContentProvider.
Let’s start by adding a new person to the address book. Just a name and nothing else.
// create a new name
ContentValues values = new ContentValues();
values.put(Contacts.People.NAME, "Test Name");
// add it to the database
ContentURI newPerson = getContentResolver().insert(Contacts.People.CONTENT_URI, values);
newPerson ContentURI that’s returned by the
insert() call is null if something went wrong. If it’s not null, then it might look something like this
where the number 1 indicates the new ID of the person you just created.
If you don’t get back an ID number, then you can’t proceed, but assuming all went well, then you can use that new ID number to add other information to the existing record. For example, to add a phone number:
// assign the new phone number to the person
values.put(Contacts.Phones.NUMBER, "(800) 466-4411");
// insert the new phone number in the database
and to add an email address:
// assign an email address for this person
// insert the new email address in the database
Adding an email is tricky because it’s doesn’t match the same coding convention as adding a new contact or adding a new phone number. To make matters worse, this mismatch/inconsistency is not documented well in the existing docs, so it required a lot of trial and error to figure out how to do this without causing an internal error in the emulator.
Essentially, the issue is that for contacts and phone numbers you can use a ContentURI like this:
to retrieve existing records or to add new records to the system.
However, for emails this is not the case. For emails, you have to use different URIs for each function, specifically:
retrieve emails –
insert new emails –
where the number 1 is the ID of the person you want to add the emails for.
I’m sure this will become documented more clearly as Android starts reaching a wider developer community. Until then, hopefully these code snippets will save some time for those Android developers struggling to get their apps finished before the March 2nd deadline for Google’s $25,000 Android competition.
Have fun coding.