Tag Archives: BlackBerry

Getting Started with PlayBook Development Links

As collected by my colleague Renaun Erickson, here’s a whole bunch of links to get you started with BlackBerry development.

Main Landing Page for all BlackBerry Tablet OS SDKs
http://us.blackberry.com/developers/tablet/

BlackBerry Tablet OS SDK for Adobe AIR
http://us.blackberry.com/developers/tablet/adobe.jsp

BlackBerry Developer Forums
http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/bd-p/tablet

BlackBerry Issue Tracker (jira based)
http://us.blackberry.com/developers/resources/issuetracker/

On the Adobe side the go url is:
http://www.adobe.com/go/bbtabos

Some hot topics:
Uploading Your Playbook App to Blackberry App World
PaymentServices
QNX and MXML
Using ImageCache

Debugging Error with PlayBook Emulator

I ran into an issues while trying to launch a PlayBook app from Flash Builder Burrito in Debugging Mode.

I launched and the “Launching [Application name]” indicator in the bottom right corner just slowly inched up to 100%, but nothing happened. Eventually I got error messages.

From Flash Builder:

The Flash Builder debugger failed to connect to the running application.

Ensure that:

1. For in-browser applications, you are running the debugger version of Flash Player.

2. For debugging on a mobile device, you have a reliable WiFi connection to the device, and port 7935 is open on your machine’s firewall.

On the emulator:

Unable to connect to the debugger at address x.x.x.x, enter the correct host name or IP address or select cancel to continue without debugging.

The cause of this error is that your Default Debug Host IP is wrong. To get to this setting:

Go to Flash Builder Preferences
FlashBuilder ->
Target Platforms ->
BlackBerry Table OS

In my case the reason the error happened was a bit confusing. But it came down to this. That IP address got set to my public IP address in my hotel. When I went to present I didn’t have a network connection, and so that address was no longer present. The easiest fix for this when using the emulator is to set that Default Debug Host IP to the gateway of your VMWare’s NAT setup.

I don’t have an easy was of getting that, but the way I did it was:
Determine IP address for Playbook emulator
BlackBerry Settings
About ->
inet

For me 192.168.253.138.

Determine all of my system’s IP addresses
OSX ifconfig
Windows ipconfig

When I did that, I found one address (192.168.253.1) that was a reasonable bet for the gateway of the NAT network.

 

Southern California User Group Tour

I’m heading to Southern California in two weeks to do a miniature User Group tour. I’ll be talking about development for the BlackBerry PlayBook using Adobe tools. I’ll also cover ColdFusion as a Mobile Backend. If you’re in Southern California, and close to one of these meetings I invite you to stop in.

Tuesday February 1st
San Diego
Hosted by SDADUG and SdFug
Time:
6:00PM to 8:00 PM
Location: 
The Art Institute of California // San Diego
7650 Mission Valley Rd.
San Diego, CA

 

Wednesday February 2nd
Los Angeles
Hosted by LACFUG
Time:
6:00pm – 8:30pm
Location:
TollFreeForwarding.com
5959 W. Century Blvd
Suite 1108
Los Angeles, CA

Thursday February 3rd
Pomona
Hosted by IECFUG
Time:
6:15pm – 9:00pm
Location:
5-16 of building 98C
(the C/L/A building)
Cal Poly Pomona
Pomona, CA

StageWebView Location Changing without a Page Refresh

I’m working on a Remember the Milk application for the BlackBerry PlayBook, and am trying to get familiar with building against the RTM API. One of the security measures they take in order to use their API is requiring all applications to authenticate against a page on their site, and give permission to the calling application. It’s a pretty common pattern these days.

To do this in an AIR application, you can use StageWebView, which allows you to open a browser display within your applications. It has limitations, but works perfectly for this use case.

So you load up the page you want in the StageWebView, listen for the locationChange event, see if permission was granted, and go about your way. Simple? Right?

It failed for RTM. Why?

The location didn’t change. It was doing one of those “Let’s be cool and not reload the page” things.

At first glance the work around was to add a close button that the user would hit when the RTM page was done. But that’s inelegant, and frankly lazy.

So, I poked around some more, and found out, that despite not firing a locationChange event, it was firing a complete event when it was done. And luckily, RTM changes the title to reflect that the user gave permission.

So, all I had to do was add a check for the title to the processor for complete as displayed below:

 


 

Simple, easy, straightforward – hopefully I save someone else an afternoon of trial and error with this post.

Tivo Remote with QNX for BlackBerry Tablet

BlackBerryQNX Tivo Remote
For my next foray into mobile development with Flex and AIR, I’m trying an application with the default UI of the BlackBerry Tablet, the QNX api.

