At These Days a lot of the websites we build have a Flash or Flex interface with content fed in via XML documents. That makes it really easy to deploy the same website in multiple languages. You just pass in a localised XML file and voila, you’ve got a localised site.

Until now, we have been translating those XML files manually, but we’ve just made a little tool called Hello Bonjour that makes that process easier. The tool generates an interface with a Rich Text Editor for each node in your XML document. It shows the original copy and the translated copy side-by-side for easy comparison. You can customise it for each project with your client’s official font faces and brand colours to make it easy to generate content that fits the styleguide. There’s also a Find and Replace tool so you can quickly update URLs or other text throughout the entire document.

You can test out a demo here. Sharing is caring, so here’s the source code. Feel free to use it or adapt it to meet your needs.

Installing the Server

You can download the Red5 server package from Google Code (current version: 0.9.1 final). Once it’s downloaded, just run the executable and it will automatically install the files and then prompt you for an IP address and a port number. When setting up the server for local testing, I just use 127.0.0.1 and 8080.

Once the installation is finished, you might want to run services.msc and check if the Red5 service is installed correctly and is running. With that done, we can open up a browser window and browse to http://127.0.0.1:8080 and you’ll see the Red5 gateway. Here you can test if Red5 is running properly and you can install some of the default applications that come with the Red5 installer. Red5 runs on Java and these applications are great for people like me, who don’t know Java and want to get right down to the good stuff. You can just install one of these basic applications (I recommend installing the oflaDemo app) and once it’s installed, your front-end application can just connect through one of these.

So how about we get to the interesting bit?

Creating your First App

Creating an app in Red5 isn’t too hard if you’re familiar with the NetConnection and NetStream classes, but you can save yourself a lot of trouble if you think your application through.

I created two classes that, in my opinion, came in quite handy:

1. Red5Connection, the Red5Connection class is a subclass of  Flash’s NetConnection class and is pretty much just a class that handles the events that a NetConnection might throw at you.
2. AbstractClient, just an extension of a Sprite or DisplayObject. Since we needed three entirely different clients (a broadcaster, a subscriber and a simple chat client, which displayed messages sent by the other clients), it was important to have one base class with the basic logic for all three clients.

Both of these classes are available for download here: Red5 Example files

When working with Red5, you’ll use two things often: a NetStream and a Remote SharedObject. The NetStream is used to broadcast or stream video footage. A SharedObject is used to store or retrieve data remotely. We use this to broadcast data to all connected users (could be used in a simple chat client for instance)

Here’s how you would normally use the NetStream object:

_ns = new NetStream(_nc);

// get the first camera
// set the max bandwidth used by the stream to infinite and the quality to 95 (0-100)
_cam = Camera.getCamera("0");
_cam.setQuality(0, 95);

// get the first microphone and if there is one, make sure there's no loopback nor echos
_mic = Microphone.getMicrophone(0);
if(_mic){
_mic.setUseEchoSuppression(true);
_mic.setLoopBack(false);
}

// attach microphone and camera to the netstream object
_ns.attachCamera(_cam);
_ns.attachAudio(_mic);

// publish the NetStream to Red5.
// the publish method uses two parameters, a name and a type
// the name is used to identify the netstream
// the method determines whether the netstream will be recorded, appended to an existing stream or just streamed live
// possible values are "record", "append" and "live"
_ns.publish("broadcastExample", "live");

If you wanted to stop a broadcast, you could use these bits of code:

_ns.attachCamera(null); // just removes the camera
_ns.attachAudio(null); // just removes the microphone
_ns.play(false); // stops the broadcast but leaves the NetStream intact
_ns.close(); // closes the NetStream altogether

And this is how we use the SharedObject’s send() method to send data to and from all connected clients

if (_so) _so.send("methodName", parameters);

An implementation of this code can be found in the Broadcaster and Subscriber files in the zip file I provided.
To recompile the .fla files on your computer, you will need to download De Monsterdebugger and adjust the class path settings via File > Publish Settings…

Furthermore, you will need to run Red5 locally (or adjust the RED5 constant in AbstractClient.as) and have the oflaDemo app installed in order for the files to work.

Well, that’s it for me, hopefully I was able to persuade at least some people to look into Red5.

Here’s an example of just how easy it can be:

Code for a simple Titanium App

The Titanium app in iPhone

The Titanium app in Android

Getting the Andriod emulator installed correctly can be a real pain. After you have downloaded the Android SDK, open the Android SDK and AVD Manager and make sure you install all of these:

• Android SDK Tools
• SDK Platform Android 1.5, API 3
• Google APIs by Google Inc., Android API 3

In your Titanium Developer profile, set the Android API location to /Applications/android-sdk-mac_86. Also, I found the Android emulator to be frustratingly slow, but I don’t think that’s Titanium’s fault.

