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.

Apparently in the last week there has been a lot of complaining about how hard it is to compile and package applications for the BlackBerry PlayBook. However all of this is just two commands. They are amxmlc and blackberry-airpackager -package -installApp -launchApp along with a few variables. It really is that easy, and any time that RIM spends trying to simplify that further is just time wasted, while the PlayBook is already taking long enough to get released.

Instead however RIM is apparently more interested in catering to random whiners who have never developed an app then working on features that would be of actual use to real developers.

The BlackBerry PlayBook has a BaseDialog class for generating modal dialogs, but does not allow developers to extend it for their own purposes. This leaves the PlayBook without a modal dialog for asking a question and receiving a response. As such I wrote one myself below, that as a parameter on the constructor, takes the name of the function responsible for removing this child, and working with the result.

import qnx.ui.core.UIComponent
import flash.display.Graphics
import flash.events.MouseEvent
import flash.events.Event
import flash.text.TextField
import flash.text.TextFormat
import flash.text.TextFormatAlign
import qnx.ui.text.TextInput
import qnx.ui.buttons.LabelButton

public class InputDialog extends UIComponent
{
public var inputText:TextInput = new TextInput();

public function InputDialog(exitFunction:Function)
{
width = 1024
height = 600

var myFormat:TextFormat = new TextFormat()
myFormat.color = 0x000000
myFormat.size = 32
myFormat.align = "center"

var titleText:TextField = new TextField()
titleText.text = "Title"
titleText.width = 500
titleText.x = 260
titleText.y = 200
titleText.setTextFormat(myFormat)
addChild(titleText)

myFormat.size = 22
var instText:TextField = new TextField()
instText.text = "instructions"
instText.width = titleText.width
instText.x = titleText.x
instText.y = 245
instText.setTextFormat(myFormat)
addChild(instText)

inputText.width = 240
inputText.x = 392
inputText.y = 277
inputText.height = 40
inputText.prompt = "Prompt Text"
addChild(inputText)

var doneButton:LabelButton = new LabelButton()
doneButton.label = "Done"
doneButton.x = inputText.x
doneButton.y = 330
doneButton.width = 240
doneButton.height = 45
doneButton.addEventListener(MouseEvent.CLICK,exitFunction)
addChild(doneButton)
}

override protected function draw():void
{
var g:Graphics = graphics;
g.clear();
g.beginFill(0xCCCCCC,.5);
g.drawRect(0,0,1024,600);
g.endFill();
g.beginFill(0xDDDDDD,1.0);
g.drawRoundRect(262,180,500,270,10);
g.endFill();
}
}

This code was earlier posted on the Developer Forums. It should be noted, that this approach has a slightly different look then the native modal dialogs, and unlike the native dialogs, will not prevent the application from being closed or minimized.

As I noted earlier this week, Java is looking to be a second class language on the BlackBerry PlayBook, so most developers are going to be programing for it in ActionScript rather than in Java. This will take some adjustment, but ActionScript is not all that different. In addition to the webcasts that RIM has put together on the PlayBook, an older ActionScript for Java Developers webcast on the adobe website may be useful as well. In addition, here are a few things that have thrown me off a bit so far.

• draw() instead of invalidate(): When updating a GUI component you call draw() where you would typically use invalidate() in Java. This is actually a bit different because the draw() method is more equivalent to Java’s paint(Graphics g) method. However, as opposed to Java where you can’t really call the paint method directly, ActionScript allows you to directly call draw() in order to refresh your components.
• Access object variables instead of get and set methods: I’ve always been a fan of using public or protected variables instead of creating get() and set() methods for internal variables. ActionScript embraces this approach, although a little magic can be used to create get() and set() type behavior. This is even used for the default components, which can take a little getting used to.
• Reuse variables instead of locally scoping them: Unlike Java and C#, variables are not scoped locally. So for example whenever you use for(int i=0;i<10;i++) to loop through your array in Java, in ActionScript you would use for(var i:int=0;i<10;i++) the first time it appears in the method, and then reuse the variable in the form of for(i=0;i<10;i++) for every loop after that.

The upcoming BlackBerry PlayBook has an operating system that is radically different from the current BlackBerry Platform. Quite simply there is not going to be any support for current BlackBerry Applications to run on the PlayBook, despite RIM’s reluctance to come out and admit it.

The BlackBerry PlayBook will support 4 main SDK’s. In order of their importance to the platform they are, Flex (Adobe Air), WebWorks (javaScript/HTML/CSS), native (C/C++), and Java. The Flex SDK is already launched, and the WebWorks will be out soon (and is mostly just an extension of WebKit). However support for the native SDK, and the Java SDK is significantly behind, with RIM unable to even confirm that they will be released before the PlayBook is available in stores. Therefore the basis of most PlayBook applications will be in Flex rather then the Java that currently runs all BlackBerry applications.

Furthermore even when the Java SDK is available on the PlayBook, most BlackBerry applications will need significant porting to bring them over to the new platform. It is possible that the PlayBook will support something closer to desktop Java, then the very special blend of J2ME that BlackBerry Java applications currently run. Even if not, in the Q and A of the last PlayBook development webcast it was revealed that the PlayBook will not have any equivalent of the current BlackBerry menu system, which will result in the underlying java being different, and the fundamental UI of many applications will need to be redesigned.

In the webcast Java developers were encouraged to wait out for the release of the Java SDK, rather then to start learning Adobe Air. However, that does not look like that option is getting the support that it needs from RIM to be viable. The fact is that the future of BlackBerry PlayBook applications is strictly in Flex and WebWorks regardless of if developers like it or not.