Problem:
A big thanks to the Magical Hobo for creating the c++ code for this. The only problem is that the code was built in debug mode and requires Visual Studio and the MSVCP100D.dll. Great for people who want to dive into the c++ code but it adds a lot of upfront time in getting everything setup.

Solution:
After downloading the project from GitHub, removing all debug dependencies and re-building in release mode, the ANE was ready for use without Visual Studio. If you’d like the full c++ source, checkout the Magical Hobo’s source on GitHub.

More information on Adobe Native Extensions:
http://www.adobe.com/devnet/air/native-extensions-for-air.html

Link to original c++ source code by the Magical Hobo:
http://blog.magicalhobo.com/2011/10/01/air-3-native-extension-example-pentablet/

How do you know if your device can detect pressure?
Open up PhotoShop, select a brush, click on the pressure sensitivity icon and start drawing. If PhotoShop can detect the sensitivity than you should be good to go.

Requirements:
> Touch sensitive capable device.
> Windows OS
> Flash Builder 4.6
> AIR 3.1

Download the ANE:
http://www.blackcj.com/blog/wp-content/swfs/PenTabletLib.ane

Create your market ready AIR apps for iOS, Android and the BlackBerry PlayBook in a single click using the same code. This ANT task compiles, signs and pushes out to attached devices (iOS requires dragging into iTunes). All of the signed apps created with this ANT task can be published to the market.

Overview:
The AIR 2.6 SDK is great but doesn't have full Flash Builder support yet. This ANT task can be used in Flash Builder, Flash Develop, FDT or even the command line. Using Flash Develop, you can create apps for all devices without paying for expensive software!

Pre-requisites:
You will need to install Flash Builder Burrito, the BlackBerry PlayBook SDK, the AIR 2.6 SDK and acquire signing keys for all three devices. If using Flash Develop, you will need to follow some additional steps for ANT integration. You'll also want to download the base project from Google Code: http://code.google.com/p/air-mobile-tools/

Video Tutorial:

Wiki:
The wiki on Google code contains more information on getting started with this base project: http://code.google.com/p/air-mobile-tools/wiki/BaseMobileActionScriptProject

ANT Task:

Resources:
http://www.terrenceryan.com/blog/post.cfm/using-ant-to-package-the-same-air-app-to-multiple-devices
http://technophi.com/2011/03/08/using-ant-to-compile-a-flex-mobile-project-for-ios/
http://www.adobe.com/devnet/flex/articles/flex_ant_pt1.html
http://help.adobe.com/en_US/air/build/WSfffb011ac560372f-5d0f4f25128cc9cd0cb-7ffb.html

Problem:
E4x is great but it requires exact knowledge of the syntax. It's easy to forget common functions if not used every day.

Solution:
This cheat sheet is a collection of examples from common XML structures. It's meant to kick your brain back into gear after a few months without working in e4x. For a more comprehensive guide to XML and e4x please visit the links at the bottom of this post.

What is XML and e4x? I'll let Wikipedia handle that one.

Step 1: Define XML

Here is a quick example on defining XML inline:

The only difference is that the ActionScript variable is typed. The JS version will work in AS but typed variables are so much easier to work with. Code completion is my best friend.

OK, from here on out I'm just going to show the XML, trace statements and expected output. Everything is cast to a string for easy output.

Step 2: Access a node value

Using the XML above...

Strikingly similar, however, break points and trace statements are so much more fun than alerts.

Step 3: Access an attribute

I assume by this point you can figure out the JS syntax. Writing JS is like eating squash. It's good for you but why do it when there is free cake?

Step 4: Access a node value given an attribute key

JavaScript developers are ActionScript developers, they just don't know it yet.

Step 5: Access an attribute given an attribute key

Using the XML from step 4...

ActionScript and JavaScript are like two people that hate each other only to later find out that they are actually siblings with everything in common. They proceed to live happily ever after.

Step 6: Parse through nodes

Just remove the typed variable, replace trace with print and your JS will be good to go. At this point you might want to start populating value objects with attributes, paths and id's.

Additional resources:
http://www.republicofcode.com/tutorials/flash/as3xml/
http://www.senocular.com/flash/tutorials/as3withflashcs3/?page=4

JSON parsing cheat sheet coming soon!

Problem:
Linking to the Android market on a mobile web browser brings up a security warning saying "There are problems with the security certificate for this site." This pop up is rather troublesome, who is actually going to click to continue? Even if they do the web interface doesn't display very well on mobile devices. Let's bypass this message all together and bring the user directly to the Android market app within the mobile device!

Solution:
Replace "https://market.android.com/" with "market://" for any valid market URL. It's that easy! Just make sure to do this only within mobile applications. Desktop browsers and any other non-Android device will not know what to do with the "market://" preface. On the desktop use the standard URL and within mobile devices use the shorthand URL. This will ensure the best user experience for everyone and ensure the most downloads of your app.