To create useful mobile applications I think it would be a good idea to start with the following:

• Userstand the role of windows and views in iPhone applications,
• Download and browse the Kitchen Sink application to get an idea of the UI components available in Titanium.

I have included some screenshots of the Kitchen Sink application built in Titanium below so you can get an idea of what can be done.

Slider UI

Entering text input

Saving data on the device

There are a number of advantages to developing with HTML5 instead of writing native Objective C applications for iPhone. You have probably already heard these:

• Developing with web technology is much faster than with Objective C,
• Bug fixes and updates can be deployed instantly,
• We can utilize our existing HTML, CSS & JavaScript talent.

But what you might not have realised is:

• HTML5 allows us to store data on the device with SQLite and run apps offline,
• Web apps can interface device features such as geo location, accelerometer and multi-touch input,
• Web apps can offer a responsive and seamless user experience. You can use a JQuery plugin to create native iPhone animations like flip, slide and dissolve. Web apps do not have to look and feel like a website.

Of course there are still differences between the various mobile devices, but with a bit of tweaking the same HTML5 app can be made to run on iPhone, Android, Palm and Nokia devices because they all use the Webkit browser engine.

Sometimes we might need to generate native applications, to sell the application in Apple’s App Store for example. But even that doesn’t mean we have to resort to Objective C or Java. There is a clever open source tool called Appcelerator Titanium which deploys native applications to iPhone and Android – and we can code them in standard HTML, CSS and JavaScript. Of course deploying as native apps removes some of the benefits inherent to web apps – such as rapid deployment and development iteration. But this approach still dramatically reduces barriers to development. Phone Gap is another open source tool for deploying native mobile applications from standard web technologies. Unlike Appcelerator, Phone Gap supports Blackberry, Palm and Nokia as well as iPhone and Android. However it doesn’t offer as rich of a feature set as Appcelerator. Rhomobile offers yet another framework, but it is targeted towards Ruby developers.

So when you next have an idea for a mobile app, don’t give up on it because you don’t know Objective C or Java, or because it is too difficult to create a cross-platform app. Put your existing HTML, CSS and JavaScript skills to use and take advantage of HTML5 or an open source web-to-native compiler. I will have a play around with Appcelerator and Phone Gap and post my findings on this blog.

Comparison of mobile application development methods

Just go see for yourself: http://labs.thesedays.com/prankwar/

(* yeah right, muaha )

In jQuery you can easily get the href attribute value off of a link by doing $("mylink").attr("href"); but sometimes in IE this isn’t reliable. For example: normally, if the href value is “#myAnchor”, jQuery will return —surprise, surprise— the string: “#myAnchor”. But in some cases with IE, you’ll get the full URL path of the page you’re currently on, with the anchor string value appended to it (for example: “http://labs.thesedays.com/#myAnchor”).

This bug is specifically annoying when you use the href value in a selector in jQuery. For example, you should never do the following, because it may result in unexpected results when browsing in IE: $("a[href='#myAnchor']").click(...);

Workaround? Instead of using the href attribute, you could use the rel or xref attributes of a link, but these attributes aren’t supposed to be used for this purpose and if you disable javascript, the anchors won’t work anymore.

The  jQuery devs should fix this issue ASAP, because I think that issues like these are the main reason why people use javascript libraries like jQuery: they make hacky javascript work!

For me, this proves once again that Internet Explorer totally fails at DOM management.

In less than a week we raised €5.247,46 with a talent auction for Music For Life! Check out the other side of the These Days staff: who did what and for how much. Follow @thesedaysBE for updates on footage from each challenge.

Expected highlights: a bucket off water on Myriam, Nuria’s Mexican serenada, Babs’ bellydancing class, Michiels slap-in-the-face-wake-up-call and many more… check it out here.

For an oncoming Nokia campaign we’ve been working on an interactive website that relies heavily on the communication between Javascript and Flash. It involves two instances of Flash Player to interact with the same bit of Javascript. We had our two swf files report to Javascript using a rudimentary event dispatcher (pretty much just a Javascript function called dispatch, that could take one or more params, one of which was the event type)

Now, the issue we encountered was that, sporadically and presenting without any recognizable pattern, the event passed on from the second of the two Player instances, would fail. We just didn’t receive any notice that anything had happened at all.  Even more baffling was that the issue only occurred in Firefox on a Windows PC.

After banging our heads against the walls and endless debugging, we finally discovered that the problem lay in the fact that we were calling the same Javascript method from two separate instances. Once we created a separate function to handle the events for both player instances, the issue resolved itself.

If anyone has any explanation as to why this would happen, we’d love to hear it from you
To me, it seems that Firefox is more and more becoming an endless cesspool of eternal doom for Flash developers.