QNX is the company behind the BlackBerry Tablet OS. They provide an ActionScript library for creating components for the BlackBerry tablet. It’s what most of the native apps use, and to get that native feel, this is what you are going to use.
For me, coming to this from Flex, not having the framework to fall back on was a little scary. Ultimately I did get it working. I did suffer from the same disgust I had for the last remote project.
Encouraged by my success with that last project, I applied some of the same techniques. I changed some of the colors, positions and layouts. I’m still not happy with it, but the failings are mine, and not QNX’s. 
Lessons Learned
Flex rocks. Not having to spend time laying out stuff, add child objects to the stage, and generally being able to style components directly through an attribute or CSS is a huge productivity boost. 
That being said, ActionScript only projects aren’t terrible. Performance is better, the file sizes are smaller. In the case of the BlackBerry tablet, it’s the native look and feel.
The PlayBook starts in landscape (and the emulator can’t turn to portrait yet). It forced me to really think about how I needed to lay things out. In the end, I’m not happy with this one yet. I need to get better at laying things out. 
BlackBerryQNX Tivo Remote with bad fonts
Finally I learned that by default when you run a QNX app on your system you don’t have the fonts to make it look good. Even if you install it, it still won’t look good. I had to manually add the font as a text format to all of my controls. Annoying, but worth it. The text is listed as something like BBSans, but it is actually called DejaVu and is freely available. Thanks to Kevin Hoyt for pointing that out. 
Resources:
AIRTivoRemoteQNX on github
DejaVu Font

 

Tivo Remote with Hero

Android Version
This is my second attempt at a multiscreen BlackBerry and Android application using Hero. I outlined what I was trying to do in general with yesterday’s post.

I added one more device to my testing rig, just to explore differences.

  • Nexus One
  • Droid 2
  • Galaxy Tab
  • PlayBook Emulator

Tivo Remote
So for a stretch there TiVo was enabling their devices with a telnet port that you could open to allow another machine on the network to connect and broadcast commands. AIR 2.0 and later can do socket connections, so it seemed a perfect use case for AIR.

At first, I hated the UI. I did a default Hero look and feel, and it felt kinda lame. Not because of Hero, but because it was basically just a grid of buttons. It was like a remote you get with a generic tv. My next step was to try a layout exactly like a Tivo. But Tivo remotes are by and large much longer and skinnier then most mobile devices.

So I studied the Series 2 Tivo remote and took some concepts from it:

  • Tivo places the most important controls in a + shape.
  • Tivo uses color to call out a few buttons:
    • Pause
    • Thumbs Up
    • Thumbs Down
  • Tivo uses a darker grey to downplay the number keys
  • Tivo uses multiple shapes for their arrows
    • Play
    • Volume
    • Channel
    • Arrow Pad

All of these combine to make it much easier to determine where to click and hit that spot.

My first pass was arranging the play controls and arrow controls in + formations. I used a tile layout with some invisible buttons to aid me in this. This worked pretty good. With those shapes settled I laid out the controls better.

It looked more like a remote.

My next pass was changing button colors. I made the number pad darker, the thumb buttons green and red, and pause button orange.

It looked even better.

Finally, I added icons to all of the buttons, to make them images instead of characters. That made a huge improvement.

Finally I had a remote.

Then I rotated my screen, and all holy layout hell broke out.

Portrait vs Landscape

BlackBerry Tablet Version
I tried a few passes but could never get the remote to layout well in landscape mode. Then I thought really hard about it. This remote is emulating a thing. That thing is always tall and skinny… Could I get away with just forcing portrait layout?

In the end, that is what I did. It’s cheap and dirty. But I had other demos to write, and I decided I would fix it in my next app.

Lessons learned
Multiscreen means being able to handle multiple sized screen with the same application. It doesn’t have to mean one layout shoved into fit all possible device sizes. Or to put it more clearly: When you design one app to work as is on multiple screens, it sucks on all of them.

Now to be clear here, it doesn’t mean having one code base that can detect multiple screens and layout accordingly is bad. It’s just you actually have to detect and layout accordingly.

To that end, I would say you can probably do one design for smartphone sized screens and one design for tablet sized screens. You do have to be willing to let little differences in layout go though, much as you have to with CSS in the browser.

I tried to deal with the differences between screen sizes by anchoring components to the middle of the screen rather then the edges. So instead of setting top and left, I’ll set verticalCenter and horizontalCenter and calculate locations from the center. This allows me to not worry about pixel differences at the fringes of the screen. I had mixed results with it, and defaulted back to left and top anchoring things for now.

