The Code

• Repper-playbook on Github – Full source code and Flash Builder “Burrito” project files

The Overview

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

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

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 480x480 product image for the App World
• At least one screenshot that is no larger than 640x640
• An 86x86 PNG icon, which includes a 5 pixel transparent buffer around it.  This effectively makes the icon content 76x76 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.

Last night I ported my fitness mobile app Repper, a rep max calculator for Android (and other devices soon), to native Android from Flex Hero for Adobe Air. When I finished all the coding, the one big problem I had with updating my app in the market was that I didn’t have the same keystore I used to sign the original app.  Or at least I thought I didn’t.

When generating an Air for Android app with Flash Builder “Burrito”, you create a p12 certificate file.  To sign your Android app with Eclipse using the export signing process, you need the actual keystore used by the certificate.

The resolution to this situation is simple.  Simply use the <strong>keytool</strong> command that comes with the Java JRE to get the keystore file from the p12 certificate.  So if you created and used ‘savagelook.p12’ in Flash Builder to sign your original Android app, these following command would give you the keystore necessary to sign your app with Eclipse.

keytool -importkeystore -srckeystore savagelook.p12
-destkeystore savagelook.keystore -srcstoretype pkcs12

Now all you would need to do update your mobile app in the Android Market is run the Eclipse Export Wizard for your app and use the keystore generated above to sign it.

The Short, Blunt Version

DISCLAIMER: Don’t leave me nasty comments if this is all you read.

Most of the available “cross platform” mobile frameworks are not as universally and uniformly compatible as they would be announced. There are inconsistencies that make “code once, run everywhere” very unlikely without at least some tweaking. The time spent fitting an app to one, universal mold can often force a sacrifice of even more time, quality, and usability.

Using HTML/CSS/JS for mobile development is seen as an advantage only to those who already have a great deal of experience with it. I say this from a pure language perspective as it carries the obvious advantage of providing portable, standards based code. If you don’t have this experience with Javascript, but do have the talent and/or diversity of background necessary to learn the languages to develop natively, do so.

I’m not saying you can’t build a multi-platform, high quality app with a mobile framework. I am saying that it is not quite as easy as it may appear on paper. This may seem counter-intuitive, but as the complexity of your project grows, the less effective a “code once, run everywhere” approach will be. That said, most mobile frameworks do a terrific job of making small to medium sized projects available to a large audience in a short amount of time.

For the quick feature comparison of the mobile frameworks I’ll talk about below, check out my prior post, “Appcelerator vs. PhoneGap vs. Adobe Air”.

Naivity

I approached the world of mobile development with the thought that a cross platform development framework was the one true path. I mean, how else could a single developer keep up with the plethora of mobile OSes, SDKs, and devices? And with that notion, I went forward in search of the silver bullet framework that would give me the coveted “code once, run everywhere” solution.

But as you may have expected, I haven’t found it. With my tunnel-vision focus on cross platform development I neglected to pay attention to the multitude of other key factors that can cost developers time. I also neglected the fact that deploying to every mobile device imaginable is almost never the goal of a particular app.

So what are the problems I’ve run into? How have they cost me time? Does this outweigh the potential time saved with the “code once, run everywhere”? Is “code once, run everywhere” really achievable for most apps? Let’s dig into these topics and see how they could impact your potential mobile development workflow.

Most frameworks are babies

Let’s take a look at the 3 frameworks I’ve looked at so far:

• Appcelerator - mobile SDK started in 2009
• PhoneGap - started in 2008
• Adobe Air & Flex Hero - Air for Android and the iOS packager came out in 2010. Flex “Hero” is still beta.

As you can see, all of these frameworks are very young. And with that youth comes ambition, which in turn can lead to cut corners. The competion is fierce in a new and growing market. They know what they need to stand out: features. Stability and adherence to standards aren’t quite as eye-catching as an app that can leverage cool mobile APIs like geolocation and accelerometers.

