So, I partook in the free Playbook offer sponsored by RIM, and developed a few applications for it.

This post is NOT about my apps, but rather touches on the process, as well as what I think about the Playbook as a device, and platform.

The Beginning

Woah… RIM is waiving the $200 developer license fee?!? WOAH, IT’S $200!?!?!?! Holy cow! But hell, it’s waived, what do I care, right? Kiiiinda.

In reality, I’m not affected by this directly, but what does this mean indirectly? Well, it could mean one of two things (in my mind/opinion):

  1. Only the elite apply. After being active on the forums, and seeing the types of apps approved (both before launch, and to-date), I’m totally OK with this. See my previous rant about what I think about the current and future state of affairs on mobile (and really any) markets.
  2. NO ONE applies. This, of course, is NOT good. The high price might scare away all the garage-developers, and not enough serious developers apply.

I’m uncertain of the outcome of either result. Honestly, neither sound all that appealing… Only serious devs mean we have a stifled app store, not enough creativity and variety of useful apps. And too few devs.. well.. same thing really.
Think about it – if you sell an app for $0.99, and you only make 70% of that means you have to sell 142 … hell, what do we call them? Licenses? Sure, let’s go with that. Now, that may not be far fetched for a free version, but for an app people are uncertain about, that might be a little difficult. Oh, and I don’t believe that AppWorld has a way to refund apps quite yet, but I might be wrong – I’ve only released FREE apps so far.

The Dev Process

Becoming a Vendor

This really didn’t bother me, but it DID seem to bother everyone else – so I’ll inform you of the history surrounding it.

At first, RIM required a form to be filled and notarized, then faxed or scanned/emailed into them. Then you wait ~72 hours to be told yay or nay. I had a few notaries in the office at work, so it was easy peasy for me. Some complained it cost them money to go and find someone to stamp a paper, and time, blah blah blah… Sorry, I guess that kinda sucks.

The over all complaint was that no other market required that. Everyone else just freely took your money, and let you distribute applications.
Currently they only require a scan/copy of your legal ID (driver’s license, passport, etc). The point of all this is to prove “you are who you say you are.”

The other complaint (while not so important at the time) was the cost: Apple – $99, Android – $25, RIM – $200! Good thing it was waived for us early adopters!

Signing

Not fun… at all. When I first started, I set out for the goal of being platform agnostic, and wanted to rely only on the AIR SDK. I was, after all, pretty darn familiar with it being a Flex/AS3 dev for the last 2.5 years, and love the idea of the cross-platformability of it. Yeah I made up that word, get over it.
Except, I found out that it wasn’t all that feasible.

First, there’s an ordering of the authoritative registration files. This required you to submit your personal information ALL over again, and this time supply a credit card to validate against. Those without credit cards (there were interestingly quite a few <18 yr olds applying as vendors as I found on the forum, and others from foreign countries without credit) were screwed, and still are for that matter. Once you applied, it took up to 72 hours (and in many cases more than that) for the “automated system” to respond back with your files to register with.

Next it turns out that:

  • you can only register those files once with a computer – moving computers or reinstalling your OS meant you had to re-request the registration files, and wait another 72 hours.
  • you can only register ONE set of files per user. This makes doing client work a huge pain. There are ways around this, but not as convenient as they could be. Essentially you have to create a user on the OS for every person that is to sign. On Linux/Mac, it’s not all that difficult to do. On Windows, it isn’t hard either, but switching users just to sign is a PITA.

Then of course, there was an issue with signing – the absolute lack of specifications on the certificate you use to sign just irritated the living bejesus out of me. I was trying to use the same certificate I used for signing AIR, Native AIR (exe, app, dmg), AIR for Android (apk) and eventually iOS (app again?). This certificate was also equivalent to the specs that you would see in a backed certificate from an authority such as Thawte. Oh, and not to mention ADT was explicit in the requirements needed to sign any of these formats, even specifically indicating the version of PKCS12 certification (x.509 v3 for those that care) criteria needed to accomplish said signing. But no, not RIM… they only gave information on how to create a self-signed cert, and how to sign with it. For MOST, this is ok. For MOST, this is tolerable. For a stickler for cross-platform, re-usability, and requirements – this was absurd and ludicrous. It literally took me TELLING RIM what their self-generated cert output was for them to come back and say “So our certs are <x, y, z>. Enjoy.” No shit, Sherlock – I told you that, now tell me WHY!

