Gonzo

Gonzo is a lightweight, open source markdown editor written for Adobe Air for desktop using Flex 4 and AS3. Its a stripped-to-the-bone application that serves one purpose: helping you deliver well formed and easy to proofread web content.

Why use markdown, I already know HTML?

Rather than drone on about the pros and cons of each, I’ll just present you with a simple example. You let me know which version you would rather proofread.

HTML version

Here's a header

Here's some content in a paragraph. And here's a link to Google and another to my Github account.

And here's another paragraph
    
this time it contains a blockquote



    
One of these lists' syntax
    
has the following attributes:
    

        

            
intrusive
            
ugly
            
very hard to read
        
    
    
which one do you think it is?

Markdown version

## Here's a header

Here's some content in a paragraph. And here's a link to [Google][] and another to my [Github][] account.

And here's another paragraph
> this time it contains a blockquote

* One of these lists' syntax
* has the following attributes:
    * intrusive
    * ugly
    * very hard to read
* which one do you think it is? 

[Google]: http://www.google.com
[Github]: https://github.com/tonylukasavage

Why should you use Gonzo?

Well, unless you are writing content for the web, you probably shouldn’t. Gonzo is written specifically for those who want to leverage the readability of markdown over HTML when publishing web content. So whether you are writing a WordPress blog post, editing a wiki, or even just an answering a question on StackOverflow, Gonzo can make your life a whole lot easier.

In the spirit of markdown, I’ve added just enough features to increase efficiency while maintaining a content-driven writing experience. The idea is to only add features necessary for making web publishing easier. All the effort saved by not implementing useless features was redirected into usability.

Just Give Me The Feature List Already

Yeah, I tend to skip the text and go right for the feature list too. Kudos to anyone who actually read the previous content before coming here.

• Live HTML preview – You can actually see the raw and rendered HTML generated by your markdown in a preview pane.
• Multi-tab editing – Edit many documents at the same time.
• Cross platform – Works on any desktop that supports Adobe Air.
• Keyboard and (context) menu shortcuts – Creating markdown is even easier now with multiple was to create it.
• HTML Export – Export your generated HTML to a file so it can easily be uploaded or shared.
• Cheat Sheet – integrated markdown cheat sheet for beginners and vets alike.

Coming soon…

This is the list of features I personally would like to have, as I’m the only user so far. Please let me know what you think would be a good addition to Gonzo’s functionality.

• yfrog integration – Wouldn’t it be nice to browse to a file on your desktop, upload it as an image, and get a markdown link placed in your document in one click? I think so too.
• bit.ly integration – see above
• Markdown toolbar shortcuts – Just in case the keyboard, context menu, and native menu shortcuts aren’t enough…
• Preferences – Let users set things like fonts, colors, editor sizes, and eventually maybe even theming.
• Local settings – For persisting preferences between Gonzo sessions

What else do you have in mind?

Want to Contribute?

Good! Like most open source projects, ongoing development will be heavily motivated by contributions and feedback from its community of developers and users. While Gonzo will continue to grow as I use and find features I want, its going to be you who determines if it matures into an application for the masses.

There’s a number of ways you can contribute:

• Use it and let me know what you think.
  • What is it missing?
  • What am I doing wrong
  • What am I doing right?
• Fork , start hacking away, and send me some pull requests. I’m very open to help, but bear in mind that its lightweight nature and usability should not be sacrificed for the sake of features.
• Design help is very welcome. I’m a dev through and through, so it will remain spartan in frills unless someone else decides to add the polish.

Summary

There’s a lot to come yet for Gonzo. I still need to get the wiki up and running for basic docs. I may even take the time to make a web page for it if it garners enough interest. Or none of this could happen and I could just continue to use it myself. Only time and feedback will tell.

If you do start using or hacking Gonzo, you can let me know here, on , or on . I’d love to hear about your experience. In the meantime I’ll continue using it to write my web content and keep improving it as I see fit.

Oh, and this entire post was written in markdown using Gonzo. Here’s a link to the original markdown for the blog post.

Gonzo

