Overview

I’d like to start by saying that I think it’s important that both of these frameworks exist.  The more I worked with each, the more I found that it wasn’t a simple question of which mobile framework was better.  Both have some of the features a cross platform framework should have, and each shines in areas that the other frankly does not.  And that will be the focus of this analysis.  What are the key aspects to a great cross platform mobile framework, and how do Appcelerator and PhoneGap stack up.

Cross Platform Support

So this is why we’re all here right? Code once, run every where.  That’s what we want.  Well in this case, one of these solutions gets you a lot closer than the other.

This is PhoneGap’s bread and butter.  By leveraging web views native to the mobile devices, PhoneGap allows you to build as an app as complex and modern as you want while providing the ability to have it gracefully degrade for lower end devices, all in the same code base.  This degradation can be controlled via CSS or even dynamically with javascript and media queries.  You can use the same design and development principles that have guided cross browser development for years.  And the list of mobile platforms they support (which includes iOS, Android, Blackberry, webOS, and Symbian)  is definitely worth bragging about.

Appcelerator, on the other hand, does iOS really, really well.  Android brings some additional headaches and quirks.  Blackberry is still in the beta stage.  They are actually creating native code based on their Javascript API, so the quirks will likely always exist. Appcelerator will constantly be one step behind/removed in their efforts to integrate native functionality.  No fault of their own, it’s just the nature of their product.

This is why I think emphasis on Appcelerator being a cross platform framework is misleading.  While it CAN be a cross platform framework, it is not by nature.  I mean, how can it be? One of its main selling points is access to native UI components, something that is obviously not part of a cross platform solution.  One code base for multiple mobile platforms is totally a possibility with Appcelerator, but you will likely sacrifice a lot of what makes it great (coming in the following sections) to get to that lowest common denominator.

Defined Workflow

The product will only be as good as the tools that support, particularly when you are trying to appeal to an audience as large as mobile developers.  In this respect, Appcelerator is the clear winner.

Earlier this year Appcelerator announced that they had acquired the web development IDE Aptana. Before this point you were stuck with Titanium Developer which did the job, but was only a project deployment tool, not a true IDE.  Just this month they introduced the first version of the new Titanium Studio, an integration of Titanium Developer and Aptana.  There were a few bugs to wrestle with the earliest versions of this software, but I must say that I am loving it.  It has truly integrated the development and deployment workflow, making it more organized and efficient.  It has built in update checking for not only the studio but also the Titanium SDKs.  Oh, and did I mention that all of this is free?

PhoneGap leaves you to your own tools and workflow.  A plus for some, but I would imagine its a minus for those of us who don’t come from primarily a web development background.  They give you some direction in the Tools section of their website, but its not what you would call a workflow.  It a different approach, basically leaving the developer to determine what libraries, IDE, touch frameworks, etc… are most appropriate for their project.  This can be problematic for two reasons. 1, new mobile developers are not going to know which tools are the most appropriate and 2, there are A LOT of available touch and JS libraries out there for mobile development.  Choosing can be a project in its own rite. All that said, of Nitobi, the makers of PhoneGap, created the XUIJS library. Its what I’m using and I’m really digging it so far.

Programming Language

EDIT: Here’s a more recent and more detailed post explaining this section.

Admit it Appcelerator developers, you aren’t interested in the Javascript API so much as you are interested in NOT writing Objective-C!  Yeah, me too.

You would think this topic would be a deadlock, right?  Its just Appcelerator’s Javascript API versus PhoneGap’s use of the standard web stack of HTML/CSS/JS.  It basically the same thing… or is it?  Remember how I said in the last section that PhoneGap gives you free reign to choose whatever framework you want for development?  Well, Appcelerator doesn’t, and it is definitely to the chagrin of many Javascript savvy developers.

PhoneGap is HTML/CSS/JS.  Anything you can do with it on a normal web page you can do in a mobile browser’s web view.  This means any chunk of Javascript you find anywhere that you like can potentially be integrated into you app.  This ranges from your favorite frameworks like jQuery and Prototype, mobile  libraries like Sencha Touch, or even graphical ones like Grant Skinner’s EaselJS or one of these many 3D libraries.  Performance and device support permitting, you can use any Javascript you want.

