Tag: AIR

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:

http://snipplr.com/js/embed.js
http://snipplr.com/json/50655

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

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

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.