Randy Troppmann

In my last post last post I mentioned that I was surprised not to find a tweening library included in Grant Skinner’s EasleJS. Wouldn’t you know it? Less than a week later Grant posted an alpha build of TweenJS. With not a whole lot of effort I was able exchange his library with my hacked version of Gtween.js. The API is intuitive and flexible. I loved how I could chain commands together and easily insert callbacks anywhere in the chain. You can see a version of the “Classical Pathway” activity that uses TweenJS here.

I am very interested in learning more about the HTML5′s Canvas and the workflow needed to build things normally tackled with Flash. I took a stripped down version of a Flash-based learning object and tried to recreate it using Grant Skinner’s EaselJS. The EaselJS package included a drag and drop example which got me up and running quickly. I was expecting but did not find any tweening methods included. I came across Gtween.js which is Josh Tynjala’s port of Grant’s AS3-based Gtween library. I added a couple things to Gtween.js:

• tie it into the EaselJS ticker
• add a tween finished callback parameter

Below are links to both the Flash and HTML5 versions. There is no question that the javascript can use some refactoring, but this is as far as I need to take it. Need to move on.

HTML version
Flash version

Conclusions:

Is Html5 + Canvas + Libraries capable of recreating this project? Definitely.
Is H+C+L an appropriate solution? No. Not enough browser support for Canvas at this time.
Did the H+C+L take more time to do? Not really. But I kept the tweens very simple. Didn’t add hit-zones.

Without a timeline to manage the assets, I found myself struggling with how to manage the collection of visual assets. The procedural spaghetti code technique is confusing and won’t scale well to larger projects. Next I would like to investigate a more structured MVC way of coding apps in javascript. You know, objects. Prototype? Really? Ugh.

Here is another problem that gets me once in a while and I end up figuring it out from scratch rather than searching google or my own previous solutions. I am blogging about it here now because it may save you or me a little time in the future. I would love for someone to show me a better algorithm. I make no guarantee that this is best approach.

The Problem: how to resize an item to fit into another that may or may not be the same aspect ratio.

The Solution: The first thing is to determine if the object is too wide or too tall in aspect ratio compared to the container. I do this by comparing the values of width divided by height for both objects. If the container ratio is less than the object ratio then the object is too wide in aspect ratio. I therefore make the width of the object the same as the width of the container and apply a formula to the height (See code example below). The opposite occurs if the ratio is greater.

Try it out in this SWF. Drag a box into the outlined area called "DROP".

Download the source FLA here.

This blog post is largely for myself because I keep forgetting the details of this.

In the past I was under the impression that you could encode video at any size as long as you kept the aspect ratio. For a recent project it was determined that a video width of 528 pixels would best fit the layout. Using this formula determined the height given an aspect ratio of 16w x 9h:

height = 0.5625 x width

This resulted in a video dimension of 528 w x 297 h. This dimension became problematic in some not-obvious ways. First of all some encoders simply won't let you enter that dimension. When you manage to encode the videos the FLV version works fine but the H.264 version doesn't render properly. This caused me to tear apart our custom made Flash video player to diagnose the problem since my co-worker was blaming the player. It turns out the player was not the culprit.

I learned that h.264 likes to encode using 16 x 16 blocks. (It was difficult getting to the "simple" truth of the matter because of a lot of mis-information in the google). This means both dimensions should be divisible by 16 which does not leave a whole lot of combinations to work with. The source video dimensions should also obey this rule. Andrew Armstrong's blog post shows a list of suitable dimensions you can pick from. Another chart is shown here.

I picked the dimension 512x288 and adjusted the layout to accommodate. Graphic designers take note! While you are definitely not stuck with a single video dimension for layout purposes, there are reasons for the existence of standard dimensions.

I attended Adobe MAX this year and one thing that caught me by surprise is the Research and Motion partnership with Adobe: RIM has gone all-in with AIR support on their new tablet device called the BlackBerry PlayBook.

More on that in a bit. Max was the first public demonstration of the PlayBook. (Watch the day 1 one keynote here). I also saw the PlayBook up close but it was mounted behind glass.

The device and specifications look very impressive, just from a tech geek standpoint. And it runs Flash. Not only that, it has the Flash platform deeply integrated into the OS. From a developer's perspective I am really stoked that RIM has released an AIR SDK for the device. After working with AIR for Android for the last 6 months, I am jumping at the chance to play around with this new platform.

I referenced Shashank Tiwari's blog post which helped me

• download the BlackBerry AIR SDK
• install it into Flash Builder
• download and install VMWare Fusion
• download and install the PlayBook simulator into VMWare
• take an existing AIR application and get it to run in the PlayBook simulator

