To plug in, or not to plug in: that is the question! 

May 17th, 2012 by Elliott Mitchell

In recent years, we have seen a tremendous amount of attention to what can only be described as a debate between browser based plugins and their more standards based equivalent technologies, HTML & Javascript. Granted, even plugin providers can argue that they have open standards, but HTML definitely has its roots originating by a standards processes like W3C which is widely accepted by the web community. While we don’t want to go down the route of arguing for either side, it’s quite interesting to consider some of the available information freely circulating on the web.

Let’s start off first by examining some of the requirements of a plugin based deployment. If a webpage requires a plugin, often the end user will be prompted to install or update before they can proceed. This prompt is often met with resistance by users who either don’t know what the plugins are, have a slow Internet connection or receive security warnings about installing the plugin. While there are steps to install browser based plugins and these may present difficulties for some, most online statistics show that this hasn’t really affected adoption rates.

To address this, I thought it would be helpful to take a peek at the current trajectory of plugin usage, plugin alternatives like HTML5, and browser usage as to better inform developers to decide whether or not to create plugin dependent content for the web browser. Let’s first take a look at desktop web browser plugin usage between September 2008 and January 2012 as measured by

Flash – 95.74%
Java Support 75.63%
SilverLight Support 67.37%
Quicktime Support 53.99%
Window Media Player Support 53.12%

Unity – ?% (numbers not available, estimated at 120 million installs as of May 2012)

Flash has been holding strong and is steadily installed on a more than 95% of all desktop computers. Flash is fortunate that two years after it’s launch, deals were made with all the major browsers to ship with Flash pre-installed. Pre-installs, YouTube, Facebook and 15 years on the market have made Flash the giant it is. Flash updates require user permission and a browser reboot.

Java Support updates for browsers have been holding steady for the past four years between 75% and 80%. Some of these updates can be hundreds of megabytes to download as system updates. At least on Windows systems, Java Support updates sometime require a system reboot. Apple has depreciated Java as of the release of OSX 10.6 Update 3 and is hinting of not supporting it in the future, at which time Java would rely on manual installation.

Interestingly enough, Microsoft Silverlight’s plugin install base has been steadily rising over the past four years from under 20% to almost 70% of browsers. Silverlight requires a browser reboot as well.

Both Windows Media support and Apple’s Quicktime support have seen installs drop steadily over the past four years, down from between 70% – 75% to a little more than 50%. It is worth pointing out that both these plugins are limited in their functionality when compared to the previously discussed plugins and Unity, mentioned below. Quicktime updates for OSX are handled through system updates. Windows Media Player updates are handled by Windows Systems updates. Both Windows and OSX require rebooting after updates.

Unity web player plugin has been on the rise over the past four years, although numbers are difficult to come by. The unofficial word from Unity is it has approximately 120 million installs. This is impressive due to Unity emerging from relative obscurity four years ago. Unity provides advanced capabilities and rich experiences. Unity MMO’s, like Battlestar Galactica, have over 10 million users. Social game portals like Facebook, Brass Monkey and Kongregate are seeing a rise in Unity content. Unity now targets the Flash player to leverage Flash’s install base. *The Unity plugin doesn’t require rebooting anything (See below).

So what about rich content on the desktop browser without a plugin? There are currently two options for that. The first option is HTML5 on supported browsers. HTML5 is very promising and open source but not every browser fully supports it. HTML5 runs best on Marathon & Chrome at the moment. Take a peek at to see how desktop browsers score on supporting HTLM5 features.

The second option for a plugin free rich media content experience in the browser is Unity running natively in Chrome. That’s a great move for Chrome and Unity. How pervasive is Chrome? Check out these desktop browser statistics from around the world ranging between May 2011 to April 2012 according to StatCounter:

IE 34.07% – Steadily Decreasing
Chrome 31.23% – Steadily Increasing
Firefox 24.8% – Slightly Decreasing
Safari 7.3% – Very Slightly increasing
Opera 1.7% – Holding steady

Chrome installs are on the rise and IE is falling. At this time, Chrome’s rapid adoption rates are great for both Unity and HTML5. A big question is when will Unity run natively in IE, Firefox and/or Safari?

