Apollo and Auto-Update

This feature in Apollo is awesome. When you start up your application you can have it check online to see if a newer version of the program exists. If it detects that there is a newer version then you can download the AIR file locally and in your application call the update method. It will immediately close the program update and then re-open it. This makes it great for updating your program without forcing the user to go and download a new version manually.

One of the concerns that people have with Apollo is the fact that it creates a very easy medium for viruses. I can see how people are concerned about this. Not only is it very easy to create a program that can edit your local files, but on a whim a previously harmless application can force a critical update (doesn’t ask the user if they want to upgrade) and all of a sudden become malicious software.

I guess general users will just have to be more cautious about installing application from un-trusted sources.

First Look at Apollo and Flex Data Services

By now you’ve all most likely heard of Adobe releasing the Apollo alpha. Teknision is proud to have developed the only featured application upon its launch; the Finetune Desktop Player. Check it out!

Since Apollo’s release is so recent it’s been really exciting trying to create new and innovative desktop applications built upon web development tools. What makes it interesting is combining features usually reserved to rich internet applications (RIA) with file manipulation and other desktop centric ideals. Also noteworthy is the ability to build desktop tools that can not only communicate with the internet, but display HTML within them is not out of reach for the average developer.

One of my first stabs at such a program is an inter-office communication tools which can sit neatly in the users task bar, and notify users that they have a meeting or display a message. Although this ambition is not totally reachable yet, because Apollo doesn’t have the task bar integration, it is never-the-less an intriguing prospect. So I set out to get Flex Data Services working within an Apollo application. I was fairly new at the whole server-side communication and set up since I had really only skimmed the surface of the Flash Media Server, but after some trial and error I got communication flowing.

Here are some things to keep in mind when you’re setting up your FDS.

The Flex Data Services needs to be running on whatever server you’re trying to use as a communication medium.

Before you start up FDS make sure that the configuration XML is properly set up. This XML is located WEB-INF\flex\ folder and is called services-config.xml. By default there will be multiple channels defined and these channels will look at the {server.name} to get the path to the channel. For Apollo this server name needs to be hard coded, because the SWF is no longer running from a browser and it will not pass the correct name. For my example I created a new RTMP channel named my-local-rtmp and edited my-local-rtmp the endpoint to uri="rtmp://192.168.1.13:2038".

In my Apollo application, to keep everything simple, I used the Consumer and Producer pair. This pair requires a destination property which is also defined in the FDS configuration setup XML. In this case I entered my new destination in WEB-INF\flex\ messaging-config.xml, by adding a couple of lines.

<destination id="ChatTopic">

<channels>

<channel ref="my-local-rtmp"/>

</channels>

</destination>

Note that the channel reference points to the new channel that I created in the services-config.xml.

With my FDS server set up and running it was just a matter of tapping into the services provided using the Consumer and Producer pair and we had lift off.

I have to admit that I am really impressed with Apollo and FDS so far, and look forward to making many more application intertwining both of them.

Understanding the Flash Security Sandbox One Step at a Time

The Flash security sandbox is a nice little entity that wraps any flash application in an attempt to prevent malicious activity. Most of the security involves cross-domain interaction. In essence it prevents a SWF from one domain loading in a SWF from another domain and editing information or the process of information which might have otherwise been secure. In the flash world I do believe that this sandbox is necessary but it does cause a lot of problems and thus headaches.

When a SWF loads, it places all of its classes into the Flash Player’s memory. If it loads another SWF then it checks to see if that SWF has any of the classes already loaded into memory and uses that instance of the class rather than loading a second instance. One of the projects we work on involves a centralized framework SWF which is essentially our API. This framework SWF loads in different SWFs on other domains which share the same code base. The idea was that we could update the framework SWF and the changes would get propagated out to every different domain. Unfortunately when you add cross-domain into the mix this is when you start to run into problems. When the child SWF gets loaded in it also loads its own version of the classes into memory. Looking through the security documentation I didn’t see any way around this. Adobe should make a property that can allow you to overwrite other classes if you load in a SWF from another domain. I imagine it could work like the Security.allowDomain().

Introductions are in Order

Hello everyone. I figured I would start my first post out by introducing myself.

I attended Algonquin College, in the capital of Canada (That would be Ottawa for the readers from the USA) and took Interactive Multimedia. One of the courses that I was the most interested in was ‘Introduction to Flash’. The course required a two month co-op placement and I was lucky enough to land a spot at Teknision.

Needless to say that now it’s been over 2 years, I’m still working at Teknision, and I love it. Now onto some more interesting posts.