One of the great new features of AIR 3.0 is native extensions. These extensions allow you to build hooks into the native OS that lets you do some things that AIR doesn’t support on its own. One of the best things about AIR is the fact that it can run on so many platforms, E.G. Android, IOS and the Playbook. However, one drawback to this is that AIR must cater to the lowest common denominator and cannot really focus on device specific features. This is where the native extensions come in. They let you write code native to the device that can tap into the cool features that make each device unique. This means, for iOS you would write the extension in Objective C. For Android you could write it in Java. On Android, this could let you push things to the notification drawer and maybe on a Blackberry you could get access to BBM messages and features. You can find a great tutorial for building your own AIR native extensions for Android at Adobe.

NOT ALL SUNSHINE AND LEMONADE:

The work flow for building your own native extensions isn’t too bad but there are a few caveats. Right now there aren’t really tools for packaging your extensions so you need to know a little bit about the command line and building bat files. The other half of this is that the packaging errors can be a little cryptic so be prepared to spend a lot of time googling random phrases and hoping someone else had the same error as you before.

For example, one of the issues I had was with signing my extension. ADT was attempting to generate a time stamp but it kept failing giving me this error: “Could not generate timestamp: handshake alert: unrecognized_name”. The solution was to include “-tsa none” as a -package option in my package.bat.

A second issue was with adt.bat. This bat file executes \lib\adt.jar however on my computer it was pointing to the wrong path when my package.bat tried to run it. The solution was to hard code the path to the jar file rather than use the aliases.

When you’re invoking the native code in AIR and there’s an error, the AIR debugger doesn’t really know how to deal with that. It can be difficult and downright frustrating to debug something when you’re not sure where its failing.

Lastly, like I mentioned before, one of the best reasons to use AIR is the fact that its cross platform compatible. By their very nature, native extensions are not. However, there are still use cases where you could build something in AIR but use a native extension if the OS had a better implementation. It was this last case that lead me to create a native extension for accessing the sharing API in Android.

ShareExt: AN EXTENSION FOR NATIVE ANDROID SHARING

There are several Actionscript libraries out there for building in links to Facebook, Twitter, Flickr etc… in order to share your content but one of the cool features of Android is that it has a standardized API for this. So if I’m deploying to Android why not use something that the users will already be familiar with? With this in mind, I built a native extension for accessing the share functionality in Android from AIR. I won’t say that its fully featured and functional but it handles sharing most mime types. You can pass it an image, video, audio or other file and it will do its best to share with the right tools. It also supports sharing straight text. I built a really basic AIR app that you can side load on your Android device to try it out. The app uses the built in AIR API for file browsing to find a file to share but when it launches the list of sharing apps that’s all Android, baby. Click here to download. If you visit the link on your device it should download and let you install it pretty easily.

You can find the source code for the native extension and the example app on github if you’d like to play around with it. The folder ‘extension’ houses the two halves of the extension. The folder ’shareAirExt’ has the code for the Actionscript part of the extension while the ’shareJavaExt’ has the Java portion. I’ve also included my .bat file. Its mainly taken from the tutorial I’ve linked above but it might be useful to have a working reference.

Once you’ve built the native extension, using it in Actionscript is a breeze. It acts just like any other object from a SWC or library.

/*
Instantiate our Native Extension and share our file with the native extension.
*/
share = new ShareExt();
share.shareMedia(file.name,file.nativePath, mimeType);

WHATS OUT THERE NOW:

Native extensions are the hot new thing right now and developers have only just started to scratch the surface of what can be done. At gotoAndLearn(), Lee Brimelow talks about building a native extension for pushing to the notification drawer on Android.

This example, from Todd Anderson, shows how you can build a native extension to get battery information on iOS.

At as3NUI they have built a native extension for using the Microsoft X-Box Kinect in AIR. This is coolest thing yet and really shows the power of native extensions in AIR. AIR and Actionscript is already a great environment for making games so hopefully, with this great new extension, we can start seeing some Kinect games and installations built in AIR.

