Flash Remoting Gateway Calls in ColdFusion 10 Require a Trailing Slash

With the rise of ECMAScript 6, tools like WebRTC, the Web Audio API, and HTML5 and CSS3 in general, we're seeing fewer and fewer Flash applications in the wild. My team, like many, still have a few out there, mostly revolving around real-time communications because WebRTC is limited to newer browsers (no Mobile Safari, sigh), and polyfills aren't always the real thing.

We ran into an issue this week where a customer reported that one small Flash app wasn't logging activity like it used to. Logging was done via a call from the Flash app to a Flash Communication Server app instance which would then pass the data to be logged to a ColdFusion cluster. (Flash Communication/Interactive Server was required for the realtime portion of the application.) To give you an idea of how small and unused this app is, the app had stopped logging properly in May, 2013, but the problem wasn't reported to us until just this week. >.<

After a lot of head scratching, we found the source of the failed Flash Remoting calls from the Flash Media Server:

In ColdFusion 9, you could refer to the Flash Remoting Gateway in your main.asc file as:

NetServices.setDefaultGatewayUrl("http://yourwebsite.com/flashservices/gateway");

In ColdFusion 10, a trailing slash is required when you create the Flash Remoting Gateway reference:

NetServices.setDefaultGatewayUrl("http://yourwebsite.com/flashservices/gateway/");

If you do not include that trailing slash, the call to NetServices.setDefaultGatewayUrl will fail.

Book Review: Programming Flex 3

Because I have the opportunity to take mass transit to work (and it's awfully convenient), I have about an hour or so to read each work day. I spend that time either reading the magazines to which I subscribe, the occasional novel, or technical books. As a result, I read quite a few technical books each year. It sounds thrilling, I know, but it's a great opportunity to expand my knowledge base, especially in areas where I'm not getting to do a lot of day-to-day work. I just finished another in a line of books about Flex.

Programming Flex 3 by Chafic Kazoun and Joey Lott is a rich and comprehensive guide to developing Flex 3 applications with many details about developing Flex applications that are left out of other books and publications. From the start, with its close look at the application startup sequence and how to manipulate that sequence, you know that you are in for a book that's thorough in every aspect of Flex application development.

One of the great strengths of the book is that the authors demonstrate both the MXML and ActionScript versions of the same framework features, where possible. This allows those new to the whole idea of XML-based declarative development the opportunity to see how things work while giving those who want (and will shortly need to) dig deeper the opportunity how the same tasks are achieved in code. The one startling omission from this approach is the <mx:RemoteObject> tag, about which the authors say "Because we have found no practical use for RemoteObject, we are omitting any discussion of RemoteObject in this chapter." I suppose that they made this statement because putting a RemoteObject tag in your MXML conflates the model (and remote data processing) with your view, which isn't good practice, but their statement seems quite severe.

While the authors demonstrate their mastery of the details of Flex and manage to explain even relatively complex concepts (such as the Flex component lifecycle) in a clear manner, the book does feel a bit bit haphazard. Very advanced topics are mixed in with introductory topics. I realize that this is done so that if you write a chapter on CSS and fonts in Flex, you cover every angle of it, but those new to Flex will find themselves getting in very quickly over their heads in each of the book's chapters. Everything is explained quite clearly, but it ends up feeling a bit random.

I'm a big proponent of context while learning. I've been to far too many trainings and read far too many books where you cover feature after feature without tying those features back in to a big picture. Being able to answer how to solve an application development problem with a particular tool is as important as knowing the extensiveness and details of a toolset. While the authors do introduce a "sample application," it's at the end of 605 page book. Although it can be limiting (because you can only write so much and publishers have limits on the number of pages they'll print), sometimes having an application you build along the way to demonstrate the concepts covered can be extremely useful.

But this is an O'Reilly book and as such, the audience may be more inclined to use it as a thorough, comprehensive reference, which it is, than a getting started book.

Considering Mate and Swiz

I have a confession: I don't get to do much Flex development. I read up on it. I've attended trainings. I go to classes. I watch webcasts and screencasts. I don't, however, have a lot of opportunities (or time) to build Flex apps. A lot of what I do mixes rich media and lots of text, and I'm not sure that Flex (or Flash) is the best environment for lots of text. Feel free to argue or disagree in comments below.

One thing I do know is that I don't like to work without frameworks, regardless of the language in which I'm working. Frameworks and standard libraries can take a lot of work out of developing applications, and can often help you organize your application according to best practices. In ColdFusion, I don't build applications without Mach-II (or Model-Glue, but I'm mostly a Mach-II developer).

