I’ve just posted a very early preview version of Metaglow - an android application for creating backgrounds. It features the animating emblem that I described in my last post.
Anyone who wants to take a look can download it using Betan which is available via the Android Market (just search for Betan). The password is simply metaglow.
This is a very early release, here are some things to watch out for:
There we go, if there’s anyone left who does want a look:
There are more detailed instructions on using Betan if you need them.
I thought I’d take some time out to write-up some details of how I produced this morphing icon effect that I demonstrated in my previous post. The video is grainy, so it’s a little difficult to tell, but the result is a sharp, glossy looking emblem that appears to switch material periodically.
This is the first emblem that the user sees and it matches the application icon. I want to promote an identity for the application and strengthen its association with the launcher icon. What isn’t visible in the screenshot is the animation with which the emblem first appears. Using an XML anim resource, I combine an AlphaAnimation and a ScaleAnimation to the icon to make it slowly rise-out from the background. At the same time I use another alpha animation, combined with scaling and translation to pop a shadow behind. The aim is to give the impression that the icon sits slightly above the background. It’s also worth remarking that since this activity is the one used to launch the application, the system will probably be animating the activity onto the screen simultaneously. For this reason, I’d say it’s not worth doing anything too complex; any fine details will be missed and flashy animations may be overwhelming when combined with an activity transition.
I have to say at this point that the code isn’t finished yet, there are a number of small flaws that should be fixed, but I don’t know if there’ll be time before the first release. This is demonstrated in the screenshot above; I’m not dithering my bitmaps (which are ARGB_8888 for compositing purposes) for an RGB565 window (which was the default for Android until Gingerbread). You can often get away without dithering, but where bitmaps contain smooth gradients, the artifacts become distracting.
After this first presentation of the emblem, the background of the icon changes and the emblem begins to cycle through any number of different textures.
These textures are actually being rendered by the phone (using a genetically based algorithm) while the previously generated texture is being displayed. This is all done off-screen. Although the texture rendering is pretty efficient (thanks, in large-part, to the efficiency of the Android 2D APIs) it’s more work than one could safely commit to on the main application thread. So I use an AsyncTask, but I am considering switching to a Thread with a Looper because message-passing is probably a better model for what’s going on here, with the UI sending a message (indicating that it wants to update the emblem) to a worker which posts back another message (containing the bitmap). Currently the AsyncTask applies its new emblem in its onPostExecute() method, but this turns out to be a bit ugly if you want precise control over when the new emblem actually appears in the UI.
How the textures are rendered is a whole other post (series of posts probably) but it’s enough to know that that textures are rendered as a square image:
A circular mask has already been created (as a PNG resource this is all white, but with alpha).
And these are combined using the Canvas.drawBitmap() method, and a Paint that controls the composition.
One way to do this is by drawing the texture Bitmap onto the mask bitmap, using the SRC_IN Porter-Duff rule (this basically preserves the alpha channel of the destination image, but replaces the colour channels with those of the source image). But in this case, the texture is being rendered into a fresh Bitmap anyway, so rather than repeatedly producing fresh masks (typically with the Bitmap.copy() method), I draw the mask onto the texture using the DST_IN mode. With the result that all the colour information from the texture is preserved with only the alpha channel being the mask (note that Android has an ALPHA_8 bitmap configuration especially for masking).
There’s a huge amount you can do with the Xfermode options that Android provides and it’s really worth becoming familiar with them.
Now I have got as far as periodically generating a textured disc, but I still need to apply the logo to the emblem and display the result. Android makes this mostly very simple; the emblem is an ImageView with the white “M” as the image, and the disc as a background Drawable. So the disc appears behind the M with the View drawing doing the composition for us.
Simply, this “M” becomes a Bitmap within an ImageView:
which is given this other Bitmap as a background:
to end-up looking like this:
Because any view Animation will be applied to both the ImageView contents and background together, the two can be easily manipulated as one unit in the Java code and layout XML. This ImageView is then overlayed, using a FrameLayout, with another imageView that displays the shadow (I could have applied the shadow as a background on the FrameLayout, but I need to animate it independently in the initial animation).
To give a greater impression of physical depth to the emblem, you can see shading on the image of the “M”, both within it and, more significantly, around it. Creating this image actually proved bothersome. First I used POV-Ray to render the icon at the correct size. Then I needed to separate out the highlights and lowlights in such a way that the lightest and darkest parts of the image had the greatest opacity. At that point I couldn’t find any way of achieving this using GIMP. After 30 minutes of hunting around for the right filter, I wrote a throw-away Java program to do the job in just 5. It simply:
The 2D classes in Java SE aren’t as slick as the corresponding APIs in Android, but they’re more than adequate for tasks like that.
This post has described in broad terms how (with a little assistance from desktop Java), the Android View, Animation and graphics APIs were combined to create this morphing icon effect. But this is only part of the work. I also needed to:
I’ll try to cover these in later posts.
This is a video of an effect I’ve developed for an android application I’m developing that will augment some of my existing applications. This is all done by combining the powerful 2D libraries with the flexible view APIs.
The video quality is poor - I still haven’t worked out how to film a mobile phone.
(Source: youtube.com)
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:
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:
I’ve given up at trying to get Blender running under Ubuntu (no number of window manager tweaks seem to have worked), so I’ve resorted to POV-Ray! We need to make those new hi-res android icons somehow right?
What’s great about POV-Ray for programmers is that it’s a very familiar environment: code, compile and run; and you get the full benefit of version control on your icon resources too.
It’s certainly not for everyone though. That I can realize a design using constructive geometry and a text editor just as comfortably as I can drag control points around in a vector graphics package, says something about me; I’m just not sure what.
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:
Actually implementing a layout comes down to implementing two key methods:
This is explained in the developer guide. There are also a few nice-to-haves that are easy to implement:
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.
I’m mostly a pencil-and-paper kind of person for sketching out application ideas and wireframes; it’s as though my thumb, index finger and middle finger close together to form a supplementary neural network. So I have a lot of inertia to overcome when I try to use wireframing applications.
A couple of months ago Roman Nurik published some Android UI prototyping stencils and a few days ago I finally got round to trying them out. They are in the form of “collections” for Pencil a Firefox add-on for doing GUI prototyping. After a bit of messing around getting Pencil to import Roman’s collections on Ubuntu I started using it to wireframe a small app I that I’m building as a tool for my other apps.
After a couple of hours spent wireframing the application, I’ve been really surprised by how productive it’s been. Tools like Pencil are still not my kind of thing, but the prefab’ed controls make things very quick.
One problem with sketching out designs by hand is that it’s easy to make small errors of scale which cause you to waste time coding-up designs that look feasible but that just don’t work. Mocking-up the designs with correctly scale components avoids that (though nothing will remove the mental reasoning needed to evaluate designs in the context of varying devices).
Here are a couple of images. The first one is the wireframe I produced using Pencil, and the second one is the progress I’ve made towards implementing it. I’m fairly confident that things are going to work out well for this activity.
I’m finally finding more time for android development again. I’ve been busy working on (amongst other things) my Daisy applications, and I’m finally making some visible progress.
The focus of the changes in the next set of releases is to enable users to easily share the content they create, both with other users, and between all the android devices they may own. This is an important feature that users have asked for. Gardens, flowers, wallpapers, designs, game levels: I’m hoping to make everything shareable though a single account.
There are also some new Zen inspired garden designs for Daisy Garden too.
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.
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).
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.
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.
At the very end of last week I finished an update to Betan that will enable other developers to distribute their applications using the same tools I use to share private copies (usually betas) with users. My website provides details about Betan
I don’t know whether other developers will be actually motivated to use Betan, since it does involve at least one additional step over simpler mechanism such as just emailing the APK. The developer needs to encrypt the published APKs.
What motivated me to produce a more secure way of distributing beta copies of my applications was not that, if the APK was shared, some people would be able to use my application illegitimately. Instead I’m more motivated by ensuring that my users have a well tested product, however they procured the application — this is my reason for sharing beta copies in the first place.
The possibility that some poorly tested APK which erroneously wipes user data might gain broad distribution is enough of a motivation for me to write Betan. It may not be enough of a reason for other developers, in which case I may remain the only listed Pubisher.
This would be a shame, but the work to broaden access to Betan was not that great thanks to the rapidity with which I was able to put a simple web app together using GAE and GWT (about 4 hours). Most of the work consisted of tightening-up the command-line tool, tweaks to the android application (mostly listing publishers and better landscape support) and documentation.
Whether or not Betan is adopted by other developers, at least one more revision is planned — it will finish support for constraints on the phones to which applications can be installed and provide automatic notifications to users when newer versions become available.
