Gonzo

• Gonzo 0.1.0 alpha release Air installer
• Gonzo on Github

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

<h2>Here's a header</h2>

<p>Here's some content in a paragraph. And here's a link to <a href="http://www.google.com">Google</a> and another to my <a href="https://github.com/tonylukasavage">Github</a> account.</p>

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

<ul>
    <li>One of these lists' syntax</li>
    <li>has the following attributes:</li>
    <li>
        <ul>
            <li><b>intrusive</b></li>
            <li><b>ugly</b></li>
            <li><b>very hard to read</b></li>
        </ul>
    </li>
    <li>which one do you think it is?</li>
</ul>

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.</p>

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 Gonzo on Github, 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 Github, or on Twitter. 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, an open source markdown editor is a post from: SavageLook.com

Gonzo

In case you haven’t heard me talking about it on Twitter, I’m creating my own markdown editor called Gonzo. 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 hosted on Github
• Its written using Adobe Air for desktop, Flex 4, and AS3
• The markdown to HTML parsing is done using Charles Strahan’s Showdown.as
• 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("<html></html>");
		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> 
 
&lt;pre&gt;<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>&lt;/pre&gt; 
 
<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

• 100's of 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("<html></html>");
    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 Github site

Taking Notes on Node.js using Gonzo is a post from: SavageLook.com

The Code

• Repper-playbook on Github – 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 Github link 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.

Repper for Blackberry Playbook with Full Source is a post from: SavageLook.com

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.

Procrastinator’s Guide to a Free Blackberry Playbook is a post from: SavageLook.com

There’s been a lot of talk as of this weekend about 3D in Flash, due to Adobe’s announcement that Flash Player 11 is now available at Adobe Labs. Included in Flash Player is the much anticipated “Molehill” 3D API. To get an idea of how huge of a leap in terms of rendering this is for Flash, take a look at some of these videos I posted a few months back. Or better yet, experience it yourself by playing “Zombie Tycoon”!

Right in step with Adobe’s announcement came one from the Away3D team. They unveiled the alpha version of Away3D 4.0 “Broomstick”. This is the first version of my favorite 3D Flash engine that leverages the power of the Adobe “Molehill” API. Check out the Adobe Labs page for Molehill to see more of what Away3D will let you do, without having to get into the nitty, gritty details of Molehill.

In order to get a jump start on your Away3D development, I’d highly suggest picking up one (or both, like me) of these books: “The Essential Guide to 3D in Flash” and “Away3D 3.6 Essentials“.  Both are great guides to getting started with Away3D,  as well as 3D graphics in Flash in general.  While no longer the latest and greatest, they will undoubtedly continue to give great insight for aspiring Away3D developers.

As these are both great texts, I’m not going to put their attributes side by side and compare every detail.  Instead I’m just going to point out the highlights of each.  You really can’t go wrong with either.

“Away3D 3.6 Essentials” Highlights

• The clearest highlight is without question the choice of technical reviewer… Tony Lukasavage (see also, me).
• Matthew Casperson is the author and his brighthub.com work was the home for some of my earliest lessons in Away3D. Great demos and tutorials.
• Gives an extremely detailed look at the objects in Away3D, even laying out the initialization objects for many of the classes.  May not sound like a big deal, but Away3D makes heavy use of init objects for class constructors.  The only way to know how to use them without a reference is to go digging through the source.
• Answers one of the most frequently asked questions in Away3D with a simple chart: Which lights affect which materials?
• While both books discuss and explain model animation, this book delves into the sometimes baffling territory of how to properly export rigged models from popular modeling and animation program for use with Away3D.  In most cases its not as simple or intuitive as you might expect and this little extra help can go a long way.
• This book branches out a little further than “3D in Flash”, discussing topics like particle engines, pixelbender shaders, and postprocessing as they pertain to Away3D.

“The Essential Guide to 3D in Flash” Highlights

• The authors are none other than Rob Bateman and Richard Olsson, cofounder and core developer for Away3D.  There’s no disputing that getting the information from the crafters of the engine cannot be beat.
• Includes set up instructions for FDT.
• While “Away3D 3.6 Essentials” gives a brief look at the differences between point, directional, and ambient lights, “3D in Flash” gives a very detailed description of each.  Paragraphs of information and easy to grasp visuals paint a much more clear picture of just how light works.
• Contains a great example of how you can programmatically animate rigged models.  In some cases even when you follow all the rules, imported animations don’t work quite right.  This valuable example lets you take the animation into your own hands.

I could go on with more, but beyond this, its just splitting hairs.  Both books are so good it’s a great choice either way.

