Parentheticals & Excursions

The Android AdapterView classes are very efficiently implemented and provide developers with a solid basis for creating fast, smooth views over arbitrarily large datasets. Their basic APIs have remained stable since Android was introduced and yet, based on the applications I try-out (and even some I use regularly) it seems that developers often make poor use of them.

This is the first of two posts that I’m hoping will improve this situation, by sharing some of the code I’ve developed for my own applications.

Creating smooth Adapters

The performance of an AdapterView is mostly determined by the Adapter you provide it with. There are two core obligations when developing an Adapter that will provide a smooth user experience†:

1. Items must be returned without delay.
2. Views must be returned without delay.

It’s that simple… Except what happens when your items are records that have to be retrieved from a Web server? And, to compound things, what if displaying the record requires downloading a couple of images? These problems can actually be tackled separately. This post provides a base class that helps with 2 (I’ll provide code to help with 1 at a later date).

Complications

What makes 2 complex in this scenario is that there’s no time to do anything other than return a preliminary rendering of the View from the Adapter, so the work to produce a complete rendering of a View must be done on a background thread.

Unfortunately, what makes this still more complex, is that the efficiency of classes like ListView and GridView is only possible because they recycle the Views they use to render items. This complicates the task of asynchronously updating the View because during the interval in which the complete content for the View is being generated, the parent AdapterView may have assigned it another item to display (possibly many times). In this case the existing rendering task should probably be abandoned (it certainly shouldn’t get assigned to the view) and instead a new rendering needs to commence.

Of course, this situation may itself be temporary: A user may briefly scroll an item off-screen and then back again; we don’t want to keep restarting the same rendering task without making any progress. To handle this efficiently caching may be necessary and may need to be combined with partial updates. And, as if things weren’t complex enough, the re-appearing item may be assigned to a different View to the one that initially displayed it (even if its position on-screen does not appear to have changed for the User).

A helpful class

So, yes, there is some complexity around implementing a good Adapter, but many Android developers have had years to get this right! Hopefully this code will help: it handles all of this apparent complexity in what is a fairly simple base class called ViewRenderer.

It’s designed to be invoked within the getView() method of Adapter. In this approach the getView() method should be limited to:

• Obtaining rendering parameters for the specified position (most often this will simply be the adapter item)
• Recycling the old View, or inflating/constructing a new one (but not customizing it for the item)
• Calling the renderView() method of ViewRenderer to perform all subsequent customization of the View.

To make this work, you obviously need to customize the ViewRenderer with your own rendering logic. This is done by implementing the following three methods:

• void prepare(View, Param, int) This method is called on the main application thread before the View is first displayed to the user. It’s your applications opportunity wipe-down the View (since it may have previously presented another adapter item) and display a quick placeholder/loading view.
• Render render(Param, int) This method is called on a background thread and does the slow work (eg. drawing or loading) to convert the item into the resources needed to display it (eg. a Bitmap or POJO).
• void update(View, Render, int) This method is called on the main application thread to apply a new render to a previously prepared View.

And that’s pretty much it, everything is reduced to these three digestible chunks. The int that’s being passed into these methods specifies an optional rendering pass to accommodate progressive rendering. There are a few additional operational aspects that can be controlled: render caching, view tagging, thread priority and execution. Documentation for these and everything else can be found in the source code comments.

ViewRenderer code

The code is amenable to a number of improvements (some possibilities are noted code comments), but I hope it’s useful and results in some smoother Android lists and grids, and here it is:

† Not creating garbage helps too.

I take accessibility very seriously, so I’m really glad that new guidance on accessibility on Android has been made available to developers.

One of the problems with designing accessible applications is that it’s very easy to overlook the needs of users when you don’t share those needs. This is compounded when users have diverse needs which is the case when considering accessibility; the blind or partially sighted have completely different needs from the deaf or those who are hard of hearing.

It also doesn’t help when you make mistakes like this (from my Metaglow app). This all looks okay on the surface (but not especially great): simple layout, Dpad navigable, labelled buttons.

Until I considered the implications of my general design for this activity:

Which I belatedly realized leaves no way of navigating to the tabs at the bottom of the screen, except by touch: with focus falling naturally on the first element in the grid, the user can never move down far enough to reach the tabs because the list of favorites is effectively infinite for UI purposes.

Fixing that mistake involves too much re-work for the first release, so I’ll have to stick with the misdesign for now. Here’s a tip: don’t combine heavily populated AdapterViews with bottom-tabbed activities.

Last night I continued to experiment with using POV-Ray, this time to create some 9-patch button backgrounds for an Android application. Where appropriate, I try to retain the standard Android buttons in an application, so that users have nothing extra to learn. But in this case I want a darker UI to avoid detracting from the application’s content. This is what I ended-up with:

For general purpose use, I think this is the minimum number of button states you need images for:

• Obviously you need a normal unmodified state to display the button.
• You need a pressed state otherwise the user won’t trust that the button is working.
• You must have a focused state because users navigating with a D-Pad or trackball need a visual cue to indicate where focus lies.
• If your button can be disabled you need to clearly communicate it visually so that the user doesn’t waste time, or suffer confusion, clicking on an inactive button.
• Finally, I think you should have a state which is both disabled and focused; users may still need to navigate focus over disabled buttons.

You may need fewer in specific cases, or more, if your buttons are selectable. Either way, you probably have several button images to produce. And though only the colour varies within my button images, one of the advantages of 3D models is that they make it painless to produce multiple versions of an image with slightly different geometry (eg. a button being pressed in/out).

There are some particular issues that arise from the use of rendered images as 9-patches. You want to be able to quickly composite the rendered image with the necessary black border pixels. This means that it’s worth spending time framing the model in the camera just right, so you don’t need to crop or translate the image later. You also need to consider the lighting of your model to ensure that you have somewhere that the 9-patch can be stretched without visibly distorting the shading or texture (my first attempt at brushed metal buttons failed in this way).

All of this is general to creating buttons in 3D. What’s good about POV-Ray is that you can produce ‘inorganic’ geometry very simply and repeatably; its support for #defines and macros means that you can effectively parameterize your scene which comes in very handy when you make a change and need to crank out all of the button images again.

Here’s a complete POV-Ray scene for rendering a simple button image. I’ve supplied some basic comments, but I think it’s short and comprehensible (more so than many of the PSDs I’ve seen).

And here’s the image it produces:

Here’s an android development tip: Instead of spending lots of time creating complicated layouts for your Android applications by piecing together stock layouts, just implement your own layout.

Creating a fully-featured and robust layout is a lot of work, but writing one that works well for just your application can be less work than the alternative. And unless you create a very poor implementation, it will almost certainly perform better than an alternative which nests several layouts in a complicated way. This is because the algorithm that measures views may need to backtrack, and this can become expensive as layouts become deeply nested.

Note that I’m using the word ‘layout’ here to refer to a ViewGroup that does nothing but lay out its children. This is different to a Swing layout, for example, which is not a GUI component in its own right, but instead operates through a container.

I’m posting this now because I have a good example that’s simple enough to share. In an activity that I’m currently implementing, I needed a layout that could rigidly arrange its elements into a square grid (see my previous post for the wireframe). This is impossible to enforce using any of the standard layouts, though it would be possible to mimic the behaviour with some extra messing around.

Instead I implemented my own layout, and here it is in action:

This layout is a good example of a simple layout because the assumptions have been simplified:

• the layout only deals with exact squares (can’t get much simpler than a square grid of squares)
• the layout of the children is kept rigid (exact dimensions are specified - my application need anything else)
• it doesn’t support gravity (it could, but again, my application doesn’t need it)
• it doesn’t care to handle oversized Views that won’t fit the grid (due to the application, I can just guarantee it won’t happen)

Actually implementing a layout comes down to implementing two key methods:

• onMeasure() to compute the size of itself and its children,
• onLayout() to compute the bounds of its children for rendering

This is explained in the developer guide. There are also a few nice-to-haves that are easy to implement:

• Basic accessors for parameterizing the layout (just remember to call requestLayout() internally when they change)
• Support for custom XML attributes (it’s much more convenient to set parameters in the XML; there’s a good explanation on stack overflow)
• Supplying custom layout parameters (via generateDefaultLayoutParams(), generateLayoutParams() and generateLayoutParams())

I’ve included the source code for my square grid layout below. WARNING: It has not been battle tested and as a consequence may some serious bugs, though it has been working well enough for me. The implementation is also limited by the assumptions described above.

This source code includes all the ‘nice to haves’ that I listed but remains a very simple class that is much easier to use, reuse and maintain than an alternative implementation consisting of nested layouts. It also has other benefits that aren’t as obvious, for example grouping children directly under one parent view can make some animations easier to control.

The source code listed below is in the public domain.

When I’m tussling with the design of a UI for an Android application, it’s often the case that I’m struggling to find some extra screen-space in at least one activity. So I’m always on the lookout for how other designers and developers have tackled the problem in their applications. Here are three interesting adaptations that I’ve noted as I’ve used my phone.

Music

I use the stock music player to listen to music, audio books and other recordings. I always get a little satisfaction from noticing how the application neatly switches the “Now Playing” control from being a button in portrait orientation into an extra tab in landscape, where vertical screen-space is always at a premium (also - nice attention to detail: gently separating the extra tab from the other standard ones).

StreamFurious

I’m a very occasional user of the StreamFurious streaming audio application. But I’ve used it enough to discover this gem.

Audio applications (like the Music app above) that play tracks into which you can ‘seek’, can elide “Stop” and “Pause” since there is no difference in how the track will be resumed: the application will just seek to the position at which play stopped/paused and start playing.