In my Flex development experience thus far, I've been working without additional frameworks (because Flex is a framework, after all). I've played with Cairngorm and understand how applications need to be laid out using that micro-architecture. It's a bit unwieldily for me. PureMVC is powerful as well, but, again, requires all sorts of extra classes and overhead that I'm not a fan of. (And, honestly, I'm not making AS3 apps, I'm making Flex apps, so the advantages of a "framework not tied to Flex" don't really work for me.) I really like the XML-based configuration that Mach-II, Spring/ColdSpring, and other frameworks provide. I know that some people hate coding in XML, and it does have its downsides, but I think that the simplicity and clarity it brings to the process outweigh the large XML files.

As fortune would have it, there are two good options that have made their way from private alpha in to public beta: Mate and Swiz. Mate is from the team at ASFusion, who brought us some really cool Flash tips and tricks as Flash, Flash Remoting and Flex began to be integrated with ColdFusion. Swiz is the brainchild of the very smart Chris Scott, who brought us the excellent ColdSpring framework (a requirement for anyone building CF apps these days).

In my initial explorations of these frameworks, I think the strength of each is as follows:

  • Mate uses an event map to describe the flow of events/actions within the application. I really like that and it makes a ton of sense, especially coming from an XML-based framework like Mach-II.
  • Swiz uses Inversion of Control and beautiful and handy things like annotations to significantly reduce coding and elegantly manage dependencies within your application.

Mate also offers all sorts of nicely encapsulated helpers for remoting and binding and dependency injection which make it pretty attractive. I don't know enough about Swiz at this point to say if it has all the same helpers and conveniences (and honestly, the documentation for Mate helps me understand a lot more about that framework that Swiz as Swiz currently lacks an equal amount of documentation). So given those conveniences and my comfort with the XML-based configuration/"event map," I think Mate is the way for me to go, for now.

I'll blog about my experiences using Mate as I build apps with the framework. I'm personally very thankful that such smart people have provided the developer community at large with these great, powerful, time-saving tools.

Flowgram: Next-Generation Demonstrations

Flowgram is a really nifty new, Flex-powered service that takes Web-based demonstrations to the next level. I don't get impressed by many training tools any more as I've been exposed to way too many that do the same thing in less and less interesting ways. Flowgram isn't just a screencasting or video demonstration tool. It actually brings up the Web page that you are trying to demonstrate. It's the full Web page and the viewer can interact with the page because, well, it's live!

This goes way beyond simple screencasts where you can watch, but not participate. It's much closer to what you can achieve with Adobe Captivate in terms of providing training for desktop or Web-based applications. Because you're dealing with live Web pages, you will run in to the issue of logins preventing users from getting inside a site that requires authentication, but theoretically, you could show them how to create and account, log in, and go from there. Captivate's simulation mode works around these issues, but you have to deal with changes to the Web pages you're demonstrating in Captivate, which can be time consuming and expensive. (Granted, Captivate can do a whole lot more, including branching, which isn't even in in Flowgram's playbook.)

You can also add in annotations to the Web pages you're demonstrating, add still images, pull from Flickr and and Facebook image sets, import PowerPoint files and then mix it all up.

The service itself uses a Flex app with and a whole lot of <iframe>s to get the job done, but the experience is really quite seamless and really darn interesting.

Like all Web-based services, there's the Flowgram branding and site redirection that you pretty much can't get around, and, of course, you run the risk of your content going away if Flowgram goes away. It is, however, a really interesting service for those looking to create Web-based demonstrations of (mostly) Web-based properties. I'm definitely going to be using this for some of my future training content creation, though I'll still rely on Captivate for demonstrations of desktop-based applications.

Easier Flex UI Building with Fireworks 3

I've never been a big fan of Fireworks, so haven't used it very much. Once I saw the MXML/Flex export from Fireworks 3 back in beta, however, I was very impressed and finally saw a use for the app. In a nutshell, you can prototype Flex UIs using Fireworks and then export the MXML from Fireworks and add your logic in Flex Builder (or whatever else you choose). Pretty handy.

What I didn't know was that you can do a lot more than just lay out the MXML. You can do a lot of styling work in Fireworks (where some tasks are easier than in Flex Builder) and then also export that information as well. Peter Baird wrote a good, short article on how to use Fireworks 3 for Flex UI prototyping on Adobe's Developer Center.

I don't do a ton of UI design work myself (I have great people on staff who are so much better at it than I), but when I do need to lay some stuff out, Fireworks is a handy tool — especially for prototyping and hiding and showing layers of the UI really quickly. There's even a Flex Style Explorer for Fireworks which helps to make sure that the work you do in Fireworks translates seamlessly over to Flex. Again, very handy.

BlogCFC was created by Raymond Camden.

Creative Commons License
The content on http://www.iterateme.com/ is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.