In case you haven’t heard me talking about it on , I’m creating my own markdown editor called . If you don’t know what markdown is, read up on it at John Gruber’s (creator) blog. It was created as a way to make web based writing more readable from a writer’s perspective.

Here’s some of the highlights of the VERY young Gonzo:

• Its open source and
• Its written using Adobe Air for desktop, Flex 4, and AS3
• The markdown to HTML parsing is done using
• Uses Grant Skinner’s StringUtils.as
• Its 3 days old as of the publishing date of the article
• It generates HTML as you type markdown and shows it live in a preview panel
• Counts your words for those web writers trying to hit quotas

Test Run

Rather than ramble on from a beginner’s stand point, I’ll leave you with the notes I took last night at the meetup using Gonzo. First, I’ll show you the notes as I entered into Gonzo. Like I said at the beginning, if markdown is unfamiliar, read up. Just one glance shows you how much more readable and editable it is than typical HTML markup.

My Notes in Markdown

## Node.js 
 
### Overview
 
* Server side JS. 
* HTTP/TCP built in
* non-blocking, event driven, 1 thread (launches process into event queue)
* not suitable for CPU intensive work
* Node.js is alpha and changes a lot between revisions
* for unix, not Windows friendly
* everything is a callback and gets its own process
        * lots of nested callbacks
* has to run from command line, no GUI for management.
* you can use it as a scripting language like ruby or perl
        * does not have to be event driven if ran this way.
* Having it server side allows you to use JS up and down your whole technology stack
 
### NPM
 
* Node package managaer
* A lot like CPAN for perl
 
### Modules
 
