One of the most highly anticipated features in Flash CS5 is the iPhone application packager. This will allow Flash Designers and Developers to create new applications for iPhones, iPod Touches and iPads. One of the greatest things about this in my opinion is the opportunity to port over existing content and applications to the devices. If you have a stack of RIAs, eLearning modules, or other Flash content that you think would be appropriate for a mobile device like the iPhone, it’s a great opportunity to give that content some new life and reach a whole new audience. If you have considered entering the world of iPhone development beforehand but were held back by the toolkit (Xcode being Mac only), or the language (Objective C is certainly a bit more high level than ActionScript), this is also a great chance to target a very popular family of devices.
The possibilities for eLearning/mLearning developers on this platform are virtually limitless. With institutions like Abeline Christian University requiring iPhone/iPod touches for all students, and the recent uptake by a number of large corporations, it doesn’t seem that the rate of application development and deployment (billions and billions of apps downloaded) is slowing down anytime soon. It seems that the market is there, and as of yet, there is not a corresponding huge development crowd in the eLearning world that is comfortable with the advanced toolkits required to create the content for the iPhone. It’s only a natural fit then, to think that eLearning professionals have interest in this new avenue. Porting eLearning content to a mobile device friendly format is a burgeoning field. This is obviously commonly known as mLearning. Barring some basic misconceptions that simply making your eLearning content work on a handheld is the perfect way to go (answer – it’s probably not), this article examines some of the technical considerations you need to recognize in this transition.
For Flash platform content creators there are a number of things that you must consider in making the transition to the handheld world. For those of you familiar with targeting other mobile devices using Flash Lite, much of this will be familiar. For designers that have only delivered to the desktop or laptop there are some big changes in front of you.
The Flash community is rapidly testing this new opportunity out and documenting these differences. Mike Chambers has a great presentation on basic performance optimization tips that is well worth the download and a must read for any nascent iPhone Flash developers. Christian Cantrell has a great article at the Adobe developer center on the new input modes that are available on the devices. Some other content from Max of last year is still very much applicable, though some minor changes have occurred that put a little of the content out of sync with some other sources floating around out there. There are even some links offering tips for the, as of yet unreleased, iPad. At Float we have performed some extensive testing on Flash performance from a mobile perspective and have some tips that you may not have heard about yet. We’d like to share some of these initial findings with you to help you in determining how to best adapt your content for the mighty mobile: the iPhone.
As mentioned before, reading the slides from Mike Chambers and the other articles is required. Beyond that, a few other things have sprung to the forefront in our tests. We have used the Hires Stats package from Mr. Doob for determining the results of these tests. These tests are not
- Framerate doesn’t seem to have a direct affect on the overall memory usage, and the old trick of incrementing your framerate by one over the lowest ten (31 vs 30) doesn’t seem to offer any noticeable benefits.
- Even a very simple application is going to have an application size of at least 3.5MB (this is evidenced by various Flash package ipa files available on the iTunes store). Not a big deal, but something to consider if you are planning on deploying this application in locations where EDGE may be the only cellular data network available.
- No real noticeable performance issues arise from orientation switches or choosing to create a full screen app or one that displays the devices title bar. That said, orientation changes do seem to produce a little hiccup in the app’s display animation when the screen is rotating. We’ve downloaded every iPhone application on the iTunes store that we know to have been produced using Flash to assess this.
Very quickly, when graduating from creating a simple Flash animation to something that requires screen transitions or state changes, people start to use programmatic tweens to move DisplayObjects around (movieclips, sprites, bitmaps, etc.) We have performed some tests on this, using several of the most popular Tweening engines out there to find out which one should offer the best speed and quality on the lower processor speed of the iPhone. We used the built in Tween class Flash provides, the Tweener engine from Zeh Fernando (we love you Zeh – Tween still rocks), and TweenLite from Greensock. In most operations, Tweenlite outperformed the other engines noticeably. It’s safe to say, that if you’re porting content over from a desktop Flash deliverable, we would consider switching over the animations from the original method you used to the TweenLite package. Of course, the TweenLite package does have a few minor limitations (no built in Color tweening, for example), so be mindful of that.
When the smartclip became the component, something wonderful happened. What was rigid and had limited utility, became powerful and highly useful. The V3 Actionscript Components dramatically improved on this once again, adding configurability and easier skinning. One thing they also added was heft. Download speed, memory usage and CPU requirements were definitely increased. On a desktop, not that big of a deal. On a handheld, it is a big deal indeed. An application with a kitchen sink of components: Buttons, Slider, ComboBox, Text Field, Text Area, Radio Buttons, Checkboxes, etc. uses over 6MB of ram and is pretty sluggish in our tests. So what are you to do if you have a piece you want to publish to iPhone that requires these form elements we all depend on to add functionality to our Flash? Here are a couple options…
- Strongly reconsider if you actually need that components featureset before using them. Realistically, the Button, Slider and Text Components offer very little in terms of advantages that make them viable for use on mobile platforms. Perhaps you could code something up quickly that uses just simple Sprites or MovieClips and write your own listeners, etc to handle the input and interaction.
- Use a smaller component set like Keith Peters’ MinimalComps. A little over two years ago Bit-101, as Keith is known to the Flash community, released a suite of simple components with a nice minimal look and feel. They also have a substantially smaller footprint than the included Flash components. They would probably require some tweaking visually to work well on the iPhone, but after those adjustments, they use nearly 33% less memory and are definitely more responsive than the defaults. Keith continues to enhance and improve the components, adding new UI elements often. Take a look at the screenshots following.
- Wait for a component framework like Slider to come out. When will this be? According to sources in Adobe, “Sometime in mid to late 2010”. *Eugh*.
Obviously stacking tons and tons of items on top of each is something that is CPU intensive. The aforementioned presentations warn us of the CPU implications of said stacking. Place items carefully. Examine why you need that item there. Do you really require that many sprites or movieclips? Could you composite them together to make one or two items out of the 6-8 of them? In addition to display object depth, we have found that on a sprite by sprite basis, bitmaps require less memory and CPU to render a comparably designed visual element. Surely, you can cache items as bitmaps or use the BitmapMatrix to convert on the fly, but why not prepare your assets the right way the first time?
Fonts and Type
Fonts have always been somewhat expensive in Flash. Back in the days of spotty broadband, they took precious kilobytes. Then, CPU. Now with mobile users, it’s really a combination of the two. Honestly, if you can get away with using a device font, do it. If not, consider how you are using the type. Could it be better served as a bitmap sprite? It’s strange but true, this could be possible. Take a look at the memory and quality in these two images and then compare. Choose wisely when embedding fonts. Certainly branding standards are important, but so is application performance.
So, the already released info from Adobe and the evangelist team is great. Very helpful and really really sharp as usual. Only dabbling in these tools can provide you with more insight. We hope that you have found these initial musings useful. What other sorts of optimization tips are you coming across in porting Flash content to mobile devices? Adobe AIR for mobile, Flash Player 10.1 mobile are all just around the corner. Are you getting your content ready for the eventuality of publishing to the small screen? We’re definitely listening. Leave a comment below and let us know.
Latest posts by Chad Udell (see all)
- Examining the Realities360 App – A Deep Dive Whitepaper - September 22, 2017
- Missed Realities360? Check out the app that Float delivered here. - September 11, 2017
- Realities360 Augmented Reality App Now Available - July 21, 2017