Archive for January, 2009

Importance of Event.clone

In Actionscript 3, the Event object has a method called clone.  This method does exactly what it says, it clones or duplicates the Event object, returning an entire new instance with the same values for all properties. The importance of this method comes into play not when you call it directly, but when the player calls it behind the scenes. As stated in the docs,

“When creating your own custom Event class, you must override the inherited Event.clone() method in order for it to duplicate the properties of your custom class. If you do not set all the properties that you add in your event subclass, those properties will not have the correct values when listeners handle the redispatched event.”

After yesterday I feel like I don’t pay attention well, because for some reason I was thinking that clone only got called by the player when bubbling an event in the display list. Yet as clear as it is stated in the docs, this occurs in non display objects which subscribe to an event, then redispatch it using their own dispatchEvent method.  In these cases, if you don’t implement clone, then your custom event will cast to the base Event class and will not contain any of it’s properties. This will in turn throw runtime errors.

I always implement the clone method in my Event sub classes, but somehow missed it in one and was wondering why it was casting to Event. Though it confused me for a minute, at least it opened my eyes to a simple concept I overlooked. Hopefully this post opens anyone else’s who didn’t realize the player’s behavior with clone.

2 Comments


BUG: AS3 Sound.isBuffering

It never shocks me when I run into bugs in the Flash player, even though it distresses me. On that note and for anyone in the know, the Sound object (flash.media.Sound) is riddled with bugs. The one I ran into most recently has to do with Sound's isBuffering property.

DEFINING THE FUNCTIONALITY

So what is buffer? Simply defined it is a cushion. In the case of Sound, it is a specified time span cushion that you want to have loaded before playing. If you set the buffer to 5 seconds, no data is loaded, the Sound will only start once 5 seconds has loaded (isBuffering is true).  This can happen at any point while playing and will cause playback to pause while buffering. In the case where you are 30 seconds in and have completely played out all data that has been loaded but are still loading data, the buffer is said to be empty and you begin buffering again (isBuffering is true). However, if you seek back to 0 seconds at this point, 0 to 5 is already cached so you return to a playing state (isBuffering is false)

To provide a little history, in AS2, the player's way with dealing with Sound buffer was to provide a global property _soundbuftime. This implementation was somewhat comedic, in that it did not actually buffer the data for the Sound, it just buffered the time before play. If you were loading a Sound, set the _soundbuftime to 10, loaded 2 seconds into the buffer in the span of 10 seconds, it would play whatever it had loaded in that 10 seconds (in this case 2 seconds). Fun right?

AS3 actually creates a true data buffer for loaded Sounds via the SoundLoaderContext. In the example script below, the MP3 is loaded from a remote server with a buffer of 3 seconds (NOTE: SoundLoaderContext is specified in milliseconds, the default is 1 second)

