Archive for October, 2007

In times of natural disaster, many people turn to traditional news and media outlets for the latest updates and information about the status of their community. But, what if those traditional news and media outlets aren’t available to you? What if you don’t have access to a radio or a television or the Internet? Chances are, you probably still have access to a cell-phone.

Push-based notification systems like Twitter are now the de-facto standard for keeping up with your friends during geeked-out conferences like SXSW or Adobe MAX. But can they be used for something more? Can they, perhaps, save lives?

As you probably know by now, my hometown of San Diego has been ablaze with unrelenting wildfires for the past 2 days. San Diego’s local public radio and television broadcaster, KPBS has made surprisingly effective use of Twitter’s messaging system to keep us few tech-savvy citizens updated with the latest evacuation, damage and fire containment information. Kudos to KPBS for their creative use of this technology.

Local authorities have been using what has been called “Reverse 911” to notifiy local residents of evacuation orders in their area. Reverse 911 is essentially a massive phone dialer, able to dial thousands of numbers from a set list or (assuming landline) by geography. Like Twitter, it is a push technology. But, unlike Twitter, it is limited to phones. What we really need, in times of emergency, is a new kind of Twitter — a state- or county-supported Twitter where every citizen with a cell phone can choose to subscribe to an automatic notification service and receive SMS messages on local emergencies. Everything from fires, to floods, to tornadoes to hurricanes. (I’d add earthquakes to that list, but at present, we can’t predict earthquakes and thus can’t provide advance warnings about them.) This system could provide notifications on everything from damage reports to evacuations to volunteer and donation requests, and remain accessible on-the-go.

An intriguing idea indeed, but unfortunately I’m probably a bit too forward-thinking for the present government. Nevertheless, as more and more people abandon traditional landlines in favor of mobile devices, in five to ten years such an imaginary system may just become reality.

Sometimes, in the process of building and creation, you’re told that you should never try to “reinvent the wheel.” If it’s out there already, take it and use it.

Unless you’re trying to learn something. Then I say take the wheel, study it backwards and forwards, and reinvent it a hundred times over. Practice building wheels over and over again. You may just learn how to build a better wheel in the process.

When you’re learning how to program something, copy and paste is your enemy, not your friend. Type out every character in your own unique way.

Recently, I've been experimenting with the various uses of Perlin Noise for randomized graphic and animation creation in Flash. I disappeared from the Flash community during the days when Flash 8, Flash 8.5 and all of the fun, new graphics functionality was introduced to the Flash player. As such, I'm only just now getting around to playing around with the functions in BitmapData like perlinNoise, getPixel, setPixel, etc.

Below is an example that uses Perlin Noise for random terrain generation ... except that my terrain is an ocean made of Lego. Everything is drawn isometrically using the drawing API, which makes it easy to add a slider to adjust the viewing angle.

Over the next few weeks I plan to write a few posts on Perlin Noise; what it is and how it can be used in Actionscript to generate pseudo-organic textures, clouds, terrain, etc. The amount of simple and readily-understandable information on Perlin Noise available on the Internet for Actionscript developers is minimal at best. I'm hoping to do my best to rectify that situation.

SQL database support in AIR is a powerful and useful technology that allows you to move your applications into the world of “occasionally-connected” functionality. Store remote data locally, and then use synchronization methods to update that data whenever your application is connected to the Internet so that users can access their data anytime, anywhere.

Sounds simple. And for the most part it is. I used the built-in SQL support in AIR extensively in my latest project. And I learned a few lessons along the way. Here are a few things you may need to know about SQLite and SQL support in AIR:

  • Dates and Times: In Beta 2 of AIR, Adobe has added native DATE support to the database. Unfortunately, DATE (as well as the new BOOLEAN, XML and STRING types) is not actually officially supported by SQLite. As such, there are several SQLite supported date and time formatting functions that only work if your date information is stored as a string and not as an actual date. These functions are very handy for grouping and ordering timestamps on table entries. For this reason alone, I have yet to use the native DATE type. Instead, I use something like the DateUtil.toW3CDTF() and DateUtil.parseW3CDTF() functions (which come with the AS3 corelib on labs.adobe.com) to convert the date to and from a supported string format instead. Yes, this is extra overhead, but for me it was worth it.
  • Statement Execution: When you are creating SQL statements for execution, you may wonder why Adobe added a parameters property to the SQLStatement class, which requires you to use a question mark (?) syntax for passing parameters into SQL statements. Why not just use string concatenation and pass the values of your parameters as variables in the text of the statement itself? I wondered this for a long time. It would definitely make your code more readable. Well, it turns out that the runtime compiles your statement before execution to determine what it needs to do. Changing the text each time before execution means having to recompile the statement each time it is used. Using the parameters property avoids this unnecessary recompilation, thereby giving you better performance.
  • Database Opening and Table Creation: When your AIR application launches, one of the first things you are likely going to want to do is open your database. But just opening your database file does not guarantee that the tables and information you need are there. What if this is the first time the application has been run? By executing the CREATE TABLE IF NOT EXISTS ... command in your database open handler, you can ensure your tables are there every time the database file opens.
  • Altering Tables: Only RENAME TABLE and ADD COLUMN are supported. Keep this in mind if you plan to upgrade your application down the road and need to change your database schema after upgrade. It may involve a bit more work than you exepected.

For more helpful information, read this rather timely XKCD comic, then try the new documentation at Adobe LiveDocs. Paul Robertson also has some great insider information.

Modern man is an impatient beast. When it comes to using new technology, we expect it to be fast, smooth and (mostly) efficient. Which is why few things can be more detrimental to the experience of a new digital product than slow or choppy performance.

Earlier in the week I wrote about the value of using transitions, effects and animations to create better user experiences in both web applications and desktop software. If you’re a Flex developer, like me, working to create great experiences in rich internet applications, here are a few tips that could improve your application’s performance when it comes to transitions:

  • Suspend Background Processing: The obvious performance boost. Most effect classes have a public property suspendBackgroundProcessing that when set to true will disable any background processing (measurement and layout calculations) while the effect is playing. This will also prevent your effect from being disrupted while playing, which means that if you’re waiting for an event to complete the effect, you might end up waiting a very, very, very, very long time.
  • Don’t Use Deferred Instantiation: Deferred instantiation is usually a good thing. It speeds up application launch time by preventing unnecessary instantiation of components before they are actually needed. Navigators like the ViewStack and TabNavigator use deferred instantiation automatically, loading child components only as they are needed. Unfortunately, this also gets in the way of smooth transition performance (at least for the first time that a transition is played) because instantiation will occur mid-transition. Setting the creationPolicy property to “all” on Containers and Navigators will mean an up-front hit in application load time, but better performance for transitions between views. Your call.
  • Hide Things That Don’t Need to Be Shown: Finally, you can and should hide any elements of your view that don’t need to be shown to the user during transition playback. This reduces the load on the CPU simply because there is less to animate.

Hope that helps. Happy animating.