A Couple of PlayBook-Related Videos on AdobeTV

The PlayBook is on sale today and it really is a beautiful device, especially for Flash developers. Having been able to play with one for a while now I am incredibly impressed with the QNX operating system and the general form factor of the tablet.

I did a couple of videos on the PlayBook for AdobeTV. The first one is on using OAuth with the PlayBook. It should be a good primer for PlayBook developers who want to leverage services like Twitter or Facebook Connect. The second one was a video of one of Renaun’s tips on how to use ImageCache in a QNX list to help improve performance. Both are embedded below.

PlayBook Development: Flex Mobile Framework or the QNX Components?

Flex or QNX

One of the first decisions you’ll have to make when you start building a PlayBook application is whether you want to use the Flex Framework for mobile devices or the QNX component set that ships as part of the AIR SDK for PlayBook. Even if you’re a Flex developer it’s not a straightforward decision so it’s important to be able to weigh the pros and cons of each side. I’ve been talking to a number of developers about Flex versus QNX and wanted to put down my thoughts to help developers decide. If you think I missed something, let me know in the comments and I’ll add it.

Performance

I don’t yet have a PlayBook to test the differences on, but in talking to people that do, performance generally seems like a wash. There’s something to be said for the fact that the QNX team is working really closely with the hardware to optimize their component set, but I also know the Flex team has made leaps and bounds in performance for Flex Mobile. When I get an actual device I’ll update this section.

Component Set

This is an area where I thought Flex would have a decided advantage. And if you count the entire component set, it does. But if you limit the comparison to mobile-optimized components, Flex ends up a little behind. For both platforms the core components are there, lists, buttons, etc. Flex has a TextArea component while QNX doesn’t, but QNX has a slider component while Flex’s hasn’t been mobile-optimized yet. Where QNX ends up winning though is in the number of components that are being built to support UI features of the PlayBook. QNX has support for a number of different dialog components including the LoginDialog component as well as built in support for lists with sections. If you’re sticking to the normal base components, Flex is a perfect fit, but the QNX components are a bit higher level and provide some specific UI elements that your users will see across the PlayBook that you can then add to your own application.

The Picker component from the PlayBook AIR SDK



The Picker component selected

Layout

Flex wins this hands down in my opinion. The layout system that the QNX components employ works just fine, and it’s elegantly simple. It uses a container system and I’ve been told it’s similar to Java. I did a screencast on how to use it and it generally accomplishes most of what you’ll need to do. But if you want to do anything above and beyond, the Flex layout system still rules. Having to use things like a Spacer container to align a component in the middle of the screen just seems hacky compared to being able to set properties on a Group. Plus, with Flex you can very easily create your own layouts, which means you can create far more customized looking applications with Flex than with the QNX components.

Skinning/Designer-Developer Workflow

Currently I see this one as a draw. The Spark components of Flex offer a lot of customization and on the desktop provide some great integration with tools like Flash Catalyst, Illustrator, and Photoshop. The only problem is that you don’t really get those integrations if you’re building mobile Flex applications because for most components you won’t want to use MXML-based skins, you’ll want to use AS3 skins. Because all of the designer-developer tooling uses MXML, you won’t be able to pull out all of the benefits of Spark on mobile devices. On the other hand, the QNX components don’t really have any designer developer workflow either. I found the skinning model for QNX to be similar in a lot of ways to the skinning model of Spark. Either way, when you skin these applications you’ll be doing a lot of ActionScript and relying a lot on images.

Mobile UI Paradigms

The TabNavigator UI Paradigm

The Flex mobile team has done a fantastic job of building the framework from the ground up with mobile user interface paradigms in mind. A base Flex Mobile application gives you an ActionBar, which can contain global content, an easy way to add and remove pages from within the application (complete with default transitions between screens), and components for tabbed navigation. With QNX you’re going to be creating most of those from scratch. On one hand it means that you can build up your own mobile UI paradigms if for some reason you don’t want to use what Flex has to offer. On the other hand, the paradigms that Flex Mobile uses are ubiquitous at this point and I’ve found myself trying to copy them in my PlayBook applications.

Flex Mobile's ActionBar Component

Native

