Posts Tagged ‘xml’

Fixing as3syndicationlib

Posted in Article, as3syndicationlib, Bugs, Downloads, Flash, Libraries on July 2nd, 2010 by Ian Ford – Be the first to comment

Perhaps you, like me, have had a need, at some point or another, to parse RSS feeds in Actionscript. If so, then perhaps you’ve also stumbled across the generally wonderful as3syndicationlib developed by Mike Chambers and Christian Cantrell. For those of you who aren’t in the know, allow me to provide the following excerpt from the project’s google code page:

Use the syndication library to parse Atom and all versions of RSS easily. This library hides the differences between the formats so you can parse any type of feed without having to know what kind of feed it is.

These claims actually hold up pretty well…once you get the code running.

The problem is that the codebase was written specifically for development in Flex. While Flex is a great platform for certain projects, many of us still use Flash for a lot of the work we do, so a toolkit that relies on packages that are only available to Flex just doesn’t do it.

This problem is also no secret. It’s listed as an accepted issue on its project page. The problem is that the codebase apparently hasn’t been updated since December of 2006.  That’s no joke kids.

Fortunately, a solution was pushed forth from outside the project by a Mr. Martin Legris in the form of a bare implementation of the missing “DateBase” class that the syndication library looks for, as well as an edit to an import statement buried down in ParsingTools.as.

So if you, like me, have a need to consume RSS/Atom Feeds in Flash and need a solution that works, look no further. I present, to you, an updated version of the as3 syndication library with the necessary changes in place to begin using it out of the box in your flash projects.

The files are all available here.

Bugs and Quirks: SWFStudio 3.7 and Windows 7

Posted in Article, Bugs, Downloads, SWF Studio on March 27th, 2010 by Ian Ford – 3 Comments

I spent the last week or so developing a kiosk application for a client that had to prevent users from exiting the application using ctrl+alt+delete, alt+f4, or any other such method.

Because I had worked with it in the past for a similar project, I advised the client that we could use Northcode’s SWFStudio to lock the application down and to record registration data without requiring an internet connection. This should have all been very simple. Create the application, load up SWFStudio, and convert my final SWF to an EXE with all the parameters configured.

In practice things weren’t so simple. You wouldn’t know this unless you dug around, but SWFStudio 3.7 doesn’t play nicely with Windows 7, and for the $300 licensing fee you’d hope they would take the trouble to make this point more prominent. To give you an idea of this problem, I’d like to demonstrate the sequence of steps you need to complete to figure out why your perfectly functional kiosk craps out after you push it through SWFStudio.


Step 1

First, you have to go to Northcode’s website. When you get there, click on the “swf studio” link at the top of the page. Don’t click “blog” and whatever you do, don’t click “support.”


Step 2

Once you get to the “swf studio” page, click to continue reading the article on making your applications work with Windows 7. Don’t bother with the “Known Problems” link in the side bar, as even though they thought to post an article about the issue (separate from their blog and their support page no less), it’s not a problem they’re aware of.


Step 3

You’re almost done! You’ve found the document explaining how to fix your problems in Windows 7. Of course, there’s no patch or software update. You have to copy the grayed out text above into a panel in SWF Studio to get everything functioning properly.

What makes me even angrier about this is the text of the article. The summary, shown in step 2, contains the following text:

Windows 7 adds support for a new section in your application manifests called Compatibility and if you want your SWF Studio applications to behave properly on Windows 7 then you’d better pay attention!

They even use an exclamation mark! I’d better pay attention if I expect their $300 application to function correctly. That might even be ok if they displayed the information prominently on their homepage, or in any of the sections you’d expect it to be in. To give you an idea of how poorly placed this content is, as I was sitting down to write this post it took me 15 minutes digging around their site to find the document in question again.

For my own satisfaction, and for the sake of anybody else who runs into problems with this software, I’ve taken the following liberties:

  1. I’m offering this code to you below so there’s a second place to find it if anybody ever needs it.
  2. I’m offering this code for download so you can keep your own copy if need be.
  3. I’m recommending a slight redesign to Northcode’s home page.

The code looks like this.