Appcelerator’s API unfortunately is purely Javascript, is has no ties to the DOM.  But wait, doesn’t the most popular Javascript library in the world assume the presence of the DOM window and document?! Yep, that’s right, you can’t use any part of jQuery that requires the DOM (which is almost all of it) in your Appcelerator code.  The one exception is that you can still use jQuery and other DOM reliant libraries in a Titanium.UI.WebView, but you can’t use it with the actual Appcelerator API.  Annoying to me, but I can see this being REALLY aggravating  to long time web developers accustomed to using jQuery with everything.

Deployment Support

If you’ve spent any time in mobile development, you know that deploying your finished app to markets and app stores can be a truly daunting task.  There’s certificates, app signing, icons, logos, promotional images, supporting text, and the task of keeping it all organized.  It can quickly become a mess.  While both Appcelerator and PhoneGap both give you detailed instructions on how to build app store ready apps from your development environment and offer professional services, PhoneGap takes it one huge step further.

PhoneGap Build is currently a free beta service that you need to get your ass signed up for now.  While I highly encourage you to check it out for yourself, here’s the insanely easy workflow:

1. Upload you PhoneGap project to PhoneGap Build (or use its Github integration)
2. Configure your platform specific accounts with certificates and signing keys (all PhoneGap supported platforms available)
3. Watch as PhoneGap Build creates deployable binaries for each of these platforms and delivers you download links for each

Now that is the type of workflow I’m looking for! A quick note on step #2 is that iOS is the only platform that requires a certificate to get a testable binary.  You’ll want to set up certificates and keys before you deploy the the market/app store, but you can test the binary without them.

Speed of Development

All this flexibility and platform support has to bite PhoneGap in the ass somewhere, right?  Speed of development, if you can’t tell by it name, is another place that Appcelerator excels.

Appcelerator allows developers to start building an app that looks, feels, and performs like a native one very quickly.  Some of the big reasons are the following:

• Their Javascript API is infinitely easier than Objective-C, and some might also say Java (but not me)
• Tons of ready-to-use native UI components
• You are not required to adhere to the MVC architectural pattern
• The double-edged sword of loosely typed Javascript allows you to create custom components like table views and rows very easily
• The new Titanium Studio gives you one place to develop and build for multiple platforms

PhoneGap, though, is a bare bones framework.  It looks to provide mobile API support (things like location, accelerometer, etc…) across all major vendors.  The UI is left up to you and your chops as a web developer.  To that end most people are left to go find another touch framework to layer on top of PhoneGap.  Sencha Touch, jQuery Mobile, JQTouch are all popular options.  There’s even efforts to create web based “native” components.  You can also take my route and build most of it from scratch using XUIJS.

The long and short is that if you are only building for iOS, or maybe also Android, Appcelerator will likely get you from concept to completion faster than PhoneGap.

Documentation

Documentation is key when undertaking any new technology.  Both frameworks have their ups and downs here.

Appcelerator maintains a newly improved collection of there documentation on their new Confluence site.  While it is fairly comprehensive, it is also a bit jumbled, particularly the “Getting Started” section.  Its all there if you have the patience to find what you are looking for.  You’ll find installation, setup, examples, tutorials, the works.  You can also find a comprehensive listing of their mobile API here.  The problems I see with their documentation are the following:

• Its sometimes hard to tell what version of their SDK examples apply to
• Often Titanium objects have properties that don’t apply, or don’t behave as the documentation indicates
• You are sometimes left digging through the Q & A section to find the quirks for specific Titanium objects
• Examples given for Titanium objects are WAY too simplistic
• How ’bout a few more “Hello, World!” scale tutorials before you throw us at the ?!
• Im sure this will change after the Titanium Studio release gets some traction, but the “Getting Started” section is still using Titanium Developer as its chosen workflow