We’ve now covered the adoption statistics of many popular browser based plugins and the support for HTML5 provided by the top browsers. There may not really be a debate at all. It appears that there are plenty of uses for each technology at this point. It is my opinion that if the web content is spectacularly engaging, innovative and has inherent viral social marketing hooks integrated, you can proceed on either side of the divide.

, , , , , , , , , , , , , , , ,

Red5 Authentication

May 7th, 2012 by Paul Gregoire

How to implement CRAM authentication in Red5

In this post we will setup a challenge-response authentication mechanism (CRAM) in a Red5 application using two different methods; the first one being very simple and the other utilizing the powerful Spring security libraries. A basic challenge-response process works like so:

  • Client requests a session
  • Server generates a unique, random ChallengeString (e.g. salt, guid) as well as a SessionID and sends both to client
  • Client gets UserID and Password from UI. Hashes the password once and call it PasswordHash. Then combines PasswordHash with the random string received from server in step 2, and hashes them together again, call this ResponseString
  • Client sends the server UserID, ResponseString and SessionID
  • Server looks up users stored PasswordHash based on UserID, and the original ChallengeString based on SessionID. Then computes the ResponseHash by hashing the PasswordHash and ChallengeString. If its equal to the ResponseString sent by user, then authentication succeeds.

Before we proceed further, it is assumed that you are somewhat familiar with Red5 applications and the Flex SDK. For those who would like a quick set of screencasts to get up-to-speed, we offer the following:


Implementing a security mechanism is as simple as adding an application lifecycle listener to your application. Red5 supports a couple types of CRAM authentication via an available auth plugin. The first one implements the FMS authentication routine and the other one is a custom routine developed by the Red5 team. In this post we will use the Red5 routine. An ApplicationLifecycle class implementing the Red5 routine, may be found in the Red5 source repository; this code only validates against the password “test”. While this class would not be useful in production, it may certainly be used as a starting point for a real implementation. Red5AuthenticationHandler Source

To enable the usage of your Red5AuthenticationHandler class or any other ApplicationLifecycle type class for that matter, you must add it to the listeners in your Application’s appStart method.

The reason for putting it in the appStart method is to ensure that the handler is added when your application starts and before it starts accepting connections. There is no other code to add to your application adapter at this point since the lifecycle methods will fire in your handler. Putting the authentication code within a lifecycle handler serves to keep the adapter code cleaner and less confusing. The authentication handler is defined in the red5-web.xml like so:

At this point, your application would require authentication before a connection would be allowed to proceed beyond “connect”. Entering any user name and the password of “test” or “password” (depends on class used in demo) would allow a client to be connected. As stated previously, this first “simple” implementation is not meant for production but is offered as a means to understand the mechanism at work.

Adding Spring Security

Once we add security layers such as Spring security, the application and authentication features become much more robust. The first thing we must do is to add the Spring Security namespace to our applications red5-web.xml.

Replace this node:

With this node:

Add the authentication manager bean and configure it to use a plain text file. The users file contains our users, passwords, and their credentials.

To demonstrate how users are handled, we will create three users: 1 admin, 1 regular user, and 1 user without a role. The plain text users file follows this pattern: username=password,grantedAuthority[,grantedAuthority][,enabled|disabled] A user can have more than one role specified; granted authority and role are synonymous. Below are the contents of our users file for this demo.

In addition to the authentication handler, a authentication manager must be added when using Spring security. The manager should be added to the appStart method prior to adding the handler, as shown below.

The Spring security version of the authentication handler will replace the simple version in your red5-web.xml like so:

Lastly, an aggregated user details service is used for storage and look ups of user details; this is essentially an interface to the internal in-memory datastore holding the user details or credentials. The user details may be configured to retrieve details from our local properties file, databases, ldap, or active directory. Our aggregated service is fairly simple as you can see below.

It should be noted that Spring security makes use of an additional Spring framework library that is not included in Red5; the transaction library provides DAO and transaction implementations which do not require an external database or related dependencies. All the libraries required for the demo are included in the project zip file.

Client code

Creation of an authentication enabled client will require a single library not included in Flex / Flash builder called as3crypto. The AS3 cryptography library will provide the hashing functions nessasary for authentication in our demo. Download the as3crypto.swc from: and place it in the “libs” folder of our client project.

