RIA Developer, Flex / Flash, Widgets
Tip of the day
Tip of the Day – Getting started with Cocomo
Jan 19th
So a little known fact about me… I am extremely passionate about Real-Time Collaboration (RTC) applications. I build them as a hobby in my free time, they fascinate me.
What does “Real-Time Collaboration” mean?
Real-time collaboration is using the Internet and presence technology to communicate with co-workers as if they were in the same room, even if they are located on the other side of the world. Real-time collaboration involves several kinds of synchronous communication tools such as:
- Instant messaging
- Group chat
- Buddy list and other presence awareness technology
- Whiteboard collaboration
- Application sharing
- Desktop sharing
- Co-browsing
- Voice over IP
- Video and audio conferencing tools
So what is this Cocomo thing and what on earth does it have to do with RTC?
According to Adobe Cocomo’s Labs page:
Codename “Cocomo” is a Platform as a Service that allows Flex developers to easily add real-time social capabilities into their RIA (rich Internet applications). Comprised of both Flex-based client components and a hosted services infrastructure, Cocomo allows you to build real-time, multi-user applications with Flex in less time than ever before. And because Acrobat.com hosts the service, issues like deployment, maintenance, and scalability are taken care of for you.
I’m as jazzed as you are… how do I start?
Visit the Cocomo Labs page and follow their 4-step program under the “Getting Started” tab.
After that, I highly recommend watching both of Nigel Pegg’s sessions from MAX about Cocomo. They can be found here.
So Nate why are you so excited about Cocomo?
For many reasons, but here are my two favorite:
Reason One: I’ve been building RTC applications in my spare time for a long time, and one of the big problems that is solved by Cocomo is the fact that the service is hosted by Adobe. Of course it costs money, but with Cocomo the barrier of entry is so much lower than before. Trust me.
Reason Two: I don’t have to write any server-side code! I know some of you are thinking that this is a bad thing, but hear me out. Sure there are times where you’re going to want to have custom server-side logic. For example, a complex game with server-side hit validation and what not. In that situation Cocomo probably isn’t the best choice, but for other types of applications im, chat, whiteboard, video/audio conferencing, casual games, etc… Cocomo is the perfect thing.
Nate… this was kind of a weak tip.
Tough, you try coming up with something new every day for a month.
Sources:
Tip of the Day – When to use include
Jan 18th
A little while ago I posed the following question to the flexcoders mailing list,
I just wanted to ping everyone and get their opinion on something. Why would anyone ever want to use the include directive? I’ve recently been working on poorly designed project where at the top of every module there is an “include Header.as” statement that has 30 include statements within it. To give a datagrid additional functionality, you give it an id=”myDataGrid”, and the include statement takes care of the rest. It’s really bad.
I just don’t see a good use for the include statement anymore. In my opinion, it just promotes bad programming practices.
I mean, can’t everything be taken care of using OOP methodologies? Thoughts?
I’d like to thank everyone who responded, you all gave me quite a bit of insight.
After thinking about this for a while now, here is my list of the common reasons people incorrectly use include (include directive).
I have common functionality that I want shared across multiple components.
That’s great that you’re using DRY philosophy! However, it’s much better to combine the DRY philosophy with object-oriented programming practices. Instead of using the include directive, abstract out common functionality into a parent class. Then you can create children of your parent component, and add additional functionality as needed.
I’m building a framework.
Great… don’t use include. See above reason.
I want to use Code-Behind.
Ted Patrick wrote a wonderful post on Code-Behind in Flex 2. He accomplishes Code-Behind, and does so in an object-oriented manner without using include statements.
Adobe doesn’t natively allow multiple inheritance in AS3, and using the include directive is the only way to fake it.
Frankly, if you understand that statement… you’re advanced enough to know what you’re doing, and you don’t need this tip.
== Conclusion ==
There are rare occasions where include is exactly what you need. However, if you still feel you have a valid reason to use the include directive on a regular basis, please leave a comment below and explain yourself.
Tip of the Day – When to use try… catch… finally
Jan 17th
A wise Adobean once told me to use try / catch / finally statements sparingly. It didn’t mean much to me at the time since I honestly don’t use them very often. Instead, I opt to check conditions prior to executing “at risk” statements.
So… here’s my advice that when it comes to try / catch statements.
Preventing errors from occurring is far better than generally handling them.
Take a look at this example.
var goodObj:Object = {foo: "bar"}; var badObj:Object = null; tryErrors(goodObj); tryErrors(badObj); function tryErrors(obj:Object):void { // DO THIS if(obj) trace(obj.foo); else trace("doing something else"); // NOT THIS try { trace(obj.foo); } catch (e:TypeError) { trace("error occurred"); } } /*** OUTPUT *************** bar bar doing something else error occurred ***************************/
Do not use blanket try / catch statements.
You gain nothing by catching an exception that your application can’t deal with at that point.
For example, if you’re trying to convert a string to a number, and you know it might fail, but you have a default value, you should catch the exception, set the default value, and allow execution to continue.
Another example, if you try to call a Web Service and the call fails, and that particular call isn’t critical to your application, you could catch the exception, warn the user that some information is not available, and continue execution.
Only use try / catch when you have to.
I don’t have any specific benchmarks, but I do know that using excessive try/catch statements will degrade performance of your flash application. Probably because Flash Player is single threaded, but an Adobe person would probably have more information on that than I do.
An application I worked on a while ago used a try catch block around every single function… not my fault, it’s code that I inherited… anyways, it’s performance and execution times were horrendous.
Tip of the Day – Tools of the freelancer
Jan 16th
So I ran across this blog post this morning, brought to us by themikej. He discusses some tools he uses in his everyday life as a freelance contractor.
Everything he mentions in this post I personally use, and he sums it up well.
So for today’s tip, I recommend reading it.
Oh… and I stole my blog theme from him.
Tip of the Day – Using Fireworks to skin those Flex Applications
Jan 15th
Today I was going to post about using flashvars and widget development. However, as I started to document the process, it became too much information for a single tip. So I’m going to do a separate post walking you through my widget development process. Now on to today’s tip!
To be honest with you guys, I’ve never really been a huge fan of Fireworks. I’m a Photoshop guy, and I have been since version 5.5 (hooray ImageReady). However, at our last SeaFlex meeting Marty gave a quick introduction into Flex skinning using Fireworks. My eyes were opened! So here is the basic run down of creating Flex skins using Fireworks CS4.
- Within Fireworks go to Commands > Flex Skinning > New Flex Skin
- Select the components you want to skin.
- Skin to your heart’s desire.
- When you’re finished, go to Commands > Flex Skinning > Export Flex Skin
- I created a new folder called testSkin and saved to that.
- Now in Flex Builder. File > Import > Skin Artwork
- Browse to the folder we just exported our assets to.
- Make sure the image to component mappings are correct.
- And…. you’re done.
Amazing.
:: UPDATE ::
Marty just posted a PC (and more in depth version) of the skinning your Flex applications with Fireworks. Read it here!
Tip of the Day – Widget personalization is important!
Jan 14th
Some people call it skinning, others call it customization, for this post we’re going to call it personalization. Having sat in many focus groups… I’ve learned this following pearl of wisdom.
Adding personalization to your widget is incredibly important.
Social Network users spend HOURS customizing their profile to… express themselves. If your widget doesn’t “gel” with their Dwight Schrute bobble head photo, then it’s not going to work for them.
But… what is personalization?
Take a look at Snapvine’s VoicePlayer skins page.
You’ll notice that the widget here has many different flavors or “skins”.
Your widget doesn’t have to be as complex as the Snapvine widget, and frankly it shouldn’t be. One corner that you can easily back yourself into is by making your skins so customizable, that it makes it difficult to add new features or UI components.
Imagine if you will, a widget that allows users to move any button they want, anywhere they want. Then later on, you want to add 3 new buttons to the interface. You have to go back through all of your skins and make the changes to all of them. If you have over 100 different skins that are unique, you have to change and test all of them. Not fun.
When your go down the path of TOO MUCH customization, the widget quickly becomes far too complex, and a burden to maintain. So use KISS methodology when dealing with personalization.
Here are some easy ways to add personalization:
- Allow an image path as a flashvar to be used as the background.
- Point to different external CSS files.
- Allow for colorization of components.
- Custom information – Name, tagline, etc…
Tomorrow’s tip I will discuss how to use flashvars for customized widget information.