I also learned that a little bit of custom tweaking of Hero components goes a long way towards giving your application an individualized feel. Changing a few button colors and adding some icons really changed the whole application for me.

Resources:
AIRTivoRemote on github
Telnet Client in AIR
I can’t include the APK as it requires an as-of-now unreleased version of AIR.

About Time with Flex Hero

BlackBerry Table Day
I’m working on getting up to speed with the BlackBerry PlayBook. The best way to do this is to build some apps. For my first pass at this, I wanted to see how it would be to build apps with Flex Hero for both BlackBerry and Android at the same time. I figured it would be a good chance to get a feel for what multiscreen development really is like.

To start with I set up a few devices to test with:

  • Nexus One
  • Galaxy Tab
  • PlayBook Emulator

About Time
This is my go-to application for trying out new things. It’s an approximate clock. If you’ve seen my “Holy Crap I’m a Mobile Developer” Series, then you’ve seen it before. It will tell you, for example, that it’s “Just after Ten” instead of “10:02.”

Android DawnI like it because it is more than a Hello World, works with date/time formatting (which is usually just different enough between different systems to be annoying to learn), and it doesn’t have any external dependencies to start with like my other go-to learning app, the Twitter Search App.

That being said, I wanted to add a little pizzazz to this one:

  • It has four states: dawn, day, dusk, and night
  • There are transitions between the states
  • It uses geolocation and a web service to get sunrise/sunset times
  • It uses those times to set the correct state

As this is a pretty simple app consisting of just one screen, it was extremely simple. The only real challenge I had was laying out images. It works and looks acceptable on all three tested environments.

Lessons learned
The simpler the application, the easier it is to handle multiscreen. This app has no input, and very few moving parts. Getting it to work on many screens in both landscape and portrait was very easy.

This may sound like I’m saying “AIR makes it easy to do multiscreen development.” I’m not; I’m saying “Multiscreen development is easy if your application does nothing.” The app I’m going to blog about next confirms that once you add actual interaction to your UIs it gets much tougher.

If you’re going to target both Android and BlackBerry Tablet OS with your application then Hero is the way to go. There’s no way to selectively swap in QNX for pieces here and there. If you want cross platform without writing for each platform you have to acknowledge that your app won’t look quite like a native BlackBerry application. It won’t quite look like a native Android Application either. There are certainly pros and cons to this.

Pros:

  • One code base for all of your target platforms

Cons:

  • Might be consciously or unconsciously confusing or troubling to the user.
  • Might be jarring.
  • Might look cheap, or somehow wrong.

There are certainly more pros and cons than this, but this is what really slaps me in the face. For me, there’s no question, the ability to write applications once and trivially tweak builds to get them onto other platforms outweighs the other issues. However, your mileage will vary. Your applications might need that extra performance, or abilities. I have not run into these as limitations yet, for my use cases the performance hit of AIR as an abstraction layer have been very overblown. That being said, I’m not writing a complex app for mobile devices.

But how complex should your mobile applications be? From my vantage point, with slower processors, and less user attention, mobile apps should do less than their desktop counterparts. Most of my experience with mobile apps tells me that my fellow developers agree. Which again is not to say you shouldn’t write complex applications, merely that the types of applications I am disposed to writing on mobile devices are simpler, and require less capabilities and performance.

Also visually, I think the Flex team is doing a good job making visually pleasing interfaces. For comparison, I hated Halo, and mildly like Spark. Hero’s mobile components are visually better than both, in my opinion.

Also as I have posted before, I learned how to publish both apk (Android) and bar (BlackBerry Tablet OS) versions of AIR applications at the same time.

Resources:
AboutTimeHero on github
I can’t include the APK as it requires an as-of-now unreleased version of AIR.

Using ANT to package the same AIR app to Multiple Devices

I had some fun today playing with the BlackBerry Tablet SDK. In addition to getting a little demo up and running I got to show off some cool multiscreen goodness. Basically, I wrote one AIR app targeted at the Samsung Galaxy tab and the BlackBerry PlayBook (emulator, no device for me yet). I got them both to compile and install at the same time.

They also both ran, which was even awesomer.

I’ve embedded GISTs of the ANT script and properties file. Enjoy.

Compiling Flex Hero Apps with MXMLC in ANT

I ran into a problem today trying to use ANT to publish the same AIR application to BlackBerry and Android at the same time. Basically, when I used Flash Builder Burrito to push directly to a device for either platform it worked perfectly. When I did it via the ANT script I just got a white screen.

The cause: I had the wrong config loaded. I had air-config.xml as the configuration, and needed airmobile-config.xml as the configuration.

Took me a bit, but I figured it out. So if you’re looking to compile your Hero apps via ANT, use the right config.