The following functions will be needed in your client support authentication:

The sendCreds method is called “later” from the sendCredentials method to prevent issues in the event thread.

These are the imports that need to be added before beginning.

In your connect function you will need to determine which authentication mode to employ. The following block will show how to set up the connect call based on the type selected.

You may notice that the type is simply a string in the url denoting which mode to use.

In your net status event handler, you will need to add handling for authentication routines. The following block demonstrates how to do so when an NetConnection.Connect.Rejected is received.

Once you are successfully connected, there are two methods in the demo code for testing access. The helloAdmin method will return a positive result if the authenticated user has the admin permission. In the helloUser method the routine is similar, but only the user permission is required. The included users file contains an admin user and two regular users, the second user is set up to have no permissions. The user without permissions may only connect application and call unprotected methods.

Protected methods in the application contain an isAuthorized check against preselected permissions.

If the user does not qualify, the call fails.

In a future post, I will explain how to add Java Authentication and Authorization Service (JAAS) to Red5.

Project Source Client and server

, , , , , , , , , ,

Android – Live Wallpaper part 2

March 22nd, 2012 by Paul Gregoire

Let’s make the star that we created in part 1 rotate in just a few simple steps. Although before we start, I’d like to note that we are technically rotating the entire canvas and not just the star itself; adding more than one star to the display will clearly expose this minor detail. I’ve done some research on the rotation of multiple individual items at-once, but I have not yet found a solution that fits; feel free to comment if you are aware of how to accomplish it.

The code modifications below are being in the source file, we are not using the only other source file at this time.

1. Add a variable where we keep track of the first frame drawn. This will prevent some calculations from being executed more than once per instance.

2. To rotate the star, we will use degrees. In steps 2 and 3, two methods of generation are shown. In this section we use a float counter for degrees of rotation.

3. In this section we use a fixed array for degrees of rotation. To do so, we also must create an index counter and an array of 360 floats; again, its up-to-you as to which option to use.

4. If using the array method, the onCreate method is modified to pre-fill our array when the application is first initialized.

Note: I’ve tried both methods for degree cycling and they seem equally fast on my device.

4. Modify our drawing code from part 1. The code block is here for reference.


After (using float counter)

After (using float array)

6. As an aside to what we done thus far, you can easily add another star with a couple extra lines like so:

The additional star will be down and to the right of the primary star. This star will not rotate per-se but instead will “orbit” the primary star.

7. Last step, build and run in the emulator. Right click on the goldstar project in Package Explorer and select Run As -> Android Application. If you haven’t created any AVD (virtual devices), you’ll be prompted to create one. Creation of an AVD is covered here.

When everything works, you’ll see this in the Eclipse console:

I recorded the emulator running the apk in this screencast

Running on my Galaxy Nexus

In the sample code, I’ve refactored the original class alittle to make things more clear.
Project Source

End of part two.

, , , ,

Android – Live Wallpaper

March 17th, 2012 by Paul Gregoire

Herein I shall walk you through the steps for creating a live wallpaper in Android. Before we begin any Android development, the SDK and ADT plugin for Eclipse will need to be installed. The best installation guide is here; Disregard this if you already have the SDK and plugin installed. For this first part, we will simply display a graphic and in the followups we will do some animation. Without further ado, let’s get started.

1. The first step, is to create the new project
File -> New -> Android Project

We will call it “goldstar” and target Android 2.1 (API 7); this version of Android was the first to support Live Wallpapers.

2. Open up the AndroidManifest.xml file and add the nodes that we will need to support our application. Here is the manifest before our additions were

This is the “after” version, where we added our feature, permission, and service nodes:

3. Create a metadata file for our service. This is accomplished by making an xml directory within the res folder of the project. Create a new file named “metadata.xml” in this folder with these contents:

4. Add a description for our application. Open the strings.xml file and add a string with a name of “wallpaper_description” and a value of “Goldstar Live”. You may actually use whatever value suits you, this one is just for the example.

5. Get the svg library and place it in the “libs” folder; this folder must be created manually, if it does not already exist in the project.
We are using svg-android library from for this example. This library was also used in the popular “Androidify” application.

6. Locate an SVG image file to use in our application, preferrably one that is not copyrighted. Remember that google is your friend