PhoneGap’s “Get Started” section is a thing of beauty.  In a very clean, concise layout, the PhoneGap site walks you through how to set up your computer for each individual platform you wish to develop for.  It list requirements, toolsets, and easy to follow instructions.  It helps ease the intimidation that can come with trying to develop for so many platforms. Once you get it up and running, PhoneGap’s API documentation is incredibly easy to follow.  A simple layout lists everything PhoneGap is capable of doing.  Clicking on these capabilities then takes you to the API specific documentation that lists usage, examples, device support, and any quirks that are currently known.  It takes a lot of the guess work and frustration out of the inevitable troubleshooting that ensues with cross platform mobile development.

PhoneGap definitely shines in the documentation department.  In all fairness, though, Appcelerator has a hell of a lot more to document.  PhoneGap’s lack of UI components accounts for a large part of its documentation being so easy to follow.

Community

An active and knowledgable community is one of my biggest factors in choosing any technology.  Appcelerator and PhoneGap both have a wiki and blog, and also offer these a few more resources.

Appcelerator has their Q & A section of their site.  It allows users to submit questions about Appcelerator to the community.  Users can submit answers, vote on others’ answers, and receive points and badges for participation.  If StackOverflow has taught us anything, its that people like being rewarded for participation, no matter how meaningless.  On top of this free resource, they also offer training, certification, and professional services for those looking to take their Appcelerator’ing to the next level.  I hand out on Twitter a lot, so its worth mentioning that you can get some great help and info regarding Appcelerator by following , , and .

PhoneGap maintains a connection with the community with their and on IRC at irc.freenode.net #phonegap.  They also offer professional services and training.  The core of the PhoneGap team is very involved with the community and I’ve often been found chatting with , , , and on Twitter.

Other than wishing PhoneGap had some kind of a forum system better than a Google group, I think both frameworks do a very good job of listening to and staying engaged in the community.

Extensibility

No developer I have ever known is just happy with the tools he’s given.  We want to be able to add to and modify anything we get our hands on.  Both frameworks are very extendable via modules and offer open source licenses, though PhoneGap’s option of “New” BSD or MIT license is a little nicer than Appcelerator’s Apache 2.0 license.

Appcelerator offers Android and iOS module development guides.  These allow you to build native components in their native SDKs and then be able to access them in your Appcelerator app via the Javascript API.  Anywhere Appcelerator falls short in terms of supporting any API or UI component, you are free to pick it up and make it happen.  Its not the simplest process and effectively removes the possibility of  cross platform code, but can be a strong tool for a single platform scenario.

UPDATE: In addition, Tony Guntharp also gave me this blog post detailing how modules can be developed in other languages as well: http://developer.appcelerator.com/blog/2011/04/tiphp-tipython.html

PhoneGap also supports additional modules, or plugins, to its framework in the same fashion that Appcelerator does.  You can develop native code and then write hooks back to PhoneGap to access it in your project.  Again, this undoes any cross platform compatibility unless you make the native component for all supported platforms.  There’s a guide to creating plugins found here.

Appcelerator on Github:
PhoneGap on Github:

Summary

So as I stated at the beginning, I think both of these frameworks are important and have their place in the mobile landscape.  From my personal perspective, as they both stand now, PhoneGap is the true cross platform solution.  , author of “Mobile Design and Development”, rang the point home throughout his book that the future of mobile development lies in web based applications that adhere to a structure of graceful degradation.  I initially thought he was a web developer who didn’t want to learn Objective-C or Java.  After spending some time with native development and multiple cross platform frameworks, I find myself coming to the same conclusion.

But that’s not to say that PhoneGap is the end all, be all of mobile development.  I happen to think that for iOS & Android projects, Appcelerator could likely be your best choice.  Unless you have prior experience with Objective-C, I would advise anyone with even a basic knowledge of Javascript to give it a shot before resorting to native development.  Trust me, you won’t miss Interface Builder, and outlets, and actions, and all kinds of other iOS MVC fun.  Oh, and you’re sure to enjoy the native UI and performance that Titanium uniquely provides.

NOTE: I would have liked to include Adobe Air as I did in this past comparison of mine, but I honestly have not used it in 2+ months and there have been serious changes since.  I’ve been focusing on cross platform solutions that can hit the big three mobile devices out there: Android, iOS, and Blackberry.  Soon as Blackberry supports Adobe Air you better believe I’m coming back to re-evaluate it.  I’ll take AS3 and/or Flex over HTML/CSS/JS any day.

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.