Early on, the errors from the signing tools were vague, and really ambiguous. After about 4 iterations of the SDK, the documentation became a tad bit more informative as to possible problems, and possible solutions. This didn’t seem to solve everyone’s issues, but did help out after time.

What probably annoyed me the most was when re-signing the app I had to increment the version number, or it would fail when authenticating with the server. PITA I tell ya!

Against my desires, I gave up the fight and moved on.

The Tools

Then came the IDE. First, let me say, I know – this was all pre-release, and in beta. I get that, really I do. What I don’t get is how you expect everyone to be able to utilize it in a work flow and produce something that is accepted.
It also didn’t help that Flex Hero / Flex 4.5 was also beta, and in pre-release. Again – I get this. But really, if this is all the case then the key to success is communication. I’ll get to that in a bit.. First let me bitch a bit about the tools.

So right out of the gates, I had issues with the IDE not even functioning. This forced me to learn ANT, and write a bunch of tasks to compile everything manually. I actually really enjoyed that, and it allowed me to build a formal build process instead of working strictly like a garage-developer and relying on the IDE to do every last thing for me. Maybe if I get serious enough, I could automate builds and do some CI… Hah, riiiiight.
But boy did I see so many issues on the forums, Twitter, etc. It seemed like a nightmare. People declared it not worth their time, and it’d be cheaper to buy the device outright upon launch. I’m too frugal to do that, so I went with learning a build tool I’ve been meaning to for years. In the end, this was a good thing. I now know everything there is to know (ok, maybe not EVERYTHING) about ADT, and compiling/signing for AIR.
But think of all those garage-developers eating dirt and feeling lost. Certainly not a way to pick up momentum, especially if they re-instate the $200 dev fees!
I’m sure in time it will get better, but RIM is seemingly banking on the idea that a certain thousand number of apps will be available at launch. I’ll get to this in a bit as well.

Even after launch, I have issues with the SDK integration in FlashBuilder, and still have to rely on my ANT scripts to get anything done. Not to mention they now require debug tokens to develop locally if you don’t want to sign your app.

Another issue I ran into was that the blackberry-packager tool didn’t seem to fully conform to the AIR manifest. There was an explicit blackberry-tablet.xml manifest file to describe the application. What’s worse, is that somehow information in your AIR manifest was still used! For example, your version of app came from the AIR manifest – but the packager name came from the BB manifest. Permissions for Android are in the AIR manifest, QNX permissions were later added to the BB manifest.
The differences and oddities can go on, but the biggest complaint I have are the icons. The AIR manifest has a section for icons, ranging from sizes of 16×16 to 128×128. Blackberry required an interesting icon size of 86×86. What made it painful was two-fold. Firstly, you couldn’t define an 86×86 icon in the AIR manifest file. ADT would fail on parsing it saying it was an unexpected node – makes sense really. The second pain-point was the fact that if you supplied ANYTHING in the AIR manifest, the first node in that section would be used, and the icon definition in the BB manifest was COMPLETELY IGNORED! So to avoid getting a 16×16 icon showing in the simulator, I put the 128×128 node up top. Worked great in the simulator – but I found out just before launch it didn’t work so swell on the hardware itself and was rejected as a product.
The solution? Don’t supply anything in the AIR manifest. “Not a big deal,” you say? I’d agree if I was only developing for Playbook, but the reality was I wanted to stay platform agnostic. This meant that in order to get an icon for Desktop, Android, and iOS I’d have to have either some hackery to remove it specifically for the Playbook packaging, or have a separate process altogether. Either way was a piss in my Cheerios.