It seems that in many cases the frameworks are spreading themselves thin at the expense of solid compatibility and stability.

How “Cross Platform” Are These Frameworks?

Here’s the mobile OSes aforementioned claim to support:

• Appcelerator - iOS, Android, Blackberry (beta)
• PhoneGap - iOS, Android, Blackberry, WebOS, Symbian
• Adobe Air & Flex Hero - iOS, Android, Blackberry Playbook

Now here’s been my experience with each so far, your mileage may vary. I will try to keep it as high level as possible.

• Appcelerator - iOS is their flagship. You can tell by the very Mac-ish look to their Titanium Developer project application that this is their focus. Appcelerator does iOs very well. Android on the other hand has been a bit frustrating. Many features and even core functionality are lagging behind in Android in terms of stability. Simple things like orientation lock and layouts work well in iOS but not so much in Android. This leads to inconsistent behavior between the two platforms, which is kinda the whole point of the framework. I have not yet tried Blackberry development, but if Android is a production release and has these issues, I worry what I may run into.
• PhoneGap - This is the one framework I’ve experimented with so far that has a relatively uniform experience across all its supported platforms. The core functionality is there, operates the same, and with a consistent level of performance. Granted PhoneGap is an entirely contained web app and has no native UI component access, though most APIs are supported. This, though, should be the expected experience with a cross platform mobile app. Give me the same thing on every device to which I deploy!
• Adobe Air & Flex Hero - Because these mobile apps run against the Adobe Air runtime you get a nearly identical experience across the supported platforms. Flex Hero comes with a wide array of mobile components for your use, though some are notable missing. The big hitch with consistency is performance. Blackberry Playbook development churns out great, performant content. Blackberry made available an AS3 SDK along with the ability to use Flex Hero. Because of this forethought and respect for the existing technology, Flash/Flex developers are really enjoying this platform and I think users will too. On Android, Air performs OK. There’s just enough lag on transitions and load time to drive you nuts as a developer, but likely won’t be a deal breaker for users. iOS seems to be a sore point for some developers. The performance is reported to be less than desirable when compared with the other supported platforms. Also, the Adobe iOS packager that allows you to deploy Adobe Air mobile applications to iOS currently only supports Air 2.0, leaving out some popular APIs like camera and video. We are all familiar with the battles between Apple and Adobe and why these performance issues exist. The users don’t care though and are likely to turn away from apps that seem sluggish as these might.

So as you can see, “cross platform” and “code once, run everywhere” aren’t quite as cut and dry as we would be led to believe. I’m not saying that frameworks should be dismissed for these reasons, but they simplicity of universal deployment and satisfactory user experience in many cases is overstated.

Do You Really Need To Support All Those Mobile OSes

I could ramble on about market share, market viability, and targeted deployment, but I’ll just let these few charts do the talking and let you render your own decision:

Javascript

I’m not here to start a holy war about whether or not Javascript is quality language. We all know the effectiveness of a programming language is largely determined by the person wielding it. But let’s be honest, Javascript is no Java, C#, or even Objective-C. And with the exception of Adobe Air and Flex Hero, almost all mobile frameworks use HTML/CSS/JS as their technology stack.

There’s no classes, no types, and the available IDEs and debugging facilities are weak in comparison to its native language SDK counterparts. As I hear many of my Flash/Flex friends saying from time to time, its a reminder of all that was wrong with the original version of Actionscript. jQuery and other frameworks make it more tolerable, but its still tough sledding when you are accustomed to a more full featured language.

Debugging

This is where you are ging to spend the majority of your life as a developer. If you don’t, you’re a better dev than I. And let me tell you something: debugging sucks in Javascript. Compound this with the fact that it is pretty much impossible to debug Javascript on a mobile device and you have a recipe for may, many lost hours chasing bugs.

Let’s look at Appcelerator and PhoneGap: They have no ability to debug on a device (I’ve had suggestions to try WEINRE and JSConsole). Appcelerator often refers to a “debug” function you can use, but it is simply a logging capability called debugging. With PhoneGap the suggested method of debugging is running your code against the desktop version of Webkit and using its debugging capabilities. Neither of these situation is very ideal.