Here’s a gold star on wikimedia that you can use:

Once you have a suitable file, save it into the “raw” directory within the “res” directory of the project. Note that your resource may only contain this range of characters in its name: a-z0-9_.

7. Now for some code; create a new class in the wallpaper package and name it LiveWallpaper. Set the super class to android.service.wallpaper.WallpaperService and click Finish. Your new class should appear like this:

8. Create an internal class named StarEngine which extends Engine. The result of this should appear like so:

9. Right-click on StarEngine and select “Source -> Override/Implement Methods”. Now select the following methods:


then click ok. This will create the method stubs that we are interested in.

10. Modify the onCreateEngine method to create a new instance of our engine.

We have also added to static variables for the frame rate and scene width.

11. Load our svg asset. Create a local engine variable and modify the onCreate method like so:

This will read the file resource and parse it to create an SVG image object.

12. Thread and handler must now be setup to take care of drawing on the canvas. We modify the engine like so:

13. Drawing on the canvas. In our drawFrame method we will use our svg asset and draw it into view.

14. Build and run in the emulator; you should see something like this:

15. Lastly, if you want to have nicer launcher images for your application there are free services to utilize such as this one:

Just upload your image and do a little configuration and you get a zip containing all the launcher images you need.

Project Source

End of part one; for part two we will cover animation.

, , ,

Clustering with Red5

July 28th, 2011 by Paul Gregoire

Once your service out grows its original space, you will most likely look at adding clustering capabilities. While clustering an application may seem daunting, it can be done in a fairly simple manner at first. Whilst at Infrared5, I have created several clustered applications using the methods which will be supplied below and now may be added to your skillset.

For this example you will need the following software (IDE’s not listed):

Herein we will go over clustering a simple chat application; both the client and server code in this example consist of only two to three source files respectively. Code blocks may not contain all of the code or comments to keep the sections short and focused.

Server-side (Java)

The first piece of code we need is the Red5 application adapter, it is used by the server to control the lifecycle of your application. In many cases, the base classes may be configured via Spring so that you don’t even need to write your own for simple applications; as an example, the SOSample demo that comes with the server doesn’t have any code for an application adapter. For this application we will override two lifecycle methods to handle the starting and stopping of the application. When the application starts, we need to start our cluster client class and join the cluster. On stop we disconnect from the cluster and perform any clean up necessary.

We must also add any methods which will be called by the client, which in this case would be one that accepts a sender name and some text.

Pretty easy looking isn’t it? Being a standard Java method, it could accept these values from anywhere that has access to the method such as a servlet. Next up, on the server-side is the code to send and receive messages on the cluster. This “ChatRegistry” extends the ReceiverAdapter provided by JGroups and is implemented in the most minimal way I could think of.

You may have noticed we’ll be using UDP for this example, I have found that this is the easiest way to setup JGroups and keep all the nodes communicating on a local network.

Last but not least for the server application we have our model class to hold a creation time, sender name, and the chat text itself.

The Actionscript twin for this model will be shown in the next section.

Client-side (ActionScript)

I used FlashBuilder to whip-up a quick chat client, so don’t bash my code too hard. For the example clients I created a Flex Project with MXML and one AS3 class file. In the MXML script block besides the connection handling, we need a method for sending and another to receive.

Be aware that the in the send function must match the signature on the server’s application adapter.
The final class needed on the client is our model, which in Actionscript is a lot less “wordy” than in Java.

I have not included the configuration files and some other things in this post to prevent confusion, but rest assured they are in the source archives at the end.


The quickest way to get up-and-running is to grab the server zip and deploy it to two servers or vmware virtual machines. Everything you need to run the client and server is in the zip.  After Red5 has started up, look at your console and you should see a line indicating that your application is in the cluster.

Please note that If you are using OSX you may need to add “” to your start-up script due to a bug in JGroups IPv6 handling.

Open browsers on each instance and navigate to http://localhost:5080/chatr/chatr.html

Once loaded, enter a name and click connect. After you have two servers running and clients connected to them, your output should look similar to this when chatting.

So now you know how easy this can be, go forth and create some cool stuff!!


Full application with Red5 server (ready-to-run):

Client source:

Server source:

, , , , ,