PANMA January 2014

panmaI’ll be speaking in the Philadelphia area this Thursday January 30th at the monthly Meeting of PANMA.

PANMA for anyone not acquainted with them is the Philadelphia Area New Media Association.  It’s a great group of people and it’s a great opportunity to network with people from various viewpoints in the digital world.  

I’ll be talking about getting your websites to work on mobile devices.  It’s a departure for me from my normal schtick.  I normally push responsive web design as the only real option, and recommend that you use Adobe Edge Reflow for it. I’m changing my tune a bit, as I realize that not everyone has access to the resources to make a pure responsive site happen.  So I’ll include other paths from Adobe, including Adobe Muse, Dreamweaver, Photoshop/Edge Reflow, pure code, and others.  We’ll see how it goes. 


Date: Thursday, January 30, 2014
Time: Doors open at 5:30pm. Program runs 6-7:30pm. Q&A and networking until 8pm.
Location: Room 260, Huntsman Hall, 3730 Walnut Street, Philadelphia, PA 19104

Please register:

Android Toast-like Alerts in HTML using CSS

One of the little things I like about Android is the “toast.” If you are not familiar with the toast, it is the little transparent notice you get that operations are done. The best example is the toast that tells you how long you will have to sleep before your alarm goes off. (Pictured here.)

I really like the concept. It usually short-circuits the whole item editing process.

Without toasts:

  1. Click save button.
  2. Get feedback that item has been saved.
  3. Manually go back to previous screen.


With toasts:

  1. Click save button & go back & get feedback.


I wanted to implement toasts in an HTML PhoneGap application. Now I know I could do this with just JavaScript, or with jQuery, but I really wanted to give CSS transitions a try. CSS transitions allow you to alter a CSS property over a set period of time. They work really well for this sort of case.

So the first thing I have to do is apply the transition.

You’ll notice a couple of things here. One the syntax for the transform is pretty simple:

[browser css keyword]: [property to animate] [duration] [easing method]

Once you do that, the rest is really simple. Basically, all you have to do is change the value for the property you have added a transform to, and the browser takes care of the rest. So to fade out my toast, I set the opacity to 0. That’s it.

See the demo.

Why do I like this:

  • I always prefer doing visual things in CSS.
  • This seems to me to be simpler than using JavaScript animations
  • CSS transitions will be hardware accelerated on environments that support doing so.


Now, I have to tell you there are caveats:

  • It doesn’t work in IE
  • I’m sure someone who knows more than I will put more in the comments

But it does work within the mobile browsers I tested on iOS and Android, which means I’m free to use this in my PhoneGap application.


Finicky, now for iPhone

I released a version of Finicky for iPhone earlier this week. It’s up and running in the app store.

Design Differences
You’ll notice that it looks somewhat difference from the Android version. This is by choice. In trying to get the iOS version working, I noticed significant issues with the UI we had designed and the iOS version. However I was still able to capture the feeling I wanted through color and font, without having to compromise too much on the design.

Feature Differences
I was able to support pretty much all of the features on both devices with the exception of mapping. I had issues getting the maps to work in production build. Worked fine in both the desktop debugging version of AIR and the fast compile version of the iOS app. It only failed on the full compile version of the iOS version. I anticipate having them working in an upcoming version.

Coding Differences
My original path was to have 2 separate code bases. I know, I know, this is all about not having to do it twice, but I was weak. The major reason behind this was that the iOS version had to run leaner, because, well, you know, performance is king. There was a good amount of Android specific UI and features that I just set to visible = false. That did terrible things for speed. So I stripped out all Android specific code, removed anything from the UI that I wasn’t showing on iOS, and generally improved performance.
However, after awhile I found two code bases presented a lot of problems. See, I’m not the best coder. I know, shocking. But I had bugs in my code. And I found a lot as I was going through and tweaking for iOS. But I had to manually copy them back to the Android project, as my git-fu is not so great.
I went back to one code base, but instead of ripping out Android specific UI and features, I loaded them conditionally. This gave me comparable performance, but allowed me to run both apps from the same code base.

2 Targets 1 Code base
If I had to do it again, what would I do different? First, off, due to some advice, I made a couple of good calls early. Kevin Hoyt pointed out, and Renaun Erikson echoed: design for iPhone 4 first, in terms of design assets. Everything else is a step down in terms of resolution. However, I developed for Android first. I’m not sure if this is the right move. I think it’s easier to add things, then it is too take them away. My process had me taking a whole bunch of things away. If I had it to do over I might develop for IOS first, then selectively add features for Android, BUT release for Android first. Maybe… I dunno. The thing I love about releasing on Android first is that I get stupid bugs out of the way on a platform that allows me to iterate through releases as fast as I can fix bugs. This isn’t necessarily a shot at iOS or Amazon or Nook or BlackBerry. I think their approval system does make you think harder about whether or not you have bugs before you submit. But, that being said my problem is not that I do not think, but rather that I often don’t think the right way. Being able to quickly react to real issues, is better then having me ruminate on what I think might be happening.