Actionscript:
  1. snd.load(new URLRequest("http://server.com/test.mp3", new SoundLoaderContext(3000, false));

Since this actually provides the true data buffer, the new isBuffering property of the Sound object returns a Boolean (true or false). This is great and a large improvement from what we were previously provided in terms of an API.

THE BUG

So where is the BUG you ask? Well there are actually 2.

  1. The first bug's use case is : if you have loaded a Sound partially or completely to cache, upon reloading it, the isBuffering property will incorrectly report true. This is the case even though it may have 30 seconds in the buffer when only a 1 second buffer is set.  This isn't to big of a deal, though it means you could be showing buffering states when not needed.
  2. The second bug's use case is : if you are loading a Sound, it has enough data to play, and plays to a point where it starts buffering, and then you seek to a cached position. For example, my buffer is set to 5 seconds, I've loaded and played 10 seconds, I've started buffering at 10 seconds, and seek back to 0. At this point I should be able to play through to 10 seconds again and isBuffering should report false until I reach that point where I don't have enough data to play again. Unfortunately, this is not the case. isBuffering continues to report true, playback is paused, and only until the 10-15 second span is loaded will the Sound start playing from 0.

SUMMARY

As you can see the isBuffering property is a great addition to the API, but you can't actually rely on it. In essence, it makes it useless and I wouldn't rely on it for determining buffer. Sorry kids :(

5 Comments


Event type naming: Tense

I tend to be a real stickler when it comes to naming elements of code that I know are going to be part of a widely used API. It's odd to me that there is not, or I have just not been privileged to find, a good resource on the subject.

Events are a programming paradigm that exist in several different languages. However, even though the concept is exactly the same, the naming tends to differ in tense a lot. In many languages you see things with past tense like Closed versus Flash which has a present or transient tense like Close (Event.CLOSE).

Which is right?

Well neither is right or wrong, but I do believe one is better. If you take the example Close, there are actually different event states, Closing and Closed. By using just Close you have no idea of what state that truly represents.

What impact does this tense have?

If you look at the function that is creating the Close event, where does it emmit it? Is it at the top of the function or at the bottom? If the event is cancellable and that cancel has effects (like it stops executing the rest of the function), then tense is very important to know. For example, you may have a dialog closing, but if you haven't saved information in it yet you want to stop it from closing.  If it is ok to close, then you may want to allow it to close, but clean up information on close. In this case you want detailed information of the Event breakdown. The present tense Close does not denote that. Therefore, it is better to use Closing, which gives you the option of an additional Closed to represent the same event in a latter state. This holds true with all Event types.

There is a lot of power in just how you name things, so give it a little thought.

3 Comments


Apple IPhone Revolution

MARKET HISTORY

For years we've been hearing that mobile was going to be an enormous market that completely dwarfed what we see with desktops. I can't tell you how many write ups, presentations, key notes, and conversations I've seen on this. It completely made sense in terms of numbers. Just a little reflection of how often people get new phones in contrast to computers, or how many phones exist in a household versus traditional computers, and one can see this. Yet at the same time you hear the numbers, they haven't made sense. Why? FRAGMENTATION and APPROACHABILITY. The mobile market has been a fragmented and unapproachable mess when it comes to the masses. For this very reason, I shelved it, watched, thought about,  and counted the days until I would actually start really devoting time to it. That is.. UNTIL NOW.

FRAGMENTATION

There have been thousands upon thousands of different models of phones, systems, programming models, distribution models, and more. It has been a nightmare for developers and consumers alike. What we needed was a uniform platform. Java attempted to redeem itself in the market, while Google Android and Flash have also staked their claims. These technologies, all try to be the "Windows" or software glue that can tie the long list of devices together. Now I'd say that is a great idea if you can get all of the devices manufacturers on board.  That "glue" is what you have to have in market without device attraction.  What is device attraction? A particular device that all consumers must have which puts up blinders to and outsells all others. With that type of device, it becomes the standard physical item and whatever environment it possesses becomes the standard platform. Despite all the highend phones like Nokia, Sidekicks, Razors, and others, we have never seen one that completely swept the market. Thus, a market of many devices requires one system to rule them all to be truly revolutionary. As anyone knows where corporations and competition come into play this is a very daunting and hard to reach task.

APPROACHABILITY

Even if a "Windows-Esque" model for phones became a reality, you still would have to have a very easy distribution model for deploying and purchasing applications. We have seen attempts, but ask the average consumer about them and they would not have a clue what you were talking about. Whats worse is ask your average developer and they would probably echo the same response. There has been nothing known to the average consumer or developer that has seen any global movement. Note the word global there. In places like Asia and to an extent in Europe, there has been some success in consumption and distribution even with the broken phone market. One could say that the success in segments of these markets is directly linked to the evolved technology infrastructure, technology awareness, and consumer "travel time".  The consumers have better services, are more technologically savvy, and have free time while traveling on public transporation to consume these things. Tokyo is a gleaming example of this. Yet anyone who has been to Tokyo will tell you it's like stepping into a different world. To be a true success we need something that touches say a construction worker in Alabama. Until that point, I deem it unapproachable.

ENTER THE IPHONE "ATTRACTION"

Anyone who attended some of my presentations 2 years ago, heard me spouting off about what ifs with the IPod and the culture adoption phenomenons it could elicit. At the time there was no IPhone or ITouch, but it seemed obvious of the possibilities and potential direction. With Apple making smaller and smaller computers like the Mac Mini, it only seemed like the logical next step to make the IPod a mini computer. In those presentations, I also talked about platforms. Although it was in the context of the living room, I noted that you really had to have a device with "attraction" like a new XBox, Wii, etc that could bring consumers to A) purchase  and B) consume through new distribution models. This same case holds true with the phone market.