Use this line of code in your AIR for Android Apps to bring up a search result (example 'terry paton'):
navigateToURL(new URLRequest("market://search?q=terry+paton"));

or link directly to an app with this:
navigateToURL(new URLRequest("market://details?id=air.com.terrypaton.tc2"));

Navigating to "https://market.android.com/..." on an Android brings up this message:

However, navigating to "market://search?q=terry+paton" brings the user to the market!

A big thanks to Terry Paton for working with me on my mobile marketing campaign. Make sure to check out all of his awesome AIR for Android games on the market:
https://market.android.com/search?q=terry+paton

Multi-screen:
The variety of screen resolutions and DPIs can be the hardest part of building a mobile app. When building an AIR app for mobile devices you have two important properties Capabilities.screenResolutionX(Y) and Capabilities.screenDPI. Using stage.stageWidth on mobile devices does not work the way you would expect it to. If you set up your application in Flash to have a width of 480 and a height of 800, the stageWidth and stageHeight will return these numbers even if the screen is smaller. Another thing to note is that the iOS packager currently targets 320x480 even though many of the iOS devices run 640x960. We'll account for that by adding a screenResolution check.

In my application when a device has lower than 400 pixels in width I drop down the paint brush width. When the device has higher than 400 pixels I increase the size of the menu accordingly. A better approach would be to use the Capabilities.screenDPI for this calculation rather than just the screenResolution. All of your view components should be able to render at different DPIs and resolutions. When you know this from the start it is easy to build into the code. Here is an example:

Notice how we are changing the size ratio of the brushes for smaller screens with a lower DPI. For larger screens we are increasing the size of the menu. This makes the application appear the same to the end user even when the app is running at 480x800 on the Android and 320x480 on the iOS! This could be improved to use the actual DPI value but the basic idea is there.

Multi-touch
This is the easy part. Use the Multitouch.maxTouchPoints to determine if the device supports touch. If it does than add touch listeners, if the device has 0 touch points add mouse event listeners. Don't be that person that only codes for one device. With only a few extra lines of code you app will work on desktop and mobile. This also makes debugging much easier!

Wasn't that easy? One thing to note is that TOUCH_END was not always dispatched, especially when you start using 3+ touch points. To work around this add a timer into your class that checks to see if a TOUCH_MOVE event has been called. The TOUCH_MOVE event is dispatched even when the user has stopped moving and only stops when the touch has ended. As a backup, check every half a second or so to make sure the specific touch point id is still moving.

Setup:
To setup your workspace to export to all three platforms you'll need to create a ActionScript only Mobile project in Flash Builder Burrito. Create an FLA in the source folder that uses the runnable AS file as its base. Create your assets in the FLA file, export them into a SWC to be used for FB and mark them as run time compiled so they work with the Flash IDE. From here you can export to all three devices without changing any files. Life is good

Conclusion:
In just 17 lines of code and a little setup we've got our multi-screen, multi-touch application ready to go! Make sure to add your event listeners for Android to close the app when the user hits back or home. This entire painting application is less than 400 lines of code (~4KB compiled), was built from scratch in less than 12 hours and is easily maintainable across multiple platforms. Performance is great and native APIs are easy to use. My only complaints are that the file size for the iOS is rather large and the iOS exporter doesn't support the Camera API yet. Outside of that, this is the best way to build cross platform apps.

Wet Paint on the Web:

Porting to the web required changing 3 lines of code. To get these source files running on mobile devices change the _webMode value to false and remove the width / height from the SWF declaration. I also had to comment out the cacheAsBitmapMatrix to get it running on the web. Still very easy to convert!

Source files.

Enjoy!

After downloading Flash Builder I thought it would be fun to check out the new Text Layout Framework. While the end result is really cool, almost all of the documentation available is already outdated. Here is an example using an ActionScript only project in Flash Builder to create underlined, padded, editable text. I threw in the undo manager for fun.

TextFlow Example:

(click in the text field above, type in text than hit ctrl-z to undo.)

Full source code can be found here.

Next Steps
Wrap all this mess into a class that I can actually use. 15 imports and 30 lines of code is far to cumbersome to use on a regular basis. Stay tuned for an encapsulated class that takes advantage of the key features.

http://forums.adobe.com/thread/458116
http://labs.adobe.com/technologies/textlayout/demos/
http://opensource.adobe.com/wiki/display/tlf/Using+TLF+with+Flash+CS4
http://corlan.org/2009/01/19/how-to-use-text-layout-framework-in-flex-32-or-air-15/
http://forums.adobe.com/message/2646565

