boostworthyisryantaylor

I am pleased to announce that the Flex application we (Schematic) have been developing for several months now has officially gone beta. We still have a long road ahead of us before it will be finished, but this is a huge milestone for us nonetheless. Here are some interesting details about the project:

Credits:

Flash development: Schematic
Production/design: Turner Sports
Data: PGA Tour and Turner Sports

Fun facts:

- Built on Flex and Cairngorm frameworks

- Wrote our own lightweight 3D engine for projecting 3D shot plot data on 2D hole graphic renderings

- Full browser integration - relies on the browser scroll bar, back/forward buttons, wide range of deep-linking capabilities

- Capable of rendering a leaderboard over 10,000 pixels tall with a single SWF file

- Turbo is being written specifically to meet the demanding performance needs of the application

- New data is polled every 30 seconds and distributed through the application automatically via our elaborate model and data binding rig

- Custom model adapters support gzip compressed or uncompressed data in the form of either JSON or XML

Again, we still have some performance/memory enhancements to make, bugs to fix, and features to add - but it’s a start! If you are interested in checking it out, Mike from Turner Sports has posted a link in the comments below. You’ll want to view it during a live tournament, which typically occurs Thursday-Sunday morning/afternoon (ET).

There is a pretty cool idea being tossed around for a chapter in the AIR Bible and we could really use some feedback from all of you. The more feedback we get, the better - so please participate! Here are the questions:

1.) What operating system do you prefer? If Linux, please specify a flavor (Ubuntu, etc.)
2.) What are your primary development tools of choice?
3.) Have you built or contributed to an AIR application yet?

Thanks in advance for your feedback; much appreciated!

[Update: 03/20/2008]
Adobe’s comments the other day were widely speculated upon since the terms of the SDK prohibit plug-in development. Adobe has since clarified their position on the matter with some additional insight in the article below.

http://www.news.com/8301-13579_3-9898166-37.html?tag=nefd.lede
[/Update]

It’s official - Adobe is working on a special version of Flash Player for the iPhone using the recently released SDK. Adobe’s Chief Executive Shantanu Narayen was quoted yesterday in saying “We believe Flash is synonymous with the Internet experience, and we are committed to bringing Flash to the iPhone”. “We have evaluated (the software developer tools) and we think we can develop an iPhone Flash player ourselves.” This is obviously amazing news since Jobs himself stated a few weeks ago that Apple had no plans to tackle the issue. Big props to Adobe for stepping up and making it happen!

More info… http://www.macrumors.com/2008/03/18/adobe-bringing-flash-to-the-iphone/

I’ve had a splash page up for the past two years; I finally decided to throw something new together as quickly as possible for showcasing some of my work. Here is the result:

http://www.boostworthy.com

I just wanted to get some of my design work out there, since most people know me best for my programming side. I have a bunch of Flash experiments and some motion graphic pieces I would like to post, as well as some other cool projects, but this will have to do until I can spare another day or two to gather assets once more. Please, by all means, leave any feedback that you might have.

I was recently reading Nicolas' most recent post on Flash 9 optimizations and I noticed that he had mentioned the use of an 'Allocator' class to help cut back on object instantiation. I actually have something along those lines in my personal framework, so I thought I would share it with you all.

First, a little bit about the subject. In an application in which you are constantly creating new objects, whether it be display objects or otherwise, you are going to suffer from a few different problems...

The first problem is performance. Creating new objects is somewhat slow, especially if their initialization process contains a lot of code. Performance is also affected by garbage collection. The more objects that are created, temporarily used, then left for garbage collection, the more that Flash Player has to work to clean up after your mess. This type of strain can be seen on the processor if you are monitoring processor load.

The second problem is memory. If you are constantly creating new objects for temporary use, the odds increase that you will screw up somewhere and things won't get garbage collected properly. When this happens, it is called a memory leak. This is a pretty serious problem because potentially it could cause your application to crash along with the browser and maybe even the user's machine.

You can cut back on these types of issues by simply keeping a close eye on your application piece by piece from the very beginning of development on a given project. Tools such as the Flex Builder profiler and the use of utilities such as 'getTimer' for timing chunks of code will help you a lot during this process. Depending on the complexity of your application, you may wish to take things a bit further to really help control the amount of new objects being created. That's where my 'Allocator' class comes into play.

The 'Allocator' class is pretty simple; it's composed of an array for caching objects, an index for tracking position within the cache, and a class type that the allocator instance is responsible for caching. Usage is pretty straightforward:

In practice, this type of workflow is ideal for a Flex application in which you are binded to data which is constantly changing. Rather than creating new model objects upon each data refresh, you create them once, then recycle each model object by passing the existing objects the new data. The sample files I have prepared for inclusion with the 'Allocator' source files demonstrate a basic model architecture that lends itself nicely to all of this.

Also worth noting is the performance numbers resulting from the included test file. The test runs two for-loops; the first one creates and caches the objects as the requests are made to the allocator for the first time. Next, the allocator is reset, then the second loop once again requests instances from the Allocator. Here are the results:

Initial -> Time: 0, Memory: 6815744
loop #1 -> Time: 20, Memory: 7467008
loop #2 -> Time: 22, Memory: 7467008

Notice that the first loop took 20 milliseconds and memory increased. The second loop only took 2 milliseconds and memory did not increase. Ten times the performance and no temporary memory increase is exactly why the Allocator is so useful.

Download 'boostworthy_alloc_src.zip'

Hopefully you will find this stuff useful in your projects. Feel free to share any questions or comments that you may have.

Wow. The iPhone SDK is amazing. If you haven't seen it yet, go watch the keynote and read up. If you're interested, the SDK is available as a free download.

http://developer.apple.com/iphone/program/

I'm getting setup with everything right now; I've never developed with Xcode, so I'm anxious to experience the Apple development experience for myself finally. I'm not sure how I'm going to find time to play with this stuff right now because I haven't even had time for sleep lately, but I must find a way. Once I do, I will post up my thoughts and review of the experience as soon as I can.

There has been a lot of extra chatter this week regarding Flash support on the iPhone. This was the result of a combination of some recent rumors suggesting that Flash on the iPhone was imminent, followed by some statements that Steve Jobs made at the latest Apple shareholder meeting stating that it's not happening anytime soon.

Here is a pretty in-depth article which really digs down into the technical limitations that are preventing this from happening:

http://www.appleinsider.com/articles/08/03/05/steve_jobs_pans_flash_on_the_iphone.html

Likewise, Ryan Stewart has spoken out against claims that Flash Lite won't fit the bill in one of his recent blog posts as well:

http://blogs.zdnet.com/Stewart/?p=777

My two cents on the matter is that it should be all or nothing. Until the iPhone is capable of handling the standard Flash Player and a majority of typical Flash sites (meaning ones that aren't extremely processor/memory intensive), I can live without it - though it is greatly missed.