So there you have it. One app two platforms. Will be getting it onto Amazon and Nook next.

Motorola at Adobe MAX

If you’ve done any Android targeted development, you’ve had the experience of getting your app out only to realize that your app looks terrible on a device you didn’t consider testing. Maybe nobody you know has it. Maybe you thought it would work alright because it works on a similar device. But it’s embarrassing, gets you bad reviews early out the gate, and frankly is a hard problem to combat. You can’t own every device.

Which is why I’m excited that Motorola Mobility is up to something really cool with their sponsor booth at MAX this year. Instead of merely showing off their latest and greatest device, they are setting up a test lab in their space. The test lab will do 3 things:

  • Let you test your device on Motorola devices
  • Help you get your app on the Android Market (They’ll cover the developer license)
  • Potentially aid you in marketing via Motorola Mobility

All in all this is a great opportunity to get some help from an actual device manufacturer with tons of experience in bringing mobile apps to market. It’s tough for a lot of us who are lone mobile developers to get this type of feedback. All you have to do is stumble* into the Motorola Booth at MAX to get it.

This past year I’ve had the great pleasure of traveling with some of folks at Motorola Mobility during their tour for the Motorola XOOM. They’re a great bunch of people to work with, and they have the same passion for their community that we at Adobe do for ours. They’re a great fit here.

This is an awesome opportunity; I recommend that if you’re at MAX you take them up on it.

To find out more, check out the MAX Blog: MotorolaMobility@MAX.

* You can also walk, jog, stride, hop, roll, shuffle, or dance into the Motorola Mobility Booth for the same treatment. Swaggerers need not apply.

Articles That Helped Me Build Finicky

On Friday I announced the release of Finicky, a new mobile app built using Flex and AIR. I wanted to take the time today to give some link love to all of the articles I used to work out the various challenges of writing a Flex Mobile application. Hopefully this list points people to something that could help them. I’m sure I’m missing some, as I did try to grab these links as I went; I’m sure I forgot to grab one or two.

Jason’s Flex Blog
I don’t know what exactly I cribbed from Adobe’s Jason San Jose, but I know it was a lot. Pretty much every bug patch, or skinning hint that I got was from him. Just read his whole blog.

@renaun posts: Using Flash CS5 to embed Fonts in SWC to use with Flex Hero and Flex Mobile Hero
Finicky uses a lot of custom fonts. My teammate Renaun Erickson has a great post here on getting all of your fonts packaged together in a SWC file for inclusion in your apps.

URI Handlers in AIR for Android: Phone Calls, Email, Text Messages, Maps, Market, and URLs « Christian Cantrell
I wanted to launch Google Maps for getting directions to a location listed in Finicky. Adobe’s Christian Cantrell sums up how to do it pretty perfectly.

Using Menus in your Flex 4.5 Mobile Application | Devgirl’s Weblog
Fellow Adobe Evangelist Holly Schinsky has a great post about using and styling menu controls in your Android AIR apps.

Reskinning the Android contextual menu (ViewMenu and ViewMenuItems) in Flex / AIR mobile to look like Gingerbread black – daaain’s thought stream
Daniel Demmel has another helpful article that helped me get through skinning the menus.

Android, AIR and the Camera | RIAgora
A small part of the UI is grabbing pictures that you can associate with items. To do this I needed to work with the camera in AIR. Another of my Evangelist peers, Michaël Chaize, has a helpful post about doing just that.

Tips for Flex mobile apps | RIAgora
Michaël also has a great article here detailing a bunch of little hints for building mobile apps with Flex. I used at least half of them.

ArrayCollection Filter Example |
I’ll admit it, there are pieces of basic Flex that I don’t know off the top of my head. Filtering the results of an Array Collection is one of them. So Roelof Albers’ post was very helpful .

Tombstoning in AIR-Mobile Applications « Filthy Rich Applications
One of the things you need to do with mobile applications is deal with deactivation events, or what do you do when someone calls, or the user just switches to another application. Finicky uses geolocation, so I need to be very careful about preventing wasted battery life. Adobe Technical Writer, Frank Jennings’ post has great information handling these cases.

