Archive for the ‘Flash’ Category

oliverm

Flex Camp Roundup

Friday, June 25th, 2010

June 25, 2010

On June 10th, 2010 we hosted the third Toronto Flex Camp. Ed Van Beilen and myself are co-managers of the Toronto Flex User Group, which is in its fourth year and sporting over 1000 members in the GTA.

Unlike previous camps, this year’s event included hands-on sessions and spanned a full afternoon and evening. We were fortunate enough to have two Adobe representatives (Lee Brimelow and Renaun Erickson) lead several sessions, including the keynote. We also had a few people from our local Flex User Group step up and present: Jason Broughton, Andrew Rybak, Clement Wong and Derek Santos.

In presenting this event, we learned a few lessons and gathered some interesting statistics that I’d like to share.

Significantly, this is the first time we’ve charged for entry into a Toronto Flex Camp. To our delight, we did not receive a single complaint about the $25 CAD entry fee. By charging this nominal fee, we were able to increase the quality of the venues and catered fare.

Financially, we did a bit better than break even. This small surplus will be used to offset the costs of future regular meetings, which New Toronto Group has traditionally absorbed.

The Numbers

Of the 120 people who registered on the site, 112 completed the payment process.

Of the 112 paid registrants, 83 showed up, and we had 2 additional registrations at the door (despite our pleas that people register in advance) for a total of 85 attendees (76%).

Out of the 85 attendees, 61% filled out the survey and qualified to be in the prize draw.

Speaking of the survey, here’s how you rated the event:

  • Quality of the presentations: 82%

  • Usefulness of the event: 76%

  • Overall quality of the event: 83%

  • Would attend another Flex Camp: 94%

Looks like we did fairly well with the new format. That last number is probably the most important for us as we look at the feasibility of future Flex Camps.

Your Feedback

Everyone seemed pleased with the venue and location, but we definitely needed more signage to direct people to the various venues. Thanks again to Brian Lesser and the folks at Ryerson for their invaluable help.

You also gave us some valuable feedback about the sessions themselves.

Foremost in the comments we received was to have more sessions, especially hands-on. Of course, the challenge is to find enough session leaders, so we may be pushing the local Flex community to help out more in the future.

Many of you also asked that the sessions be shorter in duration, perhaps limited to an hour. No argument here; just a matter of getting enough speakers to fill all those hours;)

We seem to have struck a good balance between introductory and advanced topics. Like in politics, you know you’ve done the right thing if an equal number of people on both sides complain. In our case, we had just as many people comment that they wanted more fundamental topics as those that wanted more advanced ones.

Looking Forward

One surprise we had in the Management Session (led by Andrew and me) was the intense interest in mobile. In fact, about three slides into our RIA presentation we decided to completely change gears and focus the discussion on the upcoming Flash/mobile releases. No doubt that there will be more mobile content in future meetings.

Overall, Flex Camp 3 Toronto was a great success and we look forward to doing another one in the future. Please check the Toronto Flex User Group website for Fall meeting announcements and job postings at http://www.torontoflex.org. And if you’d like to lead a future session or have an idea for a meeting topic, please contact Ed or me via the link on the site.

Finally, thanks to all who attended and gave us such encouraging feedback.

See you in the Fall!

June 25, 2010

Flex Camp Roundup

On June 10th, 2010 we hosted the third Toronto Flex Camp. Ed Van Beilen and myself are co-managers of the Toronto Flex User Group, which is in its fourth year and sporting over 1000 members in the GTA.

Unlike previous camps, this year’s event included hands-on sessions and spanned a full afternoon and evening. We were fortunate enough to have two Adobe representatives (Lee Brimelow and Renaun Erickson) lead several sessions, including the keynote. We also had a few people from our local Flex User Group step up and present: Jason Broughton, Andrew Rybak, Clement Wong and Derek Santos.

In presenting this event, we learned a few lessons and gathered some interesting statistics that I’d like to share.

Significantly, this is the first time we’ve charged for entry into a Toronto Flex Camp. To our delight, we did not receive a single complaint about the $25 CAD entry fee. By charging this nominal fee, we were able to increase the quality of the venues and catered fare.

Financially, we did a bit better than break even. This small surplus will be used to offset the costs of future regular meetings, which New Toronto Group has traditionally absorbed.

The Numbers

Of the 120 people who registered on the site, 112 completed the payment process.

Of the 112 paid registrants, 83 showed up, and we had 2 additional registrations at the door (despite our pleas that people register in advance) for a total of 85 attendees (76%).

Out of the 85 attendees, 61% filled out the survey and qualified to be in the prize draw.

Speaking of the survey, here’s how you rated the event:

  • Quality of the presentations: 82%

  • Usefulness of the event: 76%

  • Overall quality of the event: 83%

  • Would attend another Flex Camp: 94%

Looks like we did fairly well with the new format. That last number is probably the most important for us as we look at the feasibility of future Flex Camps.

Your Feedback

Everyone seemed pleased with the venue and location, but we definitely needed more signage to direct people to the various venues. Thanks again to Brian Lesser and the folks at Ryerson for their invaluable help.

You also gave us some valuable feedback about the sessions themselves.

Foremost in the comments we received was to have more sessions, especially hands-on. Of course, the challenge is to find enough session leaders, so we may be pushing the local Flex community to help out more in the future.

Many of you also asked that the sessions be shorter in duration, perhaps limited to an hour. No argument here; just a matter of getting enough speakers to fill all those hours;)

We seem to have struck a good balance between introductory and advanced topics. Like in politics, you know you’ve done the right thing if an equal number of people on both sides complain. In our case, we had just as many people comment that they wanted more fundamental topics as those that wanted more advanced ones.

Looking Forward

One surprise we had in the Management Session (led by Andrew and me) was the intense interest in mobile. In fact, about three slides into our RIA presentation we decided to completely change gears and focus the discussion on the upcoming Flash/mobile releases. No doubt that there will be more mobile content in future meetings.

Overall, Flex Camp 3 Toronto was a great success and we look forward to doing another one in the future. Please check the Toronto Flex User Group website for Fall meeting announcements and job postings at http://www.torontoflex.org. And if you’d like to lead a future session or have an idea for a meeting topic, please contact Ed or me via the link on the site.

Finally, thanks to all who attended and gave us such encouraging feedback.

See you in the Fall!

alaint

Let’s not forget about the projector!

Friday, April 16th, 2010

By Alain Thibodeau – Consultant

No, I am not talking about the projector for your next meeting, but the Flash projector. A Flash projector allows a user to view the flash content on their local computer instead of in a browser. It seems that with the coming of Flex and Air, the Flash projector has taken the back seat. But, there are some times when creating a projector is a good option. Projectors are platform dependent and can be published from the Flash IDE for PC or MAC.

In the Flash IDE you specify to export a projector in the publish settings and click publish.

export

If you don’t have the Flash IDE and work in Flex, you can also create a projector. Assuming you have the flash player installed on your computer, double click on your SWF file then select the file menu and Create Projector. Give your projector a filename and click the save button.

export2

Projector options are set using fscommand and allow you to create full screen projectors and adjust scaling for example. You can use fscommands in your Flex or Flash code. For more information about fscommand and what it can do, read up on the docs here.

Chad Upton

How to Convert XMLList to XMLListCollection in Flex

Saturday, March 27th, 2010

By Chad Upton – Senior Consultant

Massaging data is an important part of many client applications, especially if you don’t have control over the server side.

If you want to convert an XMLList to an XMLListCollection in ActionScript, try this:

var myCollection:XMLListCollection = new XMLListCollection(myXMLList);

It is very important that you call the constructor. If you omit the new keyword, this will not work!

oliverm

What’s New in Flex 4 – Part I

Thursday, February 18th, 2010

By Oliver Merk, Principal Consultant

Adobe’s Flex 4 platform and tools are expected to be released in the first half of 2010.

Of note:

  1. Flex Builder has been re-christened Flash Builder to promote the Flash platform.

  2. The Flex SDK has been turned on its head with the introduction of the Spark component set; skinning will never be the same (thank goodness!).

  3. A new product called Flash Catalyst CS5 will finally give designers a chance to realize their creations within the Flex framework.

In this entry, I’ll start with the theme that will have the most impact on everyone on the typical RIA team.

Designer/Developer Workflow

Adobe Flash Catalyst joins Photoshop, Illustrator and Fireworks in the RIA designer’s toolbox.