* [100's of modules](https://github.com/joyent/node/wiki/modules)
* examples
        * Sizzle
                * DOM selections and traversing
        * Paperboy
                * serves static files
        * Jade 
                * templating engine
        * ExpressJS
                * web framework
                * use it to deliver RESTful services
        * zombie headless browser
                * useful for testing Node driven services
                * assertions against returned data
                * DOM traversing is all custom code (why?!)
        * Coffeescript
        * multiple cores w/ web workers
        * Node Inspector
                * debugger
                        * breakpoints
                        * call stack
                        * watch expressions
                * command line
                * runs in a webkit browser
                * based on google's v8 engine
 
### Basic Server
 
        var http = require("http");
 
        http.createServer(function (request, response) {
                response.writeHead("Content-Type: "text/html");
                response.write("");
                response.end();         
        }).listen(8081);
 
### Emitters
 
Emitters are used to counter nesting of code. Should probably use constants to define emitter names. Add parameters afer emitter name in `emit()` to pass to callback.
 
        emitter.emit('eventName', param1, param2);
        emitter.on('eventName', function(param1, param2) {
                // do stuff
        });

And now, through the magic of Gonzo and Showdown.as, we get to see the markdown translated into HTML. You can then take the translated HTML and publish it to the web, allowing it to leverage any CSS and formatting your target venue has in place. Again, notice how much more readable the markdown version is than this HTML version.

My Notes Translated to HTML via Gonzo

 
<h2>Node.js</h2> 
 
<h3>Overview</h3> 
 
<ul> 
<li>Server side JS. </li> 
<li>HTTP/TCP built in</li> 
<li>non-blocking, event driven, 1 thread (launches process into event queue)</li> 
<li>not suitable for CPU intensive work</li> 
<li>Node.js is alpha and changes a lot between revisions</li> 
<li>for unix, not Windows friendly</li> 
<li>everything is a callback and gets its own process
<ul><li>lots of nested callbacks</li></ul></li> 
<li>has to run from command line, no GUI for management.</li> 
<li>you can use it as a scripting language like ruby or perl
<ul><li>does not have to be event driven if ran this way.</li></ul></li> 
<li>Having it server side allows you to use JS up and down your whole technology stack</li> 
</ul> 
 
<h3>NPM</h3> 
 
<ul> 
<li>Node package managaer</li> 
<li>A lot like CPAN for perl</li> 
</ul> 
 
<h3>Modules</h3> 
 
<ul> 
<li><a href="https://github.com/joyent/node/wiki/modules">100's of modules</a></li> 
<li>examples
<ul><li>Sizzle
<ul><li>DOM selections and traversing</li></ul></li> 
<li>Paperboy
<ul><li>serves static files</li></ul></li> 
<li>Jade 
<ul><li>templating engine</li></ul></li> 
<li>ExpressJS
<ul><li>web framework</li> 
<li>use it to deliver RESTful services</li></ul></li> 
<li>zombie headless browser
<ul><li>useful for testing Node driven services</li> 
<li>assertions against returned data</li> 
<li>DOM traversing is all custom code (why?!)</li></ul></li> 
<li>Coffeescript</li> 
<li>multiple cores w/ web workers</li> 
<li>Node Inspector
<ul><li>debugger
<ul><li>breakpoints</li> 
<li>call stack</li> 
<li>watch expressions</li></ul></li> 
<li>command line</li> 
<li>runs in a webkit browser</li> 
<li>based on google's v8 engine</li></ul></li></ul></li> 
</ul> 
 
<h3>Basic Server</h3> 
 
<pre><code>var http = require("http");
 
http.createServer(function (request, response) {
    response.writeHead("Content-Type: "text/html");
    response.write("<html></html>");
    response.end();     
}).listen(8081);
</code></pre> 
 
<h3>Emitters</h3> 
 
<p>Emitters are used to counter nesting of code. Should probably use constants to define emitter names. Add parameters after emitter name in <code>emit()</code> to pass to callback.</p> 
 
<pre><code>emitter.emit('eventName', param1, param2);
emitter.on('eventName', function(param1, param2) {
    // do stuff
});
</code>

And finally below is the above generated HTML copied directly into my blog. The CSS that governs my blog does its work on the elements and makes it look relatively web ready. Obviously if I put a little more effort in (as I will soon), I can tailor the CSS to play well with my generated HTML. For now, though, you can see the basic formatting applied. So without cluttering your writing with HTML you can still effortlessly generate web ready content.

Gonzo Generated HTML on my Blog

Node.js

Overview

• Server side JS.
• HTTP/TCP built in
• non-blocking, event driven, 1 thread (launches process into event queue)
• not suitable for CPU intensive work
• Node.js is alpha and changes a lot between revisions
• for unix, not Windows friendly
• everything is a callback and gets its own process
  • lots of nested callbacks
• has to run from command line, no GUI for management.
• you can use it as a scripting language like ruby or perl
  • does not have to be event driven if ran this way.
• Having it server side allows you to use JS up and down your whole technology stack

NPM

• Node package managaer
• A lot like CPAN for perl

Modules

• examples
  • Sizzle
    • DOM selections and traversing
  • Paperboy
    • serves static files
  • Jade
    • templating engine
  • ExpressJS
    • web framework
    • use it to deliver RESTful services
  • zombie headless browser
    • useful for testing Node driven services
    • assertions against returned data
    • DOM traversing is all custom code (why?!)
  • Coffeescript
  • multiple cores w/ web workers
  • Node Inspector
    • debugger
      • breakpoints
      • call stack
      • watch expressions
    • command line
    • runs in a webkit browser
    • based on google's v8 engine

Basic Server

var http = require("http");

http.createServer(function (request, response) {
    response.writeHead("Content-Type: "text/html");
    response.write("");
    response.end();
}).listen(8081);

Emitters

Emitters are used to counter nesting of code. Should probably use constants to define emitter names. Add parameters after emitter name in emit() to pass to callback.

emitter.emit('eventName', param1, param2);
emitter.on('eventName', function(param1, param2) {
    // do stuff
});

Screenshot of Gonzo in Action

Summary and TODO

I'll end with the current TODO list for Gonzo. Please feel free to add your own idea in the comments.

• Add ability to edit and apply CSS within Gonzo
• More robust "project" environment to allow grouping of markdown and CSS with generated HTML
• Spell Checker, likely via Squiggly
• Major UI polish (gonna need help here)
• Create Mac and Windows native downloads on the

Overview

NOTE: all source code is available for .

The above image shows my Air for Android app Repper ported over to the Blackberry Playbook.  The most remarkable thing about this port? It literally took about 60 seconds to complete!  Here is the shockingly simple, comprehensive list of steps I took to accomplish this:

1. Create a new Flex mobile project in Flash Builder “Burrito” to target the Blackberry Playbook
2. Copied the project files from my original Repper project to the new project
3. Set up the Playbook simulator run settings in my new project
4. Clicked “Run” and voila, Repper on the Playbook!

All components scaled properly.  All layouts fit to the available screen space appropriately.  All orientation transitions performed as expected.  How was this achieved without having to write a single line of device specific code?  It comes down to 3 simple things: Adobe Air, fluid layouts, and vector graphics skinning via Flex MXML.

Adobe Air

Blackberry’s use of the Adobe Air SDK for its Playbook development lets Flash/Air/Flex/AS3 developers leverage existing expertise and code to create apps.  The Air SDK for the Playbook also makes available QNX components to give Playbook apps a Blackberry look and feel.  You can choose from either.  This way Flex developers can use their existing paradigms and pure AS3 developers can make use of Blackberry’s QNX components.  You can even use both as Renaun Erickson details in this post.

For me the big win was taking Repper, a Flex “Hero” app for Android, and porting it directly, unchanged into a working Playbook app.  The Playbook Adobe Air SDK supports Flex “Hero” so everything just worked right out of the gate.  That’s the kind of portability that lets an independent developer be extremely productive.

Fluid Layout

Using fluid layouts with little to no defined pixel dimensions is key to writing a multi-screen app.  Take a look at this excerpt from the main .

        
 id="landscapeGroup" includeIn="landscape" height="100%" width="100%"
                    paddingTop="{this.height*0.03}" paddingBottom="{this.height*0.03}" paddingLeft="{this.height*0.03}"
                    paddingRight="{this.height*0.03}" gap="{this.height*0.03}" verticalAlign="middle">
                 id="landscapeInput" width="36%" skinClass="RepperInputSkin">
                        >
                                 paddingTop="{this.height*0.06}" paddingLeft="{this.height*0.06}" 
                                                            paddingRight="{this.height*0.06}" paddingBottom="{this.height*0.06}" 
                                                            gap="{landscapeInput.height*0.04}" horizontalAlign="right"/>
                        >
                        
 width="100%" verticalAlign="middle" gap="0">
                                 text="Weight" width="65%" color="0x000000" fontWeight="bold" fontSize="32"/>
                                 width="35%" text="{inputWeight}" keyUp="onWeightKeyUp(event)" restrict="0-9." 
                                                   contentBackgroundColor="0xffffff" color="0x000000"/>
                        >
                        
 width="100%" verticalAlign="middle" gap="0"> 
                                 text="# of reps" width="65%" color="0x000000" fontWeight="bold" fontSize="32"/>
                                 width="35%" text="{inputReps}" keyUp="onRepsKeyUp(event)" restrict="0-9"
                                                   contentBackgroundColor="0xffffff" color="0x000000" focusIn="textinput1_focusInHandler(event)"/>
                        >
                         label="Rep It" click="recalculate();" chromeColor="#111111" />
                >
                 width="32%" height="100%" dataProvider="{repValues1}" itemRenderer="RepperEntry"/>
                 width="32%" height="100%" dataProvider="{repValues2}" itemRenderer="RepperEntry"/>
        >

If you look at every component and container in this chunk of Flex MXML you’ll notice that no defined pixel dimensions are used. Every component’s size is determined using percentages or data bindings. I’m not going to lie, specifying dimensions in this manner will take more time and requires a bit of trial and error to get right. It helps if you do it with the expectation that another, dissimilar device will be using this same layout in the future. I did, and in this case the little bit of extra forethought paid off huge in terms of portability.

Because of design via fluid layouts, Repper appears properly in both portrait and landscape orientation on the Blackberry Playbook with no additional effort.

Vector Graphics via Flex MXML Skinning

The final factor that made Repper such a breeze to port to the Playbook was Flex Hero’s ability to create vector graphics via Flex MXML. By utilizing this capability you can create skins for your components that scale as the app scales. No external artwork of any kind is necessary. While this is not ideal for designers or highly stylized apps, a developer like me loves it.

Here’s another excerpt from Repper. This time it shows how I used fluid dimensions once again to create vector graphic skins for my components via the

     id="background" x="0" y="{this.height/6}" height="66%" width="100%" radiusX="10" radiusY="10">
        >
                 blurX="16" blurY="16"/>
        >
        >
                 weight="3"/>
        >
        >
                 rotation="-90">
                         color="#bbbbbb"/>
                         color="#ffffff"/>
                >
        >
    >
     x="0" y="{this.height/6}" height="66%" width="60%" radiusX="10" radiusY="10">
        >
                 blurX="8" blurY="8" angle="0"/>
        >
        >
                 weight="3"/>
        >
        >
                
                 rotation="-90">
                         color="#000000"/>
                         color="#444444"/>
                >
                
        >
    >

As you can see, percentages and binding are used to create skins for my components that are appropriately scaled regardless of the dimensions of the device. Not having to create skin resources for each device and orientation is a tremendous time saver. Especially for someone like myself who has no patience or talent for it.

Summary

Lesson for the day: with a little forethought and a penchant for Adobe Air, magic can happen. OK, maybe not magic, but you’ll have more time to explore the possibility of creating magic now that you won’t be wasting it on porting your mobile apps. Yes, I know, I’ve griped a bit lately about Flex Hero on , but there are undoubtedly some things it does very well.

In fact, if you think about it, anyone that openly supports Adobe and their efforts to create a viable cross-platform mobile development environment has done very well with it. I’m trying to think of who isn’t supporting it? Who’s at the “core” of the issue? I feel like day to day they are trying to keep the doctor away. Supporting Adobe should be as appealing as American pie. Oh well, hopefully some day they will have their thinking jolted like Isaac Newton did from a falling piece of fruit.

Overview

UPDATE: This was originally posted January 18th, 2011. All 3 platforms have changed immensely since.

UPDATE: If have updated and more detailed information about Appcelerator and PhoneGap at this link: https://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

I have been charged with deciding on a mobile framework for deploying a single code base to multiple devices (iPhone, iPad, Android, Blackberry). Naturally, I was gravitating towards Adobe Air since most of my personal work these days has been in AS3. I wanted to see what else was out there, though, and was pretty surprised that Adobe Air wasn’t my choice in the end.

In addition to one other commercial platform I did not fully assess (too expensive), I looked at Adobe Air for mobile, Titanium Appcelerator and PhoneGap. All are free to use frameworks for centralized mobile development. The gist is to be able to create apps for multiple devices off the same code base. With iPad & Blackberry support, speed to market, and the ability to use Contacts & Multitouch as my critical points, I began digging.

General Functionality

	Titanium Appcelerator	PhoneGap	Adobe Air for Mobile	Notes
Android Support				Adobe Air requires Android 2.2+
iPhone/iPad				Adobe Air creates iOS apps with the Packager for iPhone
Blackberry Phone				Appcelerator support is currently beta.
Blackberry Playbook				Appcelerator support is currently beta.
Symbian
Palm
Windows Phone 7				is a 3rd party attempt for PhoneGap.
Native UI support				PhoneGap and Adobe Air both require 3rd party libraries. PhoneGap has UIControls for PhoneGap. Adobe Air has and android-components
Native code support				Appcelerator allows module development. PhoneGap uses .
Desktop deployment				PhoneGap has 3rd party libraries on Github: &
Deploy without Mac?				Adobe Air uses the Packager for iPhone/iPad
IDE & Tools	Titanium Developer	PhoneGap Tools	Flash Builder, FDT, FlashDevelop	Appcelerator has no current IDE, but recently acquired Aptana
Interpreting	Javascript mapped to native code	Rendered in web view control	Adobe Air runtime
Community Resources	Developer Center	Docs, Wiki, , and	Mobile and Devices Development Center
Languages used	JS	HTML, JS, CSS	Actionscript3	Appcelerator also uses PHP, Ruby, and Python for desktop app development
Support	$2,189 per year per developer	ranges from $1,000 – $25,000 per year	Adobe Support	Adobe offers no professional mobile support for apps, just their products.

Device APIs

Beyond the overall support structure of the frameworks I wanted to get into the specific device API functionality. This was a little harder to track down, but the list here should be accurate as of the writing of this post. As I said earlier, contacts and multitouch were the only criticals, but I wanted to know what else these frameworks offered. I’m assuming anyone reading this far would find this information valuable as well.

	Titanium Appcelerator	PhoneGap	Adobe Air for Mobile	Notes
Accelerometer
Geolocation
Vibration
Camera				Not yet supported Adobe Air for iPhone/iPad
Contacts
Multitouch
SQLite
File System IO
SMS				All support SMS via the “sms:” URL prefix.
Phone API
Copy/Paste
Sounds				PhoneGap cannot record sounds. Adobe Air cannot record sound for iPhone/iPad
Bluetooth
Video Capture				Adobe Air cannot record video for iPhone/iPad.

Summary

That’s what I’ve got so far. Let me know if and when some of these assessments change. I’m also eager to hear other people’s thoughts. Feel free to chime in.

The long and short of my recommendations:

• Go Adobe Air if performance isn’t critical and you have AS3 experience. The tools and workflow for using pure AS3 or Flex Hero make turning out mobile apps very smooth. Watch out for performance, particularly on iOS.
• Go PhoneGap if you needed the widest range of support for devices. If you need it to run everywhere, this is your framework. Beware of the less than stellar documentation and wiki, though.
• Go Appcelerator everything else. The native UI and ability to access native code is a big win. Also, the community, IDE, and documentation are top notch. Appcelerator was my choice in the end, but that doesn’t mean its right for you.

This is the first installment in what will hopefully be a regular occurrence on my blog. Its simply just a digest of interesting things from my twitter feed, complete with the source articles and the people behind them. Without further ado, let’s light this candle.

Incredible Javascript Performance metrics

tweeted by:
This was my favorite this week. A tremendously huge list of common Javascript tasks (conversions, HTML5, DOM access, etc…) broken into the different ways to perform them. Each of the methods is then tested millions of times against your current browser to tell you the most effecient way to perform them.

I know I am not doing this site justice. Go to it and check it out. This site should be a must have tool for any serious Javascript developer.

Mandelbrot Plotter

tweeted by:
This Flash-based Mandelbrot Plotter application allows you to create and save beautiful images of the Mandelbrot set. A must for you generative art junkies.

If you got a few spare minutes, I’d encourage you to check out the rest of flashandmath’s content as well. Some great visual content based just in code.

Blackberry giving out free playbooks to developers!

tweeted by:
Click the link for details. The short version is that if you build an approved app for the Blackberry App World by Feb 1st, 2011 you get a free PlayBook. Pretty sweet deal.

PlayBook App template using FDT and ANT

tweeted by:
Martin Rädlinger gives FDT users a head start on their road to a free Blackberry PlayBook with this extremely helpful app template.

Understanding Accelerometer Development (AS3)

tweeted by:
A great breakdown of how to use the accelerometer in mobile development, as it relates to AS3. Simple and concise with source code to go with it.

Top 50 Programming Quotes Of All Time

tweeted by:
Nothing like a little truth wrapped up in wit and sarcasm. Especially for us geeks. Enjoy some of these pearls of wisdom from a few programming greats you may recognize.

List of the Best Animation/Tweening Packages for AS3

tweeted by:
A seemingly comprehensive list of available tweening and animation libraries available for AS3. It includes who made it, where to find it, and the pros and cons of each. This is great place to start for a Flash newbie or a terrific reference for a seasoned pro.

Using OAuth with Adobe Air and Flex

tweeted by:
Need to access a 3rd party web API in your Adobe Air application. Check out this extremely useful blog post from Christophe Coenraets that includes a description, application, and full source code.

Blackberry PlayBook will support C++ extensions for Adobe Air

tweeted by:
This isn’t some Adobe Labs Alchemy magic, Blackberry will have a legit part of their mobile development SDK that will support C++ extension use by Adobe Air. This is the best of both worlds: The flexibility and ease of mobile development with Adobe Air and the power and efficiency of native SDK development. Blackberry really is making some strong moves to engage the developer community with its latest mobile offerings.

DISCLAIMER: This article is about Adobe Air as an alternative to native API mobile development. Other mobile frameworks like Appcelerator Titanium and PhoneGap are not discussed.

The overview

So you want to make an iPhone app? Wait, you want to run it on Android too? And any tablet? And any desktop? And you want to be able to reuse the code base for all of them? OK, sounds good, now let me just get the magic elves and unicorns to take care of that for you. It will cost you one soul. Doesn’t have to be yours.

Or… you could use the Adobe Air SDK. Yeah, Adobe Air can do all that. Check out this video from Christian Cantrell’s blog where he shows how a single AS3 code base can be used to create an app for the iPad, iPhone, iPod Touch, Droid, multiple desktops, and the web. Pretty incredible stuff for indie developers:

For those wondering how you get past the Steve Jobs stranglehold on the Apple app store with an Adobe Air app, check out the Adobe Labs project “Packager for iPhone,” which also works for the iPad and iPod Touch. He also got it running on the Blackberry Playbook emulator. Its also worthy to note that Adobe Air and Flash are in the pipeline for Windows Phone 7, Blackberry phones, and many more mobile devices.

Now if I can do this with one language and one framework rather than 1/2 a dozen, why even bother learning the Java & Android SDK, Objective-C & iOS, or any other combination that may arise? At some point you have to have a better answer than “to learn it.” As with any consideration like this, there’s lots of pros and cons for each side of the argument. Here’s a few things to consider.

on the native side…

People want a uniform user experience

And by “people” I mean “non-technical users.” And by “uniform” I mean “native.” People want all their interface components to have the same look and feel. Its gives apps a more intuitive nature. While Adobe’s Flex Hero interface components are uniform to Adobe Air apps, they don’t represent the components found on each individual mobile device.

You can, however, use AS3 libraries like or android-components to preserve that native experience. As you might be able to guess by their names, they are collections of UI components for the iPhone and Android respectively that mimic those of the native system. While this solves the uniformity problem, it adds additional complexity to your multiscreen projects thereby undoing some of the efficiency added by the Adobe Air & AS3 workflow.

Or you could just forgo the whole uniformity thing and have a designer make all your components.

Native code will perform better

This is kind of a no-brainer. In my experience, and in talking with mobile users, responsiveness and performance is consistently better in native mobile applications. And not just that it is consistently better, but also that it is consistent across devices. I’ve heard many complaints about packaged Flash apps running crazy slow on Apple devices but fine elsewhere. This is especially true of resource intensive apps like games. Granted this isn’t shocking news, but it is a concern for those trying to preserve the user experience.

But this doesn’t necessarily apply to everyone. If you are building a simple data and UI component driven app, Adobe Air should be more than enough to handle that with smooth performance. And those resource intensive apps that may not run as well as native apps now are going to be catching up soon. Adobe is constantly increasing performance on mobile devices. Recently they have had a strong focus on GPU processing for graphics and will even be releasing a full, low level 3D API called “Molehill” mid 2011. As long as they keep this pace with performance enhancements, there’s no reason to believe that Flash and Air games won’t be as prevalent on mobile devices as they are on the web.

Steve Jobs can shut you down

Until just a few months ago, deploying AS3 written apps to Apple devices was impossible. This was because Apple had a restriction that no 3rd party development tools could be used to create Apple apps. You used the Apple sanctioned workflow or you were SOL.

Luckily Steve came to his senses and lifted the ban and Adobe re-released the iPhone packager. But it shines light on a dangerous precedent. There’s nothing to stop him from doing it again at some point in the future. Hell, MacBook Airs are not even preinstalled with Flash anymore. If Apple drops the hammer, BOOM, there goes a significant portion of your mobile audience.

Native functionality

Without native coding, you are at the mercy of what Adobe has currently implemented and abstracted. Things like Android Intents hit the cutting room floor for the sake of creating a single framework. While Adobe does a good job of either capturing all available functionality (like Geolocation, microphones, and cameras) or creating similar functionality, it will be by nature, a step behind the advances in mobile development. This could be offset if Adobe maintains a close relationship with the major mobile players.

on the adobe air side…

Spend more time creating, less time battling compatibility

This is why we’re here, isn’t it? With a single language, framework, and workflow you can create a code base that can be applied to any device that can support Adobe Air or Flash. That should be mighty intriguing to any indie developer. You can cut your development time down to a fraction of what it would be if you had to learn every mobile device’s framework. You are instantly building to multiple devices and broadening your target audience with almost no additional effort.

Flash, Air, and AS3 resources are abundant

The mobile APIs out there are well documented and have strong, growing communities. Adobe’s communities, though, are even more so. They have been around a much longer time than these relatively new APIs and are chock full of expert developers, designers, examples, and code. The sheer volume of resources available to AS3 and Flash based projects is incredible, just look at this list of available game engines for example. Need inspiration? Check out one of the many open Flash sites out there, like wonderfl.net.

Now lets move on to the tools invovled. Love them or hate them, Adobe knows how to make design and development software. Expensive, yes, but worth every penny. They have the design to development workflow that helps apps stand out down to a science. Let’s say you don’t believe me, or you don’t want to pay the money. That’s fine, because there’s plenty of free tools for creating Flash and Air content out there too. Check out FlashDevelop or FDT for great alternatives to the Adobe suite.

Reuse existing AS3 code

I know what you’re thinking: Can’t I also reuse existing Java in Android or Objective-C on the iPhone? Well yes, but not to the level that you can with AS3. Let’s say you have a game that logs top scores, uses a physics engine, and has some built in menus. Chances are that most of these things, with some serious effort, can be translated into the mobile API of your choice. But even if that is the case, you still need to integrate that all into the mobile API’s framework, which can be a daunting task.

With Flash or Air, though, you can literally compile or package the application AS IT IS to any mobile format that Adobe supports. Wanna make your old flash game a mobile app? Run it through the appropriate compiler or packager and you are good to go, no changes necessary. Now don’t get too excited. Chances are you will need to do some scaling and appearance tweaking in descriptor files to accommodate your target devices, but the transition is much simpler than with mobile APIs and native code.

Flex “Hero” and flash builder “Burrito” makes things a lot easier

Before the MobileApplication framework added to the Flex SDK, mobile development was very possible, but still felt like a flash app instead of a mobile app. With Flex “Hero” Adobe focused on creating a framework for multiscreen development, but also to be able to create apps that behaved like mobile apps.

What do I mean by “behaved like mobile apps?” Well, mobile apps typically operate as a stack of full screen views. Gestures or menu options are used to navigate between the views. Things like “Back”, “Menu”, and “Search” buttons need to be handled in a way the user expects. The app also needs to be able to close itself when no longer in use. These are just a few of the things that give that mobile feel that are not typical of flash apps. These are now present in Hero.

And how do we simply and quickly leverage this new functionality in the Flex SDK? With Flash Builder “Burrito” of course! Burrito is currently a preview release of Flash Builder that supports the creation, development, debugging, and deployment of Air for Android apps (And you can bet other devices are just around the corner). Complete with design view and dimension emulation for the various target Android devices it supports. I highly suggest trying it out since its now available free for a 60 day trial.

The Summary

Condensing the majority of your mobile development down to one framework can cause one indie developer to match the work of a team of native mobile developers. But there are drawbacks. The factors listed above point out the potential shortcomings of an abstracted Adobe Air solution. If you are not willing to deviate from native workflows or only need to develop for one platform, perhaps the Adobe Air path is not for you.

If you are a mobile developer, you owe it to yourself to spend some time with Adobe Air’s workflow for deploying mobile applications. If you are an INDIE mobile developer, especially with an AS3 background, you are shooting yourself in the foot productivity-wise if you are not pursuing this further. Here’s some links to help you on your way to multiscreen development bliss:

→ Flex SDK
→ Air SDK
→ Flex “Hero” SDK
→ Flash Builder “Burrito”
→ Packager for iPhone

If you do go down this path, let me know, I’d love to hear your experience. If not, why not?