While it's a fairly powerful Flash Lite 3.0 device, the Chumby's processor is very slow compared to a typical desktop computer. I equate it with an old Pentium-era computer. The harsh reality is that your Flash widget can quickly eat up its share of the available 32 MB of RAM. If nothing else, developing Flash applications for the Chumby will cause you to consider every available option to optimize your code, to seek out and follow best practices. This process can influence the development strategies you follow in the future, making your regular apps even more efficient.
The message of this section is simple: be conservative. When adding animated content, be super creative as you decide how to communicate your ideas. In other words, step back and consider the minimum message you're attempting to convey. Instead of using a 20-frame tween to display a bouncing ball, create a similar effect using a few carefully crafted keyframes. There are many old tricks that you can borrow from traditional animation to improve performance on devices. Another way to design conservatively is to think about the impression you want to make, not the actual physics behind the movement.
For example, imagine you want to animate a bird in flight. It is more important to animate the impression the movement makes on you (free flight, fluttering, changing course) than showing the true physics (the wing formation, aerodynamics, and so on). Of course, in a perfect world you'd use long, smooth alpha tweens with bounce effects, but remember that your animations will not look very good if the SWF file chokes due to performance issues.
When I first began developing for the Chumby, it was a real wake up call for me. The prototype Chumby had only 16 MB of RAM. I created some really cool widgets, and they worked great when I tested them on my desktop. But it was an eye opener when I deployed them to the Chumby. All of the available RAM was quickly consumed and the Chumby restarted.
The bottom
line here is to clean up after yourself in your code. Don't leave any variables
hanging around that you don't need. Use the
delete myVariable
command whenever you're done with a variable. Also, be sure to call clearInterval() for every setInterval() you start to conserve resources.
Traditionally, programmers advise that you worry about optimization later in a development project, but when you are developing Chumby widgets I think it helps to adopt an efficiency-minded approach from the very start. For more tips, be sure to check out the performance tips provided in the Chumby Wiki.
Finally,
there are a few other design considerations to keep in mind. For one thing, you
can't call the Mouse.show() functions because the cursor never appears. Similarly,
it's best to forget about creating any rollover effects. Making the
user drag their finger on the touch screen is questionable—so use
"flicking" features with discretion. The good news is that while the
Chumby hardware imposes some restrictions, it also opens up a very interesting
opportunity, to access the built-in accelerometer. In the next section, I'll
describe how to connect to Chumby's accelerometer using ActionScript.