Speaking of games Milkman Games has built a iOS native extension for using Game Center in your AIR apps. This should mean a more unified experience of AIR apps on iOS.

This is only the beginning and I, for one, am excited to see what comes next.

UPDATE ON JAN 5th, 2011:

I committed a packaged version of the ANE file to the github repo. You can find the repo here. Or, if you’d prefer, you can download the ANE file directly by clicking here.

When I first heard of PixelBender I was so stoked.

PixelBender is a shader language built for Adobe products. You notice I say Adobe products and not just Flash. Pixel Bender can be used with Photoshop and After Effects also. (probably other products too)

Basically a shader is a “filter” that can be run over an image or data. To get started with PixelBender it’s best to start out with images rather than with data cause it will be easier to get the hang of things.

I’m really surprised we haven’t seen PixelBender being used more in Flash. You can write some really amazing effects very quickly. Of course you could write the same effects using BitmapData however PixelBender will be much faster. Most things in Flash currently only run on one core of your computer. So when you are doing calculations on BitmapData objects it will run on one core. Most computers have multiple cores today and PixelBender is able to run evenly across all your cores. Of course most likely in the very near future PixelBender will be running on the GPU instead of the CPU, which is even better.

So what can PixelBender do (click below):
(Please open the article to see the flash file or player.)

Here’s the PixelBender code to get this effect:

It may look a bit scary because it looks nothing like AS3 or JS or another scripting language. But basically how it works is that this code will run over every single pixel of whatever is passed to it. This is performed in the evaluatePixel function. With this filter we have one image that’s passed to it which is called src.

You can see src defined being defined near the top of the code:

So you may have noticed that with all the variables type comes before the variable name. This is because PixelBender is a C-Style language. What we are saying here is that we’re going to be passing it an image that has four colour components: red, green, blue, and alpha.

In turn right below where we declare the input we define the “output” which is a pixel with four colour components:

Under those two declarations you’ll see a whole bunch of paramaters. Parameters are important! They are the variables that will be accessible in Flash. So if you check out the SWF example you’ll see sliders that are effecting these parameters.

Cool things in the PixelBender language:

• Don’t have to write a lot to get cool stuff
• You can perform calculations on objects with regular data types (float4 col; col+=3.0;)
• Very very fast

Gotchas:

• No looping in PixelBender Flash (there is a bit of a hack that I might talk about later)
• When using floats/Number data types you always have to use “.” so for instance 0==0.0
• float4 is the same as Pixel4
• Hard to start thinking of evaluating pixels and not “pushing” pixels

To get started with PixelBender visit this page:
http://www.adobe.com/devnet/pixelbender.html

However, when you finish writing it you realize that it took you twice as long as it would have if you didn’t worry about horizontal and angled scrolling. Also, now when you use the scroll bar it now takes twice as much set up time just to get a vertical scroll bar. Let’s say instead of 10 minutes, it now takes 20 minutes.  This isn’t a huge deal most of the time but in aggregate it is. If you use the scroll bar class 10 times in one year you’ve spent an extra hour and forty minutes on it. A better idea would be to code a vertical scroll bar and extend the class when you do need the rare horizontal scroll bar.

This is what i call coding for the 90%. This should be your guiding principle when writing code. Worry about the 90% of cases, and deal with the other 10% when it comes up.

This principle can also help guide API development. When creating an API its important to think about how a person will use your API in the future. Rather than include a million constructor parameters to handle every use case think about whats the most important. It may not take much to develop that class but if every time someone uses it they need to configure 10 different options, a lot of time is lost. Like my previous post on writing reusable code, following the 90% principle can help you pick your battles when it comes to writing reusable code. Not everything has to be resuable, just the things that you use a lot.