Adobe Air and Flex Hero debug the way you would expect an application to be debugged. Air can do full integrated, on-device debugging in a number of IDEs (Flash Builder and FDT spring to mind). This is what should be expected. While Javascript based mobile frameworks are using web technology, they can no longer expect developer to abide by the web’s workflow. When developing native apps we want application debugging, not web debugging.

Do not underestimate the impact that poor debugging capabilities will have on not only the timeline of your project, but also the quality. In both cases, you just might be better served going the native route.

2 Layers Of Potential Bugs

We all know that Android, iOS, Blackberry, and any other mobile OS you may encounter is going to have bugs and quirks in its SDK. The same could be said of all software. If you are using a mobile framework to develop against these SDKs, you now have 2 layers of potential bugs and quirks. It can often be difficult and time consuming to determine which one is the culprit… after you’ve ruled out your own code of course!

While PhoneGap and Adobe Air suffer from this to a degree, the impact is less on these two frameworks. This is because they make no attempt to handle native components. They rely on your own HTML/CSS/JS or Flex/AS3 components respectively to serve your UI. Some see this as a drawback and taking away from the native user experience. I, on the other hand, see it as a step towards true uniformity in your app. You need to make a decision: Do I want a native or uniform experience?

Appcelerator suffers more from this situation. By taking their unique approach of offering a Javascript SDK by which you can create native components, you are given the opportunity to create a native experience without having to engage in native development. This is very appealing to many developers. I know it was to me. The unfortunate side-effect of this is that you many times will not get exactly what you would expect out of a component. Due to the need to abstract functionality in order to make one code set apply to many different mobile OS components, you may find configurability difficult. Determining whether something is misbahving in your app because of your code, your framework, or your SDK becomes quite troubling.

Summary

I gave the summary at the beginning, since I don’t know if a lot of you have the stomach for this much negativity in one blog post.  There was a lot to say and detail, but the short, blunt intro summary is my current sentiment on the state of mobile development.

Just to be clear, its not all gloom and doom for mobile frameworks.  Check out the post I did a little while back detailing all the areas where these mobile frameworks can make your life much easier.  And these frameworks are getting better everyday.  PhoneGap is quickly closing the gap (pun) between itself and the other mobile frameworks in terms of features.  Appcelerator is making some major moves by creating a community of Titans to bring more notoriety to the cause.  They are also due to release the first public beta of their new IDE, a fusion between Titanium Developer and Aptana, sure to help the current state of Javascript development.  And Adobe is aggressively garnering support for its pre-release programs for Air, Flash Player, and Flash Builder.  I believe new features along with improved performance across all platforms is going to be the fruit of this labor.

So I haven’t given up yet and will continue to actively pursue these platforms.  I may wait for a bit more dust to settle though before engaging in a large scale project with any of them.  I’m sure folks braver than I are more than able to have success doing so right now.

So I wanted to update my BetterTouchTool version while I was on my work network. You would think this was a simple thing, but the damn proxy seems to almost arbitrarily drop connections. So to get around this I was planning to use my Droid X with the free PdaNet app and client to tether my MacBook Pro.  For details on how you can do this yourself, check out this link.

But I hit a snag when initiating the tethered connection:

PdaNet: Unable to open interface (e00002c5)

Really helpful and descriptive error, right? There’s another factor here, though. I neglected to mention that I was actively developing in the Android SDK with Eclipse. As it turns out, the Android Debug Bridge (adb) doesn’t play nice with the PdaNet tether Android app. In fact, it likely that it doesn’t work with any other tether app since it takes full control of the USB debugging connection.

So how do you fix it? Well, you can’t really. The best you can do is make sure you aren’t doing both at the same time. If you are developing in Eclipse for Android against a physical device via USB, you will have to do the following to be able to tether:

1. Close Eclipse
2. Kill the adb process
3. Restart your tether app

With those applications closed, you should be able to successfully tether your computer once again. Hopefully this will save the someone the frustration of tracking down this error themselves.

OK, so I’ve downloaded and installed all my normal tools and apps that I have available to me on Windows: Tweetdeck, Skype, Chrome, all my IDEs (except Visual Studio), and a handful of others.  Now that I have those in place, how do I finish bridging the gap between what I still need from Windows?  How do I take it from an equivalent of my Windows laptop to something much more?

I don’t have all the answers yet, but I’ll get by with a little help from my friends.  In this case I’d like to mention those friends as they have helped ramp me up in Mac knowledge a hell of a lot faster than I would have thought possible.  Big thanks out to @john__olson, @s9tpepper, @JayMoretti, @newtriks, and @pedramp.  They pointed to most of the applications below that are making my time with Mac OS X extremely productive.

Survival Kit

• Alfred - Alfred is a productivity booster that uses keyboard shortcuts to quickly access applications, web searches, bookmarks, and a lot more.  It searches as you type and the results are instantaneous, which is something by which this long time Windows user is stunned.  I almost passed this one by because it didn’t sound like anything special.  5 minutes of using it changed that perception big time.  Don’t take my word for it though, go download it yourself or at the very least check out its introductory video.
• Gmail Notifier - How else am I going to know whether or not I have email in my Gmail account now? Can’t use Google Talk anymore (and don’t need to with iChat).  There’s other clients out there but this one is simple, free, and gets the job done.  However I did have occaisons where the email checking intervals took way too long, like 20+ minutes.  But there’s an easy fix.  Just type the following from the Terminal, restart the Gmail Notifier, and you’re good to go: defaults write com.google.GmailNotifier AutocheckInterval 1
• OpenTerminal - The website may not look like much, but I think that’s because all the effort was put into the tool.  OpenTerminal adds the simple, yet powerful functionality of being able to open Terminal based on a folder in Finder, or any folder you drag onto it.
• Skitch - Skitch is the smarter, stronger, better looking brother of Windows print screen.  It lets you quickly take snapshots of any sized portion of your screen.  In that same interface you can also add arrows, annotations, shapes, and highlights to augment you snapshots.  I’ve probably used this 20 times already in the 4 days I’ve been using this MacBook Pro.  In fact, the picture below shows how I used Skitch to make the snapshot for the OpenTerminal example above:
• TotalFinder - TotalFinder is everything that the built-in Mac OS X Finder should be.  It adds missing features and tweaks like tabbed browsing, sorting files with folders on top, dual Finder views, and many other features.  Well worth the $15 asking price for this high quality bundle that integrates into directly into the existing Finder.
• MySQL Workbench - OK, this isn’t exactly critical for everyone, but it was for me.  I needed a full featured MySQL GUI client and I didn’t want to pay for it.  The choices are abundant for Windows, not so much for Mac.  Lots of people suggested Sequel Pro, but it was way to light on features, specifically the inability to alter stored procedures inline. I had tried MySQL Workbench before for Windows and was pretty displeased with it.  it offered a great deal in terms of functionality and is the sanctioned client of MySQL, but it was very glitchy.  I had a lot of inconsistent behavior and found myself losing time instead of gaining it while using it.  Just for fun I revisited it for Mac and am very pleasantly surprised.  Everything I need to be there is there and I’ve run into none of the aggravating behavior problems I did before.  Plus they added “snippets” to their SQL query area, which are awesome.  I highly suggest this free tool to anyone doing database development or management from Mac.
• VMWare Fusion - VMWare Fusion is a specialized virtualization software that allows you to integrate your applications from a Windows VM seamlessly into your Mac desktop.  Aside from your Windows applications appearing in standard Mac windows, you get the added compatibility of copy/paste, drag-and-drop, printing, and more.  This was huge for me since the biggest hurdle in moving completely to Mac was the fact that most of my development for my employer is C# in Visual Studio.
• Outlook:Mac 2011 - This was critical for me.  I needed to connect to our Exchange Server to be able to fully switch over to Mac for development.  Sure I could run it in a Windows VM, but I wanted the notifications in my Dock as I often have to respond quickly.  Outlook:Mac 2011 does exactly what I need, which is exactly what Outlook does on Windows.  On additional note is that the contact email address auto hinting seems to work significantly faster on Mac.  A happily welcomed perk.