It all went very smoothly and I didn't have to change anything in my AIR app to get full functionality. (That being said, my app is not designed for touch and needs to work to really take advantage of the platform).

On the deck for me is some work around building an iPad app for a client. Suddenly AIR is very attractive because I can sell them on the idea of build once and deploy on multiple platforms. This no longer just marketing speak but a reality. Great times to be a Flash Platform developer!

You can find out more about AIR development for the PlayBook by joing in on the live webcast series which you can watch or register for at this PlayBook developer resource. You can also get yourself a free PlayBook by developing an app! Here are some additional links:

http://us.blackberry.com/developers/tablet/
http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/bd-p/tablet
http://us.blackberry.com/developers/tablet/devresources.jsp
http://labs.adobe.com/technologies/flash/blackberrytabos/
http://us.blackberry.com/developers/appworld/distribution.jsp
http://renaun.com/blog/2010/11/repacking-an-air-based-apk-to-playbook-bar/

Day 1 at FITC Edmonton is over and my mind is already blown. In a good way. Branden Hall gave us a full day workshop on the Hype Framework which enables incredible beauty with simple code. Here is some takeway code that he "whipped up" in front of us. (this is my own version ... I swapped out the photo with one of my daughter)


(Click image to see it in action!)

Very inspiring Branden. I will definitely use this framework in the near future. Here is the code used in this project. To use it you will need the HYPE library.

A year ago our RunningMap.com companion app called Trackometer went on sale on the iPhone App Store. On October 8, an iteration of this app became available on the Android Market.

A year ago I had no intention of producing an Android version anytime soon. Fast forward five months. Who knew that Steve Jobs would declare war on Flash and alienate every Flash developer on the planet? Who knew that Android uptake would explode?

In March 2010 I travelled to San Jose for the 360Flex conference and had an interesting chat with Ted Patrick. A couple weeks later Ted called me and ask me if I would consider porting my Trackometer app to Android using some prerelease tools Adobe was developing. Yes! The project was a perfect fit.

I used the same workflow as with other recent Flash app projects: pure AS3 project using RobotLegs and mxmlc via Flash Builder. The visuals from the iPhone app were made in Illustrator so it was not a lot of work to adapt the graphics to the higher res screen. For the iphone app, the custom graphics were bitmaps. This time the graphics were all vectors imported into Flash, optimized and then compiled in a swf which was embedded into the pure AS3 project. I didn't hold back on drop shadows and other effects because I knew FPS was not a huge issue. Many thanks to Matt LeGrand for the multi-touch code; the map has pinch zoom!

I wanted the app to look and function just like any other Android app. Which meant using the Android context menu and other UI elements. But in AIR we get no access to native chrome so I had to build it all myself and "imitate" the context menu animation effect. It was a lot of work. More work than I thought it would be. Even still it's not perfect, but I had to move on ... perfectly mimicking the way a dialog box appears is possible but I had other challenges to tackle. The big advantage of the DIY components is that there is only enough code that is needed. No bloat.

So many things could have derailed this project. Show stoppers. But the first 95% of the app went smoothly. The SQLite SQL from the iPhone version ported perfectly to AIR. The last 5% was as much work however than the first 95%. When the build was feature complete I declared it as being in BETA. Testing testing testing. Bugs bugs bugs. Found them; squashed them. The night before release I was still tweeking things. Finally reached release status!

A hundred little details beyond the testing and the bug fixing needed to be attended to. Launching the iPhone app taught me that bringing software to market was a ton of work and this time I was more prepared.

Debugging on the device is challenging but the ADB Logcat application that comes with the Android ADK is pretty cool!

I am writing this is a hotel room in Los Angeles. Tomorrow is the big keynote at Adobe MAX and I can't wait to see what Adobe has to announce. I've been told that Trackometer will be demo'ed at the conference in one way or the other and it will be cool to see where it shows up.

UPDATE: The keynote was GREAT! It turns out every one at MAX gets a free Motorola Droid 2. The BEST part is Trackometer was preinstalled on all of them. If you are one of the lucky recipients of this phone, please note that you will have to update the AIR Runtime from the Market to run the AIR apps. To run Trackometer you will need to turn on GPS and be connected to a data network. The version of Trackometer installed is a little old version so if you like it, grab the latest version from the Android Market.

- Randy

This video demonstrates how Trackometer for Android works. My friends were asking me how I shot this. Here is the rig:

An amazing photo from Leonard Nimoy! He tweeted this on Mother's Day.

At the recent Google IO conference Adobe announced the public beta of Flash Player 10.1 for Android and the public prerelease program for AIR on Android.

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.