Text and typography effects are all the rage right now. This example shows you what you can do when you can manually animate each individual letter. Manually splitting text fields for animations can be pretty annoying though. In this post I’ll show you how to split your text fields for use in animations.

First off, you’ll need a text field. I prefer to have my TextField in place and added to the displaylist already so that you can replace it later with your individual fields.

To split our fields we’re going to create a class that will split our text up for us, store references to the fields it creates and replace our single TextField with many fields. This class should also provide methods for accessing our newly created fields.


package {

}
}
}

So now we have our class structure flushed out. As you can see we have a Vector for storing our fields, as well as places to store references to both our original field and its parent.

We would use this new class like this:

var splitText:SplitText = new SplitText();
splitText.splitify(myField);

//do something here to the new fields!


But wait! our split method doesn’t do anything yet! Lets fix that.

Lets build our function:

public function splitify(textField:TextField):void{

//we increment our counter like this because using myArray.length() is actually very very slow.
_numFields++;
}
}


Done! we now have our fields in place and ready to be animated!
As an example of what we can do, this next chunk will change the color of each letter to something random.


for(var i:int = 0; i< splitText.numFields;i++){
var tf:TextFormat = splitText.textFields[i].getTextFormat();
tf.color = 0xFFFFFF * Math.random();
splitText.textFields[i].setTextFormat( tf);
}


One thing that a lot of coders talk about is writing reusable code. You see it on job ads, tutorials, coding articles, etc… However, as a junior developer it can be hard to get into the habit of writing things that are portable. Writing things worth saving can also be a challenge for newer developers. I think one thing that could help is to simplify. Don’t worry about making that drop down menu work for every possible configuration, and don’t worry about making SwfAddress integration perfect. Pick out the small things and work it out.

One thing flash developers do a lot is to make sure that text is on whole pixels, For example:

One way of doing this:

Another way, the reusable way, that doesn’t involve littering your code with int() is to simply create your textfield class.

This way no matter what we set the x and y properties to, they will always be floored to whole numbers. We have just saved ourselves countless seconds and keystrokes from typing int(xVal) over and over again. We’ve now begun our foray into reusing code and saving time. Even though this example is very simple, its a good way to get your mind thinking about other ways you can save code for later use.

Another way to get into the habit is to save important functions. How many times have you needed a random number between two integers?
You could try to remember this:

or you could write this once and then add a static Utils class that contains this:

I’m sure if you look around your code you’ll find all kinds of small snippets that you use over and over again. The more you recognize the small things that can be reused, the easier it will be to understand what makes even complex code reusable.

So for the past two days I’ve been playing around with Away3D/Molehilll. I really like how easy it’s to get stuff going in Away3D but I got this feeling that I don’t like not knowing what’s going on in the background. So I started looking at the low level stuff for Molehill.

Now… I’ve literally had two evenings to look at this stuff and so I’m sure some of my assumptions are wrong but I still want to write a blog post on this stuff. So… If I say something completely wrong please correct me gently.

Before we get going I think there are some terms everyone should know.

Terms:
Vertex-One point in a triangle, a 3d point. A vertex will define the “corner” of a triangle. A gotcha in Molehill is that a vertex will define the position and colour of that corner.

Matrix-You use Matrices you modify Vertices. Think of a Matrix as an “equation” to rotate, scale, or position of a vertex.

Shader-A shader is a small program that is used to modify vertices. A shader can use a Matrix to modify the Vertex. (program that runs the equation over all 3d points) My gotcha was that my mind was thinking of Shaders in terms of modifying textures and looks but they also modify positions of things.

So now that we have that out of the way we can start looking at the different parts that make up MoleHill.

Basic Parts Of Molehill:
Stage3D
Context3D
VertextBuffer3D
IndexBuffer3D
Program3D
AGAL
VertexShader
FragmentShader

