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

The Code

• – Full source code and Flash Builder “Burrito” project files

The Overview

I mentioned this week that if you hustle you can still get yourself a free Blackberry Playbook.  Just follow my procrastinator’s guide and you could very well still have enough time to make it.  I also made posted a while ago the incredibly simple process of porting Repper, my fitness calculator mobile app written with Flex “Hero”, to the Playbook.  If that wasn’t enough for you, here’s one more bit of charity to motivate to try and beat that March 31st, 2011 deadline to submit an app for a free Playbook.

In the at the top I’ve included the full source and project files for Flash Builder “Burrito” for Repper.  Yep, everything it took to make a Playbook app that was submitted and approved is included within.  Take a look, pull it down, load it up, and see how a simple, functional app can get you a free tablet.  If you are wondering what your time is worth in comparison to the effort necessary, the model that developers are likely to receive (16 GB) is being priced at $500.  Seems a fair trade for a few hours of your time.

Repper on Github

Guide to a Free Playbook

So now you have a guide to getting a Blackberry Playbook app submitted as quickly as possible and full source code for a project that has already been approved. Pair that with the fact that I’ve not heard of one functional app not being approved, you are completely out of excuses to not cash in on this offer. Dig in and get it done.

This past week my fitness calculator app, Repper, was approved for the Blackberry App World.  In return for enduring Research in Motion’s arduous app submission process, I will be awarded with a free Blackberry Playbook once they are officially released to the public.  Because I’m so pleased with this news, I thought I would share what I perceive as the easiest route to getting your hands on a free Playbook yourself.

You only have til March 31st to submit your app, according to the latest version of their offer.  While this date has been pushed back a number of times, I suspect this may be the hard deadline.  You don’t need to be approved by the due date, you just need to have your app submitted.  You may think I’m exaggerating here, but creating the app is the easy part, submitting is the real pain in the ass.

So before I get into too many boring details, let me lay out the list of things you need to do in order to reduce the amount of surprise time sucks you will encounter:

• Sign up to be a Blackberry vendor
• Get your code signing keys
• Follow the getting started guide for setting up your AS3/Flex development environment (or WebWorks if that’s your thing)
• Convert an existing AS3/Flex project or create a new app (IF YOU ONLY READ ONE SECTION, READ THIS)
• Sign and submit your app to the Blackberry App World through the vendor portal.
• Wait for approval

The steps necessary are listed in a very specific order to maximize efficiency, particularly becoming a vendor and getting code signing keys.  Read the section below detailing each step to find out why.  So again, DO THE STEPS IN ORDER, it will save you time in the end.

Sign up to be a Blackberry vendor

This is simple enough. You just need to fill out a form with relevant personal information do that Blackberry has a record of who you are.  In the early stages of this process you actually needed to submit a notarized letter, if you were an individual and not a company, in order to complete the registration.  From what I understand this is no longer required so it should make your life a little easier.

Blackberry is also waiving their usual $200 registration fee for developers during this period.  So whether or not you plan to hit this deadline, it may be worthwhile just to sign up and get in for free.

You will do this first because this process may take a few business days to complete.  They review the vendor registration submissions and Blackberry has not been terribly quick with approvals at any step in this process.  In fact, that is the most common complaint about the app submission process so far is simply how long it takes to complete.  So get this done first and don’t wait for approval to move on to the next step.

Get your code signing keys

This is another step that is as simple as filling out forms, but again requires Blackberry’s intervention to approve.  Also bear in mind that the code signing key you will receive will only work on one workstation once registered and cannot be transfered to another workstation.  You have to request another key is you want it to work on another workstation.  I have requested 2 keys thus far and both have taken at least 2 business days to arrive via email.

Like the last step, get this done now and don’t wait for the key to arrive to move on.  Hopefully by the time you are ready to submit your app to the App World you’ll have received your vendor approval and signing key.

Follow the Getting Started Guide

I’m not going to go into a great deal of detail here because the Blackberry documentation lays it out very well.  Just follow the guide found here and you’ll be fast on your way to your Blackberry Playbook “Hello, World!”.

One thing to keep in mind is that you must be building against the 0.9.4 SDK. I initially made the mistake of hanging on to the old 0.9.3 SDK and Blackberry has requested that I rebuild against the latest version before being able to make my app available on the App World.  Its not a huge deal, but will require you to go through the whole app update process if you don’t do it right the first time.  That said, they still extended me the offer of the free Playbook without yet having made this change.

Create your app

I know, I’m trivializing what sounds like a big step.  But here’s the thing: I’ve not heard of one Playbook app that has been turned down due to perceived usefulness or quality.  The only apps that I have heard being rejected are ones that actually don’t work.  This is common in the case of people trying to implement multitouch or gesture support when the simulator does not properly emulate the behavior.

In other words, put together a simple application that is useful to a niche group.  Or better yet, convert an existing AS3 or Flex Hero project to a Playbook app.  Check out my prior post to see how I did this in literally seconds.

For me, Repper was a no brainer.  It is a simple fitness calculator that determines your 1-15 rep max on exercises.  It was originally built using Flex Hero in Air for Android.  Its currently available on the Android Market if you wanna take a look at it there.  You can see there is no rocket science.  Blackberry has no high expectations for the functionality of an app for which developers have no device.  KISS is the key factor here.  Wait til you have one of these Playbooks in your hand before you try to get really creative with it.

Don’t get me wrong, I’m not encouraging fart app development here.  I’m just saying that at this point in the game Blackberry is happy handing out Playbooks to competent, motivated developers.  The quality of this one app is not what they are banking on.  They are hoping that with their generous gesture that they may woo more than a handful of mobile developers to spend their time on Blackberry Playbook apps rather than iPad or Android tablets.

In short, no excuses.  Create a useful, simple app.  Its not that hard and you know it.

Submit your app to the App World

Before digging into the specifics of the submission and signing process, here’s the things you’ll need:

• Your signing certificate (CSJ file)
• A less than 4000 character description of your app
• A 480×480 product image for the App World
• At least one screenshot that is no larger than 640×640
• An 86×86 PNG icon, which includes a 5 pixel transparent buffer around it.  This effectively makes the icon content 76×76 or less.

First you are going to sign your release build of your application using your CSJ signing certificate.  This is an intimidating and somewhat complex process.  I highly suggest picking from the choices at the bottom of their code signing guide and following them to the letter.  I personally had no problems with the workflow for signing apps through Flash Builder 4.5 “Burrito”, but I’ve heard that some people had issues.  The safest route might be to follow the command line instructions for the entire process.  Again I emphasize, follow the instructions to the letter and don’t try to frankenstein multiple guides together, it makes it harder to troubleshoot the issues.

After you have successfully signed your app, you just need to submit it to the App World through the vendor portal. Just go to “Manage Products” and click the “Add Product…” button.  You will be walked through the steps necessary to submit your signed BAR app file.  So long as you have all the items I mentioned above in the list, and a successfully signed app, it should be pretty smooth sailing.  Finding these things out during the submission process was quite frustrating.

Carve out at least an hour for the above process, because it will take some time.  The code signing can be especially time consuming from the command line, but it seems to be the one sure fire way to get the app successfully signed.

If you followed my advice and became a vendor and requested your signing keys first, you won’t find yourself waiting for days once you’ve reached this part of the process… like I did.

Wait for approval

Now that you finally have your app submitted, you just have to sit back and relax… and relax…. and relax… and do your taxes… and ge your car inspected… and renew your driver’s license… you get the idea.  It takes a LONG time to get approved.  I’ve not heard of anyone getting their first app approved in under 2.5 weeks, with many waiting as long as 7.  But once again, as long as you get the app submitted before the deadline, you are still eligible for the free Playbook.

Once you finally do get approved you’ll receive an email telling you as much.  It may also include additional steps you must take in order for your app to be made available in the App World, like mine did.  Shortly following this, for me it was a day later, you’ll receive a congratulations notice for your free Playbook.  Included in this email should be a link to a purchase order for your Playbook with a cost of $0.00.  I have not heard of a single case where an app was approved but the developer did not receive a free Playbook offer.  Fill it out, send it in, and join us in the patient wait for the release date.

Hope you follow these steps and find yourself with your very own free Blackberry Playbook too!  Let me know if you happen upon success yourself.

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.

Disclaimer

This article is from the perspective of someone whose AS3 and Flex experience is measured in months. This is meant to show those who aren’t long time Flash developers what they can expect with Flex “Hero”, Flash Builder “Burrito”, and Air for Android. But I didn’t go in alone, the Adobe community is full of smart and helpful people, just check my to see some of the names that helped. Particular thanks to , , and .

Overview

Recently I wrapped up my first Flex “Hero” Air for Android app, Repper. You can read my earlier blog post about it to download, get source code, or just learn more about it. I learned a lot about mobile development and deployment, but I want to talk specifically about Flex “Hero” and Flash Builder “Burrito”. Here’s this developer’s experience and perspective with using Adobe’s workflow for mobile development.

The Good

• The Flash Builder “Burrito” workflow for building Android apps is fantastic. It was a breeze to setup a basic project and be testing it live on my Droid X. Some of the specific things I really liked were:
  • Pre-built templates for projects, components, skins, item renderers, and more speed up the development process
  • Built-in emulation for various Android devices
  • Testing on a device is very easy to set up
  • Managing Flex states through the Design View can be helpful in visualing layouts
  • Offers the familiarity and plugins of Eclipse
• ViewNavigator and View make navigating through applications using multiple views simple. Using simple functions like pushView() and popView() you can move through your application and pass data with ease. Check out these posts for a more in depth look at this powerful and intuitive interface:
  • Mihia Corlan – Understanding Flex Mobile View and ViewNavigator
  • Brian Rinaldi – Passing Data Across Views in Flex Mobile

  

• PersistenceManager alleviates the hassle of trying to manage data between view states by using Local Shared Objects. Even when your mobile OS decides to close your app for memory or power shortages, the PersistenceManager will preserve your designated data. Check Jonathan Campos’s post on it for more details: Flex 4.5 PersistenceManager
• Flex 4 skinning is pretty damn nice, especially for someone like me who is about 95% developer, 5% designer. Using MXML and AS3 you can create design and graphics for your components, keeping them separate from your UI’s layout and logic. This means you can effectively create vector skins using the AS3 drawing classes. No more importing images just to create gradients and rounded corners. Not as big a win for designers, but the pure developers out there will love this. Check out Ryan Frishberg’s article for more details: Introducing skinning in Flex 4. The screenshot showing Repper below highlights entirely programmatic design.

• 

• Multiscreen development potential is very appealing and Adobe is working to grow it further. Christian Cantrell’s demo video below shows what Adobe Air is capable of in terms of “code once, deploy everywhere.” Android, iPhone, iPad, Blackberry Playbook, Desktop, and web are all valid targets for your single code base. While this is very exciting, it is also very young. Take this all with a grain of mobile salt as this topic shows up again in the “Ugly” section.

• The Bad

  • Lack of native component support can be a deal breaker for some people building mobile apps. Its not for me nor for lots of people who are comfortable building their own components, but many want the native experience. But all hope is not lost with the following AS3 libraries available that emulate native components:

  • Nick Jonas –

    Kevin Hoyt – android-components

  • Flex “Hero” is missing some core components that mobile developers will be expecting to be present. I for one was not expecting to have to build a modal select list from scratch. Unfortunately, though, Flex “Hero” does not contain the mobile equivalent of a combobox. You can create it with their scrollable List component paired with a semi-transparent background, but it would be nice to have this out of the box. Other notable absentees are sliders and tabbed layouts.
  • Not all native APIs are supported. While this should be expected in a cross platform framework, it can sometimes lead to unexpected roadblocks. In my case, I have only numeric input in my app. I wanted to default the soft keyboard to the numeric keyset. Unfortunately this is not possible in Air for Android. It takes some AS3 parlor tricks just to keep the soft keyboard closed when you don’t want it open on a TextInput focus. There’s even more to worry about with Apple development, but I’ll mention that in the “Ugly” section.
  • Simple things can be complicated. Take for example closing an app when a user leaves with the back button. Seems easy enough, but it takes 3 event handlers to do it properly and even this method is not without its problems. Check out the code I used below, thanks to Tom Krcha:

    protected function mobileapplication1_creationCompleteHandler(event:FlexEvent):void
    {
            if(Capabilities.cpuArchitecture=="ARM")
            {
                    NativeApplication.nativeApplication.addEventListener(Event.ACTIVATE, handleActivate, false, 0, true);
                    NativeApplication.nativeApplication.addEventListener(Event.DEACTIVATE, handleDeactivate, false, 0, true);
                    NativeApplication.nativeApplication.addEventListener(KeyboardEvent.KEY_DOWN, handleKeys, false, 0, true);
            }
    }
     
    private function handleActivate(event:Event):void
    {
            NativeApplication.nativeApplication.systemIdleMode = SystemIdleMode.KEEP_AWAKE;
    }
     
    private function handleDeactivate(event:Event):void
    {
            NativeApplication.nativeApplication.exit();
    }
     
    private function handleKeys(event:KeyboardEvent):void
    {
            if(event.keyCode == Keyboard.BACK)
                    NativeApplication.nativeApplication.exit();
    }

  • Debugging on a device can be tricky. So tricky in fact that I never got it working. In all fairness, I didn’t try to diagnose it any further after the getting the initial error because the app I was building was so simple. But the fact remains that it didn’t work out of the box for me. Maybe your experience will be different and I welcome anyone to call me an idiot and tell me what I did wrong.

  The Ugly

  • Universal mobile device support is minimal at this point. Android is covered pretty well up through the Air 2.5 SDK, but iPhone/iPad only support Air up to version 2.0.2 via the Adobe Packager for iPhone. This leaves out key APIs like camera support and video/sound capture, not to mention the bevy of bugs and gotchas that you have to watch out for. The workflow for deploying apps to iOS devices with the packager is also no picnic. While the Blackberry Playbook is proudly supporting the Adobe developer community, there’s been no official announcement, though there has been mention, of Flash or Air being on Blackberry smart phones.

    Long and short, you aren’t going to be hitting the widest part of the market when compared to other mobile frameworks like Appcelerator or PhoneGap. And even if you do, I’ve experienced first hand how users can be put off by having to install Adobe Air on their phone for the sake of an app. Until Air for mobile devices support becomes more common place, it may be viewed as an unnecessary evil by many mobile users.

  • Performance can be a problem for even the simplest apps. This for me is the most critical area that needs to be improved before people will take Air seriously as a mobile framework. Simple things like view transitions, scrolling, button interactions, etc… have a noticeable sluggishness that users won’t stand for. Even the cream of the crop among Flex Hero apps, like Jonathan Campos’s nearly 100K user base NetFlix Queue Manager, is not immune to these problems. Though a majority of the comments are very complimentary, the few detractors have a very common message: we don’t want to install Adobe Air and we find it slower than native apps. Are these types of comments the whole story? Absolutely not. Does that mean they can be ignored? Absolutely not. The vocal complainers, though not always very helpful, can sometimes spur the necessary advances that can take a product to the next level.

  Summary

  Hey Adobe, fix the ugly, stay on top of the bad, and keep highlighting the good.

  While I am far from swearing off AS3 and Flex development for mobile devices, I think Adobe has a long way to go before it will be able to bring in a significant amount of non-Adobe developers. Their mobile platform and workflow seems as though it caters entirely to existing Flash and Flex developers. There just doesn’t seem to be an effort to bring in new blood from the outside. And if that remains the same, Appcelerator, PhoneGap, Sensa Touch, jQuery Mobile, or whatever other platform that comes next and engages larger cores of developers will take away valuable relevance in this land grab for mobile supremacy.

Time to say “Hello, World!” to the newest kid on the tablet device block, the BlackBerry Playbook.  Why bother developing for a tablet that isn’t even publicly available yet?  Because Research in Motion (RIM) is offering free Playbooks to developers who create “useful” applications for it.  Thats right, if you join the RIM vendor list (free registration for a limited time only) and submit a quality app, you will receive a free Playbook.  Great incentive to bring developers to your platform.

So how do you get started? Go to the Playbook developers site and follow the instructions there.  Be warned, though, that its not the simplest setup.  Right now RIM has workflows for developing Playbook apps in Blackberry WebWorks and Adobe Air (via Flash Builder 4.0.1 or “Burrito“).  For my first go around I chose the Flash Builder 4.0.1 workflow.

Wanna take a quick peek at the code involved with the Hello World (seen above) for this workflow?

AIRHelloWorld.as

package 
{
        import flash.display.Sprite;
        import flash.events.MouseEvent;
        import flash.text.TextField;
        import flash.text.TextFormat;
        import qnx.ui.buttons.Button;
        import qnx.ui.buttons.LabelButton;
 
        // The following metadata specifies the size and properties of the canvas that
        // this application should occupy on the BlackBerry PlayBook screen.
        [SWF(width="1024", height="600", backgroundColor="#cccccc", frameRate="30")]
        public class AIRHelloWorld extends Sprite
        {
                public function AIRHelloWorld()
                {
                        var helloButton:LabelButton = new LabelButton();
                        helloButton.label = "Hello World!";
                        helloButton.x = (stage.stageWidth - helloButton.width)/2;
                        helloButton.y = (stage.stageHeight - helloButton.height)/2;
 
                        var myFormat:TextFormat = new TextFormat();
                        myFormat.color = 0xAA0000;   
                        myFormat.size = 24;  
                        myFormat.italic = true;  
                        myFormat.align = "center";
 
                        var text:TextField = new TextField();
                        text.text = "Close";
                        text.setTextFormat(myFormat);
 
                        var closeButton:Button = new Button();
                        closeButton.addChild(text);         
                        closeButton.addEventListener(MouseEvent.CLICK, closeWindow);
                        closeButton.x = (stage.stageWidth - closeButton.width)/2;
                        closeButton.y = helloButton.y - helloButton.height;
 
                        addChild(helloButton);
                        addChild(closeButton);
 
                        stage.nativeWindow.visible = true;
                }
 
                private function closeWindow(event:MouseEvent):void{
                        stage.nativeWindow.close();
                }
        }
}

All of you AS3 and Flash developers should be pretty pleased. You get the comforts of your language of choice with the ability to access native QNX components; the best of both worlds.

Setup Pitfalls

I can’t stress enough that you need to follow the instructions exactly or you won’t get it working.  I speak from experience.  Perhaps you can save yourself a few minutes (or hours) of searching for the resolution to the cryptic errors you may encounter by looking at the problems I ran into.  But really, all of these could be avoided by following the instructions exactly as written.

The Flash Builder 4.0.1 update must be installed

They only mention 4.0.1 about a dozen times but I figured “how important can a point release be?”.  Turns out, very.  You’ll see this if you ignore it too:

An internal error occurred during: "Launching AIRHelloWorld".
com.adobe.flexide.launching.air.ApolloLaunchConfiguration.getAIRProfile()Ljava/lang/String;

Just download and install the Flash Builder 4.0.1 update and all will be resolved.

Adobe Air 2.5 must be installed

Again, they are clear as day about this, but you need to install the Adobe Air 2.5 SDK. The version that comes with Flash Builder 4 is only 2.0.2, or might be 1.5, I can’t remember off hand. You can find the version of Air your BlackBerry Tablet SDK is installed against by looking at the app config XML file (AIRHelloWorld-app.xml) in your project. The first node, application, indicates the Air version used:

 xmlns="http://ns.adobe.com/air/application/2.5">

In any case, if its not the right version you have to install Air 2.5 or you’ll see an error similar to this:

Error: Cannot find node: versionNumber

This is because the versionNumber node in your app configuration isn’t supported before Air 2.5. In order to fix this error, you need to reinstall the BlackBerry Tablet SDK and make sure to point it at the directory of Adobe Air 2.5 during the install. If someone knows a better way to do it without having to reinstall the Blackberry Tablet SDK I’m all ears.

Put your Playbook Simulator in Development Mode

Even if you remember to put your Playbook Simulator in Development Mode as per the instructions, you’ll probably forget (like me) that you need to do that whenever you restart the simulator. I’m not aware of a way to set Development Mode ON by default. Here’s the error you’ll see:

Using icon: C:\development\AIRHelloWorld\bin-debug\blackberry-tablet-icon.png
Package created: C:\development\AIRHelloWorld/AIRHelloWorld.bar
Sending Install and Launch request...
Error: Device is not in the development mode. Switch to Development from Security settings on the device.

All you have to do is follow the instructions here, which will tell you to do the following:

1. Activate the Playbook Simulator
2. Click the gear icon at the top right
3. Click “Security”
4. Click “General” under “Security Settings”
5. Toggle “Development Mode” to ON under “Development Settings”

Summary

That’s all I got so far. It looks like a terrific platform and is really engaging a lot of the development community by integrating native access through external SDKs. Soon as my plate clears up a bit I’m gonna hit this full steam and add myself to the list of the lucky talented developers (like Jason Fincanon) getting themselves a free Playbook.

The Demo

Scan 1 of the 4 QR codes below with your mobile device. Here’s an Android Barcode app and a couple iPhone apps if you don’t already have one.

The resulting link will take you to an augmented reality image marker. It doesn’t mean much by itself, but take a look at what can be done with this “QR to AR” method:

The Overview

NOTE: If you are totally unfamiliar with augmented reality, check out these previous posts: Augmented Reality and Augmented Reality with Away3dlite.

What’s one of the biggest blockers to augmented reality taking off? The difficulty in distributing the augmented reality markers necessary to make the technology work. If you’ve seen an augmented reality site, you’ve read the off-putting instructions to print an image to a sheet of paper to hold in front of your webcam. If you are a massive publication like Esquire, then its not so big of an issue.

But if you have no problem distributing AR markers, you probably aren’t reading this and don’t need my help. But if you do, you might want to try the “QR to AR” method of distribution shown at the top of this post. You should always offer the method of printing your AR marker, but with the widespread use of mobile technology, this is another viable method.

In short, the positive is that this method is easy to distribute and is more likely to be tried than with the “print this marker” method. The negative is that augmented reality is already a technology that depends heavily on a quality image. Consider the following when attempting to use the “QR to AR” method:

• Mobile phones can add difficulty with their reflective and glowing surface
• Good lighting and webcam quality is critical for the best possible augmented reality experience
• Disable auto-orient on your device, if possible, otherwise the image will turn when your phone does

This isn’t necessarily meant as a practical solution to augmented reality marker distribution and use, just a simple attempt to think outside the box. Hopefully it encourages people smarter than me to think of even more clever ways to bring augmented reality to the masses.

Special thanks to all techs involved here: FLARManager, FLARToolkit, Away3D, and my trusty Droid X using the .

This is my list of favorites from Twitter for the past week. Be sure to take a look at not just the links, but the people posting up the great content. Some heavy hitters on the list this week.

Quake 3D Environment running in Flash

AutoHotkey

tweeted by:
AutoHotkey is a free, open source utility to let you hotkey just about anything in Windows. Let’s you streamline and customize your Windows experience as much as you want. Here’s a brief list of hightlights:

• Automate almost anything by sending keystrokes and mouse clicks.
• You can write a mouse or keyboard macro by hand or use the macro recorder.
• Expand abbreviations as you type them. For example, typing “btw” can automatically produce “by the way”.
• Remap keys and buttons on your keyboard, joystick, and mouse.
• Create custom data-entry forms, user interfaces, and menu bars.

Control Your Computer With Your Brain in AS3

tweeted by:

jQuery Mobile

tweeted by:

Rockbox

tweeted by:
Rockbox is an open source firmware for mp3 players, written from scratch. What this means is that you can load open source, totally customizable firmware onto the supported MP3 player of your choice. This includes the following (with many more unstable ports):

So what can you do with it? You can customize the interface, use themes, watch movies, or even play Doom. Yes, Doom on your MP3 player. Badass.

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.