Originally a lot of us Flex developers got very excited when this new product was announced as Thermo back at Adobe MAX 2007 in Chicago. But Catalyst is distinctly not aimed at Flex application development as you might currently understand it.

Rather, Catalyst allows designers to do three critical things, which I’ll detail below:

  1. Easily import assets from the above mentioned applications for use in a Flex/AIR application.

  2. Quickly prototype an application for demonstration purposes.

  3. Create fully skinned components which can be delivered to a Flex developer for integration into a working application.

Let’s dig into these a bit further.

What the FXG!

Most professional designers work in Photoshop, Illustrator or the two in combination. Being Adobe products, it’s not hard to guess that the integration between Catalyst and these stalwarts is tight.

With Catalyst, designers tasked with creating Flex application GUIs can begin where they’re comfortable, in Photoshop, Illustrator or, my personal favorite, Fireworks.

The native formats of these programs will be importable into Catalyst as a library of assets. Files such as .PSD, .AI and .PNG can not only be imported into Catalyst, but their layers will be maintained as well.

Now the first question an astute designer will ask is, what if I want to go back to Photoshop and tweak my artwork?

Known as round-tripping, this feature is already incorporated into the latest beta builds of Catalyst. Right within Catalyst, the designer will choose to edit an asset and the appropriate program will open with the artwork ready to edit. Upon saving, the designer returns to Catalyst, which has remained open, and sees the changes immediately on screen.

But there’s another way to move assets around: using the new FXG file format.

This new format is similar to the well-intentioned Open Source SVG format we’ve heard about for many years. FXG is an archive format which contains all the information (MXML code and binary assets) required to import and export Flex components and assets using Photoshop, Illustrator, Fireworks, Catalyst. The new Flash Builder 4 can also open FXG files as imported projects.

Show me!

One of the greatest challenges in creating RIAs for clients is getting them to visualize what the completed application might look like. Currently, your options include using Flex Builder’s design mode (still hard to apply complex skinning) or mocking up something in Open Office Impress or the ubiquitous Powerpoint, which are never very accurate.

With Catalyst, designers will be able to quickly prototype not only the visual aspects of the application, but most of its behavior as well. For example, lists can be skinned and populated with temporary data, with minimal effort, so that a client can see the component as it will appear in the final application.

In fact, Catalyst is so easy to use that I wonder how long it will be before sales people realize that they can use it to help clients visualize an application and close the deal a lot quicker. I recommend Catalyst as a sales and marketing tool for those who are tasked with demonstrating the power of RIAs to potential customers but don’t have the time or resources to enlist a designer or developer to create a mock-up.

What About Us Programmers?

I said earlier that Catalyst is not a hard core developer tool and is clearly geared towards developers.

However, it will still make developers’ lives easier in several ways:

  1. For those tasked with implementing a design and given a Photoshop file, Catalyst will make short work of converting the original artwork into usable components which can be imported into Flash Builder. If you’re a Flex developer who does a lot of design implementation, Catalyst will be a game-changer for you.

  2. Catalyst gives the designer the tools to define not only the skin, but the behavioral characteristics of components. Separate components can be composed in Catalyst and delivered to the developer for integration into a Flex or AIR application. These components can be delivered as FXGs or as SWC libraries.

Here’s another great reason to check out Catalyst. I could argue that the new Flex 4 SDK is almost a whole new platform compared to Flex 3. There’s going to be a learning curve when you first try to grasp how components are composed and while investigating all the cool new features in this release. Because Catalyst generates MXML code, a developer could study this as a good introduction to how things will fit together in the new framework.

Smells good! Is it baked yet?

Catalyst is in its late beta stage and is likely to be released in the first half of 2010. While round-tripping between Catalyst and the graphics applications is almost complete, the round trip between Catalyst and Flash Builder may have to wait for a point upgrade; though I really hope they get it in for the first release.

But that shouldn’t stop you from downloading the latest beta and checking out Catalyst for yourself. You can learn more about it and download a beta from http://labs.adobe.com/technologies/flashcatalyst/.

Have fun!

Adobe Flash Catalyst Beta

Adobe Flash Catalyst Beta

Chad Upton

Secret Key Encryption Options in the as3crypto Library

