You know what’s a sweet user interface element?  Coverflows.  They aren’t that great for what they were initially used for: selecting albums to listen to based on their album cover.  Turns out people really do know what albums are called, or just want to see the artist/track title.  But!  You know what they are great for?  Selecting objects (in the software sense) with the identifier as a picture instead of text.  This is primarily limited to selecting photos, and even then, some may say that a simple grid is more utilitarian for this task, and I would tend to agree, but this doesn’t address a big problem with selecting from a grid: it’s ugly!  Google tried to do what it could with the Gallery app, but the grid of picture stacks still looks plain.  It also separates different categories (stacks) in a way that isn’t ideal.  Anyway, for the applications I am pursuing, I want something that places more emphasis on the content of each picture, which has led me to the coverflow.

The first, and largest, problem with this is: there isn’t any sort of standard coverflow implementation that has been made for android yet!  I’ve seen examples in which people expand the Gallery view – which by default displays a horizontal list of pictures – such that it would rotate the pictures based on their position.  This has a variety of problems associated with it, though:

1. Object spacing within the list is constant.  What you want is to have rotated images have increased density.  This way, you can see the edge of many pictures to give the user more information about what is further down the line in the list.
2. The gallery extension is very slow!  Seriously.  My Galaxy SII couldn’t handle a 5 picture list.  And yes, the bitmaps being displayed were of appropriate resolution.
3. The extension of the gallery, while convenient, isn’t constructed around the objective of creating a coverflow.  Things like minimum object spacing, maximum object rotation, focal length, etc. are all very awkward adjustments to make.

So!  What does this mean?  That I have to create a coverflow package, of course!  Due to the overtly 3D nature of the coverflow view, OpenGL ES2.0 will be utilized to create a lighter weight coverflow view with proper rendering of elements.  The topology of the package will be:

• Coverflow (extends GLSurfaceView)
  This will be the top level class through which users will interface with the coverflow, setting separation, rotation shaping, picture size, etc.
  • CoverflowRenderer (extends GLSurfaceView.Renderer)
    This object will handle rendering of the coverflow, and will receive configuration specs from the parent Coverflow class.  It does the heavy lifting and will contain all the ugly code we don’t want the use to have to mess with.
  • CoverflowSquare
    The coverflow square class will contain all pertinent data required for each square in the coverflow: path to the picture to be displayed, size, byte buffers for rendering in OpenGL, etc.  It will contain limited APIs for updating byte buffers.

So far, I’ve got a cursory version of each of these made.  The coverflow renders the list with unity separation between pictures, rotates pictures based on position, and has a single pole IIR filter implemented to mimic the critically damped spring settling effect for when a user flicks it.  Oh!  It also ensures that it settles on an integer position, thus ensuring that a square is dead on, or “selected”.  The view is very snappy and is working exactly as expected.  Here is a washed out laptop webcam recording of the coverflow in aciton:

Going forward, I plan to clean up the code to increase usability, and implement more features to make the coverflow as pretty as it deserves to be.  When it gets to a respectable point, I’ll post the code somewhere so that others can utilize this view as well.

Thanks for reading!