In constrast to the uniform platform for all devices, the IPhone has become the mobile device with "attraction". It has brought consumers to buy a new phone or switch plans just to have it. The initial draw was with the Apple lovers, who lined up in mass, which we all know isn't a good indicator since at times the lovers can be compared to kool aid drinkers. Given this fact, my take at launch was don't drink so much kool aid and watch the market. Any new technology doesn't have an impact until it starts to seep out to the masses. To know when this takes place, you have to look for indicators of the shift. Mine was quite clear. A friend, who is not the least bit tech savy, called me up and started raving about his new phone and how he "got email" now. Though he had an email account for 5 years, he had never checked or bothered with it. With this new phone, he was apparently sending and receiving emails everyday. Not only had he entered into the email age, he was downloading and using several apps from the app store. With this observation and with several similar ones, I knew the shift was definite. A HUGE point here is that, not only was the device attracting consumers, it was providing such a pleasurable experience that it annihilated all cognitive dissonance and created promotion through positive experience relays. In essence, every IPhone owner is becoming a walking promotional billboard for the device. I can't name another phone I have ever had someone sing praises to me about.

UNIFORM and APPROACHABLE IPHONE PLATFORM

So here we sit with the IPhone becoming the must have phone. Unlike having to unify a billion different devices, you just have to focus on looking at the one that everyone wants. This is a big game changer. However, it only changes the game if there is a market to consume what you develop. Apple has done a tremendous job at breaking down this wall. Just turn on the TV and they will let you know that you can download an application in a few seconds that will listen to a song and tell you what it is. There is a mass wow factor and education that is going on which is opening up and creating the market.  No other device manufacturer has been able to pull this off to date.  We now have a solid market and uniform platform to target. Develop an app today, sell it tomorrow. Apple has created the environment that many have dreamed.

WHAT ABOUT THE OTHERS

Apple has taken heat for being a closed environment and having a weak feature set. Those drenched in the mobile industry will argue that Apple will have to bend to competition. If that is the case, let's break down some of the competition factors.

Are other devices' capabilities better?

One could make a long list of features where the IPhone falls short in relation to the competition. It's camera is horrid,there is no video camera, and the list goes on. Yet, despite this weak feature set and long list of phones the surpass it in these areas, none compete. It is not a single feature set where the IPhone wins, it is the overall experience, from software to hardware. The IPhone has the complete attractive package. Where it falls short, anyone that watches a Steve Job's keynote, or walks into an Apple store twice a year will tell you that the IPhone's feature set is going to evolve dramatically.

It's a closed platform

This is the biggest complaint from developers and from creators of development tools. The thought here is that if other devices allow for open types of development like Flash, Java, Python, Javascript, etc then they will bring in more developers and create larger markets that put competition on Apple. The point that is missing here is that you have to have a market first. One could go and use Android or Flash and develop for a phone today, but there is no "universal" market there yet.  There is not a distribution model or awareness of one on other devices that constitutes a competing market for the IPhone. You are actually seeing an inverse of this argument. Developers are learning the environment because they know a market exists on the IPhone.

