The bezel on the top of the PlayBook is reserved for developers to integrate a menu that can be swiped down from the top. However, an unfortunately large number of applications do not currently make use of this option. This breaks the consistency of the platform, and makes it more difficult for users to quickly get used to the tablet’s interface.

If not enough apps make use of the swipe down menu, users will not expect it to exist, and for those applications that do use it, users are liable to be unaware of the menu’s existence, and any additional items that are located there. Furthermore the alternative is to place a menu button on the screen that takes up space, and prevents the app from feeling like a native application.

Currently of the top 10 free apps, only 3 (including Pixelated) support a swipe down menu. Furthermore RIM is not even including one in all of its own applications such as the Scrapbook App, or even BlackBerry AppWorld. Given all of the support that RIM has offered to EA for Need For Speed, you would think that it would implement this basic UI function, but instead this app ignores the top bezel, and uses a convoluted two finger swipe instead.

RIM does not appear particularly interested in promoting this swipe down menu, but should they change their mind, they could do so by requiring that an app make use of such a menu in order to be featured in AppWorld. If RIM were to do this, the number of apps implementing a menu would rather quickly hit critical mass, and in turn give users a more consistent, and predictable interface to navigate.

The ActionScript SDK for BlackBerry AppWorld does not include any published api’s to directly invoke native applications such as BlackBerry AppWorld. There is however a round about way to do so. The navigateToURL() method can be used to launch the web browser. Furthermore the browser intercepts specific app URLs to launching BlackBerry AppWorld instead. So if you wanted to launch AppWorld directly from inside an ActionScript app, all you need to do is to use the navigateToURL() method by pointing it at an AppWorld URL.

The following is an event that is fired following a click to a “Launch AppWorld” button.

public function lauchAppWorld(event:MouseEvent):void
{
navigateToURL(new URLRequest(“http://appworld.blackberry.com/webstore/content/1839”))
}

You can test this approach by simply entering the URL into the browser on your PlayBook. The one downside this course of action has however, is that along the way you will end up launching the browser with a blank window. But until more API’s are available this is at least an approach that works.

Update:

A better approach has been found. In order to go straight to AppWorld you can use navigateToURL() with a link in the format “appworld://content/1839” instead. The below approach is much cleaner and preferred to the work around listed above.

public function lauchAppWorld(event:MouseEvent):void
{
navigateToURL(new URLRequest(“appworld://content/1839”))
}

I recently found some issues with my apps on the BlackBerry PlayBook. These issues were a direct result of following RIM’s BlackBerry Tablet development guide. They need to fix this and stop making suggestions that simply do not work.

The article wisely recommends that you make sure that the application’s state is saved when it is deactivated and pushed to the background, but recommends a technique that is inconsistent at best. They are recommending that you save data by listening for Event.DEACTIVATE which detects when another application receives focus. However this event is never fired when the application exits (unless you run in Paused mode like the simulators used to). Assuming that you could use this approach to save data upon exiting is at the root of a lot of the problems in the early PlayBook applications.

Instead you can actually detect the application closing by using NativeApplication.nativeApplication.addEventListener(Event.EXITING,saveData) to listen for an exiting event, and saving data then. Until RIM’s development guide on the life cycle of PlayBook applications mentions this, it will just be wrong.

With the release of the BlackBerry PlayBook next week, a good amount of time has been spent coding in ActionScript rather then Java. One of the main differences between ActionScript and most other object oriented languages is that ActionScript does not support threads.

Instead ActionScript is an event driven language. Instead of worrying about a main thread, or which one of many threads are running you instead just respond to events as they happen. Languages like Java are like this in some respects, such as reacting to key presses, but not to the point where you get rid of threads. As such in ActionScript methods doing complex work are never blocking, and you don’t have to create temporary threads for doing things like editing the main UI. Furthermore using the flash.utils.Timer class is a much cleaner way to periodically preform an action then any separate thread and loop system that you would otherwise have to do.

While the lack of threads may be limiting for the few uses that actually need them, for the most part ActionScript instead gives you an alternative for the instances where you were only using threads for lack of a more efficient option. The end result is that ActionScript can result in cleaner and more efficient code that is better for both the developer and the user.