This is one of those intangible things but I think it’s important to look at critically. Alex Payne noted some of the issues with AIR applications and how they compare to native applications (also read Ed Finkler’s post on the subject). One of the things I find most exciting about the PlayBook is that it’s the only platform where Flash is native. The QNX components that you use in the SDK are the exact same ones that are being used across the device. It’s very exciting to be able to build native UIs with my Flash/Flex skills. I’m obviously a big fan of Flex and AIR for a lot of things, but given the chance to build native apps, I’ll do it. And it couldn’t be easier for Flash developers to use the QNX components to create native PlayBook apps. That being said, the native APIs and device functionality are all exposed via ActionScript APIs so even if you’re building a Flex app you can still take advantage of the same native and device-specific functionality that developers who use QNX can. So it just comes down to how you want your application to feel compared to other applications on the device.

Another important consideration is being able to reuse your code to deploy to other devices. If you’re looking for a consistent brand across multiple devices and the ability to reuse big chunks of code, Flex is the only answer. You won’t be able to use the QNX components outside of the PlayBook environment so you’ll have to rewrite the application for iOS or for Android or for any of the other devices AIR supports.

Conclusion

I don’t really see a winner for either one of these because I think it comes down to developer skills and what kind of experience you’re going for. I’ve really enjoyed diving into the native QNX components because I like when applications have a native look and feel. If you’re primarily a Flex developer you’re probably going to miss some of the things that you’ll lose by moving to the QNX components. And someone may come up with a Flex skin that mirrors the look and feel of the QNX components so you can get the best of both worlds. Either way building applications for the PlayBook will be right up the alley of any Flash developer. It’s a device that has basically been built from the ground up to support Flash and I’ve been enjoying it immensely. I’m hoping to have a Pintley application out for the PlayBook at launch so if you’re a beer lover, check back here.

One good place to start hashing out the differences is to take a look at the developer documentation for each: Flex, QNX. That will give you a feel for some of what’s supported in each one. And again, I’ll be updating this post with comments so feel free to comment below or to drop me an email.

Creating Custom List Skins for the BlackBerry PlayBook

Disclaimer: I’m fairly certain this isn’t best practice. There is a ton of stuff going on with List and CellRenderer that I don’t fully understand. I’m hoping to sit down with the QNX team at some point and figure out how this might be done correctly, but for now I’ve found a way that works so I wanted to share it for anyone who is having issues.

Skinning a List is quite a bit different than skinning something simple like a Button or a TextInput box (which I talked about in my post here). It seems like the correct way to customize the look and feel of a list would be to create a CellRenderer which gives you access to the label for the list, and then swap out the graphics by creating a skin specifically for that CellRenderer. But my particular code didn’t rely on the label field so I skipped the first step and just created a CellRendererSkin that extends UISkin and implements ICellRenderer. By implementing ICellRenderer I get access to the data methods, but as you’ll see, that created some issues.

First off, here’s the list I wanted to create. It’s got an image and a few lines of text. You can see the regular state (white) and what it looks like when it’s selected (grey). I wanted a little bit more of a custom look so I put some space between each item and drew a rounded rectangle with a border around the content.

List Screenshot

To skin a list this way, the most important method is still initializeStates(). That method has to be overridden just like if we were skinning any other component, and it’s where we call setSkinState to associate a graphic with a state. A list has basically 8 different SkinStates: SkinStates.UP, SkinStates.UP_ODD, SkinStates.DOWN, SkinStates.FOCUS, SkinStates.DISABLED, SkinStates.SELECTED, SkinStates.DOWN_SELECTED, and SkinStates.DISABLED_SELECTED. I have no idea what FOCUS does, I’m not alternating my rows so I don’t care about ODD, and I decided I could live with my DOWN, SELECTED, and DOWN_SELECTED being the same. So here’s the code for my initializeStates() method

override protected function initializeStates():void
{
     _upSkin = new Sprite();    
     setSkinState(SkinStates.UP,_upSkin);
 
     _downSkin = new Sprite();    
     setSkinState(SkinStates.DOWN,_downSkin);
     setSkinState(SkinStates.DOWN_SELECTED,_downSkin);
     setSkinState(SkinStates.SELECTED,_downSkin);
 
     SkinStates              
     showSkin(_upSkin);
}

Here’s where things get a bit messier. With normal skinning, I could just start adding graphics to my sprites and then set the skin state accordingly. But what I found was that when the initializeStates() method got called, the width and height of the component hadn’t been set yet. So when I tried to draw a rectangle that used the height/width of the component, it would look scrunched. If you know the exact dimensions you want, you can just hard-code the values. But I wanted to be able to use this on different sized lists, so I wanted those dynamic values.

