In my last post, I wrote about the lack of animation API provided in the Blackberry SDK. Sure, OS 6.0 provides some means for doing animations, and OS 5.0 added an API for screen transition animation. But, that’s not enough for developers targeting devices running earlier OS versions. According to some numbers I dug up, there are still quite a few users running OS 4.6. So, the fact that OS fragmentation exists can’t be ignored. Maybe, at some point in the future when all Blackberry users are running OS 6.0 and up, animated UIs will be a lot easier to create and maintain. But, until then, a lot of the work is left up to the developer.

The simple example of field layout animation I provided previously works great, but it’s missing something. When watching those fields slide into place, I’m reminded of an Atari 2600 video game. The animation is too stiff and robotic. It needs life. It needs the help of easing curves. An ActionScript developer by the name of Robert Penner posted a chapter from a book he’s written that gives an excellent introduction to the concept of easing curves. In addition, he’s published a bunch of easing equations and licensed them under the BSD license. If you have any interest at all in this kind of stuff, I highly recommend taking a look at his work.

With the help of Penner’s work, I’ve added an overshoot interpolator to the original animation example I wrote. This makes the two text fields overshoot their targets and decelerate into position. It makes for a much more lively and fluid visual. In addition to this, I’ve created two other example projects. The first one demonstrates what could be called an elastic or bounce effect. The field being animated, captioned “Boing,” bounces into its target position like it’s attached to a bungee cord. It can be a great effect when used to drop things like status messages, for example, into place for a brief period of time and then pulling them out of view. This example shows how the dynamic positioning of the animated field can have an interesting cascading effect on the fields around it. The last example, however, eliminates that cascading effect and simply overlays the animated field over top the others.

As far as performance is concerned, these examples are probably not going to set any FPS records. They rely on the updateLayout method provided by the framework’s Field class. When called, it triggers the sublayout method of the containing Manager (which is a subclass of Field). A more efficient method may be to bypass the layout and directly paint objects on the screen. Instead of calling updateLayout on each notification from the Animation class, a call to the Manager’s invalidate method could be performed instead. That would, in turn, trigger its contents to be painted. The contents could be fields, shapes, text, bitmaps, or whatever. But, unless your application is really busy, I’m assuming that the updateLayout method will be acceptable. I have yet to actually try these techniques in an application, so I could be wrong.

I’ll leave you with a short screencast of one of the example projects in action. It’s really not a great visual of the animation, as it looks choppier than it actually runs on the simulator. But, perhaps it will be enough to get you excited about adding animations to your applications too!

Hello World from Neil Loknath on Vimeo.

After using a few Blackberry applications, I noticed that many (if not all) of the them lack anything more than a very basic UI. So, I decided to take a peek and figure out why.

As it turns out, RIM hasn’t provided an API for animations in their Blackberry SDK until now. Now being OS 6.0. Yes, after six OS versions, they’ve finally realized that people enjoy a visually attractive and fun user experience. Better late than never, I guess.

So, what to do if you’re writing apps for devices running anything less than OS 6.0? Googling the keywords “Blackberry animation” brings up very few hits. I did find a great example, however, on stackoverflow.com. I found that one particularly interesting, so I decided to work up a test based on it. It’s very, very basic. But, the Animation class that materialized is something that could be very useful. See below:

/**
 * Copyright 2010 Neil Loknath
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 ***/

package com.nloko.animationtest;

import net.rim.device.api.system.Display;

public class Animation {
	public static interface AnimationListener {
		void onNewFrame(int time);
	}

	private static final int DEFAULT_FPS = 40;

	private int _duration;
	private int _time;
	private int _fps = DEFAULT_FPS;
	private Thread _thread;
	private volatile boolean _running;

	private AnimationListener _listener;

	public Animation(int duration) {
		_duration = duration;
	}

	/**
	 * The number of frames in an animation per second
	 * @param fps
	 */
	public void setFPS(int fps) {
		_fps = fps;
	}

	public int getFPS() {
		return _fps;
	}

	/**
	 * The total duration of the animation
	 * @param duration
	 */
	public void setDuration(int duration) {
		_duration = duration;
	}

	public int getDuration() {
		return _duration;
	}

	/**
	 * The time elasped since the animation started
	 * @return
	 */
	public int getTimeElapsed() {
		return _time;
	}

	public void setListener(AnimationListener l) {
		_listener = l;
	}

	/**
	 * Start the animation
	 */
	public synchronized void start() {
		if (_thread == null) {
			_running = true;
			_thread = new Thread(new Runnable() {
				public void run() {

					final int idleTime = 1000 / _fps;
					final int duration = _duration;
					_time = 0;

					try {
						while(_running && _time <= duration) {
							animate(_time);
							_time += idleTime;

							Thread.sleep(idleTime);
						}

						if (_time - idleTime < duration) animate(duration);

					} catch (InterruptedException e) {}

					stop();
				}
			});

			_thread.start();
		}
	}

	/**
	 * Stop the animation
	 */
	public synchronized void stop() {

		_running = false;

		if (_thread != null && _thread.isAlive()) {
			_thread.interrupt();
			_thread = null;
		}
	}

	/**
	 *
	 * @param time
	 */
	private void animate(int time) {
		AnimationListener listener = _listener;
		if (listener != null) {
			listener.onNewFrame(time);
		}

	}
}

Without going into too much detail, what the class does is abstract away all the boring details of managing when and how often to display animated frames. All the user of the class needs to do is tell it the duration of the animation, when to start, and listen for events. To see it in action, here’s a sample project that simply scrolls in the word “Hello” from the left and the word “World” from the top until they both meet in the centre to form the sentence (can you guess?) …”Hello World!”

In the coming weeks, I hope to find the time to add an Interpolator to this class for rendering effects like acceleration, deceleration, and elastic effects ie. overshooting a target and bouncing back. Fun stuff!