Problem:
Let me start by saying SWC's are great. I've been using them more and more to include third party API's, utilities and assets. There is one problem, embedding a font into an asset in a SWC will override the internally defined fonts in a project. Why is that bad? Well lets say you have a static text field in your SWC using Georgia and a TextField instance in your Flex project using Georgia. No text will show up in your Flex TextField. Check out this example (notice it starts invisible):

SWC Text Embed Conflict:

(switch between MyGeorgia and Georgia fonts to see the disappearing text)

Full source code can be found here.

Solution:
Define your embed tags in ActionScript with a different fontFamily and fontName. So, if your font is Georgia than name it EmbedGeorgia. This will allow your TextField to reference the correct class definition. In my experience the SWC will always win if there is a conflict.

rather than...

It's that easy?
Yup.

What if you have two SWC's with Georgia embedded text?
Will they conflict with each other? Based on the example above the answer is no. Awesome!

What if my fonts are stored in a SWF file?
Than duplicate the above code but reference your SWF instead of the font in the assets folder.

Code that results in invisible text:

Swap out the Embed tag, update the TextFormat and you will be good to go.

Rant:

On the way to this solution I came up with a number of hacks that appeared to work only to break at the worst time. These hacks included storing a second reference of the font in the SWC (assuming you have access to the source), enumerating through the font list at runtime (which only fixes the problem in debug), and breaking apart the text into bitmaps (you don't want to know how long that takes). Rather than stop using SWC's I started to create more and more of them pushing towards an acceptable solution. This is what I ended up on. Hopefully it will save everyone some time and a little sanity

Bitmap Encoding - (link)

Advantages:
Keep transparency
Fastest Method
Does not require a Loader

Disadvantages:
Largest Filesize
Will only work with images up to a certain size

PNG Encoding - (link)

Advantages:
Keep transparency
Smaller filesize than Bitmap Encoding

Disadvantages:
Slower than Bitmap Encoding
Larger than JPG Encoding
Requires Loader

JPG Encoding - (link)

Advantages:
Smallest Filesize
Variable Quality

Disadvantages:
Slower than Bitmap Encoding
No Transparency
Requires Loader

Definition:
A CAPTCHA or Captcha is a type of challenge-response test used in computing to ensure that the response is not generated by a computer.

Solution:
What if we have a user drag a circle onto a box? A spider would have a pretty hard time with that, right? WRONG. While this may be a good filter at the view level it still does not solve our problem. All the hacker would need to do is submit the form correctly one time and use a program like Firebug to sniff the submission URL. They could then completely bypass your view and submit the form as many times as they want.

The only way to ensure the Flash form is being used is to pull the logic out of the view and onto the server. The Flash merely serves up content and never knows what the 'answer' is. In this example we will use PHP to generate the image, MySQL to store the key value pairs, and Flash to display the content. This implementation does not require any images to be stored on the server so it NEVER re-uses an existing image. The PHP generates the image on the fly and serves it directly to the Flash application.

Here is a diagram representing the high level information. Blue lines represent Captcha generation and the red lines represent the Captcha verification.

Server Side Captcha in Flash

Let's start with the PHP. There are already plenty of PHP scripts out there to generate Captcha. In this example I re-purposed a script called Securimage.

First we need a script that will retrieve the image:

Next we will need one that verifies the user input with the image:

Now that we have the PHP in place we can create the Flash. The display logic is separated from the view so you can re-use this code with any server side script. The Captcha class requires an ID and a URL to the image to display. It has optional styling parameters to match the look and feel of your webpage.

Generating a Captcha in Flash:

Verifying a Captcha in Flash:

Flash Demo and Source:

(click the image to manually refresh the captcha)

Full source code for Flash & PHP can be found here.

In the source code you will need to replace DB_USERNAME and DB_PASSWORD with your username and password. This example also requires a MySQL database with a table called captcha containing rows flash_id, captcha_id and valid. Valid is used to ensure the Captcha is only submit one time. Since we are always generating a new image there is no reason the Captcha should be allowed to be submitted twice with the same id.

Next Steps:
Additional steps could be taken to prevent robots. Failure rates and number of attempts could be stored for each IP address. No human should ever attempt to re-submit an old Captcha since each time it is randomly generated. The system could block anyone that attempted to re-submit a Captcha.

I would eventually like to make this accessible by integrating audio support. This is a feature of Securimage and would make the utility more versatile.

Box2D Anti-Gravity Example:

(click and hold the mouse down for anti-gravity)

Now that we have a Box2D environment set up and lots of polygons in it, let's make it cool.

Anti-gravity boolean.
Add this boolean and if statement into your shape environment class.

Now add a mouse event handler and the following functions into your main class.

Now you have anti-gravity!

Miss out on the basics? Check out part 1 and part 2 of this series.

Full source code here.