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.

Getting the Distance Between Two Points Using ActionScript

As you may know I recently released an application named Finicky that allows you to match up locally available items to locations. These locations are stored by their latitude and longitude coordinates. One of the features I wanted to enable was a display of the distance between your current location and the location of each item. To do this you have to do some math on the two pairs of latitude and longitude.

This is evidently a common need, and there is a mathematic formula with a name and everything:

The haversine formula:

a = sin²(^lat/2) + cos(lat1).cos(lat2).sin²(^long/2)

c = 2.atan2(sqrt(a), sqrt(1-a))

d = R.c

This frankly sounds like some sort of experimental drink that pulls a Jekyll and Hyde on you, but instead of making you a monster, makes you upperclass British. But I digress.

One of the cool things about it, is that as written it’s capable of finding distance in whatever measurement you want, as long as you know the radius if the earth in that measure. Very cool, math nerdy stuff. 

There is a great bit explaining this, and a version of the haversine formula in JavaScript at Movable Type Scripts. But I had trouble finding an ActionScript version. So I just translated the JavaScript version. It is included below.

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:

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

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.

NY Flex User Group and Flash and the City 2011

I’ll be in New York next week doing two events:

NY Flex User Group
Tuesday June 7th 2011
Razorfish: 1440 Broadway 18 Flr. New York, NY 10018
I’ll be talking about the Flash Builder 4.5 and Flex 4.5. But I’ll also touch on some of upcoming features of Flex and Flash Builder and showing off a few cool new mobile projects.
Flash and the City
Thursday June 9th 2011
Find out more
I’ll be talking about ColdFusion, what’s currently going on with it, and why you would want to use it as a Flash Developer.

Flex Media Queries for BlackBerry PlayBook

A cool feature now in Flex is media queries. Media queries allow you to deliver different CSS, depending on either the device OS or the pixel density of the device. This is very useful for tweaking your apps to work with the different standards for UI across devices.

Here’s an example. It changes the appearance of Flex menus on iOS, to make the look more iOS’y.

The relevant docs mention:

  • Android
  • IOS
  • Macintosh
  • Windows
  • Linux

But there’s no mention of BlackBerry PlayBook. After a little digging, I found this tidbit in the original sdk docs.

os-platform (allowed values are “Android”, “IOS”, “Macintosh”, “Windows”, “Linux”. Other values are allowed and will be matched against the three character platform abbreviation in Capabilities.version in case new platforms become available).

Which means the example below totally works for BlackBerry PlayBook.