Being Flex-ible

A recent project I worked on needed to record audio from the microphone of the user and store them on server. I should mention that this was a web project and since plain vanilla HTML and JavaScript can’t handle this sort of thing it was time to do something radical. Well it was radical enough for us. See we are mainly a .NET based software house. Since .NET provides us with so much baked in functionality, we rarely face a need to go out of the .NET ecosystem. In this case however we decided to step out. We couldn’t find a practical solution to implement this use case within .NET. Silverlight 3, the current version of Microsoft’s RIA platform currently doesn’t provide webcam/mic access. Silverlight 4 has it but its final version hasn’t come out yet and even if it did have webcam/mic support we still had to consider the market penetration aspect of it.

Thus we decided to use Flash but as is widely known that Flash isn’t exactly developer friendly. To remedy this, the nice folks at Adobe provide us with something called Adobe Flex. The great thing about Flex is that it boasts an event driven programming model that most developers nowadays are used to and it runs on the existing Flash Player that has an enormous user base already.

So we decided to use Flex to get the job done. It should have been an easy task to do. Why do I say should have? Because in the end it wasn’t. I was done with the POC in a day. It worked GREAT. It recorded my voice and streamed it to Flash Media Server which then saved it on the server. All was well until we tested it on other machines. We faced a classic problem of ‘It works on my machine’. It worked fine on my dev machine but not on other machines. We tested and tweaked the code like crazy which we know now didn’t matter.

The problem we discovered eventually was that the code refused to run properly on Dell Desktop PCs. It worked fine on unbranded machines, laptops and even Dell laptops but it specifically didn’t want to run on a Dell desktop machine. Apparently an event didn’t fire when the code was running on a Dell machine. But we still don’t know why? When all else failed and we couldn’t Google anymore we resorted to a hack. Instead of listening for the event we decided to use a recurring timer.

In the end we had spent a total of FIVE man-days just on this issue. Implementing the workaround took only half an hour of that time. Sounds cheap right? But it’s what we had to do. Moral of the story is that sometimes you have to settle for a cheap hack to get things working. Being a Software Developer we should know when to compromise because in the end what matters to us and the client is that we got it working. Meanwhile I hope that the enormously talented folks over at Adobe can fix this issue and we can get rid of this workaround.