This week, rather than put someone else under the microscope, I'm going to do an
Android App Surgeryon one of my own apps: Earthquake!
I hope you'll excuse the indulgence, the distinct advantage of reviewing my own application is that I can find and point out some of the things I should be doing differently that are harder to spot without access to the code.
In an effort to see if I practice what I preach, I'll evaluate my own app according to the criteria I set out in my Google I/O presentation on
Android best practices.
The App: Earthquake!
Like most apps based on a data feed, the UI is centered around a
ListView. The main screen is a vertically scrolling list of recent earthquakes each displaying their magnitude, times, and locations. This is enhanced by a map that displays each earthquake's location and which uses shaded circles to indicate the area likely to be affected by each quake.
Sloth and Gluttony
First the good news. All non-trivial processing is done using
ASyncTasks. There are no modal "loading..." dialogs, but incremental refreshes are indicated using the default
indeterminate progress indicator. Changes to the quake list are handled dynamically at runtime with the list updated with new data as it's acquired.
The earthquake feed lookup and parsing is handled within a background Service that
kills itself on completion.
On the flip side, the Service uses the pre-2.0 onStart method rather than onStartCommand (here's how to
support both). Because of this the Service will restart as soon as sufficient resources become available. Instead, onStartCommand should return
START_NOT_STICKY, knowing that the Service will be restarted within a reasonable period of time.
Updates are handled via regular background polling - with battery impact minimized through
setInexactRepeating. There is scope for using
C2DM to replace this polling approach with an event driven update approach.
Hostility and Arrogance
I know several of the engineers working on the Android framework; it didn't take long to decide that second guessing their decisions was likely to have a low ROI. Similarly, watching my friends suggested that some people actually use their phones for making calls and sending SMS message (who knew?!) .
In an effort to make this app seem as native as possible and allow the system to manage as much as possible it:
- Uses the dialog mechanism to display dialogs.
- Application preferences are handled using Preference Screens.
- System icons are used (where possible) for menu items.
- The back button behaves consistently and inline with user expectations.
That said, there are a couple of areas that annoy me as a user:
Discrimination
Arguably this app's biggest sin.
The manifest doesn't declare a
target SDK, nor does it explicitly declare which
screen sizes are supported. As a result it's unavailable to users of small screens (such as HTC Wildfire and Sony Ericsson X10 mini/pro users). Worse, it doesn't
include assets for low or high resolution displays.
There's no internationalization support, which isn't great, what's worse is that I've gotten lazy with
externalizing the strings. About half are defined in XML, the rest are string literals. There's no excuse for that.
The manifest doesn't
declare which
hardware features are mandatory, or which are used but optional. It uses (but doesn't require) both Location-based services and the vibrator, so to ensure it's available on the
largest subset of devices both should be specified as optional in uses-feature nodes.
Beauty and User Experience
I am not a designer. If I were serious about turning this app into something I could charge for, I'd do well to seek out someone with skillz.
Even so, there's some simple improvements that would help:
- The map is probably its most appealing aspect so it makes sense to make this more obvious. ATab Layout might be a better option, together with the ability to horizontally swipe between views similar to the Calendar or News and Weather apps.
- The list view lacks "sparkle" - replacing the standard header bar with something that includes the logo might improve this, as would a dynamic background for each quake. A LevelListDrawablethat adjusts the background based on the magnitude of each quake would be simple to achieve.
- Long-pressing earthquakes should display a context menu that provides a wider range of alternative actions: such as viewing quake details (via a dialog or USGS.com), sharing a quake, or 'pinning' it to prevent it from being removed when it falls out of the 24 hour feed.
- The map display has some unnecessary padding around the edges, and the quality of the map markers needs to be improved. Clicking on a quake marker should display an info window with actions (show details, etc.).
Generosity and Ubiquity
The app includes a
Widget and a
Live Folder for the home-screen, and it uses
Notifications to announce new quakes.
Search integration is missing though. Given that the quakes are stored in a Content Provider, it would be relatively simple to include it, both within the app and surfaced to the Quick Search Box.
It's worth considering using the
send intent to let users share quake details with friends using other apps like email, SMS, Twitter, Facebook, etc.
Similarly, Earthquake doesn't expose and data or
Intent Receivers, nor does it leverage Intents available from other apps. It might be worth exposing an Intent Receiver to allow other apps to show the earthquakes at a given location, or even plot the size of an earthquake on the map.
Utility
The utility of this app is likely to be in direct proportion with your distance from a significant fault line. If knowing when and where earthquake strike is useful to you, then so is this app.
Epicness
Epic is a high bar to aspire to, it's fair to say that this app does not reach such lofty heights.
Imagine your app was written by a competitor - what would you do to steal their users?
App developers take note: the easiest way to improve your app is to apply a critical and objective eye to it. I'm going to leave Earthquake as it is for a couple of weeks so that you can evaluate the app based on this review. I'll then look to implement the improvements I've suggested here.
). Up to this point, the students have already modeled over 130 buildings in the city!
