RIA Developer, Flex / Flash, Widgets
Posts tagged Adobe
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 – 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!
Tour de Flex… It’s no rubygems, but it’s a start.
Jan 13th
Mike Chambers has a blog post asking, “How can adobe make the as3 learning curve easier”?
As I talked about in my Why YOU should contribute to Flex post, Adobe wants our input. Here they are again asking the community, “What do you think”?
I commented on Mike’s post.
I think that a more centralized component library and delivery system would make the lives of many developers much easier.
Take RubyGems for example. It’s extremely easy for developers to benefit from the work of others. This has increased the value of Ruby in my eyes tenfold.
As a developer, there isn’t a uniform place that I can go check to see if someone has done this before. So I have to scour the net for a while trying to find a solution by looking through blogs, articles, googlecode, etc…
I know there are a few places out there that make this easier. RIAForge, Adobe Developer Connection, Project Sprouts, Adobe TV, flexcoders.
Most of these sites (blogs especially), have a way to externally interact with them. I think that an Adobe sponsored site or program that would allow a developer to quickly see what’s out there would be an amazing asset to brand new ActionScript developer and veterans alike.
However, I didn’t realize until now, that Adobe is already doing this. This dream “site or program” does exist as the Tour de Flex. Which if you haven’t installed yet, I highly recommend it.
As the title of this post says, it’s no rubygems (not yet anyways)… but it’s a start. Go Adobe!
Tip of the Day – Using the libs directory in Flex Builder
Jan 11th
This tip I’m stealing from Amy over on the flexcoders list.
One not so well documented feature of Flex Builder is the use of the libs directory. By default, when you create a new Flex Project, a libs directory is created. So say for example, you want to create a project, and you are planning to use the Cairngorm framework.
All you need to do is copy Cairngorm.swc into your libs directory, and you’re good to go.
ColdFusion – Let’s be honest here
Jan 9th
This morning when I woke up and opened up Google reader, I ran across this post by Aral Balkan. Nothing sparks an argument more than telling a group of developers that they’re platform is headed the way of Davy Jones locker.
After reading his post, and then the comments. I really started thinking about where ColdFusion fits into my development career today.
I started programming in ColdFusion back in 2003, using version 6.0. For a long time ColdFusion has been my language of choice. I’ve developed applications for quite a few companies using ColdFusion including Knight Transportation and Boeing.
Don’t get me wrong, I love ColdFusion! But recently I’ve found myself opting for other server side language options, particularly Ruby and PHP.
Hosting a ColdFusion project requires a significant investment, whether you are purchasing a ColdFusion license or using a hosting provider. I was paying for a ColdFusion VPS over at HostMySite.com. Which I unfortunately had to get rid of due to HostMySite’s inability to keep my server running.
I then learned that there aren’t really a lot of quality ColdFusion hosting options available out there. Which means that if I want to deploy a ColdFusion site, I pretty much need to put my own servers up somewhere, in addition to purchasing a ColdFusion license.
What I think Adobe should consider doing is setting up a licensing tier much like they did with Flex. Back when Flex was in it’s infancy, it was packaged as a single server product, with a price tag around $15,000 per CPU. Flex’s adoption of version 1 and 1.5 was very poor. It wasn’t until Adobe started giving away the Flex SDK did developers really get on board with it.
So why not do the same thing with ColdFusion? Heck, there is already a watered down version of LiveCycle which Adobe has open sourced, BlazeDS. Why not give us an open source server solution for ColdFusion?
There is no doubt in my mind that ColdFusion is still alive and kicking. It screams to be used within corporate environments, and it’s integration with Flash / Flex is second to none. But outside of the enterprise / corporate market, I don’t see much use for it anymore unless they changed how it is licensed.
Widget development on the Flash Platform
Jan 2nd
An interesting conversation has been happening for a while over on flexcoders. The conversation started with a simple question… Whether or not using the Flex framework is a good idea when developing widgets.
First a little background about me.
A little while back, I worked for a small startup named Snapvine. Snapvine currently has many widget offerings, one of which still gets loaded millions of times each week. These widgets are deployed across hundreds of social networks (who knew there were so many). As the lone flash developer in the company, it was my job was to create and maintain all of these widgets.
The great thing about Snapvine was that I was surrounded by brilliant people, we discussed the Flex framework in extraordinary detail, weighing the pros and cons of using such a framework in our widgets.
So that brings me to the whole point of this blog post… pros and cons for building widgets for the Adobe Flash Platform using Flex.
[Sidenote]
My experience in widget development was mostly focused on development for social networks, so I might say some things that may not apply to other types of widget development.
[/Sidenote]
– Pros –
Flex does a lot of the work for you
Flex does so much of the heavy lifting for us. If you’re ever bored, skim through the Flex documentation. It’s not uncommon for me to find things within the framework I didn’t know existed.
Also, If you haven’t already done so, I highly recommend picking up the O’Reilly Flex 3 Cookbook, or thumbing through it at your local bookstore. I’ve found some really great things in there that I didn’t know about the Flex Framework.
Flex allows quicker development time because there is less code YOU have to write.
Once again, Thanks Adobe… for doing my work for me.
RSLs decrease frequent loading time
The use of Adobe’s Runtime Shared Library significantly reduces multiple loads of your widget. This is because parts of the Flex Framework become cached inside the Flash Player itself. One of the big benefits of the framework RSLs is that not only your widget benefit from them. The framework is cached the first time ANY Flex content, on any site, using framework RSLs is loaded.
One caveat to Runtime Shared Libraries is that you have to configure your widget to utilize them during compilation. They don’t just get used magically. This also means that when you deploy the widget on your web server, you need to also upload and distribute the RSLs.
So if a user visits Picnik, which uses the Flex framework RSLs. Then the user visits a myspace profile page with your widget on it, they wouldn’t download the framework RSLs again (if you and picnik.com are using the same version of the SDK).
Myspace wants users to use Flash Player 9 and above
A while back Adobe and MySpace scratched each other’s back a little bit. Adobe added support for MySpace to disallow navigation events from flash widgets (allowNetworking=”internal”), and MySpace in turn highly recommend users to upgrade to Flash Player 9 (I’m pretty sure they also did this for the video support in Flash Player 9). Myspace did this by prompting users to update their Flash Player if they detected version 8 and below.
That’s a BIG pro for us widget developers, because that means the majority of our widget market is using a player with loads of the features we know and love. At the time of this writing, I’m unsure if MySpace is pushing Flash Player 10, I haven’t noticed it yet.
[Rant]
I’m currently writing this post aboard an airplane at 33,000 feet. Would the person who keeps passing gas, please knock it off, this is an enclosed air system for heaven’s sake.
[/Rant]
– Cons –
Flex is huge, comparatively
300 KB is still too big for dial-up. Many people argue that if people are using MySpace on dial-up, that they’re used to slow loading times. It’s not uncommon for a MySpace profile to be littered with hundreds of 100 KB photos, music, etc… However, that brings me to one of my main points.
By keeping your widget small, It’s more than likely going to load prior to other things on the profile. This is key for getting your brand out there. In Snapvine’s case, this meant that before pictures of friends, before the music players, before the slideshows… Snapvine’s logo was spinning on the page.
Bandwidth is expensive
If your goal if for your widget to go viral, bandwidth is something you should consider. It is bandwidth which drives how much money you are going to spend.
This calculator estimates how much it would cost if you were hosting your widget on Amazon S3 (US).
If you want a direct link… Widget Bandwidth Calculator
If you are curious, you can view the source.
Why is this a con? Using the Flex framework bloats a swf’s file size, and ultimately costs you more money, even if you are using Runtime Shared Libraries.
A simple application which is JUST a combo box, is still 56 KB, even when using Runtime Shared Libraries.
Flex was built primarily for Enterprise Development
This means that lots of the components within the framework, are pretty much useless within widgets. For example, using a datagrid to show massive amounts of data… not really a good use for a widget.
Remember, we’re talking about widgets, not about widgapplications (my spellcheck doesn’t like that word). Most widgets are fairly simple apps. Examples – a music player, slideshow, awesome video slideshow, small game, etc…
Keep your widget fairly simple, if it begins to become too complex, you should probably ask yourself, “Should I be building a 3rd party application (OpenSocial or FBML) instead of a widget?”
It’s hard to selectively use pieces of Flex
I’m not going to say that it is impossible, but loads of classes in the Flex framework are dependent upon each other. Which means that if you’re going to use one Flex class within your widget, it will import ALL of it’s dependencies, whether you use them or not.
– Nate’s opinion –
If I’m building a widget whose soul purpose is to go viral and be loaded millions of times a day, I’m going to write it in straight ActionScript.
Sure, it will take a bit more time, but in the end I’ll save money, have more granular control over my widget, and feel good about myself.