Explanation Of The Different Parts Of MoleHill:
Stage3D
Stage3D is the part that sits in-between Flash and all the GPU goodness. Stage3D does not sit in the display list (you cannot do a addChild on a Stage3D object). Stage3D just exists in the same way that stage just exists. Stage3D sits behind all your regular flash content but in front for the new StageVideo.

Context3D
A Stage3D will contain a Context3D. Think of it this way… It’s almost the same as Bitmap contains BitmapData. You do not draw to Bitmap in the same way as you do not render stuff in Stage3D. All the work is done with BitmapData the same as Context3D.

VertextBuffer3D
Context3D will contain VertexBuffer3D objects. Think of VertexBuffer3D as being “instructions” on what to draw and what it should look like. VertexBuffer3D will contain a Vector.<Number> (array of type Number) that will define vertex position and colour for each vertex. (more on that in a bit)

IndexBuffer3D
The IndexBuffer3D just like the VertexBuffer3D will contain a Vector. But instead of a Vector.<Number> it contains a Vector.<uint> which defines triangles in VertexBuffer3D. Think of it this way… VertexBuffer3D will contain a bunch of positions but IndexBuffer3D will determine what order those positions should be drawn. As a real world example VertexBuffer3D defines cities on a map then IndexBuffer3D will define what order to visit those cities.

Program3D
Program3D is a “program” that will run through the data in your VertexBuffer3D and “modify it”. Program3D contains two shaders (smaller programs) that will modify the position of every vertex and figure out what every pixel within a triangle should look like. The two smaller shaders or “programs” are called VertexShader and FragmentShader.

VertexShader
The VertexShader is a small program written in AGAL that will modify the Vertex positions within a triangle. For instance if you wanted to scale, rotate, or move your triangle you would use the VertexShader to do this.

FragmentShader
The FragmentShader is another small program written in AGAL that will modify the pixels in your triangle. For instance if you want to tint your entire triangle red you would write a small FragmentShader to do that.

AGAL
AGAL is a very low level language. It’s used to write your VertexShaders and FragmentShaders. It’s the heart of MoleHill.

Quick diagram on how all the parts interrelate:

When you use Molehill there are really two parts to your program:

1. Setup
2. Render

Things we want to do during Setup:

1. Get a Context3D instance from Stage3D
2. Setup the Context3D
3. Create an VertexBuffer
4. Create an IndexBuffer
5. Upload Initial Vertex Data to the VertexBuffer
6. Upload Initial Index Data to the IndexBuffer
7. “Compile” a VertexShader
8. “Compile” a FragmentShader
9. Create a Program3D which will use the above shaders
10. Add a ENTER_FRAME loop which will send data to the GPU

I know that’s a lot of stuff just to get this sucker setup but it’s not as bad as it sounds. Setup is WAY more complicated in my mind then the actual rendering.

Things we want to do during Render (ENTER_FRAME):

1. Clear the Context3D
2. Set the Program3D that will be using
3. Send the Vertex Buffer to Context3D
4. Setup data for you your shaders (variables)
5. Draw some triangles
6. Update the screen with your drawn triangles

Now let’s dig into source code.

The setup part described above is done in the function “onGotContext”. This is because in order to get the Context3D we have to request it and when it’s available Flash will send it to us.

The render part happens in the ENTER_FRAME function listener “onRenderLoop”.

Enjoy… I tried to write as many comments as possible in the code so you can follow along. I should note that this source code is based on Thibault Imbert’s blog post and this video.

1. How to get people to see your app
2. How to make money off that app

App stores really solve both of these issues. One of the coolest things as a web developer is the fact that there are ways to create “native” apps for these app stores using the standard languages we use: html, js, css, and AS3.

Here are some platforms web developers can deploy to using the languages noted above:

Conclusions:
If you are a developer and want to start developing with minimal overhead and with huge reach the Nokia Ovi store is the way to go. The Apple iDevices are extremely popular in North America but worldwide Nokia is still a HUGE player with bigger reach.