What’s Next?

Anybody else got some can’t miss applications I should be using for Mac? I’m all ears.

So this week this long time Windows/Linux developer was presented with his very first Mac.  In this case, it’s the brand new MacBook Pro.  Its a pretty sweet and sexy machine, sporting a quad-core 2.0 GHz processor, 4GB of RAM, 500 GB of disk space, an HD webcam, and one of those fancy new Thunderbolt ports.  All this packaged in a sleek frame and accompanied by a 27” cinema display, a Bluetooth keyboard, and a Magic Mouse.  At first glance it’s easy to see why some people get so crazy about Apple products.

Then I turned it on.

OK, it wasn’t that bad, but there’s definitely some stuff I liked and some stuff I really hated.  Some of it, of course, is the total tech shock of using a completely foreign OS.  But that doesn’t explain away some of the “interesting” workflow decisions that one must become accustomed to with Mac OS X Snow Leopard. Here’s 9 things so far that I love and hate about my MacBook Pro and the Mac OS X operating system.

9 Things I Love

1. Trackpad gestures - while it took a little getting used to, the multitouch trackpad gestures of the MacBook Pro are fantastic.  Using 2, 3, or 4 touch gestures you can scroll, navigate in your browser, and access Expose and running applications respectively.  This type of user input is truly what’s coming.
2. Expose - Expose is a great feature that let’s you reorganize, hide, and access all your running applications by using either trackpad gestures or hot zones on your desktop.  It’s Windows “show desktop” and “task switcher/flip” on crack, and much cooler looking.
3. Easy uninstalls - No more long waits, 3rd party uninstallers, or registry unpleasantness.  All you have to do in Mac OS X is delete the application from the Applications folder.  Its simple and quick.  A very welcome change of pace.
4. Easy setup - Apple sure got it right when it comes to getting you up and running fast.  I had my Bluetooth mouse & keyboard, wireless connectivity, VPN access, Google Talk through iChat, and Gmail through Mail all working in probably less than 30 minutes.  No driver downloads, 3rd party software, or updates.  It just works well and fast.
5. Documentation and how tos - almost every built in application or system tool has its own easy to read documentation, often times with a short video for clarity.  It got this fish back in the water pretty quickly.
6. iOS and Mac development tools - XCode: massive, robust, free.  Why does Visual Studio cost so much again?
7. Terminal - I probably should hav ranked this higher.  As a guy who spent 6 years developing Perl and C/C++ from no-GUI Linux, this is the perfect addition of power to Mac’s flair.  I can’t tell you how many times I saw this at a Windows DOS prompt:
8. Dock - it is great for accessing and viewing common applications, as well as your downloads and notifications.  Quick, always-there access to your most used resources… why didn’t everyone think of that?
9. Boot, restart, and sleep - All function fast and exactly how you think they should.  Reboots, though far less common on my Mac so far, are extremely quick.  I’m talking less than a minute for full shutdown and reboot, often even faster.  Sleep is my favorite, though.  Less than 5 seconds to sleep, near instant wake up.  I love it.

9 Things I Hate