So are we going to see competition?  I think you will see attempts, but it is starting to move over the hill at this point. Apple is already starting to offer lower price points, hitting even larger mass markets. Just ask yourself, how can a 600 dollar phone compete with a 99 dollar one? Also, when the AT&T deal expires and the IPhone is available across carriers, you'll see a mass flock of those who weren't converted primarily because they didn't want to switch their service provider. Apple's marketing machine can reach the masses like no other device manufacturer can. Do you know of any other that carry Apple's power of culture branding?

FLASH ON THE IPHONE

For a lot of my readers, I'm sure having Flash on the IPhone is the first thing they want to discuss when talking about the subject.  It's quite obvious from the days of Macromedia that they want to be in the mobile market. Further, one can deduce from all the public annoucements from Adobe, they have Flash running on the IPhone. In what form is unknown, but a lot of discussions revolve around the "REAL WEB" and point to the browser. If this is the case, anyone looking at this from a experience or business standpoint will tell you that's the wrong angle.

There is a TON of Flash content on the web, almost all of which was not developed with a device in mind. What that means is that a lot of Flash content on the web will flat out fail. Not only will it fail, it will cause the browser to fail. In terms of the IPhone, that means that the user will perceive that the browser failed, and thus the device failed. The thought will be that the device is buggy. In a world where image is everything, Apple would kill 5 people for that. Standalone applications are different. If an app dowloaded from the App store fails and is isolated, the reaction is #$@#$@ app! The unpleasant experience is reflected on the app and not the device.

From a development perspective, a standalone application requires the developer to focus on targeting whatever environment that standalone is hosted in. This means that the developer is (or at least should be) consciously thinking and working towards making their application look, perform, and take advantage of the targeted device. Developing for a web browser on the IPhone has it's perks, but it isn't as powerful and can't enforce quality standards like a standalone app can. Truly the real power comes into play with an app that has online/offline capabilities, is tied into the phone feature set, and is designed for the device.

Experience aside, the only place Flash could make sense on the IPhone for Apple would be the App store. Since Flash is a rapid development environment with a large developer and existing code base, it could mean more applications, which in turn could relate to more money. Apple could preserve it's "environment" image and cash in on new Apps. The web browser equates to no financial return and really only boils down to a kind gesture that could have experience backlash.

Personally, as a developer, a consumer, and a business owner, Flash in the browser holds no appeal to me on the IPhone. Adobe has to put it's focus on the App store with Apple. If that is a losing battle, they and every other company in the mobile space have to create both the "attractive" deterrent and the competitive market to play on that side of the field. The only other option would be modifying their tools to create native compiled applications. This would be similar to  what Unity does, but that starts branching their overall goals since it is no longer a player mentality.

The main issue here, as previously noted, is that the IPhone market is converting developers into Apple developers. Without a strong case of how Apple can benefit from Flash being on the device, there is no driver for it. It boils down to business.

CLOSING THOUGHTS

The mobile market is finally here in my opinion. Anyone with half a brain should be gearing up to develop for it or they are missing out on a huge opportunity. Don't let learning a new development environment be a deterrent, because that is like buying cassette tapes instead of CDs. You don't want to be stubborn and not evolve. To that point, you aren't just learning to develop for the IPhone, you are learning to develop for the APPLE PLATFORM. It's definitely strategic on Apple's part and probably a large reason they close off the development. They have the market as a side effect of the IPhone and with that power are able to convert developers in mass. Right now that conversion means IPhones and Apple computers. What does that mean tomorrow? Only time and Apple will tell. I believe if Apple still has some fight and innovation in them, I'm still guessing the living room as a target. They have fallen considerably short in that area, with the ITV becoming a weak element in their box. The XBox partnership with NetFlix is really just nailing their coffin, but I think there is hope. Blockbuster could chime in, subscriptions could exist, DVR can come into play, and all the Apple devices could work together as one, we shall see. Regardless the IPhone IS MOBILE, and I'm happy to see it coming to life.

5 Comments