This is an updated version of IOS Installed application I blogged about couple of weeks ago.

The biggest change is , this is no longer just to install iOS applications but Android ones as well. There’s a big IOS/ANDROID switch to manualy select the platform.

I did consider automatic platform selection by the type of attached device, but if you do a lot of cross platform development you tend to have both kind of devices attached, so in that case manual selection of target platform is best..

The other big change is, you no longer need to drag the application manifest xml file unto the app. Just the application file : .ipa for iOS and .apk for Android.

I unpack the application file in the memory and find the bundled application manifest and get the app ID information from it..

Getting into iOS development isn’t exactly straightforward. Even before deploying a simple test app on iOS device you have to get (and pay) apple developer membership fee, and then there’s a whole process of obtaining a developer certificate, generating p12 file and provisioning profile that needs to be bundled with your app in order to test it on device. This process is made slightly easier for users of Macs , since they have a nice keys management tool installed on every mac called Keychain.

On windows though there’s no such tool, and every single guide I came across (including the official one from Adobe) instructed users to install OpenSSL, and then use command prompt and type in paths, names , commands etc.

This was very tedious, slow , user unfriendly and error prone.

Thankfully, there is another way! It’s a OpenSSL based GUI for Windows called XCA: X Certificate and Key Management.

This tools enables you to obtain a personal development certificate, certificate signing request, private or public key encoded with 2048bit RSA encryption, export p12 certificate i.e. everything you need to do in order to publish a valid .ipa file for iOS device. All with nice drag and drop interface, with easy to manage and access sections, lightweight and organised. Secured and safe as well.

Although it would seem that you can do everything on Windows PC, in order to develop iOS app that’s not entirely true. Unfortunately, Apple has made the final step (of uploading the final app for general distribution via iTunes store) available only via mac OS only based software (xCode or appUploader). So you still have to use Mac (mac emulator) for this final step. I’d love to be proven wrong and if anybody knows of other way.. please leave a comment here!

Let’s face it, nobody in their right mind would describe developing applications for Apple as a “pleasant experience”. This is especially true when you’re on a PC. Especially when you compare developing android air app on PC and deploying it for testing on android device. The amount of hoops apple makes you jump through and the effort needed to deploy your app on device just so you can test it is just downright discouraging. The fact you need to use iTunes to deploy your app makes it very frustrating, as there’s a limit to a number of computers that are authorised to connect to certain devices, which is a pain if you have a multiple apple devices in the company, that we use for testing and debugging, and each of these when connected would have to be first sync, and depending on the size of your team de authorised from one computer to other, the whole deployment process just took too long and was a major pain.

Thankfully , since couple of month ago and version 3.4 of AIR we can deploy AIR apps directly to apple devices without using iTunes. There are couple of ways to do this – like using ANT scripts if you are using eclipse based IDEs, or command prompt, but none of them are very straightforward and user friendly.

That’s why me and my colleague Ben decided to make a GUI wrapper for this, that would make this matter of a simple drag and drop..

Don’t get me wrong. I LOVE FDT 5. I think it’s the best AS3 development IDE period. (The second best being intelijIDEA, if you must know.)

Especially with the new refactoring enhancements, improved mobile workflow, haxe support, build in Joa’s apparat / stripper / reducer abc optimisation tools and my two belowed magic shortcuts ctrl+1 and ctrl+shift+o that fix just everything you could wish for in the code. Having freshly upgraded from the version 4 Max to FDT 5 Max I was excited to try the new Air 3.2 gpu accelerated molehill capbilities on the iOS and android devices , perhaps revisit my Augmented Reality Demo so I can compare the performance now.

Made the simple hello world project, got all the appropriate certificates and provisioning profiles from our Apple Dev center, all the icons sizes, changed the app xml descriptor to say air 3.2 in the namespace, and hit the run button.

Now, if this was an actionscript error, you could follow it up to stack, see where it originated, what caused it and hopefully know how to fix it. Unfortunately this is INTERNAL error of FDT threw in Java, so all I could try was to blindly try to change some settings, tweak some launch parameters. To no avail. Luckily after some time spent googling I was able to find this issue being added to FDT’s bug tracker. It was caused by using the SDK 4.6.0 ! And solution ? You can still use the latest sdk, just have to go to the SDK xml descriptor file and manually rename it’s version tag to 4.5.0.

Once I found the ‘solution’ for the SDK problem, I thought I was on my merry way to the land of mobile development. Unfortunately, that wasn’t the case.

Although swf now compiled fine, instead of getting ipa file, I got message : application descriptor not found

Although there clearly WAS an application descriptor file! To cut the long story short, there was again an entry for this in the bug tracker.

The issue is missing stringAttribute key=”ADL_DESCRIPTOR_FILE in the launch file. Once I added line

to my .settings/launch/Air32Demo.launch file the ipa file has compiled correctly.

So at the end it all ended well. Right ?

Here’s my problem though..

Both of these problems were marked as “Solved” in the bugtracker. To me they are not solutions. These are “hacks” in the best case.

They’re both completely non transparent bugs, without any intuitive solutions. I think that for a $600 software, these ARE showstopper bugs, and should be dealt with immediately by releasing correction patch!

