Maybe I’m not the sharpest tool in the toolbox, but it seems like every “security” related document I’ve ever read about Flash Player has been deliberately obfuscated to prevent ‘normal’ humans from understanding it. For instance, take a look at the example below regarding changes made to Flash Player 9.0.124 (image links to the article).
I had to read this sentence over several times before I felt like I understood the intent and I still wouldn’t stake much money on my interpretation. Even when drilling down and following the link it was several paragraphs before getting to what I believe is the salient point (its still not clear if I need to do anything if my web service doesn’t utilize request headers).
It’s absolutely insane that a security update to Flash Player that will ‘break’ existing content isn’t explained better. I’m not sure why concrete examples aren’t given that would help those not steeped in security lexicon understand the implications quickly and easily. For instance, it might be helpful to note that if you have a restful or SOAP web service (serves up xml) API which allows 3rd party content not hosted on your server to access the API, you’ll need to update your cross-domain policy file (at least this is what it seems like the the security bulletin is saying). I’m also assuming this effects all cross-domain data loading which means if you serve up JSON or AMF you’re impacted as well.
Yo Adobe, if you want to safeguard the reputation of Flash Player then you need to make this information a bit more friendly, clear and explicit–if only for obtuse folks like me. :)
I usually avoid nested functions (aka closures) like the plague. They just seem messy and there’s ample opportunity for memory waste. However, there are times when it makes perfect sense to use closures, such as when using them as event handlers for web service calls. Using closures makes understanding event flow, and therefore application logic, much, much easier. You don’t have to come up with unique names for a bunch of very similar methods and you eliminate scrolling all over the page to try and determine what happens when a web service call is made and a response is returned from the server.
Take a look at the image below. Notice how I’m registering an event listener and scoping it to a closure (nested function) within the method. When the asynchronous event is dispatched the mapped closure correctly catches the event and life proceeds beautifully. This is an example of closures and scoping working the way you would expect them to.
A couple of notes:
Lots of Adobe news lately and this time it’s the announcement of the Lightroom 2 public Beta available on Adobe Labs.
The first item to make an impact with me was the ‘getting started’ wizard you’re greeted by the first time you launch the application. Aimed at IUE (Initial User Experience), the getting started wizard is nothing new, but Adobe’s added a wrinkle — as you click through the wizard various elements described in the wizard are highlighted in the actual interface. It’s common to see lots of videos and written guides thrown at the user, so it’s nice to see the wizard be actually integrated within the projects. As a user I feel much more connected to the software and there’s no disjointing experience of having to switch between apps to view the IUE information.
Tight hooks into the application in order to provide IUE is something that Adobe’s latest efforts have put a lot of work into. Photoshop CS3 provides a ‘workspace’ which highlights elements that are new with the application as you work in it.
The other thing that jumped out at me was the location of the tools when in the ‘Develop’ module.
It’s way too late for me to stay up and play more, but John Nack gives the full run down on what’s new and improved.
I’m not exactly sure why, but MXML kind of gives me a sickly sweet feeling. You know, the feeling you get from watching something that’s terrible, but beautiful (i.e. boxing). I really dig being able to lay out simple forms with a WYSIWYG editor, but I haven’t found too many cases where I can slide by with just MXML (ignorance on my part I’m sure) and that’s where the funk begins.
Here’s a short video (13 seconds) illustrating how to implement an interface in an MXML component.
Is it just me, or does it feel like the interface implementation should be a compiler directive set via metadata rather than a property? Having an ‘implements’ property in the markup is easy, but it somehow feels unnatural to me to be setting properties, binding variables and also setting compiler directives. I’ve come quite a ways with MXML over that last few months — my reaction has gone from alien to uneasy acceptance, but never to nirvana (I feel the same way about XAML — it’s seems awfully messy once you move beyond simple layout).
In the next example I have a custom MXML ViewStack component that contains a number of Canvas components (individual containers whose z-index is controlled by the ViewStack). A Dissolve transition object is also being declared and then bound to the showEffect trigger of each Canvas. Each time the view is reordered by the ViewStack the trigger fires and uses the Dissolve object to perform a tranistion.
Here’s the end result of this simple MXML effects binding. Click on the buttons to see the transition performed each time the ViewStack is reordered. Yah, yah, yah — the button bar is a bit long, but writing a custom extension that will allow multiple rows of buttons will have to wait for another day.
All of this fancy MXML coding is ultra cool, but it also hurts my ActionScript soul a bit; mind you, not enough to not bitch ferociously if you try to take it away from me. :)
Jing is absolutely brilliant when it comes to recording and sharing media hosted on Screencast.com, but its ftp output enables some incredibly powerful, customized experiences. Unfortunately, ftp support is extremely rough around the edges making it not all that accessible for the layman. This post aims to change all that by providing a complete example implementation of customized ftp output.
First we need to take care of the basics and configure Jing’s ftp server preferences and ftp code templates (Jing–>More–>Preferences–>FTP).
You can think of the code templates as providing a blueprint of where files will exist on the server. Jing uses these blueprints to create the urls and embed code it returns to your clipboard when you push the ‘share’ or ‘embed’ buttons after recording. The blueprints use several tokens which allow Jing to insert the correct file name and dimensions in each url or embed phrase.
Now you might be looking at the embed code in the image above and thinking it looks a bit strange — that’s because it is. I happen to use the Kimili plugin for WordPress to embed Flash content within my blog and it uses a special syntax. Notice that Jing doesn’t care, you can create pretty much any specialized syntax you want . No worries though, here’s some ‘actual’ embed code like you might get from YouTube or Screencast.com.
Whew, we’re finally through the basic configuration, but there are a few pieces missing. You see, in the embed code template example above an additional file not provided by Jing is referenced which is an absolute must when embedding videos in your blogs. I call this additional file a “click to play” loader. Its a small swf file (8 KB) which is embedded in your blog (any web page really) that serves as a placeholder for your Jing video.
Why is this important? Well, embedding Jing videos directly in your blog means that every time someone visits your page that video (often MB’s of data) will be loaded up, regardless of whether the visitor actually watches the video. That’s not very nice for visitors or for your bandwidth, so instead we’ll embed a small placeholder with a ‘play’ button which, when clicked, will load the video. The placeholder takes up the same space and position as the actual video so your page layout will still look fine and the play button clues people in to the fact there’s a video sitting there waiting for them.
Here’s a link to a zip file containing the ‘click to play’ swf file. You’ll need to download it, unzip it, and then use an ftp client to upload the swf to the directory where your Jing videos are being uploaded. Now you just need to configure your embed code template (see examples above) and you’re all set. Blogging Jing videos is now just a matter of recording your video, hitting the ‘embed’ button and pasting the returned embed code into your blog’s rich text editor.
Here’s an example of the results.
Aren’t happy with the provided ‘click to play’ swf and have moderate Flash skills? You’re in luck–I’m making the source code available so you have complete control over the embed experience within your blog / site.
Hope this helps. Let me know you’re taking advantage or this or another custom Jing FTP solution.
Being awake and trawling the web at 3 AM sometimes means you get an early jump on tomorrow’s big announcements. Here’s a snapshot of the Photoshop Express uploader. Great workflow with a sophisticated and understated UI. I dig it, MUCHO.
Looks like they will be using a tiered model with a free basic version and a paid premium version that unlocks more features. You can really start to see the impact of the Adobe / Macromedia aquisition with these web based products. Looks like 3+ billion dollars gets you Flash Player and sweet ass web based versions of your products.
I made a couple of Jing’s of my first stumble through the application. These are really only useful if you don’t want to sign up, but want to check out the ui and workflow. If you’re an Adobe user experience guru you also might be interested in watching someone pop their cherry. There’s no audio so scrub away.
Here’s the end result.