Archive for March, 2012

A slight makeover for KeepScore

Recently I went to the trouble of de-uglifying the “Load Games” screen for KeepScore. The whole screen is just one big ListView, so taking a cue from my own recent post, I added some fast scroll sections divided by date. I think the effect is more pleasing to the eye, and it also makes it easier to navigate through your past games.

The old version of the UI is on the left, and the new one is on the right:

There. Isn’t that much nicer? The important information (i.e. the player names) pops right out, whereas the other stuff is banished to a light gray subtitle. The icons to the left give the user the feeling that each row refers to some tangible object, saved somewhere, and the checkmarks on the right are useful for doing bulk-delete operations.

Here are some more screenshots:

I’m especially proud of the little row of buttons there at the bottom. They pop up when any boxes are checked, and gracefully recede when the boxes are unchecked, similar to the Gmail app. It was really tough to get them to actually hover over the ListView as they animate upwards, and then have the ListView concede screen space once the animation is complete. I report with some satisfaction that even the Gmail app (version 2.3.5.2) doesn’t do this – when the animation starts, the ListView jumps upward, leaving an awkward little white space for the buttons to pop over.

Awkward white space in Gmail

No awkward space in KeepScore

Overall, the new UI is cleaner, prettier, and more usable. And the code is open source for anyone who wants to borrow it.

Spruce up your ListView by dividing it into sections

If there’s one piece of the core Android framework that every Android dev struggles with, it’s ListView. ListView is incredibly flexible and complex, and you’ll probably find you need it more than once in any decent-sized app. If you haven’t already slammed your keyboard and screamed at ListView before, you probably haven’t been writing Android apps very long. It’s so important, Google even had a whole session about it at their I/O conference in 2010.

ListView is the crucible, the teeth-cutting, the rite of passage for all aspiring Androidians. It’s like Luke seeing Darth Vader in the cave on Dagobah. Once you’ve battled with ListView and emerged from the cave victorious, you’ll know you’re a true Android developer.

This is just one story about ListView.

When I was writing Pokédroid, I came across an interesting problem. The first screen of the app was just a huge list of creatures, but it was too difficult to navigate through. Depending on what game you had, you were only interested in the ones numbered 1-151 (first generation), 152-251 (second gen), 252-386 (third gen), 387-493 (fourth gen), or 494-649 (fifth gen). This meant that the newer (and therefore more interesting) Pokémon were at the bottom, where they were hard to get at. But assuming the National Pokédex numbering, this was just the proper order.

Problem: there were too many goddamn Pokémon.

Too goddamn many.

The solution I came up with was to make the list more navigable by showing “fast scroll” overlays with the names of the various Pokémon generations. Named after the games’ regions, they go “Kanto,” “Johto,” “Hoenn,” etc. That way, the user could immediately know what section of the list they were in, and they could quickly scroll between sections.

Lots of Android apps do a similar thing. The Contacts and Music apps, for instance, show overlays to let you know which part of the alphabet you’re on:

This is made possible by the use of the “fast scroll thumb,” i.e the little grooved square to the right. It allows you to zoom through your list contents and hone in on the item you want. It’s like blasting down the highway and watching the exit signs, versus crawling down a suburban street, inspecting each house number one-by-one. It’s a much better user experience.

So the fast scroll thumb is awesome. And to use it, all you have to do is add fastScrollEnabled=”true” to your ListView’s XML. The only catch? If you want to use it for anything other than alphabetical sorting, your section overlays are going to look like this:

Bleccch.

Yup, the overlay has a fixed width, so you can only really use it for single characters. What’s a poor Android developer to do?

As it turns out, the only way to fix this problem is to implement your own version of the Contacts app’s internal FastScrollView and hack it yourself. I wasn’t the first to discover this, but I did post some snippets of the solution to Stack Overflow back when I first implemented it in Pokédroid. Since then, I’ve been getting some questions and clarification requests on the original post, so I decided to go ahead and write a full demo app to show how it works. After all, Pokédroid is and will probably always remain closed-source, but this code at least is probably worth sharing.

The demo app is on GitHub. Since Pokémon is kind of an esoteric subject, I decided to go with the topic of countries and continents instead. In this example, we’ve got a big list of countries, sorted either by continent or by country name. When you use continent-sorting, you can see overlays of the continents:

…and when you sort by the country name, you see alphabetic overlays instead:

Of course, if you wanted to get really fancy, you could vary the width of the overlay based on what kind of sorting you’re using. But it should be clear enough how to do that from the source code. In any case, with Pokédroid, I had a handful of different sorting mechanisms, but the most common ones had rather long titles, so I just kept the width the same for all of them. In the end, it looked like this:

That’s Pokémon sorted by generation, type, and base HP. The possibilities are pretty endless. You can take your ListView and sort it, divide it, slice-n-dice it however you want.

The important thing is that “fast scroll” sections make for a better user experience. ListViews can hold a lot of data, but that doesn’t mean you should let your list get bloated and then leave all the hard scrolling up to the user. I have an app on my phone where the developer uses an unsectioned ListView with over 200 items. Two hundred! It takes almost five seconds just to scroll from top to bottom! That may not sound like much, but in the UI world, five seconds is an eternity.

Just imagine your poor users, holding their phone in one hand and flipping your ListView with the other hand, over and over again, like they’re trying to light a wet match. Then reflect on how much you could improve that experience with some fast scroll sections.

Well, ListView-abusing Android developers (you know who you are): now you have no excuse. The CustomFastScrollView code is public and open-source, so go use it. Get cracking!

App Tracker and Chord Reader go open-source

I recently open-sourced two of my Android apps – App Tracker and Chord Reader. You can find the code on GitHub.

I open-sourced them for very different reasons, although the catalyzing events were similar. In both cases, I had a request from a fellow dev for more information about the app, which made me question why I was keeping it closed-source in the first place. And in both cases, I couldn’t find a good reason to keep the code private.

App Tracker

But in a broader sense, the two apps mean very different things to me. App Tracker was a project that I poured a lot of effort into, but which turned into an unmitigated failure, with only 294 active users (and less than 4,000 downloads) after almost two years on the Android Market. It’s kind of embarrassing to admit now, but at the time I was writing it, I actually thought App Tracker would be my ticket into doing freelance app development as a full-time gig – hence the laughable premium version. Ultimately, though, the app suffered from bad design and bad marketing (can you guess what it does from the name and icon?), and it never really took off. So in this case, opening up the source means acknowledging my failure and cutting my losses. It’s a humbling moment.

Chord Reader

Chord Reader, on the other hand, was an app that I barely put any effort into, and against my expectations became pretty successful, with over 35,000 downloads (and 10,000 active users) after about a year. It’s even made me a modest amount of money from the AdMob campaign (about $100), although I put in the ads more out of curiosity than anything. I never really found the time or interest to keep maintaining this app, though, so it ended up becoming something of a neglected stepchild to me. There were lots of requests for new features (autoscroll, set lists, bluetooth integration), but for some reason I just couldn’t muster up the enthusiasm to implement them. So in this case, opening up the source means releasing my app to the community, where hopefully it will find more dedicated contributors. It also means getting rid of the ads (since there’s no point in having ads in an open-source app), which I’m actually relieved to do, because they weren’t making me enough money to justify uglifying up the UI.

Of course, a lot of code gets open-sourced, and a lot of it gets lost in the abyss of endless cyberspace. There’s no point in making a big show about releasing this code without explaining a bit about why anyone should bother looking at it. So here’s my brief run-down:

App Tracker reads the system logs (“logcat”) in a background Service and notes when other apps are being launched, which allows it to keep usage statistics. It should be interesting for anyone looking to write an app to detect when a third-party app has been started (which was the question from a fellow dev that prompted me to open-source it). For instance, all of the various “protect my apps with a password” security apps use this technique. Be forewarned, though: these methods are faulty, given that the Android OS treats with suspicion any Service that tries to run 24/7, and may kill your Service without warning.

Chord Reader reads chord charts downloaded from sites like AZChords.com and UltimateGuitar.com, parses the text, and displays information about the chords, including various guitar fingerings. The most interesting part is the system of regexes (really, a grammar) to parse the chords and determine, for instance, that “Abmaj7” and “G#M7” both mean the same thing: “A-flat, major quality, 7th added.” A good place to see this in action is the unit tests. Music geeks should get a kick out of it. And of course, anyone who just wants to contribute to the project (like the dev who first contacted me and suggested open-sourcing it) is welcome to create branches and pull requests on GitHub.

Oh, and in case I haven’t made it clear elsewhere, when I open-source something on GitHub, please assume that the license is the WTFPL license, or some other very permissive open-source license. I honestly don’t care what you do with the code, although hopefully you’ll be nice about it and give me credit. Happy coding!