Now with AIR 2.6 iOS camera support and the unrestricted camera feed access to developers in iOS4, we can finaly build some cool AR apps on the mobiles right ?. Well… in theory at least!

The Setup :
To see how it would perform, I made a quick AR demo using Flar toolkit 2.5.5 for motion tracking and pattern recognision and Papervision 2.1 for the 3D scene. Scene consist of a simple flat shaded 3Ds model, plus 4 interactive buttons. The whole scene has less then 170 polygons. A very lightweight scene with very low poly count. To make the conditions fair for both devices I kept the AR scene dimensions the same (hence it looks smaller on HTC Desire HD). Both apps use gpu rendering.

I exported the app into an iPhone format using latest available AIR SDK – 2.6. For comparison I also converted the flash project into Android format. I tested the iPhone version on iPhone 4 and Android version on HTC Desire HD.

The demo has 2 buttons that enable the user to turn off the motion tracking/pattern recognition – (FLAR ON/OFF), and scene 3D rendering. By turning off the 3D rendering, and seeing the changes in frame rate, we can see how much resources are consumed only by the rendering of the 3D scene. By turning off the 3D rendering we can see how much resources are spent on the motion tracking.

Here’s the quick video showing the iPhone, and Android version

Framerate results comparison:

(Swf had frame rate set to 25fps)

And here are the lessons learned :

Lesson 1: Augmented reality can be implemented on mobile devices via flash conversion, just not in any usable manner

Although app will still run and function, the poor frame renders the application unusable. The problem is not just visual – stuttering screen playback, it’s also functional. If you have interactive elements in the scene such as buttons, low frame rate will make a click / touch detection difficult and user would have to try multiple times for a touch event to register.

Lesson 2: iOS conversion performance is superior to Android one.
Although both devices run on a similar hardware (both have 1GHz processor) and the apps were converted from the identical swf file – Android performance was on average worse. Also, while framerate on the iPhone seemed to be pretty stable, on the Android it was generally erratic and fluctuating.

Why is this happening?

I personally think it’s due to the way the apps are being converted and run on the device. While iPhone app is generated by converting the swf file into a native app, android app is being converted into an android air app compatible file and run by the Air runtime wrapper that has to be separately installed on the device.
That , in my opinion , creates a performance decrease , as it requires an extra hardware abstraction layer between the code and the device hardware. Think of it as flash file being run inside a flash plugin in the browser, versus OS native app. By design, swf app will never achieve the same performance as the native one.

The question here is , why does Adobe approaches Android conversion in this way. As for the iOS, it is quite clear why the iPhone apps are converted to native format. Apple wouldn’t let them do the Air wrapper approach. For the Android , they don’t need to however, yet they choose to do it. From the marketing point of view , it makes perfect sense of course. In the same way the spread of flash plugin helps to spread the entire platform and the tools (mainly the creative suite).
From the developers perspective it’s not that great though.

It means that every Android user , in order to run your app, will have to download AIR for android runtime. Although this helps to keep the file size relatively small (android version 451Kb vs 5.3MB iPhone version) the air runtime itself has 17 MB!
I would really like to hear justification from Adobe, as they were really conscious about increasing the file size of flash plugin (still less then 3MB) when almost everybody has broadband at home, yet they’re OK with forcing people to download 17MB on 2G/3G mobiles? I think they might be shooting themselves (and developers ) in the foot here.

The extra AIR Runtime file size issue is bad enough, but if you add an inferior and erratic performance to the mix there is really no reason to prefer conversion to air vs native app.

I am aware that performance in AIR 2.7 is better (there’s no Android Air runtime available at this moment so can’t test this personally) and with flash 11 and molehill we might see even better increase when it comes to GPU rendering.

However; there will always be applications that rely heavily on the cpu and for those, native app conversion will be always superior option.

Recently I’ve worked on a mobile app for the company I work for , and instead of just showing company’s address or displaying it on a map I thought.. wouldn’t it be more helpful to give user directions from wherever he is to where the company is ?
To do this, you of course, need to utilise a few APIs:

1. Google Maps API to download map tiles and draw a poly line from user’s location to destination,
2. Air’s Geolocation API to determine current users location
3. Air’s Multitouch API to let the user pan/zoom and rotate the map.

Getting the google maps to show on your display list is pretty straightforward, there’s a couple caveats though. It is now compulsory to initialise map with a sensor parameter (just a Boolean switch expressed in string format indicating whether map is used on a device with geolocating sensor.)
Also , to get it working in AIR app, you have to pass the ‘url’ parameter. I used local host for this.

Once we have the GeolocationEvent fired , we can determine user’s location from event.latitude and event.longitude.
However, Google maps Directions.load normally works with address format query, eg. “from 25 apple Street, NewYork to 22 Boulevard Street, San Francisco”. To get it working with LatLng you have to use this format (Thanks to Barry Hunter from Google maps forums for this tip)

It’s important to centre and zoom the map so that the whole journey is visible on the map.
OnDirFail is called when the given coordinates couldn’t be resolved, and then it’s probably best option to give user a chance to input the address manually.
Tested on Android 2.2 on Desire HD with Air 2.6 runtime.