AIR on Android OS Interactions – Send Email | EverythingFlex: Flex & AIR
Sending email from a mobile app is pretty commonplace. Doing it is well explained by this article by Rich Tretola.

AIR SQLite Optimization tricks | Parametrized SQLStatement | SQLite Transactions | zedia flash blog
Working with IO can be expensive in a mobile application. I didn’t realize how much so until I started doing some bulk inserts of sample data. So I needed some AIR optimization hints. I had forgotten completely about transactions, but luckily for me, this Dominic Gelineau post reminded me.


Finicky – a Flex and AIR mobile app

For the past few months, I’ve been working hard on a mobile app called Finicky. It’s a mobile journaling application for tracking hard-to-search-for, local items.

The idea for it came to me in San Francisco. I wanted to smoke. I smoke cloves. (Make your hipster jokes.) However, cloves tend to be a little hard to find. Most convenience stores don’t carry them. The tend to be found in tobacco shops, head shops, and occasionally at a random spot like a newsstand. I tried searching on Google, but it’s hard to get reliable data on which stores stock them. The really frustrating part of this was that I know I had found them before. If only I had somehow kept track of it…

Now a mobile app just for tracking cloves would be overkill. But as I thought about it, there were a lot of things that I would love to track like that. Ever been a Coke/Pepsi fan in a Pepsi/Coke town? Can’t search that out. I like a whole bunch of other specific things. So thus was born Finicky.

I approached this a little different from most of my apps, in that I got design help from the beginning. By design help, I mean a full Photoshop comp and UI treatment. I wanted a different look for my app then I’ve seen with most mobile apps, especially on Android. I wanted something grungy and organic. I know what I wanted, but I don’t know how to design it. So I got help from The1stMovement, a design firm who our team had done work with in the past.

What they designed was beyond my imagination. Hence, why I needed a designer. It’s great looking, it’s got a specific style, and it doesn’t look like anything I’ve seen on a phone.

I took those comps apart and turned them into mobile Flex skins. And here is the result. I am releasing it as an Android app first. Then releasing it as an iOS app. I’m going to have it out on Android, iterate through bug reports as fast as I can, then when I’m sure of stability, get it onto iOS. For now I’m targeting just phones for this app. If it there is interest, I’ll port to tablets.

In any case, find out more and link to downloads at

Source is available on github

Delay Closing Mobile Apps on Exit

When a user switches to another application on a mobile device AIR on mobile applications keep running. It continues to hold on to resources, fire off events, and has the potential to use power draining resources like network calls, or geolocation if your app makes use of them.
That’s why one of the first tips you see is to kill or tombstone your application when the user switches away from it. In general, unless you have a good reason to do not do this, you should. Your users might not notice that you drain their battery to zero, but then again they might.
But I have a good reason for not wanting to do this right away. Actually I have a few:

  • As a user, I frequently accidentally hit the home instead of back button
  • As a user, I frequently lookup stuff on the web then come back to an application.
  • As a developer, I frequently makes calls to OS resources like the camera or mapping in my app.

All these add up to needing to revisit closing on exit.
I’d like to get the benefit of closing on exit in terms of resource usage, but I’d like a grace period. So, my solution, fire off an event when a user leaves the application, that sets a timer to shut down the app. Then if the user returns, kill that timer.
Simple, easy, and best of both worlds.

Flex Mobile – Getting Rid of the Action Bar

The viewNavigatorApplication framework in Flex 4.5 is awesome. The ability to manage the various screens of your application is really useful and powerful. But one part of it doesn’t make sense in all applications.

I speak of the ActionBar. This is the UI chrome at the top of the app that contains the screen title and any application navigator features you use. This make a lot of sense in iOS or PlayBook apps, where the entire UI is software based, but in Android, you should use the hardware buttons. If all of the controls move off of the ActionBar, then depending on your needs it might make sense to get rid of it completely.

This is easy enough to do in a view, you just turn it off by setting actionBarVisible=”false” on the view. This worked for me for awhile, but then I changed the way I set up my application. I followed tip number 2 on this post by my colleague Michaël Chaize. In short, I load my data on application start, and push to the first view only after the data has loaded. Makes for a great experience for the user, except that I was getting flashes of the ActionBar while the data was loading up. I can’t tell what exactly is going on, but it looks like there is some sort of placeholder or default view that’s not obvious.

This was a pain for me for awhile, but today I finally figured out how to fix it. On your main application page, where you define viewNavigatorApplication, set actionBar.visible=false;

Good thing to note is that this only affects the ActionBar that is visible in that little flash; if you make another ActionBar visible later, it will show up.

Here’s the source:

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!