If you are serious about picking up Away3D for 3D Flash development and want the quickest path to success, either one will do just fine.  Just be sure to follow it all and actually code along with the examples.  That’s where a lot of the real value in these books lies.  And be sure you make it to the end where possibly the most important topic lies for each book: performance.  But then again, with the coming of “Molehill”, those performance concerns might not be quite so critical anymore.

“3D in Flash” and “Away3D 3.6 Essentials” is a post from: SavageLook.com

Overview

NOTE: all source code is available for Repper at Github.

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 RepperHome.mxml view.

        <s:HGroup 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">
		<s:SkinnableContainer id="landscapeInput" width="36%" skinClass="RepperInputSkin">
			<s:layout>
				<s:VerticalLayout 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"/>
			</s:layout>
			<s:HGroup width="100%" verticalAlign="middle" gap="0">
				<s:Label text="Weight" width="65%" color="0x000000" fontWeight="bold" fontSize="32"/>
				<s:TextInput width="35%" text="{inputWeight}" keyUp="onWeightKeyUp(event)" restrict="0-9." 
							 contentBackgroundColor="0xffffff" color="0x000000"/>
			</s:HGroup>
			<s:HGroup width="100%" verticalAlign="middle" gap="0"> 
				<s:Label text="# of reps" width="65%" color="0x000000" fontWeight="bold" fontSize="32"/>
				<s:TextInput width="35%" text="{inputReps}" keyUp="onRepsKeyUp(event)" restrict="0-9"
							 contentBackgroundColor="0xffffff" color="0x000000" focusIn="textinput1_focusInHandler(event)"/>
			</s:HGroup>
			<s:Button label="Rep It" click="recalculate();" chromeColor="#111111" />
		</s:SkinnableContainer>
		<local:VDataGroup width="32%" height="100%" dataProvider="{repValues1}" itemRenderer="RepperEntry"/>
		<local:VDataGroup width="32%" height="100%" dataProvider="{repValues2}" itemRenderer="RepperEntry"/>
	</s:HGroup>

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 RepperEntry components via the RepperEntrySkin.mxml class

    <s:Rect id="background" x="0" y="{this.height/6}" height="66%" width="100%" radiusX="10" radiusY="10">
	<s:filters>
		<s:DropShadowFilter blurX="16" blurY="16"/>
	</s:filters>
	<s:stroke>
		<s:SolidColorStroke weight="3"/>
	</s:stroke>
        <s:fill>
		<s:LinearGradient rotation="-90">
			<s:GradientEntry color="#bbbbbb"/>
			<s:GradientEntry color="#ffffff"/>
	        </s:LinearGradient>
        </s:fill>
    </s:Rect>
    <s:Rect x="0" y="{this.height/6}" height="66%" width="60%" radiusX="10" radiusY="10">
	<s:filters>
		<s:DropShadowFilter blurX="8" blurY="8" angle="0"/>
	</s:filters>
	<s:stroke>
		<s:SolidColorStroke weight="3"/>
	</s:stroke>
	<s:fill>
		<!--- @private -->
		<s:LinearGradient rotation="-90">
			<s:GradientEntry color="#000000"/>
			<s:GradientEntry color="#444444"/>
		</s:LinearGradient>
		<!-- <s:SolidColor color="#333333"/> -->
	</s:fill>
    </s:Rect>

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 twitter, 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.

From Air for Android to Blackberry Playbook in seconds is a post from: SavageLook.com

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 Twitter follower list to see some of the names that helped. Particular thanks to @killerspaz, @jesterxl, and @jonbcampos.

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 – as3iphonecomponents

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.

The Good, The Bad, and The Ugly of Flex “Hero” is a post from: SavageLook.com

]]> http://savagelook.com/blog/actionscript3/the-good-the-bad-and-the-ugly-of-flex-hero/feed 10 http://savagelook.com/blog/actionscript3/repper-my-first-flex-hero-mobile-app http://savagelook.com/blog/actionscript3/repper-my-first-flex-hero-mobile-app#comments Mon, 07 Feb 2011 14:02:35 +0000 Tony Lukasavage http://savagelook.com/blog/?p=2215 Repper: My first Flex Hero mobile app is a post from: SavageLook.com
]]>

Get Repper

