CFAIR Synchronization Resources

I talked earlier today as part of Adobe Developer Week on synching up data between ColdFusion and AIR (mobile) clients.

I referenced a whole bunch of pages in my talk, and wanted to link them all out at once.

Finally source code from github for the demos I showed in my session:

Hope this helps!

Toddler Timeout

My first full fledged mobile app is now on the Android Market.

It’s called “Toddler Timeout!” and it’s got real world uses. If you do the whole timeout thing on your kids, this is a timer for doing that when you’re on the go. That’s right, discipline for your child ANYWHERE!

My plan is to release it on the Android Market first, use the easy to publish nature of the Android Market to iterate over all of the bone head bugs I’ve left in it. I’ve also submitted it to the Amazon App Store too. It’s awaiting approval.

Then once I’ve stabilized it, I’ll get it on to submit it to the BlackBerry and IOS stores.

A couple technical things about it:

  • It uses Flex
  • The timer is a Flex MX PieChart
  • I minimally performance tuned it

Expect a few blogs posts around it soon.

Go give it a shot. Toddler Timeout!

Motorola MOTODEV App Summits – South American Leg

A few weeks back I announced that Adobe would be participating in Motorola’s MOTODEV tour featuring the XOOM and ATRIX. Mark Doherty and I will be talking at multiple events with Motorola.

I’m pleased to tell you we have confirmation on dates for the South American (and Central American) leg of the MOTODEV tour.

Beijing, China – April 26 (Mark)
Shanghai, China – April 29 (Mark)
Sao Paulo, Brazil – May 16 (Terry)
Buenos Aires, Argentina – May 19 (Terry)
Mexico City, Mexico* – May 23

Can’t wait.

Motorola MOTODEV App Summits Tour!

I’m pleased to announce that Adobe is participating in Motorola’s MOTODEV App Summits. The App summits are designed to bring developers up to speed in developing Android Apps for Honeycomb, specifically focused on the XOOM with Honeycomb OS, as well as for smartphones like the ATRIX.

I’m also pleased to announce that Mark Doherty and I will be giving sessions on AIR for Android development at these events.

Berlin, Germany – April 11 (Mark)
London, UK – April 15 (Mark)
Beijing, China – April 26 (Mark)
Shanghai, China – April 29 (Mark)
Seoul, Korea* – May 2
Sao Paulo, Brazil* (Terry)
Buenos Aires, Argentina* (Terry)
Mexico City, Mexico* – May 25

If you’re near any of these cities and eager to get your Honeycomb on, or just to check out the cool stuff Motorola’s got going on, please come on down. Register at the MOTODEV App Summit website.

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

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

Multiple Screens, One Server – Max Session

There are several ways to approach mobile application development. You can:

  • Write native apps
  • Write mobile browser based app
    • Rolling your own
    • Use a mobile framework
  • Use Flash and an AIR packager
Each has their plusses and minuses, but they all have one thing in common: They have to talk to a server somewhere. If I were to build the ideal server for a mobile application I think it would have the following attributes:
  • Ability to communicate with JavaScript Frameworks
  • Ability to communicate with Flash
  • Ability to communicate efficiently

It’s be nice if it did all that, and didn’t make me jump through hoops to get the same backend to do all three of them with the same code. If you threw in SMS communication, that would just be gravy.

It turns out (quite coincidentally) I know a server that fits all of those criteria. It’s also easy to use, and does a lot of other stuff for you. Of course it’s ColdFusion.
Come to my MAX Session Multiple Screens, One Server, to find out how ColdFusion can speed up your mobile development efforts.

Multiple Screens, One Server

Monday, October, 25th, 3:30 pm – 4:30 pm

ESRI Dev Meet Up – Philadelphia

I’ll be speaking at the ESRI Dev Meetup next week. It says it’s in Philadelphia, but it LIES… it’s in King of Prussia. Because I like to have all of my speaking engagements inside of monarchs of countries that no longer exist.

If you’re local to Philadelphia, you know exactly where King of Prussia is, and if you like GIS, then you’re going to want to come to this. I’ll be talking a little Flex, AIR, Mobile, and GIS.

Dev Meetup – Philadelphia
Thursday September 30th 2010
5:00PM to 8:00PM

160 N. Gulph Road
King Of Prussia, PA 19406

Lanyrd Page: