When working on porting over my very first foray into Flex, my Flex particle engine, to the more current Flex4.6 for mobile purposes, I realized I wasn’t getting key events or change events from a debug Spark TextInput!

Simple As?

  <fx:Style>
    @namespace s "library://ns.adobe.com/flex/spark";

    s|TextInput {
      skinClass: ClassReference("spark.skins.mobile.TextInputSkin");
    }
  </fx:Style>

Tell your TextInput classes to use the standard TextInputSkin. The same applies for TextAreaSkin.
If we look in our defaults.css for the mobiletheme, we’ll see that it’s normally set to: spark.skins.mobile.StageTextInputSkin.

Why?

StageText allows some nice features, such as dictionary completion from the OS and better keyboard support for alternative keyboards, to advanced features like quick zoom and fancy selection support that each OS provides. But it ruins the Events that one would expect that it dispatches.

I don’t know if this is true for ALL events, but certainly it is true for KeyboardEvent.KEY_UP, KeyboardEvent.KEY_DOWN, and Event.CHANGE. Bummer!

In my case, the loss of the native features isn’t that big of a deal right now… Right now.
Eventually we’ll need a formal solution for this if we’re going to rely on StageText at any point.

Oh, and by the way…

My Flex particle engine is working rather well so far on my tablets and phones, even with it’s nasty memory leak!

Once I clean it up, I’ll release a public APK for everyone to test on Android!

In Flex 3, there was a backgroundImage style property, but in Flex 4 things have drastically changed. Often times, this means you need to re-skin things in order to achieve your goals.

Overview

The gist is we’ll be extending the default application skin, and adding an image to it. For the sake of render-time, I also include a background color. Without the color, the background is white until your image/app loads, which may not be your desired effect.

The Setup

The class is simple… As an enhancement, feel free to include a this.getStyle() for backgroundColorAlpha (or whatever you want to call it). I didn’t find it necessary, so I default the alpha to 1.

package skins.common
{
  import mx.core.FlexSprite;

  import spark.skins.mobile.ViewNavigatorApplicationSkin;

  public class BGApplicationSkin extends ViewNavigatorApplicationSkin
  {
    protected var _background:DisplayObject;

    override protected function drawBackground(w:Number, h:Number):void
    {
      var bgClass:Class       = this.getStyle('backgroundImage') as Class;
      var bgColor:uint        = this.getStyle('backgroundColor') as uint;
            
      this._background        = new bgClass() as DisplayObject;
      
      this.graphics.beginFill(bgColor, 1);
      this.graphics.drawRect(0, 0, w, h);
      this.graphics.endFill();
      
      this._background.width  = w;
      this._background.height = h;
      
      //Add the background at the lowest display hierarchy.
      this.addChildAt(this._background, 0);
    }
  }
}

The CSS is also rather simple… Simply put, we define the skinClass for the Application type we’re using (in this case, ViewNavigatorApplication). We also supply the styles for the backgroundImage, and backgroundColor. In this example, I’m using a symbol from a SWF file to define a class. You can also use images, but the skinClass I’ve supplied does not support URLs (you can add error/type checking all you want).

The other key is to set backgroundAlpha for Spark View classes. Without this, you won’t see the background as a View will be painted white by default. Setting the alpha to 0 allows a common background to be visible at all times.

s|ViewNavigatorApplication {
  skinClass:              ClassReference("skins.common.BGApplicationSkin");
  backgroundImage:        Embed('/skins/skinFiles/commonComponents.swf#BackGround');
  backgroundColor:        #000000;
}

s|View {
  backgroundAlpha:        0;
}

Troubleshooting

Since we’re cheating and not actually extending ViewNavigatorApplication, but rather ViewNavigatorApplicationSkin, the styles won’t auto-complete correctly in your CSS file. A skin is always passed the hostComponent as the styleName (which is actually an object, not a string as you would expect), so assigning the CSS properties to ViewNavigatorApplication still works.

If you get Null Pointer Exceptions (NPE) about this._background, be sure you’re defining your CSS correctly, and ensure that the this.getStyle(‘backgroundImage’) line is assigning properly. If not, you either have a typo in your CSS declaration, or you’re not supplying the right data-type.

To understand more about how Embeds work, as well as how to debug retrievals of Embeds via getStyle, see my other blog post: Mixing Flash and Flex.

There’s a lil gotcha – Flex 3, or MX components, ooorrr Halo components, are not exactly welcomed on Mobile.

Fret not! I’ve figured out the task, and it’s rather simple.

Why and how are they removed?

Well the why of it is simple. Performance and interaction. Granted, we now had Flex 4 which also allowed for virtualization for most complex components, it didn’t have what we needed: speed and interchangeability between desktop and mobile. A 1-stop shop, if you will. Flex 3 was stuck in the days without touch; thus the lists would all be scrollbars, and no dragging. Not to mention how scrolling used to be handled (yuck!).

As for how… It’s a combination of the mobile theme, and the lack of including it. LOL!  You can compare yourself the build configs for Flex (flex-config.xml) and AIR Mobile (airmobile-config.xml) and see how one includes the mx.swc, while the other doesn’t.

Flex 4 completely reintroduced skinning by separating behavioral and display logic. This is a good thing, especially for mobile where devices have many variant display types. All you need to do is change skins for a different platform/device, and you’re golden. But sometimes we have components that are completely custom, but utilize mostly-light components (i.e., Button, ProgressBar, Container, etc. Basically, not a lot of lists, charts, data rendering, etc. Really custom UIs). Certainly it can’t be THAT bad, right? As it turns out, not for me, no. If you keep it simple and lightweight (i.e., no extra containers, and as close to a flat Display List as possible), it should be OK. That’s my official blessing – if it doesn’t work for you, I blame you! No really though, it’s not supported by Adobe.

So tell me how to fix it already!

OK, it’s actually very easy. I’ll be using the default paths for Windows users, but this should all translate easily for everyone.

Missing Components

First thing is to include the MX components swc:

• Right-click your project > Properties.
• Click Flex Build Path > Library Path tab.
• Click Add SWC button, and point it to: C:\Program Files\Adobe\Adobe Flash Builder 4.5\sdks\4.5.1\frameworks\libs\mx\mx.swc

Missing Skins

The Problem

When a series of form inputs are displayed on a mobile device, consideration for the on screen keyboard must be taken. In most scenarios, the operating system will shift your application up for you, but getting to the next field below it can be troublesome.

Take a look at this example in my current mobile app, Crash:

Inputs Covered	Inputs Uncovered

As you can see, when the user has the keyboard in position, the next TextInput is barely in view, and extremely difficult to tap. What’s more, is if you ARE able to tap it, it seemingly lines it up perfect so you can’t tap the one just below it.

I set out to find a solution that was easy to understand, and really easy to implement.

The Solution

It turns out, in Flex 4.5, the TextInput class now dispatches FlexEvent.ENTER when the enter key is pressed. From the ASDocs directly, the statement appears:

This control dispatches a FlexEvent.ENTER event when the user pressed the Enter key rather than inserting a line break, because this control does not support entering multiple lines of text.

AHA! It’s obvious now! I just listen for this event… and… then… do… something?

Yep! That’s exactly right! I’ll skip the banter and get right to the code:

override protected function partAdded(partName:String, instance:Object):void
{
    switch (instance) {
        case this.txtInpName:
        case this.txtInpPhone:
        case this.txtInpAddress1:
        case this.txtInpAddress2:
        case this.txtInpLicense:
            TextInput(instance).addEventListener(FlexEvent.ENTER, this._onPressEnter, false, 0, true);
        break;
    }
}

Simply put, whenever a part from the skin is added, and I can identify it as one of my TextInputs, I simply listen for the FlexEvent.ENTER event, and handle it as such:

private function _onPressEnter(event:FlexEvent):void
{
    var nextFocusObj:IFocusManagerComponent = null;

    var focusMap:Dictionary                 = new Dictionary(true);

    focusMap[this.txtInpName]               = this.txtInpPhone;
    focusMap[this.txtInpPhone]              = this.txtInpAddress1;
    focusMap[this.txtInpAddress1]           = this.txtInpAddress2;
    focusMap[this.txtInpAddress2]           = this.txtInpLicense;
    focusMap[this.txtInpLicense]            = null;

    nextFocusObj = focusMap[event.target];

    if (null !== nextFocusObj) {
        this.focusManager.setFocus(nextFocusObj);
    } else {
        FlexGlobals.topLevelApplication.setFocus();
    }
}

Here I’ve simply created a mapping from one input to the next. this.txtInpName will map to this.txtInpPhone as it’s the next in order, this.txtInpPhone to this.txtInpAddress1 and so on.
The special case is the last TextInput item, and I’m assigning null to the mapping. Furthermore, when the nextFocusObj is null, it merely calls setFocus() on the Application itself.

This isn’t the CLEANEST approach in my mind, because there is some setup you have to do first, but it does work.

For those that are going to say, “Why not just use FocusManager::getNextFocusManagerComponent() method to get the next item.” Well, honestly, it wasn’t working as I expected. It was selecting some arbitrary button on the screen; certainly not what I had hoped/expected to see. Thus, I have to be a bit more explicit.

I’ve tested this on the Playbook, and it works great! When the last text input is reached and the user hits Enter/Return, the Application gets focus and the keyboard automatically hides.
Win!

Adobe released an early version of Flex 4.5 (Flex Her0) just before Adobe MAX last year, and tons of people grabbed it and started writing mobile apps with it.
Since then, quite a bit has changed both in common functionality, and under-the-hood things like List scrolling.

I couldn’t find any clear documentation about migrating your applications, so I figured I’d try to throw together as much information as I could think of.

I will be updating this frequently as I find more changes or caveats while converting my apps, or from what I hear from others.

Quick Map

So before I start, I’m going to try and attempt doing a quick mapping of some classes you might have used in 4.5 MAX Preview, and what their current counterparts are:

Some Different Approaches

There’s also a few different approaches we must take when developing for 4.5 final, which I’ll try to cover as much as I know.

CSS:
Back in the 3.x and 4.0 days, we’d typically do camel case definitions of styles in metadata, and when accessing via setStyle() or getStyle(). However, in a stylesheet, we’d define the properties as hyphenated values, and not camel case. For me personally, this was irritating, frustrating, and downright weird. Worry no more! This has been changed! In CSS in Flex 4.5 we now should ALWAYS use camel case, all around.

View:
The View class is what we use for components handled by ViewNavigator. Before, these extended Group, but now they extend SkinnableComponent.
This means a few things:

• You can easily skin Views, just as you would a custom component.
• There isn’t a layout by default since it’s expected to be skinned (this is typical of SkinnableComponent implementations).
• In the 4.5 final, the defaults.css for the Mobile Theme applies a white background.

MobileSkin:
This part is a tad fuzzy for me, as I didn’t get into skinning a whole bunch early on. The gist is there’s a few methods added to the component lifecycle that abstract implementation a tad bit further, in order to make compounded components (ones that build on another) simpler to implement.
Quickly referencing, there’s only a select few to worry about:

• layoutContents(unscaledWidth, unscaledHeight) – An isolated method to merely layout the contents of your component. Simple enough!
• drawBackground(unscaledWidth, unscaledHeight) – Again, a basic method merely targeted at drawing the background. No default implementation!
• setElementPosition(element, x, y) – In the early days it was positionPart(); clearly a more common naming convention with setElement*. This handles ILayoutElement, IFlexDisplayObject, and lazy DisplayObject implementations.
• setElementSize(element, w, h) – Should be self explanatory now, former method was resizePart().
• commitCurrentState() – When a skin’s state is updated, it will immediately call this method; apply any visual changes in this method based on the state.

Some interesting methods to take a look at:

• applyColorTransform(displayObject, originalColor, tintColor) – In order to quickly “theme” your components, you can utilize this method to do a color transform for you. This is akin to the themeColor or chromColor styles.
• hasState(stateName) – By default, MobileSkin always returns true, as there isn’t a state listing like in SparkSkins. If you want to throw an error to a developer, override and return false for states you know you don’t implement. Typically this is only useful for when you extend a skin and want to avoid handling a state.

I’m hoping it has been beaten into your skull already, but you should be writing your skins in PURE AS3… I’ll be honest, I break this rule too, but haven’t compared with a pure AS3 implementation to know if the performance is really as much as they say it is. Maybe that’ll be my next experiment

Backwards compatibility:

• http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7ede.html
• http://opensource.adobe.com/wiki/display/flexsdk/Flex+4+Backwards+Compatability

Some Tricks

Here’s a few tricks I’ve found while trying to migrate my application:

• There is no quick way to fix the CSS to go from hyphenated to camel case. I’m considering writing a quick javascript or Flex app to handle this for me. I just spent like 30 minutes going through ALL my CSS, and it wasn’t fun!
• Use REGEX search to help identify items needing change quicker: \-.?
• Be sure to limit searches to “Enclosing Projects,” and limit file types to *.css for faster and more accurate searching!
• Views now  have a backgroundColor of #FFFFFF applied to them. I was expecting to see my application background, so I had to set backgroundAlpha to 0.
• ActionBar components are given an ID. Because of this, CSS must be applied slightly different than desired/expected:
• ActionBar #titleDisplay – set fontSize for header here. Setting on ActionBar is futile!
• ActionBar Group#navigationGroup Button
• ActionBar Group#navigationGroup Button.myStyle – for a unique style for a button
• ActionBar Group#actionGroup Button

External Links:

• How to use Flex 4.5, and target AIR 2.5 – Jason San Jose – Mostly useful for Playbook development
• Flex Mobile Skins – Jason San Jose – Part 1, Optimized skinning basics

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 ).

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!

This is a quick post to throw up the slides, and a link to the presentation.

Instructional

Here’s the recording from the user group (laugh if you want ) and here are the slides.
I’ll have the links in the slides updated at a later point in time.

The Goods

• Example 1
• Example 2
• Example 3
• Example 4
• Source

Yeah… This is a rant guys… If you don’t agree, tell me – but take rude comments elsewhere. Comments will be open for as long as I can tolerate it (assuming anyone comments at all).

Get ready for a long read – and a lot of personal frustration; this won’t be pretty…

Who are you?

Honestly… I’m just a guy. I’m a guy that happens to be a USER and a DEVELOPER. That’s right, I play on both teams.
I’m anti-Apple, pro-Android, and heavily interested in the mobile platforms, both current and upcoming. Even with my angst against Apple, it’s important for me as a developer to understand it, and cope with it.

What’s MORE important is that I try to make products that are intuitive, clean in appearance, and generally enhance someone’s life. Having said that, there is a place for the “fart” apps and the sound boards. In a particular way, they enhance lives just as much as an advanced Augmented Reality camera app that will find the closest pub to get smashed at. As silly as it seems, stress relief is a very important factor to our markets.

Come at me, bro!

Ok, I’m just going to get right to it…

If you make any of the following arguments, you’re trash in my book:

• “I’m just a developer, I don’t make things pretty”
• “… I know more than my users do”
• “… I don’t need to change that, my users will have to get used to it”

Yeah – I said it! You’re TRASH! You don’t deserve to even sit behind a keyboard. You’re a crappy user, and a crappier developer for saying these things! C’mon! Why would you want to spend time building something to turn around and frustrate your users?! It wastes everyone’s time.

If you’re coming to a platform, and “trying to learn to develop” then allow me to suggest to not even think about publishing your first, second, or even third attempt at an application.
There’s a 90% chance it sucks. Ah screw it, let’s just say 100%; I know for a fact it will suck. How do I know? I’ve been doing this a while; and there’s not only a pragmatic, arguably an algorithmic approach to development – but presenting your application interface to a user has some psychological aspects to it as well that you’re just not keen or privy to yet. It’s ok, you’re green… It’s actually NOT your fault. But it is important you recognize your naivety regarding these topics, and educate yourselves about these things. Worst case, you find out how to build better apps, and sell them better (or rather they sell themselves).

What IS your fault is cruddying up our markets with this garbage. It’s equivalent to just throwing trash out the window – it’s unhealthy to an ecosystem, and ultimately causes other people more work.

My current take on markets

There’s too much crap. WAAAYYYY too much.
One thing that’s irritated me the most about the Apple store is the boasting of the number of apps… To me it’s not about quantity, it’s about quality. And honestly, given Apple’s (*cough* Jobs’ *cough*) superior attitude, I’d expect them to be more strict on the “single function” and redundant apps. But again, the marketing is centered around the shear quantity of apps. As a user, I don’t care for 20,000 flashlight apps and 14,000 fart apps (numbers pulled right out of my ass, btw). that’s 34,000 apps I just don’t care about.. and really, if i wanted either of those apps, I shouldn’t need to browse through that many, as I’m most likely going to pick ONE to THREE of the top few and move on.

Now before I go any further, let me explain why I think there’s more than one of any type of app.

• Some if not at least 50% of it can be attributed to “noobs” coming to our markets, and trying to get used to the whole process. It’s super-hard to bash on them, because honestly their excitement and thirst for knowledge is rather inspirational – to a point.
• I would be willing to attribute another 48% to competition. That is, “my app is better than yours.” Hell yeah! You mean I can COMPETE with another app? YES! Well, except the reality of the situation your app is NO different than the other guys. How many ways can you make a flashlight? One? Two? 14, 173? (the answer is no)
• And lastly I’d chalk up the last 2% to ignorance and laziness. As a developer, I just didn’t check the market thoroughly enough to see if my idea has been done a couple hundred times already. To be fair (and I’ll get into this more a little later), it may have been difficult to figure out the right search term to pull up an app that satisfies their needs. Whether it’s a funky name of an app (“LightHouse” doesn’t exactly indicate it’s a flashlight), or it’s such an obscure/ambiguous idea that identifying a term is difficult (“message board” has so many meanings to me personally).

Now, having said that – I totally believe that competition is a must. After all, I’m an American (don’t hate me) and I believe in capitalism. A core fundamental part of that is competition.
However, competition is defined as the following:

Competition is a contest between individuals, groups, nations, animals, etc. for territory, a niche, or a location of resources. It arises whenever two or more parties strive for a goal which cannot be shared.

Wait… Look at that last part… “which cannot be shared.” Yes folks, that means your competition is trying to out-do the other guy in a way that knocks him off his totem pole. You’re trying to be the winner here, not comfortably co-exist.

Do you think Apple and Google are content with providing the same features? Hell no! And if you’re a part of either camp, you know it’s black and white. It’s a rare thing to enjoy both platforms, because we as users definitely see, feel, hear, and interact with the competition directly. We vote with our feet and dollars, and we vocalize ourselves (I know I do ) to state which territory we defend. Dag-nabbit!

So the only way competition can work in a true market is to actually be distinctly different than the next guy (or gal, sorry ladies, no disrespect). SO FREAKIN’ DO IT!
If everyone made Ferrari-like cars, no one would care about Ferrari’s, and that’s how I feel about a lot of different apps. If there’s a discernible difference between them, then by all means, submit your app! Let me have choices!

But with choice, comes great responsibility as a user. I must be willing to help establish a viable ecosystem, and be able to assist in seeding the lifespan of a particular application just as much as the developer himself.
“How,” you ask? Simple. VOTE: Mark that bad boy 5 stars, comment on what you like or don’t like, give feedback DIRECTLY to the developer. This is a two way street folks!
As a quick ancillary point, I really hate seeing comments like: “Great! 5 Stars”. You’re not contributing with that comment. By all means, mark it 5-stars! But if you have no critical feedback, keep it to yourself!

I’ve been mocked a few times, particularly on some forums about this whole idea of “there’s just too much crap in our markets,” and am often asked “So you think 150 apps is better than 5000 apps!?”
Well, to answer that truthfully we have to consider the then and now of things.

As a quick note, I am almost completely oblivious to the Microsoft channel as both a dev and a user. Sorry, but I can’t speak to this at all. I took one look at their design-language, and decided I wanted to have nothing to do with it.

Then:
Sure, the idea of markets was new. We wanted to explore the entire realm and possibility of what developers could come up with – without stifling creativity. Granted, developers aren’t known for their creative, intuitive, or expressive applications; but some of the most successful applications have come from being (without getting into too much detail) “open” to types of applications that are allowed to be submitted. We had no clue to what a successful application would be, and what wouldn’t. We would continually be surprised to hear, as both users and developers that someone was making money off something so simple as a fart application, with equal if not more success as a dedicated team to develop some application such as ShopSavvy or Shazaam.

Now:
We’ve seen the success stories about a simple tele-banker creating a Bejeweled-type game and get rich over night. Same can be said with a fart app, and something as well executed as Angry Birds. But we’ve also seen a plethora of applications that have 0-1 star ratings, no comments, and less than 100 downloads (particularly on the Android Market).
The illustrious fart and flashlight applications ARE proof that simple-function applications have a place in the market – there’s no question there. But do we need tens of thousands of them?
What about simple converters that merely convert Celsius to Fahrenheit? Shouldn’t it do more? Give me more conversions, give me more options. I want to convert all types of units of measurement, not just one. And I think more importantly, I don’t want to download 20 different apps to convert different things. Maybe you’re not smart enough to develop this type of application, and that’s OK. But maybe you shouldn’t be developing at all.
So at this point we have the TWO largest markets, Apple and Google, making claims to the number of applications they have as if it warrants them some kind of merit badge. Maybe it should?
After all, it is rather impressive to hear that there’s a HUGE number of apps – until you actually see them all. It becomes cumbersome, and often a chore to find something that’s actually useful. I challenge you to count the number of apps you use in a day, versus a week, versus a month. Not all apps are created equal, and thus aren’t USED as equally. Granted, if you were to take inventory, you’d probably find over 60% of your installed apps are useless and just taking up space. Again, I’m pulling this out of my ass, but quick Google searches prove that people don’t use apps as much as they think they do. Games being the ultimate exception. Everyone plays Angry Birds while dropping a deuce – everyone.

So yes, I DO feel that 150 apps is better than 5000 apps… At least I know those 150 apps are most likely going to actually improve my productivity, utility, and entertainment.

Upcoming Market(s)

RIM/Blackberry PlayBook

This rant came about from my interaction with a new community and platform for the upcoming BlackBerry Playbook. Honestly, even with my issues with the whole ordeal (which if you keep reading, you’ll hear plenty about) I still feel like it’s a strong competitor with the current platforms.

If you’re a new product line, I think it’s more important than ever to learn from other products’ mistakes. Just as important, learn from their successes.

Jumping back to the Playbook, we see immediately (especially as Flash/Flex developers) how open RIM is about the Adobe AIR platform, and how they’re heavily supporting it. This excites me, and is an indirect jab at the big fruity Apple, which I’m always a proponent of. Except… Your workflow STINKS. It reeks of inexperience, unprovoked thought processes, and some of the most unintuitive interaction I’ve seen in a LOOOONG time!
As I said above, I’m still optimistic about this platform, but they seriously need to work out a LOT of kinks, and arguably start over.
Some developers have completely left the market as a choice of publishing their apps because of the high level of frustration. We even have posts disguised as a tutorial (as Joseph puts it) to prove the non-existant intuitiveness of the signing process, which has caused some of us (me included) an insane headache (which still hasn’t been alleviated). That could be it’s own entire rant, but I’ll save you the earache (you’re welcome!).

Is this ok? Hell no! And I’d have nothing short of high expectations for RIM to come back to us developers with not only a better process, but an APOLOGY. It doesn’t have to be a super long and deep felt apology where someone says “I’m sorry,” but at least acknowledge our frustrations and throw us a bone. After all, you too are developers and hardware manufacturers. Let us know you are human, make mistakes, but can also learn from them. Drone or gestapo companies don’t bode well in my book.

What’s more is that it doesn’t seem they’ve rejected a single app, and instead have actually opened up communication channels with developers to assist them in fixing bugs in their application. This certainly requires time, and time is money. It’s not just $200-500 per device as some were estimating in the forums; and it’s most definitely not “just half a million dollars.” I would venture to guess it’s a ton more than that. Lets see you go and try to tell your board members and stock holders you’re going to give away a potential of a couple million of dollars away on a gamble. It certainly wouldn’t be easy!

But the notion that cost is limited to ONLY the cost of hardware is not very practical! From a business perspective, they’ve had to hire WAY more QA/systems engineers/probably managers/etc, possibly purchase more servers to support the submission system, as well as AppWorld. The offer started Dec 7, and will end March 15th.. That’s just a week over 3 solid months of approvals, and if we’re looking at a minimum of 4000 apps, that’s 44 apps per DAY (INCLUDING WEEKENDS) that are to be approved and rejected. If we go above the 4000 mark (which I seem to recall they said we well exceeded that earlier this month) then that speculated number just goes up and up and up. Sure if you only consider the hardware it might be $200-500 out of pocket, but the company as a whole is probably seeing more like $1000-1500 per device. Once more, these are numbers that I’m making up, and have no evidence to back it up. But common sense tells us we shouldn’t limit this idea to just the hardware as anyone in business can tell you there’s overhead costs in EVERYTHING.

An interesting thing we’ve seen happen a few times over, particularly with gaming consoles, is that the manufacturers will often sell the hardware at a loss. I believe the numbers range from $50-200 loss per unit sold. This is done with the expectation that they will sell more, and make up the costs with royalties, licensing fees to developers/distributors/publishers, and advertising channels. Sometimes it works out… sometimes it doesn’t.

Amazon Marketplace

This one is SUPER strange to me. It’s by far the most interesting setup, for a multitude of reasons.

Right off the bat, on their blog, they’re open about sharing apps between Android and iOS. Even though it’s an Android store, they’re informing the developers about considerations for other markets, and potential bumps in the road. They’re not giving away secret info or anything, but the idea of looking out for the developer is awesome.

What’s strange though is their pricing schema. Basically- there is none… Or rather, they choose it for you! Basically the set a price point, and sometimes even promote it by putting it on sale. For some this is irritating, there’s no guarantee for you to make the income you expect from other markets.

Another point of contention is that this officially fractures the market. Android has had other smaller markets (e.g., AndroidTapp, Slideme, MiKandi, etc) that had wildly varying success – but none have the infrastructure of Amazon. I’m not normally one to concern myself with fragmentation and fracturing, but I feel the limitations of setting price-points causes some warrant for a double-take.

But then again, this is Amazon. They’re no dummies, they’ve thrived off the e-retail markets venturing from everything from groceries to sex toys, car parts, books (Kindle), electronics, music, and even letting individuals sell whatever they want. It just shows that their business modeling works, and it works well. The retail market is nothing new, and the advancement of the internet has only broadened the reach and potential discreteness of personal shopping. Why would selling applications be any different?

What I’m curious is if Amazon is going to decide to release their own line of products similar to how they push Kindle – but this time running Android (be wary, Nook!).

So… What now?

What… You think I have all the answers? Well I don’t – and I know I don’t. But I have some ideas. In one sense, I feel we’ve almost gone too far. Our current markets are saturated, and upcoming markets are more concerned with getting a torrent of applications to peddle. I don’t think this is right.

I think Apple and Google need to prune their markets quite a bit, and take a step backwards in how they promote them. Yes, as a developer, I’d be upset if I was told my application was now deemed unworthy (especially if I paid $99 for a license) and will be removed, but you know that’s nothing new. That has always been possible, and in a lot of cases has actually happened! You signed an agreement that said your app can be removed from the market at any time, based on the beliefs of the market runners. Apple’s yet to be afraid to put their foot down, and on a few occasions Android has had to step in as well.
It’s my belief that these markets need to be careful of becoming a Goliath. The next David is always around the corner, with slingshot and rocks in hand.

Now with the instance of the Playbook, I’m actually rather surprised and disappointed. A quick recap: If you submit an app before a deadline, you are eligible for a free Playbook. Eligible? Might as well say “guaranteed!” Being heavily active in the community I’ve come to see MANY apps that just don’t warrant a free Playbook, and even in some cases don’t warrant being on the market at all.
One could continue to argue that fart apps can still be successful, and deserve a place in the market – but others can argue that they don’t, and the novelty has fully worn off. I’m apparently one of the few who never installed a single fart app; getting a Playbook won’t change that for me.

The simplicity of some of the apps I’ve seen, and also seen how they’ve advertised their acceptance of getting a free Playbook is a point of disgust for me. I’ve been told a few times on the forums I’m in a place of misunderstanding, and that this ploy of RIM is to gain attraction, and that it’s working. And maybe it is? But as a user, if I get a Playbook in hand, and all I see are really crappy/ugly conversion apps, or equation solvers then I really want nothing to do with the product. What am I going to do with these apps?! NOTHING!

That brings me to a quick side-rant… If my job is centered around solving inverse sign calculations, then why the hell would I need an app with 3 text fields for this!? I’m an expert in this field, I shouldn’t need that! A simple PEMDAS calculator should suffice considering my need for expertise centers around this calculation. Just like I don’t go into a surgeon’s office, and feel comfortable with him looking up techniques of removing livers from a reference book or application. That would scare the @#&$ out of me!

I once was a big proponent of the Android Market being fully open as it is. I thought “Great! I can create a new browser, and not worry about Google rejecting me because it competes with them!” Heh, apparently I’m the only one who took it that way. There are plenty of people that saw it as “Great! I can create some heaping pile of junk, and throw it out there, without anyone to tell me I’m doing things wrong, and am implementing bad design/UX/and development practices.”
I don’t think the Apple market or the Android market are doing things right – but rather a mix of the two seem to be what’s needed.

That’s where I was hoping the Playbook was stepping in – their clearly open acceptance of Adobe AIR/Java/C++ SDKs, along with HTML5, Flash, and CSS3 compliant browser was an awesome first step in the right direction. It went quickly downhill when they declared their expectation was to have 4,000 apps at launch. Yes… 4,000. Why even put a number to it? Why 4,000? I’d rather take 40 super solid apps over 3,960 really crappy apps.
I like the openness, but for the sake of preservation, and more importantly forward moving markets, there needs to be a bit more precision.

I’m not even going to touch the licensing fees, trials and tribulations of developing for any particular platform, or the market share arguments in this rant… WAY too much to talk about there. And this is getting long enough.