<br><br>&lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;<br><br>&lt;assembly  xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"&gt;<br><br> &lt;assemblyIdentity  version="1.0.0.0" processorArchitecture="X86" name="stub.exe"  type="win32" /&gt;<br><br> &lt;description&gt;stub&lt;/description&gt;<br><br> &lt;dependency&gt;<br> &lt;dependentAssembly&gt;<br> &lt;assemblyIdentity<br> type="win32"<br> name="Microsoft.Windows.Common-Controls"<br> version="6.0.0.0"<br> processorArchitecture="X86"<br> publicKeyToken="6595b64144ccf1df"<br> language="*" /&gt;<br> &lt;/dependentAssembly&gt;<br> &lt;/dependency&gt;<br><br> &lt;trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"&gt;<br> &lt;security&gt;<br> &lt;requestedPrivileges&gt;<br> &lt;requestedExecutionLevel  level="asInvoker" uiAccess="false"/&gt;<br> &lt;/requestedPrivileges&gt;<br> &lt;/security&gt;<br> &lt;/trustInfo&gt;<br><br> &lt;compatibility  xmlns="urn:schemas-microsoft-com:compatibility.v1"&gt;<br> &lt;application&gt;<br> &lt;!-- the ID below indicates the application supports Windows 7  --&gt;<br> &lt;supportedOS  Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/&gt;<br> &lt;/application&gt;<br> &lt;/compatibility&gt;<br><br>&lt;/assembly&gt;<br><br>

You can download a file with this information here: SWF Studio Manifest for Windows 7 Projects

And my suggestion for a redesign of Northcode’s homepage is below.


The Corrected Northcode.com!

Bugs and Quirks – Path Resolution Inconsistencies

Posted in Article, Bugs, Documentation, Flash, Tips on February 26th, 2010 by Ian Ford – Be the first to comment

So, I thought I’d bring attention to a strange inconsistency I run into on a very regular basis while developing applications in Adobe Flash.

Much of the work that I do in flash has to do with displaying and managing video. To date, I have probably created at least 50 different playlist enabled video players, by which I mean video players with a list of either links, thumbnails, or both that allow you to play other videos in the same container without leaving the page. For example, something like this…


A Generic Video Player


…with a playlist that allows you to select other videos, like this…


Video Player with Playlist


This is all well and good. Because I try to build in a way that’s generalized for client accessibility and ease-of-use (and because I don’t want to be solely responsible for updating these things myself), the standard way to go about creating something like this would be to have an external XML document that contains all of the information required to build the playlist. The application is responsible for loading that document and extracting that information from it, which it uses to build a clickable, interactive playlist. This is all quite simple. The XML could look something like this:

<playlist>
	<item>
		<uid>1</uid>
		<title>Video 1</title>
		<video>PATH TO VIDEO</video>
		<thumbnail>Image for video</thumbnail>
	</item>
	<item>
		<uid>2</uid>
		<title>Video 2</title>
		<video>PATH TO VIDEO</video>
		<thumbnail>Image for video</thumbnail>
	</item>
	<!-- and on, and on, and on -->
</playlist>

The folder structure for such an application could (and would) conceivably look like this:


FLA Folder



Within our document root, we have an FLA folder to hold our source files.

FLV Folder



We have an FLV folder for holding video assets.

SWF Folder



We have a SWF folder for holding all of our compiled application SWFs.

XML Folder



And finally we have an XML folder for holding any XML documents we’ll be loading in the application. The index file resides in the document root.

Here’s where things get screwy.

In my application, when I’m ready to load my external XML in order to build a playlist, my code will look like this:

var req:URLRequest = new URLRequest("xml/playlist.xml");
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, _playlistHandle, false, 0, true);
loader.load(req);

After I’ve loaded my playlist, suppose I want to play the first video. For the sake of brevity, we will suppose that I have an instance of a video player class that will allow me to simply pass the path to the FLV in to begin playing it, and that it’s already been instantiated and configured under the name “_player.”

function _playlistHandle(e:Event):void {
	var loader:URLLoader = e.target as URLLoader;
	var xml:XML = XML(loader.data);
	_player.play(xml.item.video[0].toString());
}

What do you suppose the path to my video is going to be, within my xml doc? If you look above, you’ll see I loaded the xml from the document root, and it would be natural for you to assume that the path to the first video is “flv/video.flv.” In this instance, you would be incorrect.

The correct path to the video file would be “../flv/video.flv.” Why is this? The relative path to an asset, in flash, varies according to what type of asset it is you’re accessing. In the case of XML you load your file from the location in which the SWF file is running, which in our example is the document root. When you’re loading video, however, you have to load your file from the physical location of the swf, not from where it’s running. In our example, that means our video file must be loaded as if the application is running from within our “swf” subfolder.

Why is this the case? I honestly have no idea. I can only imagine that in some obtuse way it’s meant to protect video content from being exploited by external domains or malicious third parties, though I can’t see exactly how.

Hopefully if you find yourself developing such an application, and you can’t figure out why the paths to your videos won’t resolve correctly, you’ll remember reading about the issue here. If anyone has a good explanation for why this is the case, I’d also be very curious to be informed.