The other big kick in the nuts was the simulator itself. Can you say “BUUUUUUUUGGY?” Oh  man, I had never seen such a failure of an emulated run-time environment since…. well.. pretty much never. The install process was finicky, sometimes not working at all for some, while working perfectly for others. PC/Linux users were capable of using VMWare Player, a freeware application to set up a basic VM. MAC users were required to use VMWare Fusion – a NON-freeware, with 30 day trial; and boy did I hear some complaints around that! But what made it the absolute worst was the fact that it would freeze if you blinked at it wrong – or apps would randomly close. Every new release of the simulator and SDK fixed a plethora of bugs – but it also introduced new ones. The latest 1.0.1 release was a day and night change – it’s much more stable, but also didn’t quite reflect the previous versions we became used to. There wasn’t that much of a change, but it was enough that you had to actually stop and consult the documentation to get into it. They wised up and included the pre-setup VM with the SDK so as to avoid others incorrectly creating it.

Post-Launch

Here we are, now 8 days after the launch, and people have gone out to stores and bought the devices. Reports are out there that first day sales have well exceeded expectations, and even outsold the Xoom and Galaxy Tab. Somewhere around 50k units sold on the first day. I’m too lazy to find actual reports and numbers, so either take my word for it, or go Google the hell out of it.
Either way you look at it, it did impressive sales that not really many expected. Afterall, a 10″ Android tablet had come out, there was already a 7″ Android tablet out, and of course the iPhad.. err iPad had been released a little over 5 weeks before.

My Thoughts

That’s why you’re here, right? To hear my thoughts? If not, GTFO! HAH!
But really, I do have  opinions on it. As everyone expected/feared, it wasn’t ready – and the more I use it I find more ways it’s “not ready.”

AppWorld – the Marketplace

Right off the bat, I can tell you the free Playbook offer didn’t do crap for app availability. I know first hand that not all apps that were even approved are available. Hell, none of my apps are in approved state, and we’re over a week into the launch. I can only imagine how many thousands are still in a pending review state, or were completely given up on because of the frustration or the fact they were informed of their rewarded Playbook. Either way, having spent hours in the AppWorld market, I can say the selection is lackluster, and I’ve only managed to install about 5 apps – 4 of them are really just junky toys to show off to others that “hey it works and it can do multitasking.” I’ll probably delete them in a few days once I’m done showing it off.
Honestly, I expected this, and it doesn’t exactly bother me. It does, but it doesn’t. I does because I really would have liked to see more people (read: ACTUAL DEVELOPERS) spend time making quality apps that would make the platform appear to be the “business-grade” as advertised. I lied when I said it doesn’t. It actually bothers me on all levels… Again, read my rant.

A big, big, BIG miss is the lack of the following:

  • Native email client (granted there is one if you bridge with a Blackberry phone, but that’s not useful to us non-bb users)
  • Instant messenger client – there’s a BBM client coming, but I want a gtalk, AIM, YIM, and MSN all-in-one client.
  • Social networking – out of the box there’s a bookmark shortcut icon to Facebook and Twitter – but let’s face it, the web interfaces of those just don’t cut it. I really just want Tweetdeck 😛

I am disappointed these aren’t available on the market if not installed out of the box, but they’re getting the device out – I’m 100% certain that will change over time.

Hardware Interfacing

First, the bad. The power button is incredibly small, and flush with the body making it difficult to find without looking, and equally as difficult to push.

The volume buttons don’t have a “click” to them when you push them, or at least not as much as I’d like. You know like on a stereo in your car, you push a button, and feel a bit of a click to let you know “ok, you pushed me, now let off”… Yeah, that doesn’t happen on this thing. Took a bit of getting used to. The other thing is, an undocumented feature (at least I couldn’t find it documented, and rather found it in a youtube demo) is if you hold one of the volume buttons down it will skip to the next song or video. Problem is, it functions like this even when audio/video is not currently playing. What I mean by this is that if you expect to quickly turn volume up or down by holding the button down – think again.
What’s strange is that the play/pause button DOES have the click tactile feature I wish the volume buttons had. Also interesting is holding it down un/mutes volume. A nice feature, but nothing to write home about or accept as revolutionary.