What I found was that if I overrode the setState(state:String) method, I could get the values for width/height there and then draw the correct graphics depending on whatever state was being set based on the height/width of each cell.

override protected function setState(state:String):void
{
     super.setState(state);
 
     var matrix:Matrix = new Matrix();
     matrix.createGradientBox(width,height,90/180*Math.PI);
 
     if(state == SkinStates.UP)
     {                   
          _background.graphics.clear();
          _background.graphics.beginGradientFill(GradientType.LINEAR,
                    [0xffffff,0xf2f2f2,0xffffff],[1,1,1],[0,127,255],matrix);
          _background.graphics.lineStyle(2,0x221206);
          _background.graphics.drawRoundRect(20,10,width-35,height-20,7,7);
          _background.graphics.endFill();
     }
     if(state == SkinStates.DOWN ||
          state == SkinStates.DOWN_SELECTED ||
          state == SkinStates.SELECTED)
     {                        
          _background.graphics.clear();
          _background.graphics.beginGradientFill(GradientType.LINEAR,
                    [0xaaaaaa,0xcfcfcf,0xaaaaaa],[1,1,1],[0,127,255],matrix);
          _background.graphics.lineStyle(2,0x221206);
          _background.graphics.drawRoundRect(20,10,width-35,height-20,7,7);
          _background.graphics.endFill();
     }              
}

Here I ran into another odd issue. Notice that I’m not adding the graphics to the state, but rather adding them to a _background Sprite. What I found is that when I would try to draw the graphics right on the skin sprite it would either overwrite my other content when the state changed and I couldn’t get it back, or the graphics wouldn’t display at all. I’m still not entirely sure why those two things happened and I went through so many iterations that I don’t remember the code that caused it. But what I found was that if I created a background Sprite and added that to the display list first, I could alter it depending on the state and it would draw correctly. That’s also why I have a _background.graphics.clear() call because the _background Sprite is in every state, it just needs to be redrawn when the state changes.

The next step was to add everything to the cell renderer and then to clean it up when the cell renderer goes away. All of the QNX components have an onAdded() and onRemoved() method that gets called when the object is added to or removed from the stage. So I just overrode those methods and added my content.

override protected function onAdded():void
{
     super.onAdded();
     addChild(_background);
     addChild(_image);
     addChild(_name);
     addChild(_brewery);
     addChild(_beerType);
     addChild(_ratingText);
     addChild(_avgRating);
}
 
override protected function onRemoved():void
{
     super.onRemoved();
     removeChild(_background);
     removeChild(_image);
     removeChild(_name);
     removeChild(_brewery);
     removeChild(_beerType);
     removeChild(_ratingText);
     removeChild(_avgRating);
}

There’s just one final step. As you’ll see in my code below, I set up most of the properties of the labels and the image in the constructor. But I don’t set any of the dynamic data. That’s because I had a really hard time finding out when I could access the data property of the cell renderer. There isn’t any data on init(), onAdded(), or initializeStates() so trying to set the dynamic data in those methods threw an error. I could access it in the setState() method, but I found that when I tried to set it there, the list wouldn’t display the values correctly. I finally figured out that it was because of the way the list is virtualized. The setState() method doesn’t get called when you initially scroll the list because the state hasn’t changed, just the data has. So I was seeing the values repeat when I’d scroll the list and didn’t see the correct value until I clicked on it and forced setState() to be called.

The solution was just to embrace the fact that I was implementing ICellRenderer and set all of the data in the data setter method. That set the data correctly for each cell and didn’t depend on the state at all. I also had to set the width of the Label objects there so that the text wouldn’t be cut off.

public function set data(data:Object):void
{
     _beer = data;
 
     _image.setImage(data.thumb);
 
     _name.text = data.beerName;
     _name.width = width-150;
 
     _brewery.text = data.brewerName;
     _brewery.width = width-150;
 
     _beerType.text = data.styleName;
     _beerType.width = width-150;
 
     if(data.avgRating > 3)
     {
          _avgRatingFormat.color = 0x4c9d17;
     } else if (data.avgRating < 1)
     {
          _avgRatingFormat.color = 0x9d1717;
     }
 
     _avgRating.text = data.avgRating;
     _avgRating.format = _avgRatingFormat;
}

