How to fix iOS7 and Flex Mobile with Adobe AIR 3.9 status indicator issue.

Recently Apache released Flex SDK 4.11 and Adobe release AIR 3.9. I currently have Flex/AIR mobile applications released for iOS in the app store that were compiled pre iOS7, and when iOS 7 was released my applications in their current state had no issues installing or running on the new operating system from Apple. As with every release of Flex/AIR though I test out how the application compiles, and with AIR 3.9 I noticed a big change.

The iOS status bar was now transparent, and was overlaying the header bar causing it to appear on top of the header text and nav buttons. I was not upset by this because this is something I wanted to do as this is how all the apps designed for iOS7 worked and I thought I would not be able to match using Flex/AIR. There has been some developers lashing out at ADOBE and FLEX in the forums calling this a bug, however I am not one of those developers. I am happy we now can match iOS7 design aesthetics using Flex/AIR, and with having to support multiple platforms/ devices I understand it is going to take some code.



To get it to work properly requires some configuration in your application. First you need to figure out what color you need the status indicator text to be. It defaults to black and on most interfaces unless your header is white - gray will be hard to see. So white works for most cases and to set this to white you need to do the following in your apps application xml in the iPhone InfoAdditions section.


view plain print about
2 <false/>
4 <key>UIStatusBarStyle</key>
5 <string>UIStatusBarStyleLightContent</string>



This will set your status bar text to white.

The next step is to now push the header content down to make space for the status indicator. I was able to do this by adding padding to the top of the Action Bar.


view plain print about
2        @namespace s "library://";
3        @namespace mx "library://";
4        s|ActionBar
5        {
6            paddingTop:40;
7        }
8 </fx:Style>



Adding this padding pushes the header down, and that is all you have to do. Keep in mind this will only address this issue for iOS7, so if you plan on supporting other platforms you will need to put in some conditional logic to check the device version and operating system to adjust your configuration to make sure on each platform your app displays as desired.

CFDirectory speed issues OR how I learned to love native Java functions

This little issue has cropped up from time to time during development with myself and several of my co-workers and you may have encountered this as well. Over time an application which requires a list of files begins to slow down, and the more the application is used, the more it slows down.


No flash in Android 4.1? That's the word from Adobe.

Reposted from, it appears that flash support is being cut starting with Android 4.1.

This isn't too surprising with the way web browsers in general are moving towards HTML5, but it's important to consider in future development decisions.

Adobe even goes as far as recommending that you uninstall any implementations of flash on 4.1 devices.


Functional Specs for Programming Projects

Functional Specs / Requirements Document

Here are some highlights from Joel on Software's very good analysis of why Functional Specs should be written. The entire article is a very good read for programmers and managers alike!

What are functional specs?

A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.

A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.

When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there. There's no use arguing about what programming language to use before you've decided what your product is going to do. In this series, I'm only talking about functional specifications.

Notable quotes from the article:

...Failing to write a functional spec is the single biggest unnecessary risk you take in a software project. It's as bad as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it." Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for...

...When you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad when they delete a paragraph in a word processor. But when you design your product in a programming language, it takes weeks to do iterative designs. What's worse, a programmer who's just spend 2 weeks writing some code is going to be quite attached to that code, no matter how wrong it is...

...Another giant important reason to have a spec is that without a detailed spec, it's impossible to make a schedule. Not having a schedule is OK if it's your PhD and you plan to spend 14 years on the thing, or if you're a programmer working on the next Duke Nukem and we'll ship when we're good and ready. But for almost any kind of real business, you just have to know how long things are going to take, because developing a product costs money...

Click here for an example of a good functional spec:

Read the full article here: Painless Functional Specifications - Part 1: Why Bother?