→ Download Repper from its Android Market page → Full project source code available at Github → Follow the conversation on Twitter (#Repper) → Scan the QR code below to download from your mobile device

Overview

Repper is an Adobe Flex “Hero” based Android app that calculates your 1-10 rep max on any lift in the gym. For example, you might have a workout that requires you to know your 5 rep max on the bench press, but you you only know that you can lift 275 for 1 rep. Using Repper you can get a very close approximation based on estimation methods developed by fitness specialists. Just punch in 275 for the weight and 1 for your reps and Repper will return your 2-10 rep weight estimations.

The application itself isn’t that exciting, I know. The idea here was to see what the entire development and deployment cycle was like for Air for Android development. What’s easy with Flex/AS3/Air? What’s hard? What are the limitations? What are the annoyances? Where does it excel? Where is native development or even another mobile framework better suited? As it turns out, I generated a lot of answers to those questions. So many so as to merit their own blog post in the near future.

The other concept I was testing here was multi-screen development (inspired by Christian Cantrell’s work). If you peruse the source code you’ll notice that all layout and skinning was done with a liquid layout in mind. This means once I get the chance, Repper should be able to be deployed to other mobile devices like iPhone, iPads, Android tablets, or the Blackberry Playbook without much additional effort.

It was an interesting project and one from which I learned a great deal. in addition to the blog post on the ups and downs of Flex “Hero” that I alluded to earlier, I plan at least a handful of smaller instructional posts on some of the technique I picked up in this experiment. Topics will include handling portrait and landscape orientations with states, AS3 and MXML skinning, and liquid design for multiscreen projects. There’s more to share, but that seems more than enough to start.

All in all, this backend developer had a great time creating something visual and usable in the mobile environment. It won’t be long be another one of these app blog posts shows up!

Screenshots

Repper: My first Flex Hero mobile app is a post from: SavageLook.com

]]> http://savagelook.com/blog/actionscript3/repper-my-first-flex-hero-mobile-app/feed 2 http://savagelook.com/blog/away3d/qr-to-ar-using-qr-codes-to-serve-augmented-reality-markers http://savagelook.com/blog/away3d/qr-to-ar-using-qr-codes-to-serve-augmented-reality-markers#comments Mon, 03 Jan 2011 12:58:43 +0000 Tony Lukasavage http://savagelook.com/blog/?p=1472 QR to AR: Using QR Codes to serve Augmented Reality Markers is a post from: SavageLook.com
]]>

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 Barcode Scanner app from Zxing.

QR to AR: Using QR Codes to serve Augmented Reality Markers is a post from: SavageLook.com

]]> http://savagelook.com/blog/away3d/qr-to-ar-using-qr-codes-to-serve-augmented-reality-markers/feed 10 http://savagelook.com/blog/actionscript3/shit-my-twitter-says-xmas-edition http://savagelook.com/blog/actionscript3/shit-my-twitter-says-xmas-edition#comments Fri, 24 Dec 2010 14:47:28 +0000 Tony Lukasavage http://savagelook.com/blog/?p=1782 Shit My Twitter Says: Xmas Edition is a post from: SavageLook.com
]]>

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

tweeted by: @thibault_imbert Aerys shows off Minko, their tool for developing 3D applications for the Flash platform. This demo in particular is cool because they were members of the Adobe “Molehill” 3D API prerelease program. Take a look to see the future of 3D in Flash, in a very familiar format. That’s right, Quake 3D right there in your browser.

---

AutoHotkey

tweeted by: @johnlindquist
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: @seantheflexguy

Sean Moore blogs about his exploits with NeuroSky’s Mindset headset, a USB device that actually reads brainwaves (EEG) as user input. It comes complete with a free, open source API for developing your own applications that use the headset. Also there’s a sort of brain emulator that allows you to develop against the API without even buying the headset. Check out this blog post, and his previous one on the topic, to get a look at this incredibly cool technology.

---

Write high quality unit tested AS3 for fun and profit… tweeted by: @jhooks A great assessment of unit testing resources, particularly as they relate the Actionscript 3 programming. The insights on the high points and pitfalls of test driven development are well worth the read. “As with all code, complexity is easy. It is the default. Elegant simplicity is much more difficult.”

---

jQuery Mobile

tweeted by: @mesh

From the framework that made Javascript tolerable comes a version specially built for the unique needs of mobile developers. Enter jQuery Mobile. My favorite part about this framework, other than the familiar syntax, is the upfront honesty about its compatibility. Check out the compatibility chart on the “Platforms” page for more details.

---

Rockbox

tweeted by: @bit101
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):

Apple iPods (lots of versions) Archos Cowon iriver Olympus Packard Bell SanDisk Toshiba

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.

---

Shit My Twitter Says: Xmas Edition is a post from: SavageLook.com

]]> http://savagelook.com/blog/actionscript3/shit-my-twitter-says-xmas-edition/feed 0