But applications that stream live radio can’t do this as easily. Pausing implies that the application needs to continue running, constantly buffering data from the stream until the user resumes play. Stopping, on the other hand, is generally taken as an indication that the application should cease reading the stream.

StreamFurious avoids having two buttons (one for “Pause” and one for “Stop”) by retaining the regular Play/Pause button and using a long-press during play to fully stop the stream. Perhaps this is a common idiom, but it’s new to me and I find it elegant and intuitive.

GMail

Guessing from the approach taken, the developers of the GMail application on Android have particular difficulties with implementing a UI for it. Preserving GMail’s distinctive conversation view has resulted in HTML controls that masquerade as native Android components (I guess a list of web views was just too problematic).

In recent versions of the application, to make it easier for users to follow which email is currently being viewed within a conversation, the email header pops-up over the conversation below at exactly the point where the information would have been hidden by scrolling, and scrolls away at exactly the point where the email message ends. This is an efficient use of space, because the design ensures that the header is only occupying space on-screen at the same time as the email message it relates to (which is also the only thing it ever obscures).

I think this is a really nice touch, and demonstrates the effort that has gone into producing some of these UIs, especially since I have a hunch that the overlay is produced using Android widgets and not HTML, which presumably means careful tweaking of both the HTML and the layout XML to make the switch between both seamless.

User interface design is always a challenge. It’s a big subject and there have been plenty of books written about it. With a little experience I’ve discovered that designing UIs for the class of devices on which Android currently runs has a number of new considerations.

New Considerations

Here are some of them:

• The device screens are small and touch operated.

  • Far from shrinking content to accommodate a smaller screen, it needs to be large enough to tap reliably with the fingers or thumb. This includes situations where an impatient businessman with big fingers is dashing to a meeting.

  • Because the user is touching with the end of their finger, they will usually completely obscure the item they are operating. This is a particular difficulty for precision operations (such as drawing) or drag-and-drop style interaction.

  • Discoverability of UI function is hampered because there’s no direct equivalent to ‘hovering’ as one does with a mouse.

• Generally people will not be fully dedicated to using a phone application in the same way that an office worker might be sat in front of a PC (games being one possible exception). People will often use their phones in short intervals between (or even during) other activities. This has many implications for the UI design of a phone application:

  • As touched-on above, people won’t generally want to spend much time operating the application; users of desktop applications that have awkward UI controls will subconsciously slow down to ensure they operate the application accurately; on a phone this change in behaviour will be far from subconscious.

  • I can’t say that there is categorical empirical evidence for this, but I believe that users simply don’t spend as much time trying to learn how to use a new phone application and in part I put this down to the a typical pattern of user behaviour that doesn’t give mobile phone applications their full attention — applications will be downloaded and evaluated by most users in between other activities.

  • The UI must be responsive because users may not have even two seconds to wait to know that an action has been performed. And phones have slower processors and much slower network speeds than a typical PC. So you can’t avoid some operations being slow, instead you need to minimize their impact on the user.

• There is a significantly greater variation between the capabilities of different phones than would be typical of desktop PCs. At the time of writing, only a small number of Android devices have already been released/announced/leaked and that collection is fairly homogenous compared to the abundance of handsets on the market. I’ve chosen to highlight three:

It’s really worth reflecting on the disparities exhibited here between three handsets running the same operating system and due to be released less than a year apart.

• Users will typically use their devices in a much wider range of environments, that vary more rapidly, than than they might a PC. Think of the difference in visibility as a phone user walks indoors on a sunny day; or the change in audibility as they walk out again onto a noisy road.

Old Considerations

All this is in addition to the old considerations, some of which are:

• Accessibility

• Internationalization

• Visual Attractiveness

• Comprehensibility

• Comprehensiveness

• Branding

• Evolution

Solutions

I’m not even going to attempt to provide any solutions in this post. Instead, I’m going to finish with an exhortation. Given the herculean task of producing a usable mobile phone application:

Discover the frameworks Android provides to help with these things and use them!

Huge swathes of the Android frameworks exist to help with some of these issues:

• Widgets – high quality UI controls that work under a variety of input mechanisms
• Activities – decomposing applications into discrete units that the user can navigate with little attention
• Services – keeping an application working for the user without keeping it on their screen
• Notifications – keeping the user informed without directly interrupting them
• Alerts – scheduling work to be done for the user
• Intents – triggering actions by other applications as chosen by the user
• Tasks – keeping Activities cohesive without overly-constraining user navigation
• Resources – adjust the application’s UI automatically based on the user’s device and settings
• Settings – persist user information to minimize the frequency with which the need to provide it
• Content Providers – share data with other applications so that users don’t need to duplicate information
• Animation – can provide important cues to a user without using extra screen space
• Adapters/Cursors – allow users to navigate data without making them wait for all of it

Good applications of any significant complexity will probably use all of these extremely useful parts of the Android framework.