Quick and Dirty Skinning of a Flex Mobile Button

I’m working on a mobile project and trying to implement based on a beautiful design comp. Unfortunately I haven’t had a lot of luck finding out how to do this right… So I’ll tell you how I did it, right or wrong.

So I start off with the design comp.  This is what I want to achieve: 

First, I create a blank skin that extends spark.skins.mobile.ButtonSkin.

The mobile skins use an image named “border” to render the border of the button. I’ll exploit that to show the new background image of my skin. There are two images for mobile skins: an up and a down. The Button has a function to return, which should be the correct image for either the up or down state… so:

I import new background images to replace the default up and down backgrounds of the button.


I override the getBorderClassForCurrentState function. (I’m also changing the font color here on the down state, probably the wrong place to do it but it works.)


This will yield this result:

It’s using the background but it’s small, so I hardset the size in the constructor.


This is a big no-no when it comes to mobile development, as that doesn’t scale to many screens well. But my app is pretty specific and I can get away with it.

This yields:

Good, but I need to remove the background shape. I do this by overriding drawBackground and setting it to do nothing.


Which yields this:

Finally I need to set the fonts. Mobile buttons have drop shadows on their text, but they don’t render using an actual dropshadow filter; they do it by having a second textfield behind the first. So I need to alter and tweak that font to the same settings by overriding the labelDisplay_valueCommitHandler.


And there you have it, a custom skinned button in Flex Mobile. If anyone sees glaring problems with this let me know.

Here’s the entire source if you are interested.


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 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.

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.


  • One code base for all of your target platforms


  • 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.

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.