The Chrome web store is the most straightforward option for web developers. The sign up fee is very minimal and there are no other tools you need to learn (or buy) to deploy apps. Out of all the stores the Chrome web store takes the smallest cut however it’s a very new platform and doesn’t have the same user counts the other platforms can boast. The $1.99 minimum app price point is interesting in that as a developer you will not be competing against $0.99 apps however it being a new platform it could deter users.

Even though neither of the Apple stores won in any of the columns they are obviously still a great option to develop for. They were the first platform to have an app store and so the other app stores are definitely trying to compete against Apple’s stores and with good reason. The iOs store still sells the most apps out of any store.

The Android market shouldn’t be forgotten as it is currently the biggest competitor in app sales vs the Apple store. Enrollment fees are quite a bit lower than the Apple store’s and it’s nice that they payout developers quite often.

Blackberry App World is an interesting underdog. Currently it’s receiving A LOT of developer support especially from the Flash Platform community because of the Blackberry Playbook and this promotion. It’s very cool that they’ve been working on app monetization strategies more than anyone else. This gives the most avenues for developers to make money. Cost for being a App World developer is much too high though. (although currently the initial $200 fee is waved) Unlike the other stores where you pay a one time fee or anually in the App World developers pay $200 to receive 10 credits. One credit is used per app you submit. You will not receive your credit back if your application fails the QA process. You will also have to use one credit to update your app. This to me is ridiculous! In order to maintain quality of applications developers should not be penalized.

Overall the great news is that using the languages you know with some new tools you can target most, if not all of these platforms. (more on these tools in a future post)

Time line Animators are very good at what they do. They can make a site come to life. Many of our projects here at Jam3 would not be possible with out an animator. Family’s Baxter is a great example of how an animator can help to put a project over the top. The paint splatters might seem simple but they would have been very difficult to produce only using code; the animations for the games (I.E. Jackal or the zombie walking) would have been downright impossible. However animators are not typically versed in Flash/web development. Therefore it is important that communication occurs before the project begins in order to make sure that the developers and animators are on the same page. The following is an assortment of tips and instructions for working with an animator.

Firstly, if the animator is animating something for actual use in a site, you make sure that they limit the amount extra animations. If the animator is making an animation guide then they are free to incorporate all parts of the site for proofing. However, normally the animator is trying to provide the developers with a specific effect for a specific graphic.

It’s important that the animator organize the .fla properly. This means they should try to limit the amount of clip nesting. The animator should be instructed to only nest clips when absolutely necessary. This makes it easy for the developer to control animations (e.g. the speed of the animation or start timings) and to remove parts that may no longer be needed. Also, there should be a discussion with the animator about how things should be named in the library.

Next, it’s very important that the animator is consistent with registration point placement. Ideally the placement will be dictated by the developer but if that’s not possible it’s important that the animator chooses one placement and sticks with it. Top-left or centered is fine as long as its consistent throughout the file.

Another useful tool an animator/producer/developer can use to help organise animations are frame labels. They are very useful in identifying frames and states such as “up”, “over”, “animate in”, etc… Since these are case sensitive it is important that they are consistent. Either all uppercase, or all lowercase. camelCasing or Proper Casing are possibilities as well, assuming their use is consistent.

The biggest takeaway when working with an animator is that they understand how important it is to be consistent. The developer shouldn’t have to constantly check how a clip is placed or what case a frame label is in. It cannot be assumed that the animator understands why this is necessary and, frankly, it is not their responsibility to know these kinds of things without being told. It is up to you (i.e. developers/producers/designers) to make sure that the animator knows how you want the clip.

If animators are given proper instructions, development time can be saved or put to better use. There is nothing more frustrating than to have to redo something because proper communication wasn’t present at the beginning of the project.

When everybody is on the same page, it is a magical time when projects take that extra leap from good to great.

Maybe it will become more or maybe not.

(sorry for the frame rate drop from when I was recording, first time recording in HD)