Some developers have a legitimate need to share files with the PlayBook simulator. This is broken in the Beta 2 simulator. If you don't care why, jump ahead to the workarounds.
With the first (Beta 1) simulator this could be done using FTP. The simulator had little in the way of security: all apps ran as "root" and you could log in via Telnet or FTP as the root user. They didn't even make any attempt to make the password difficult to guess!
Unfortunately, with the Beta 2 simulator, they've tightened up security substantially. This is overall a good thing, since the final release should be very secure so we need to test under the same conditions, but it has hampered some testing efforts.
Hurray! The next SDK and simulator for the PlayBook are out. Actually, not only have the Beta 3 AIR SDK and simulator been released, but there's now a Blackberry WebWorks SDK for PlayBook available on the Tablet OS Development site.
The AIR SDK release notes tell us what is new and changed. Here are the highlights, from my point of view:
Lots of interesting tidbits starting to come out from CES 2011 with a slew of new videos (well, I've seen two so far, but compared to the recent dearth of new stuff I call that a slew).
In a previous post I talked about several non-obvious gestures that let you exit from an app but, if you're a developer, you'll sometimes want to provide a Close button or some other way for users to edit more directly.
The most straightforward way is stage.nativeWindow.close(). This is actually a call that must be made from within a method in your main Sprite class, or any other suitable DisplayObject since it references the read-only stage property.
Using the flash.text.Font.enumerateFonts() routine one can see the following fonts available (at the moment... back at SDK beta 2) in the PlayBook simulator (skipping over some Japanese, Thai, and Indian fonts, and grouping related ones with slashes, to keep the list shorter):
I did a little technical support tonight for a major Canadian bank. Unpaid. Unrequested, too, actually. Not unappreciated though.
We were browsing the World of Gold Rewards site to see what "reward" my wife might want as a birthday present from her father. (Yes, we have everything we need, so she wanted my help choosing. :-) )
The pictures were not showing up on the rewards, just empty boxes where they should have been.
As mentioned in my previous post I have some concerns about UI design in the tablets. One of those concerns is "discoverability", as described in Jakob Nielsen's summary posting about his early iPad usability study.
I found this to be a problem the first time I touched an iPad. While some things are done very well -- it didn't take a second to understand how to unlock the device -- others are pretty obscure. Note that this first screen a user ever sees even has a nice clear instruction to "slide to unlock", and a sharp-looking slider, but they could have done as well with other features inside.
While responding to a question in the Tablet OS Developers' Forum I ran across links to a free 93-page iPad usability report by Jakob Nielsen. (Actually, you may prefer his summary posting if you don't have time to read a 93 page PDF.)
Jakob's comments about inconsistency in the initial iPad apps reminded me of my first concern as I listened to the Fourth PlayBook Webcast. I thought that RIM was being pretty sparse on the guidelines.
I think they've had a year to review the iPad situation and learn from its mistakes, and they would do well to provide more thorough and substantial guidelines. Unfortunately they seem to be too busy with getting the product ready to give due attention to the quality of the user experience.
On the PlayBook an application goes through several stages in its lifecycle, and various events are issued to allow an app to monitor its externally controlled state. I say "externally controlled" because these state changes are generally out of the control of an application.
When an app is first launched, the NativeApplication.nativeApplication object will get an InvokeEvent.INVOKE event. This is likely not of much use, as an application knows it was just invoked when it enters its main constructor routine (generally a subclass of flash.display.Sprite).