Best Practices for Releasing Android App Updates

07.05.11Posted by in Android0 Comments       

Since the Android version of Pulse was released in July of last year, we’ve released 40 some updates. Here are some of the basic and more advanced best practices that we’ve accumulated:

The Basics

To publish an update, you must sign it with the same private key you used when you initially published the app. After you publish the initial version, back up your key and make sure you don’t forget the keystore password, otherwise your app will be un-updateable.  You’ll have to change the package name and publish as a separate app, but if you have any users, this is really a bad situation to be in. Make sure to back up your keystore!

In general, you want to test the new version on a variety of devices with different screen sizes and running different versions of Android. Building a community of beta-testers can be a great way to get some feedback and testing on a bunch of devices.

Testing Upgrades

Make sure to test various upgrade combinations. For example if you’re going to be releasing version 2.0, test upgrades from the last few versions (1.7 → 2.0, 1.8 → 2.0, 1.9 → 2.0) because a lot of users don’t install updates immediately after they are published.  To facilitate upgrade testing, you can keep an internal-only Dropbox folder with all the previous Market versions, and upload a new one when you have an updated version of the app.

When you have a previous version running on your device, add a few widgets (if your app has them) and shortcuts to the home screen, and make sure they stick around and keep working after upgrades. Double-check that you are not changing any of the things that cannot change. Also make sure user settings are persisted through upgrades.

Another thing to watch out for when upgrading is database changes. If you use the standard SQLite database, make sure your onUpdate method handles upgrading your database appropriately.  If you have any tutorials when the app first opens, check that the messaging is appropriate for upgrades as well as new installs. Someone who has been using your app for a year shouldn’t get a welcome message or another walkthrough of how your app works.

By accessing the version name (use PackageManager to get the the app’s PackageInfo which includes version name) and saving the current version name somewhere like SharedPrefs, you can easily figure out whether it’s a new install or upgrade or same version, and handle messaging or anything else appropriately.

Communication with Users

The changelog is the main place where you can communicate with users about changes in the recent version. Even if it’s a small update with trivial bug fixes, you definitely need to put something in the changelog. If you forget to add messaging in the changelog, many Android users will give you 1-star reviews if you have an empty changelog, and then after you do update the changelog, Android Market can take up to a few hours to persist those changes.

We tend to keep change history around for the last few updates, since not all users are on the current version.

Post-Publication

Even if you’ve done your best right up until you click “Publish,” bugs will probably show up in production. For the next few days, keep an eye on crash reports through the Android Developer dashboard, and be ready to release a quick fix release if anything urgent comes up.  For whichever version control system you use, always keep a branch synced to the latest published version, so if there are any crash reports or email feedback that require quick fixes, you won’t be introducing any new bugs into the app.

If you’ve found any other useful guidelines or tips for releasing updates, we’d love to hear them!

5 Tips for Honeycomb Design

06.21.11Posted by in Android1 Comment       

The explosion of Android-powered devices has been a boon and a burden to Android app makers. An application’s potential reach has never been so vast, yet the diversity of hardware can throw designers/developers for a loop. Today, we’ll talk about how to design an application that takes advantage of all the slick new Honeycomb tablets (present and future) so your app can shine in all sizes!

 

1. Modular components make full use of screen real estate

Compared to phones, the amount of space available on tablets can be confounding – how on earth can you fill up all those pixels?! One thing you absolutely should not do is blindly scale up a design meant for a phone. It’s hard to envision something looking sillier than a 10” list view.

Please don't do this

Luckily there are several ways to tackle this issue, one of them is the concept of Fragments introduced in Honeycomb. Fragments are UI components that are meant to be modular and dynamic. The clearest example of this is in the official GMail app. On the phone, the user can view a list of all emails, which takes up the entire screen. Selecting an email will proceed to another screen showing the email conversation itself.

With the fragments, these list and email can appear side-by-side, allowing a user can view an email while gaining the additional context of their entire inbox.

 

2. Use dialogs

Sometimes it simply doesn’t make sense for a view to take up an entire screen. For situations like these, dialogs are quite handy. In Pulse, we enable users to connect with social networks when they wish to share stories – all of which require a login screen. On the phones, login utilizes the full window, but on a tablet such a view would be visually offensive. Dialogs provide an easy way to show these smaller components in a more natural manner.

 

3. Utilize 9 patches creatively

Unpredictable screen dimensions create some interesting challenges for the visual designer. Being pixel-perfect is possible, but not without some ingenuity. 9-patch image files allow you to determine how images get stretched when resized, which happens quite often when using relative layouts.

In the tutorial for saving stories with Pulse.Me, we use an arrow that points from the star button to the “.me” button. With the magic of 9-patches this arrow behaves correctly on all screen sizes and orientations.

 

4. Design for both landscape and portrait

Never assume a user will only use the app in one orientation. People have wildly different (and very strong) opinions on proper tablet usage and your app must accommodate both. In landscape mode, the wide screen makes horizontal layouts more natural. Avoid stretching things out to span the entire width unless absolutely necessary, otherwise you’ll most likely end up with a lot of blank space.

 

5. Remember the Honeycomb UI conventions

There are several UI patterns for Android tablet apps that users have come to expect from all applications. The first is the lack of a menu button. While users may have overlooked menu buttons on phones, they’re completely MIA in Honeycomb. In their place, the concept of an Action Bar governs what the user expects to be possible on a particular screen.

Even if you don’t explicitly use the Action Bar classes in the Android SDK, rolling your own is a good idea to fit the expectations of Honeycomb users. In general, the top left is reserved for going back to a previous screen, with the rest of the bar containing other actions. By following this pattern, a user will never feel lost or confused when using your application.

Now that you’re newly equipped with these tips, start creating compelling, beautiful apps!

We are hiring! Check out our current openings - we would love to hear from you!

Categories