Monday, February 15th, 2010

Written By: Chad Upton

The as3crypto library is an open source ActionScript 3 encryption library available from google code.

In an earlier post I demonstrated how to take plaintext and encrypt it into an unreadable file, then decrypt it so you could read it again. This is very useful in Flash or Flex projects where you need to hide data from the user, either because it’s sensitive information such as software licenses or personal info, or because tampering with it could cause your application to function incorrectly (ex. application settings).

In that post, I used the AES encryption algorithm but I promised a future post that talked about why. In this post, I want to revisit the secret key encryption choices in as3crypto, breaking down the choices, their strengths and weaknesses.

This guide should be used for general knowledge or to narrow down encryption methods you should consider for your project. Before making a final decision, you should deeply investigate that method to ensure it is right for your implementation.

In as3crypto, the secret key encryption choices are DES, 3DES, RC4, XTEA, AES and BlowFish.

DES

DES stands for “Data Encryption Standard.” It was developed to improve the security of US government computer systems and was completed in 1974. It has a fairly short key at 56 effective bits (8 of the 64 bits are used as a checksum and not encryption). Many encryption methods have been developed since then; it is the second fastest compared to other methods in as3crypto but it has a large number of vulnerabilities.

It should not be used unless absolutely necessary for legacy support, even then you should be considering migration to a modern cipher. As an interesting side note, there are also rumors of an NSA backdoor in this algorithm.

3DES

3DES, or “triple DES”, was developed in the late 90s as a simple way to make DES stronger and more resistant to brute force attacks (trying every possible key). It’s called “3DES” because it applies the DES algorithm three times. As you can probably guess, it’s about three times slower than DES. It does provide more security, but it’s not an ideal choice when considering what else is available. It may be required to support legacy systems.

RC4

RC4 is a fairly modern and widely used cipher method. It was developed in 1987 by Ron Rivest of RSA security (RC4 stands for “Rivest Cipher 4”). Many of you probably use this cipher everyday without realizing it. Secure website (SSL) certificates use this cipher and some wifi encryption systems use it too. It is not without its share of weaknesses, especially in certain implementations. For that reason, it has been completely deprecated by some platforms, including Microsoft .NET.

When implemented correctly, RC4 can offer a fair amount of security but there are better options available in most cases. That said, there is one case where it should at least be considered: when you have tens of megabytes of data or more to encrypt. RC4 is by far the fastest cipher method in the as3crypto library. It is about 4.5 times faster than Blowfish (third fastest in library), but keep in mind it is slightly less secure than Blowfish.

XTEA

XTEA has fewer vulnerabilities than RC4, so it is slightly more secure. But, this is the slowest encryption method in the as3crypto library. Frankly, the only case where I could see this being used in ActionScript is when you’re interacting with other systems that use XTEA encryption. If you’re developing a new system, choose one of the following methods.

AES

AES is one of the best general purpose secret key encryption methods in as3crypto. Like I mentioned above, there may be cases where another method is more appropriate, but AES is going to be the method of choice in many cases, particularly because many other systems that your application may interact with will use it.

It has a lot of credibility because it is the standard encryption used by the US government and the first publically available cipher approved by the NSA. It is fast and secure, although it does have some known weaknesses that can usually be protected by prevented brute force attacks. This method should not be overlooked.

Blowfish

Blowfish was developed in 1993 by Bruce Schneier, who has developed many other cryptographic algorithms, written several articles and books on security, and also publishes a free monthly security newsletter called CRYTPO-GRAM, which I subscribe to and recommend.

In as3crypto, Blowfish 256 performs more than twice as fast as AES 256. It is also capable of using a 448 bit key, although the as3crypto implementation uses a 256 bit key. When compared to AES 256, Blowfish gives you slightly better security since it has no known cryptanalysis. It’s may not be as widely used as AES, but for great speed and security, it should not be overlooked. For many projects, this is an excellent choice of encryption.

Conclusion

If you don’t have any legacy system requirements, you should start by looking at Blowfish or AES encryption. One of these is likely going to meet your requirements, especially if you’re working with less than a megabyte of data. With large amounts of data these two may be too slow, so be sure to look at RC4 in more detail — it’s really fast. All of the others are likely going to be used because you’re working with a legacy system that requires them.