I’ve been working with the AIR for Android SDK for a bunch of weeks now and Adobe loved my prototype of Trackometer (info on the iphone version) so much they were going to include it in the Day 2 keynote demos at Google IO. I guess Google put serious time constraints on things and the demos did not happen on the main stage. However, Trackometer was demonstrated in the Adobe booth and the AIR team featured it in their blog. Ted Patrick also included it in his demo in the video below (see 2:00). Adobe also used the Trackometer source code with Flash Builder to do a live demonstration of compiling and moving the application to a device.
Work continues on the Trackometer app. It will have more features than the iPhone version currently has.
Adobe’s recognition is a huge thrill for me and a nod to independent developers. My inclusion in the private prerelease group was a direct result of the 360Flex presentation I gave in San Jose this past March. I have to pass on a big THANK YOU to Andrew Westberg for asking me to co-present a topic and to Tom Ortega/John Wilker for accepting our presentation proposal. This proves that sometimes you just need to get away from your computer, get on a plane, and go and talk to people in the industry. Face to face.
Adobe loves choice. They believe you should be able to develop once and deploy across multiple screens. Or devices. RunningMap Trackometer is a real example of this happening. To the right is a swf that is a proof of concept for an app that is being developed to run on Android-powered devices using Adobe’s AIR for Android runtime. To make the point clear, this swf was compiled from the same source (minus some device specific calls) that is used to compile the app that runs on Android mobile phones.
I have developed apps for the iPhone – one of them award nominated. RunningMap Trackometer for the iPhone was accepted for sale October 2009. I think it is a great platform to develop for and has tons of potential. But, learning Objective-c and Cocoa was and is tough for me. It’s pretty foreign and it still sometimes takes a long time to solve simple things. I have no doubt that will get easier over time and I love to learn new things. Once you get into it Objective-c has an oop-elegance about it. The real barrier in my mind to creating apps for the iPhone is the torturous process you need to go through to test, provision and submit your app so that you have maximized your chances at Apple blessing it and allowing it to be sold on the App Store. Anyone who has been there knows what I am talking about so I will stop there.
Trackometer for Android is not so much a port of the iPhone app as it is a port of the RunningMap.com application itself, with far fewer features. I’ve been developing for the Flash platform for 10 years and, unlike when I program in Objective-c, problems are solved very quickly. The workflow is like butter. And this is full blown Flash. While developing using the AIR for Android SDK, I did not need to change my well-honed workflow in any way, shape or form. RobotLegs is there. GTween is there. Flash Builder goodness. The API is only limited by the new paradigm; MOUSE_OVER, for example, is not possible with a touch interface. In fact there are a host of new APIs. Geolocation for example. And Trackometer uses that. Try to take your laptop for a run and see how fun that is.
So far I am amazed by how well AIR for Android performs on my Motorola Droid.
Getting the app on your phone is SO MUCH EASIER than with iPhone apps. No provisioning etc. Android phones could install Trackometer directly from this blog post if I placed the package here. But I can’t be cause a) Trackometer is not finished and b) the AIR for Android runtime is not released yet. I’m not sure when but I hope to know soon. I can’t wait.
An important lesson I learned today: the onRegister() method of a Mediator in the RobotLegs framework get’s fired when it’s view is added to the stage. This means that the event mappings and event listeners that you place in the onRegister() method will get invoked each time and (assuming you are adding and removing the view multiple times) unless you use the onRemove() method to un-map and remove the event listeners, you will most certainly get a memory leak. Good to know!
This is a little inconvenient because I was hoping that I could use the mediator event handlers to update a view while it is not on the display list. As it turns out, the mediator will not respond to event mappings when it’s view is removed from the stage. Also good to know.