I also think that markets need to grow faster… No silly, not in size! Have you not read a single thing I’ve said? No, instead they need to grow in functionality. It’s taken a while, but we’re finally seeing particular markets (Microsoft, AppWorld, etc) allow trial applications, micro payments, subscriptions, etc. But it’s taking FOREVER – and these processes and transactions are not fully solidified and often talked about like a bastard child. The point is, markets need to be able to grow instantly, and with confidence. Users are seemingly more than apt and willing to whip out their monies to buy things, you’re only guaranteeing another channel of revenue by doing so.

As more and more publications start moving digital, this also will be important for markets to support. Kindle and Nook are current pioneers in that industry. But the surprising, yet refreshing introduction of Martha Stewart Living app shows that other publishers are wanting a more rich experience. The only problem is, right now everyone has to roll that out themselves as an application. It would seem to behoove the markets to allow some “framework” to support this media-type just like we distribute music.

Once more, as both market leaders are approaching, the “cloud” is becoming much more important. It’s still taking too long in my opinion – the idea of waiting on future releases of Android and iOS are killing me! Right now with Android, I have a few options to stream media from my personal library; and I’m sure some exist for iOS as well. But there’s still some dependency there that I have to be on a private network, with software fully configured. The cloud will eventually diminish the need for all of this.
Google has a bit of a leg up with gmail pushes, calendar syncs, settings and app installs pushed to the cloud, and even Chrome to Phone. It’s surprising that other markets haven’t taken this approach YET, and it’s been a few years now!

My father-in-law has a silly saying, that I love to quote: “The problem with instant gratification – is that it takes too damn long!”

In the interim, we have to fend for ourselves and build custom components… Well, that’s not always all that fun, but also not always that bad!

I’ve done the dirty work, and created a MobileNumericStepper, as well as a MobileLabelStepper as a parent to it.

Whatcha Got?

Simply put, this is just a stepper. It mimics the Android style where buttons are above and below the text input, but is completely skinnable.
Also by default the bottom button is a flipped version of the top button. This is so you can use a single arrow graphic and the component will just flip it for you to save time.

A few key features:

• min/max – set a minimum and max value
• loopAtLimits – auto-loops to the opposite bound by default, but can be disabled. Ex: max = 100, when 101 is attempted, it will loop around to the min value
• buttonRotate – Good for having just a single arrow icon, and flip it for the opposite direction.
• stepTimerInitialDelay – When the user holds down a button, a timer starts to allow for repeated entries. This is the initial delay before starting the quick-stepping.
• stepTimerRunningDelay – After the quick-stepping kicks in, this is how fast to update the next tick.

A Variant Forms!

There’s not really a WHOLE lot more to talk about, as it’s just a stepper; but the MobileLabelStepper version might interest you.

The label version of the component allows a developer to define label replacements for the number counterpart. For example, if using a display type of Month, then 3 = April (remember zero-based indices).
It also allows for bounds that the label type should allow, again in the month context we’d limit from 0 to 11.

Be careful to look at the following static vars (indexed by the displayType) if implementing a MobileLabelStepper:

• BOUNDS_MAP – specifies an array which defines the lower and upper bounds of the stepper
• LABEL_MAP – specifies an object that maps numbers to their label replacements. For examples, check the source for the TYPE_MONTH/TYPE_AM_PM implementations.

Date/Time Example at RunTime, fully skinned

The Goods

• Example – View Source Enabled
• Source

And what about if we’re doing a browser application that we want to save a state of something, but don’t want to host the storage and write a web service to handle data?
We don’t have stealth access to the filesystem directly, which makes it hard (errr, impossible) to silently store things on behalf of the user.

We can actually tackle both easily using serialization.

Quick note: I could quite possibly be wrong about some of these concepts, as they’re just things I’ve come across, and can’t find an exorbitant amount of documentation about these topics.

Overview

First thing’s first… Let’s take a quick look at some of the interfaces/classes we might run into:

• IExternalizable – When writing a byteArray object, it checks for this interface.
• IDataOutput – Output object for writing bytes to
• IDataInput – Input object, exact opposite of IDataOutput
• ByteArray – Our binary data source.
• Base64Encoder – Encodes bytes to a string representation
• Base64Decoder – Decodes a string to bytes
• FileReference – A mechanism to save to a user-appointed destination

The act of Serializing data in AS3

A quick serialization is rather simple, and we use the ByteArray to convert objects for us into AMF bytes. This is done in-memory, so we want to make sure our client systems can handle the amount/quantity of data we’re serializing. For most situations, this probably is not much of a concern.

Setting up a serialized Class

So in order for the Flash Player to know what to de/serialize to/from, we have to assign an Alias to our class.
This is done simply by using the RemoteObject metadata tag to define the mapping.

package com.killerspaz.examples.serialize.vo
{
    [RemoteClass(alias="com.killerspaz.examples.serialize.vo.JunkVO")]

    public class JunkVO
    {
        //.... Class Implementation ....//
    }
}

Notice that I made my alias the fully qualified class name (that means I include the package name) my alias.
This is NOT required, but I personally suggest doing this. Keep reading to find out why…

If you want to map to a different name (such as something easier to remember, or to match the package space of a remote system) you can easily do so, and is acceptable.
The caveat to this is that in order to deserialize your objects, you MUST register the class alias using registerClassAlias():