1. Price - Damn these things are pricey! Let’s get one thing straight.  For most intents and purposes, you are paying more for “different”, not “better”.  Yes, Mac is superior in some aspects, but not “twice as expensive as a comparable device with a different OS” superior.
2. Green pebble confusion - I know, I know, its designed to fit to the size of the contents.  But guess what? That’s not always what it does.  Sometimes it maximizes, sometimes it fits to content, sometimes it does something entirely different and specific to one application.  It is confusing and unintuitive. SHIFT + green pebble for pure maximizing has been useful though.
3. Most of the good dev tools cost money - While Mac is quite generous with XCode, the community of Mac developers doesn’t seem to share the same sentiment.  It seems a lot of the quality free apps I came to love on Windows have no free Mac equivalents.  For example, does anyone know a good, free Mac GUI client for MySQL that comes anywhere near the functionality of Toad, or DbForge? People suggested Sequel Pro, but it is sorely lacking in the features department. MySQL Workbench is next on the list, but I didn’t even like it for Windows.
4. Magic Mouse - I’m sorry, but beyond the gesture support for this mouse, its terrible.  The tracking is very hard to get used to on any surface, regardless of mouse settings.  The gestures accessible from the mouse surface are too sensitive and can occur accidentally.  Its also a weird size and shape, which isn’t very appealing when your hand has become accustomed to a certain interface for 15+ years.  One of the first things I did when starting with my Mac was replace this with my normal scroll wheel USB mouse.
5. Copy, Cut, & Paste - Use CTRL + C,X,V like every other OS on the planet!  Using CMD + C,X,V is freaking annoying.  I know I’ll get used to it, but it seems like one of those things that is different for the sake of being different.
6. Dock - I know I mentioned it as a thing I love, but its also something I hate.  Why? Because it is no substitute for the Windows taskbar.  Its far less intuitive and obvious at a glance to determine what is running, how I maximize/minimize it, what’s going to stay there, etc.. I’m getting used to it, but I really think in the end I will still like the Windows taskbar over the Dock.
7. Safari sucks - This site does a far better job documenting its shortcomings than I can: http://www.safarisucks.com/
8. Installs can be confusing - Do I drag the icon to the applications folder?  Then what?  What if there is not instruction to drag it?  What if I instead get a package, what does that do? How bout if I’m told to put the file in the Applications folder manually? Why is there an image open on my desktop? These are all things that make sense eventually but were crazy confusing right off the bat.
9. Apple clearly hates Adobe - I have had almost no installation or usage errors or problems, except with Adobe related software.  I couldn’t install Adobe Air via the auto installer when I pulled down Tweetdeck.  I had to manually install and restart my system before it would work.  Despite having the latest Flash installed, I can’t get the Flash uploaders for this blog to work.  It just seems pretty coincidental that I’ve never had these problems on Windows, yet the Mac is littered with them.

Summary

So that’s my account so far of the world of the MacBook Pro.  And in my whopping 3 days experience I’ve learned that there’s a lot to love and hate.  This sentiment, though, is far from unique to this OS and device.  If I was to write a “Things I Love/Hate” post about Windows or Linux, it would take a hell of a lot more than 9 points to fully cover the scope of their strengths and weaknesses.

In short, I’m embracing this entirely new workflow.  I’m gritting my teeth at the unintuitive and smiling pleasantly at the simple and powerful.  in the end, I hope only to come out an effective  Mac OS X user with a stronger and deeper understanding of why it differs as it does from the others OSes with which I have experience.  Its been a while since I’ve felt this out of place in front of a computer, and I’m enjoying every minute of it.

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

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

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

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

“Away3D 3.6 Essentials” Highlights

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

“The Essential Guide to 3D in Flash” Highlights

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

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

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

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 Repper at Github.

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

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

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

Adobe Air

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

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

Fluid Layout

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

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

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

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

Vector Graphics via Flex MXML Skinning

The final factor that made Repper such a breeze to port to the Playbook was Flex Hero’s ability to create vector graphics via Flex MXML. By utilizing this capability you can create skins for your components that scale as the app scales. No external artwork of any kind is necessary. While this is not ideal for designers or highly stylized apps, a developer like me loves it. Here’s another excerpt from Repper. This time it shows how I used fluid dimensions once again to create vector graphic skins for my RepperEntry components via the RepperEntrySkin.mxml class

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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

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

Summary

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

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