Overview

If there’s one thing I’ve learned from delving into iOS, Android, and Blackberry app development, it’s that there’s a lot more to creating a mobile app than just coding it. One of the things that can catch you off guard, especially if you are devoid of design ability like me, is the amount of icons and images necessary to deploy your apps. This becomes even more daunting when you intend to deploy to multiple platforms.

The other concern is that it isn’t always evident from the development tools how many different graphics you need to account for all scenarios. A new iOS developer will likely be unaware that you need a 58×58 pixel icon for iPhone 4 Spotlight and Settings. To attempt to alleviate some of this confusion, I put together these charts to detail what I know so far about the graphics required for submitting mobile apps to the various Android, iOS, and Blackberry markets.

Icons

	Android	iOS	Blackberry Playbook	Notes
29×29				iPhone Settings and Spotlight, iPad Settings
36×36				low pixel density icon
48×48				medium pixel density icon
50×50				iPad Spotlight. iOS will trim 1 pixel off each side and add a drop shadow, making it 48×48
57×57				standard iPhone icon
58×58				iPhone 4 Settings and Spotlight
64×64				optional small custom document icon
72×72				Android high pixel density icon, iPad icon
86×86				standard Playbook icon. It will trim 5 pixels off each side, making it 76×76
96×96				Potential icon size if iPad gets a high ppi screen
114×114				standard iPhone 4 icon
144×144				Potential icon size if iPad gets a high ppi screen
320×320				optional large custom document icon

Distribution Images

	Android Market	Apple App Store	Blackberry App World	Amazon App Store	Notes
screenshot sizes	320×480, 480×800, 480×854, 1280×800	iPhone: 320×480, 480×320, 320×460, 480×300 iPhone 4: 640×960, 960×640 iPad: 768×1024, 1024×768, 748×1024, 1004×768	640×640 or smaller	480×854, 854×480	required # of screenshots: Android: at least 2 Apple: at least 1 Blackberry: 1-50 Amazon: 3-10
114×114					device icon
180×120					Promotional graphic (no alpha)
480×480					Product icon that should match your 86×86 icon
512×512					Large/High resolution product icon
1024×500					Feature graphic for market

Additional Notes

For Android, your 36×36, 48×48, and 72×72 pixel icons should be placed in the drawable-ldpi, drawable-mdpi, and drawable-hdpi folders of your Android project respectively. Be sure to specify the name of the file you will be using in the android:icon attribute of the element in your AndroidManifest.xml file. Android also allows you to include a promotional video.

For iOS you simply need to add your appropriately sized and named icons to your Resources directory in your XCode project. Here’s a mapping of the icon sizes to the required name of the icon file. NOTE: There is purposely no extension on the 512×512 iTunesArtwork file.

• 29×29 – Icon-Small.png
• 50×50 – Icon-Small-50.png
• 57×57 – Icon.png
• 58×58 –
• 72×72 – Icon-72.png
• 114×114 –
• 512×512 – iTunesArtwork

For Blackberry Playbook, you need to specify the name of your 86×86 application icon in your application’s blackberry-tablet.xml file. Below is a sample of how you would set that up.

>
    >
        >86x86.png>
    >
    >My Company>
    >core.games>
    >my_splashscreen.jpg>
>

For the Amazon App Store you can also submit promotional images of various sizes and up to 5 promotional videos.

Summary

So as you can see, you’ve got a lot to consider when it comes to presenting your mobile application to the masses. As a developer, I’m looking for the simple solution here. For me, the easiest thing to do was use this 512×512 iOS icon template, create my icon, and scale it down to all the required sizes. If you happen to be reading this post and know a better/easier workflow, please let me know.

Here’s a few references to check out to get some additional information on mobile app icons and market images:

• iOS Human Interface Guidelines – Custom Icon and Image Creation Guidelines
• App Icons on iPad and iPhone
• Android Icon Design Guidelines
• Blackberry Playbook – Designing Application Icons

The Code

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

The Overview

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

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

Repper on Github

Guide to a Free Playbook

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

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

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

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

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

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

Sign up to be a Blackberry vendor

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

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

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

Get your code signing keys

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

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

Follow the Getting Started Guide

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

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

Create your app

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

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

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

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

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

Submit your app to the App World

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

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

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

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

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

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

Wait for approval

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

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

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

Overview

Interested in Blackberry Playbook development?  Well you should be if you want to get one for free.  And to get one for free, you need to develop for it before the device is even available.  How do we do that?  With the freely available simulator.

While Blackberry does a good job of getting you up and running with their Getting Started guide, they leave a few useful tidbits out about the simulator itself.  How do you minimize apps?  How do you change the orientation of the simulator?  Before we answer that you need to know one bit of information.  The “bezel” in the simulator is the black area surrounding the actual Blacberry Playbook OS running in your VMWare virtual machine player.  This is important to know as it is the area where many useful gestures start and end for the simulator.

Now with that in mind, here’s a list of items I’ve found so far that will help you move a little faster in your Playbook development.

Tips

• Minimize your running app by holding the mouse button down while over the bottom bezel, then dragging it up into your app, like a touch “swipe”.  The simulator doesn’t have an easy, built-in way to close apps once you open them in development.  This tip will let you get back to your Playbook interface if you haven’t already coded a custom close or minimize into your app.
• Change orientation by doing the same as above, but end your “swipe” in the bottom right hand corner of your app.
• Cycle through currently open apps by mouse “swiping” from either the left or right bezel into your app.  As you might expect this will transition you to the next open app horizontally.
• Quickly find your simulator’s IP address by clicking the hammer icon at the top of the simulator’s active screen.

And that’s what I’ve got so far.  I’ll be sure to update if I find more.  Please share your own tips for the simulator as well.  Good luck and have fun with this cool new device.

Overview

NOTE: all source code is available for .

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

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

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

Adobe Air

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

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

Fluid Layout

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

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

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

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

Vector Graphics via Flex MXML Skinning

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

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

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

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

Summary

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

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

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

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

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

AIRHelloWorld.as

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

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

Setup Pitfalls

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

The Flash Builder 4.0.1 update must be installed

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

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

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

Adobe Air 2.5 must be installed

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

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

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

Error: Cannot find node: versionNumber

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

Put your Playbook Simulator in Development Mode

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

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

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

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

Summary

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

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

Incredible Javascript Performance metrics

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

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

Mandelbrot Plotter

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

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

Blackberry giving out free playbooks to developers!

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

PlayBook App template using FDT and ANT

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

Understanding Accelerometer Development (AS3)

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

Top 50 Programming Quotes Of All Time

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

List of the Best Animation/Tweening Packages for AS3

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

Using OAuth with Adobe Air and Flex

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

Blackberry PlayBook will support C++ extensions for Adobe Air

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