Again, I want to stress that this probably isn’t the ideal way to do this. Especially if you have a pretty basic label you could just extend CellRenderer and override the draw() and drawLabel() method to do what you want. Or, like I said above, apply a special skin to that CellRenderer that handles all of the states for the list correctly. This was the rabbit hole that I went down though, and I found it to be kind of handy because I killed all of my birds with one class. Even if it’s an ugly class. Here’s the full code.

package com.pintley.components.listClasses
{
     import flash.display.GradientType;
     import flash.display.Sprite;
     import flash.filters.DropShadowFilter;
     import flash.geom.Matrix;
     import flash.text.TextFormat;
 
     import qnx.ui.display.Image;
     import qnx.ui.listClasses.ICellRenderer;
     import qnx.ui.skins.SkinStates;
     import qnx.ui.skins.UISkin;
     import qnx.ui.text.Label;
 
     public class BeerCellRendererSkin extends UISkin implements ICellRenderer
     {
          protected var _beer:Object;
          private var _row:int;
          private var _column:int;
          private var _section:int;
          private var _index:int;    
 
          private var _yOffset:int = 12;
          private var _xOffset:int = 35;
 
          /**
           * Skins
           **/
          protected var _upSkin:Sprite;
          protected var _selectedSkin:Sprite;
          protected var _downSkin:Sprite;
          protected var _disabledSkin:Sprite;
 
          /**
           * Cell Renderer content
           **/
          // I use a background sprite because I want to
          // make sure it's the lowest layer. Then I can just
          // modify the lowest layer without overwriting the text.
          protected var _background:Sprite;
          protected var _name:Label;
          protected var _brewery:Label;
          protected var _beerType:Label;
          protected var _ratingText:Label;
          protected var _avgRating:Label;
          protected var _image:Image;
 
          /**
           * TextFormats
           **/
          protected var _nameFormat:TextFormat;
          protected var _breweryFormat:TextFormat;
          protected var _beerTypeFormat:TextFormat;
          protected var _ratingTextFormat:TextFormat;
          protected var _avgRatingFormat:TextFormat;
 
          public function BeerCellRendererSkin()
          {
               super();
 
               /**
                * TextFormats
                **/
               _nameFormat = new TextFormat();
               _nameFormat.color = 0xbd5251;
               _nameFormat.size = 16;
               _nameFormat.bold = true;
 
               _breweryFormat = new TextFormat();
               _breweryFormat.color = 0x525252;
               _breweryFormat.size = 14;
               _breweryFormat.bold = true;
 
               _beerTypeFormat = new TextFormat();
               _beerTypeFormat.color = 0x525252;
               _beerTypeFormat.size = 14;
 
               _ratingTextFormat = new TextFormat();
               _ratingTextFormat.color = 0x79523e;
               _ratingTextFormat.size = 12;
               _ratingTextFormat.bold = true;
 
               _avgRatingFormat = new TextFormat();
               _avgRatingFormat.color = 0x000000;
               _avgRatingFormat.size = 14;
               _avgRatingFormat.bold = true;
 
               /**
                * CellRenderer Content
                **/
               _image = new Image();
               _image.x = _xOffset;
               _image.y = 20;
               _image.filters = [new DropShadowFilter(3,45,0x000000,.5,4,4,.5)];
 
               _name = new Label();
               _name.x = _xOffset+80;
               _name.y = _yOffset;
               _name.format = _nameFormat;
 
               _brewery = new Label();
               _brewery.x = _xOffset+80;
               _brewery.y = _yOffset+20;
               _brewery.format = _breweryFormat;
 
               _beerType = new Label();
               _beerType.x = _xOffset+80;
               _beerType.y = _yOffset+35;
               _beerType.format = _beerTypeFormat;
 
               _ratingText = new Label();
               _ratingText.x = _xOffset+80;
               _ratingText.y = _yOffset+55;
               _ratingText.format = _ratingTextFormat;
               _ratingText.text = "AVG Rating";
 
               _avgRating = new Label();
               _avgRating.x = _xOffset + 150;
               _avgRating.y = _yOffset+54;
 
               _background = new Sprite();
          }
 
 
 
          /**
           * Getters/Setters
           **/
 
          public function get data():Object
          {
               return _beer;
          }
 
          public function set data(data:Object):void
          {
               _beer = data;
 
               // Set the text and images for the
               // label after we get data from the list.
               _image.setImage(data.thumb);
 
               _name.text = data.beerName;
               _name.width = width-150;
 
               _brewery.text = data.brewerName;
               _brewery.width = width-150;
 
               _beerType.text = data.styleName;
               _beerType.width = width-150;
 
               if(data.avgRating > 3)
               {
                    _avgRatingFormat.color = 0x4c9d17;
               } else if (data.avgRating < 1)
               {
                    _avgRatingFormat.color = 0x9d1717;
               }
 
               _avgRating.text = data.avgRating;
               _avgRating.format = _avgRatingFormat;
          }
 
          public function get index():int
          {
               return _index;
          }
 
          public function set index(value:int):void
          {
               _index = value;
          }
 
          public function get row():int
          {
               return _row;
          }
 
          public function set row(value:int):void
          {
               _row = value;
          }
 
          public function get column():int
          {
               return _column;
          }
 
          public function set column(value:int):void
          {
               _column = value;
          }
 
          public function get section():int
          {
               return _section;
          }
 
          public function set section(section:int):void
          {
               _section = section;
          }
 
          public function get isHeader():Boolean
          {
               return false;
          }
 
          /**
           * Overriden Functions
           */
 
          override protected function initializeStates():void
          {
               // Set up the skin states
               _upSkin = new Sprite();    
               setSkinState(SkinStates.UP,_upSkin);
 
               _downSkin = new Sprite();    
               setSkinState(SkinStates.DOWN,_downSkin);
               setSkinState(SkinStates.DOWN_SELECTED,_downSkin);
               setSkinState(SkinStates.SELECTED,_downSkin);
 
               showSkin(_upSkin);
          }
 
          override protected function setState(state:String):void
          {
               super.setState(state);
 
               var matrix:Matrix = new Matrix();
               matrix.createGradientBox(width,height,90/180*Math.PI);
 
               // Check to see what state is being set and then draw
               // the graphics on the background Sprite accordingly.
               if(state == SkinStates.UP)
               {                   
                    _background.graphics.clear();
                    _background.graphics.beginGradientFill(GradientType.LINEAR,
                              [0xffffff,0xf2f2f2,0xffffff],[1,1,1],[0,127,255],matrix);
                    _background.graphics.lineStyle(2,0x221206);
                    _background.graphics.drawRoundRect(20,10,width-35,height-20,7,7);
                    _background.graphics.endFill();
               }
               if(state == SkinStates.DOWN ||
                    state == SkinStates.DOWN_SELECTED ||
                    state == SkinStates.SELECTED)
               {                        
                    _background.graphics.clear();
                    _background.graphics.beginGradientFill(GradientType.LINEAR,
                              [0xaaaaaa,0xcfcfcf,0xaaaaaa],[1,1,1],[0,127,255],matrix);
                    _background.graphics.lineStyle(2,0x221206);
                    _background.graphics.drawRoundRect(20,10,width-35,height-20,7,7);
                    _background.graphics.endFill();
               }              
          }
 
          override protected function onAdded():void
          {
               super.onAdded();
               addChild(_background);
               addChild(_image);
               addChild(_name);
               addChild(_brewery);
               addChild(_beerType);
               addChild(_ratingText);
               addChild(_avgRating);
          }
 
          override protected function onRemoved():void
          {
               super.onRemoved();
               removeChild(_background);
               removeChild(_image);
               removeChild(_name);
               removeChild(_brewery);
               removeChild(_beerType);
               removeChild(_ratingText);
               removeChild(_avgRating);
          }
     }
}

RIM’s PlayBook and Adobe AIR

Yesterday RIM announced their tablet computer, the PlayBook, with an impressive set of specs and what looks like a great form factor. But what I thought was the coolest part of the announcement is that Adobe AIR is going to play a central role in application development on the tablet. While there will be support for Java eventually and developers can use C++ to tie into things like OpenGL, Adobe AIR is the primary way to develop applications for the tablet.

In fact, a lot of the work on the tablet is already being done in AIR. The browser, the application launcher, and a lot of the default applications have been built using Adobe AIR. One of the cool things is that this is just one step in a long evolution of Flash. The company behind the tablet OS, QNX, was acquired by RIM back in April. QNX has long been a partner of Adobe and is one of the experts on porting Flash to different pieces of hardware. So they’ve got a ton of experience working in the guts of Flash and it sounds like a lot of that knowledge went into the AIR integration on the PlayBook.

So if you’re building AIR applications then this is one more place you’ll be able to bring those skills. You can get a jump on development by heading over to the labs page we have set up for the BlackBerry and of course, there will be a lot more good stuff at MAX, so you’ll want keep an eye on news coming out of LA for the latest.