Yesterday I had Dreamsocketeer – Chad give this blog a much needed face lift. Unfortunately, I let it go to long with a dated default look that made it hard to read some entries. Obviously, most people just grab the feeds through a reader, but for those making the trek to the site it made sense to give you something that appealed to the eye. In addition to lovely new “clothes”, I threw in some additional social links of mine in the navigation for those wanting more info on who I am, what I do. Enjoy the new lovely!
The base Event class in Flash has 3 parameters.
public function Event(type:String, bubbles:Boolean = false, cancelable:Boolean = false)
The first parameter, type, is required. The second two, bubbles and cancelable, default to false. This means that you don’t have to pass either of these two parameters and they will incur values.
If you look at any of the native Flash Event subclass constructors, their additional parameters follow the Event base’s default parameters and have defaults.
public function IOErrorEvent(type:String, bubbles:Boolean = false, cancelable:Boolean = false, text:String = "", id:int = 0)
So the questions arise when you subclass an event and you have a new parameter you consider required: Should all additional parameters be required to follow the base parameters to ahere to the base signature? Should a developer have to type in values that almost a 100% of the time will be defaulted in order to type in one that is thought to be required? Obviously, if this is the case then the additional parameters can not be required by the compiler and only enforced by practice. These parameters would have to have defaults.
// required parameters following default ones is illegal and the compiler will flag it public function Foo(defaultParam:int = 0, requiredParam:int)
While working on our media framework, I debated on whether it was valid to follow Flash’s native Event subclasses and make required parameters only required by practice or whether to change the subclass signature and make them required by nature. I settled on the fact that it’s ok to switch up the order of parameters in the constructor’s signature and place new required parameters before base default ones.
// super constructor public function Event(type:String, bubbles:Boolean = false, cancelable:Boolean = false) // subclass constructor public function DownloadEvent(type:String, currentProgress:Number, totalProgress:Number, bubbles:Boolean = false, cancelable:Boolean = false)
If the parameters were all defaults, a developer could forget a “required” one and end up having to debug unexpected results. By actually requiring parameters, a developer who forgets to put them in then will get warned by the compiler. This seems better practice and also feels more natural when programming. For example, when creating new instances, you only have to pass in required parameters and can let the base ones default.
this.dispatchEvent = new DownloadEvent(DownloadEvent.DOWNLOAD_STARTED, .5, .5)
Personally, I don’t think signature familiarity is as important as context responsibility. It also doesn’t make sense to force yourself into a practice that can actually be less productive and hurt you rather than be beneficial. That’s my take.
SEO (search engine optimization) refers to the tailoring of web based content so that search engines like Google can traverse it and index it more efficiently. Flash content on the web has typically been difficult to index. However, if you understand the underlying methodologies of SEO indexing, you can understand how to index your Flash content.
Whether you are indexing just a site or a specific application, SEO is important because it let’s people find your content. At Dreamsocket, we have advised clients with some of the highest trafficked Flash content in the world on how to accomplish this. And though we found write ups on specific techniques, we figured that a more comprehensive break down of the subject and techniques was needed. To address this, we have published an article and example files on our site that break down different techniques that we have used or seen over the years. In the article we compare and contrast the techniques by showing their benefits and drawbacks, as well as how to accomplish them.
Check and comment on the article when you get a chance. The more information on this subject the better!
Dreamsocket is a software company located in Atlanta, GA, focused on media and entertainment industry solutions for the web, desktop and mobile platforms.
We have built ground breaking software for clients including CNN, Disney, Cartoon Network, Adult Swim, NBA, PGA, Scripps Networks, SonyBMG, Rolling Stone, NASCAR, CBS, Barnes and Noble, Motorola and IBM. Our award-winning work has been featured in the New York Times and various web publications.
We are a group of diverse individuals, but together we share one dream. We wish to do great things and push our talents as far as they will take us.
WHO IS BEHIND DREAMSOCKET?
I guess it is best to start with letting you know who I am. My name is Kenny Bunch. I am a programmer, dreamer and founder of Dreamsocket. Growing up, I created my own GI Joe vehicles out of scrap cardboard, started a snowboard clothing company at 15 years old, traveled the US with a skateboard and had a lot of fun just enjoying life. I never would have guessed that I would end up as a programmer. Yet, it has always been part of my story.
If you had come to me when I was an 8 years old playing on an Adam personal computer, I would have shown you some crazy BASIC games that I wrote with my older brother. In college, I would have tried to persuade you to test out the latest and greatest media applications I was programming in order to edit some skateboard videos. Come to me now and I’m essentially showing and saying the same thing. Fate has given me direction, and I’ve followed with a smile.
So yes, I have been extremely lucky to have been able to make a career out of something I love. Coming from a small town where factory jobs were the norm, my life is all a dream. The fact that I started out as a developer at some of the biggest companies in the world — CNN, Cartoon Network and Bell South– blows my mind. I cherished each of those opportunities. But, when a dream calls, you have to keep moving towards it. When the time came to start a company, I questioned if I was crazy, doubted what I was doing and was scared out of my mind when I left. My decision was always based on the fact that I had dreams that I wanted to accomplish, and I had to follow them.
Why am I telling you all of this? Quite simply, because that is the foundation of Dreamsocket . Even though we’ve legally been a software company for over three years, we don’t view what we have as a company. Everyone here views it as a destiny and a gateway to our dreams. I know those are strong words, but Dreamsocket really is a place built from the heart. We have great respect for those around us and treat every opportunity as a gift. We want to do great things in our work and in our actions.
DREAMSOCKET’s PHILANTHROPIC PLEDGE
Dreamsocket was founded with the aid and support of a great number of generous individuals. We have been fortunate enough to have a community that has allowed us to thrive and become who we were meant to be. We want to provide the same opportunities to others and genuinely make the world a better place. We view our employees, vendors and customers as partners in our dreams. Therefore, we want to offer them the opportunity to participate in our vision of a better future for all humankind. Through our philanthropic program, for every service contract we enter, we will make a donation to a nonprofit charity of our partner’s choosing that they feel will make a positive impact in the lives of others.
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)
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.
So where is the BUG you ask? Well there are actually 2.
- 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.
- 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.
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 🙁