package com.killerspaz.examples.serialize.vo
{
    [RemoteClass(alias="MyJunkVO")]

    public class JunkVO
    {
        //.... Class Implementation ....//
    }
}

//** Before deserializing anywhere, register the class alias:
registerClassAlias('MyJunkVO", JunkVO);

It’s typically best to register your aliases as soon as possible, such as on application startup.

Simple Serialization of an Object

Here’s a quick snippet of how to serialize your object:

var myJunkVo:JunkVO = new JunkVO();
var bytes:ByteArray = new ByteArray();
// ...
// set some properties on myJunkVo
// ...

bytes.writeObject(myJunkVo);     //Write our object to the ByteArray
bytes.position = 0;              //Reset position of ByteArray to the beginning

As a quick note, this is one half of the steps required to clone most objects at runtime. I’ll probably go over this in another post as well – in the meantime, check out mx.ObjectUtil::copy().

Done! Your object is now a ByteArray – you’ve serialized! Ok we can all go home now… Wait… I’m not actually done.

The whole object, and nothing but the whole object

a.k.a. It’s not working right

If you found yourself going through this post, or any other post you’ve found, but things just aren’t working right – this section is most likely the concept you missed.

There’s 2 considerations to serializing your data:

1. If your object hierarchy is made of completely public properties, then there really is nothing extra special you need to do in order to serialize…
   Seriously, I’ve never had to do anything fancy for fully public classes.
2. If your object has complex objects as children, which utilizes encapsulation and needs to save its complete state; well then we have some extra footwork to do.
   This is necessary for objects that we can’t easily derive states from our public variables, and have maybe collections of custom objects. Essentially, the nature of the data is valuable for an instance to function properly.
   It’s an all or nothing thing too – you either rely on all public vars and everything’s dandy, or if you want to serialize private/protected vars you’ll need to ALSO write the public ones!

So #1 is what we saw above. Assuming all members of JunkVO are public, we can safely serialize as demo’d.

As it turns out, #2 isn’t that difficult to pull off, but can be rather tedious depending on your model.

Implementing External Serialization

If you implement the IExternalizable interface, when a ByteArray::writeObject()/readObject() is called, internally it checks for these interfaces and calls the appropriate method.

The trick to implementing these methods is that you do it in the exact same order. For every write, you read, no exceptions! You’re essentially manipulating the ByteArray your object is stored in.

public function writeExternal(output:IDataOutput):void
{
    output.writeObject(this._createdDate);
    output.writeInt(this.somePropInt);
    output.writeObject(this.somePropString);
}

public function readExternal(input:IDataInput):void
{
    this._createdDate      = input.readObject();
    this.somePropInt       = input.readInt();
    this.somePropString    = input.readObject();
}

See, pretty simple!
Just remember:

• Sub-objects could also need to implement the interface for recursive de/serialization to occur properly. If they appear as null or default values when inspecting, count on this being the issue!
• Every property MUST be written and read in the same exact order.

Things to do with your serialized ByteArray

Well, you can take your ByteArray, and shove it right up your ……. storage mechanism

The easiest way to handle this is writing the ByteArray directly into a file:

protected var _fileReference:FileReference;

protected function save():void
{
    var ba:ByteArray = new ByteArray();
    ba.writeObject(someObjectInstance);
    ba.compress(); //compress to save space
    this._fileReference = new FileReference();
    //Prompt the user to save out to a file. Extension is made up here btw
    this._fileReference.save(ba, "OutputFile.amf");
}

But wait, there’s more!

While this works, and is quick and useful – I prefer to encode the binary data into a String.
This may not be that big of a deal for most of you, but for me personally I like to be able to copy the output and paste it into a sandbox app to see what’s going on.
I might make this app as simple and quick as possible, so I only have a text field to put the data, and binary data gets all wacky when copy/pasting.
I might also want to store the data into a database column to void a bunch of key/value tables that muddy things up. Binary data can be a pain working with in a database, and generally adds to confusion.

So for that, I’ve implemented a nice utility class I call SerializeUtils. You can see it in full effect in the example, or just take a look at the interface – it’s super simple!

Using the same file-save technique above, you can now save this text out to a file – just replace the byteArray reference with your string!

Troubleshooting

Things don’t always go as planned. Here’s some things that I’ve found along the way:

• When deserializing, and things are turning into Objects, or ObjectProxy, then we need to check our Alias’.
• If deserializing a built-in Flash object (e.g.: Date), be sure to register the class alias with the fully qualified class name.
  • Not all objects will serialize correctly. Unfortunately the only work around is to store the variables in a custom class of your own, and serialize that data.
• An error about converting an Object when writing a ByteArray: Ensure your metadata alias, and/or your registerClassAlias() is correct/exists.
• For writing to a file, make sure the client is using Flash Player 10+, this is a new-ish feature.

Example, Source, and Additional Info

To prove this works, check out the example. Once you serialize the object, copy the Base64Encoded string, and close/reopen the SWF. If you paste it back in and deserialize, you should see that the values are the same as you entered them originally, including the date the object was created!

• Example – View Source Enabled
• Source

Some Additional Information:

• Adobe Docs – Using RemoteObjects: Custom serialization