Now the bezel – what really makes the Playbook, the Playbook (in my opinion). It’s gesture capable and how you navigate the operating system. It took a little bit to get used to, coming from Android devices with dedicated buttons, and early on I found myself fumbling and quickly swiping from all over not thinking about what I was really doing. It wasn’t frustrating, just – different.
Now that I’m used to it, I LOVE this feature. Dare I call it innovative and revolutionary.
I used to badmouth Apple’s 1-button approach, saying that only one button limits your input – but RIM went with (virtually, ignore the volume buttons) NO buttons! But you totally have great UX with this. On Apple, pressing the one button always takes you home… Sure it’s consistent, but not very friendly if you ask me (which you didn’t, but who cares).
On Android, we have a menu button, home button, back button, and a search button. I almost never use the search button, use the menu and back buttons on the regular (saving real estate for useful info on screen instead of silly perma-menus/buttons), and home button is great for more than just going home (holding it down shows recent apps).
You still get the maneuverability of android, but no precision required on exactly where the buttons are (this is more important as more and more manufacturers are using capacitance buttons instead of physical buttons anymore).

I was impressed to find that there are stereo microphones on it as well – while not all that important it does seem to be impressive to most I showcase it to.
The speakers are so-so, not bad in a pinch. They’re stereo as well, and front-facing which is nice. But nothing will beat headphones on devices like these.

Hardware Functionality

Another thing that bothers me is 2 things I really wanted this device for: A2DP, and Ad-Hoc networking.

A2DP, in layman’s terms, is stereo bluetooth. I have a (ironically) Blackberry Stereo Audio Gateway hooked up to my surround sound receiver, which allows me to send audio directly into it and listen to it in awesome stereo quality. I do this from my phone currently utilizing GrooveShark or WinAmp on Android. And really it works great. But it’d be nice to have a larger interface to navigate with. Unfortunately, the current OS release does not support ANY bluetooth features except tethering, and ONLY with BlackBerry devices (keep in mind, we’re talking bluetooth… but see my next point for more info on tethering). You can’t share files over bluetooth either except with the included Blackberry Device Manager, and I’m not even sure that works as I’ve not messed with it. Essentially, no bluetooth services work properly per specs.

The ad-hoc networking is one that’s probably not utilized by many, but is very useful for us advanced Android root users. You see, with the help of an Android WiFi Tether app, we can create a simple ad-hoc network to connect to and utilize as our gateway to the internet. Again, in layman’s terms, this just means we can tether and access the internet through our phone. This currently isn’t possible on the Playbook, and requires me to fake out the cell network into utilizing Android’s built-in (yet carrier favored) tethering functionality. I mentioned carrier favored, because it requires the user to authenticate with the cell network, effectively allowing the carrier to charge for tethering access. A gyp if you ask me, but alas, there *is* a way around it for the time being. I’m sure, however, it’s only a matter of time before my carrier catches on and fixes it.

Expectations

Hopefully at this point it’s obvious… I have a love/hate relationship with the Playbook right now. As a developer, I’m irritated… As a user… I’m irritated – but optimistic.

Honestly, and being humble, I couldn’t even begin to guess where this device is going. One thing I do like with the launch is they’ve released a WiFi version first. Most other devices have required a data package up-front, which can be hectic and stressful. A Sprint version will come out shortly, which will satisfy (hopefully) those that want data only on their tablet device.

As I’ve stated, more is to come from RIM directly. My hope is that more carefully thought software is brought out for it. I know in my personal development endeavors, I plan on making a few more tablet form-factor applications, and the Playbook is one of my desired platforms. But given the issues I’ve had, it’ll certainly take a back seat to other platforms (but not quite as far back as iOS :P).

I’d really like to see a nice RDP client, and some kind of keyboard/mouse replacement app for it like we see on Android and iOS (RemoteDroid, and Mobile Mouse respectively). But that just goes to speak as to how at the current time the Playbook is a toy for me… I don’t find much in the way of productivity, or really that much entertainment. But again, that’s me. I’m a power user – I have a PC in every room of the house, and 4 just in the office. Most are at least dual core, and the desktops are quad cores… I don’t NEED an internet browser at my fingertips in most cases because I’m in front of a computer ~85% of my waking life. Geez…. I need to get off the computer more often. How about I start —- NOW!