Web Application Developers are used to being able to write automated tests for their applications and have them run with every PR and before deploying to production to give a level of confidence that things are not broken. OpenTok and real-time applications in general present new challenges when it comes to writing and running automated tests. There are challenges when it comes to getting access to microphones and cameras, testing multiple participants and installing the plugin for Internet Explorer among others.
There has been lots of work around WebRTC testing automation and our friends at rtc.io and &yet have written some great articles on the subject. However these articles don’t cover some of the specifics of testing OpenTok applications for example testing Internet Explorer and installing the OpenTok plugin for Internet Explorer. If you haven’t already I would recommend taking some time to read the articles by the folks at rtc.io and &yet before coming back to this. Also if you’re not familiar with Travis and Selenium WebDriver you might want to check those out too.
When I’m working on developing an OpenTok application, I want to move fast. As a software engineer, I have loads of little workflow shortcuts, scripts, tricks, and favorite tools. When I started to build optk, I wanted to shave off just a couple seconds off of something that I had to do dozens of times a day.
GUEST POST: WebRTC.ventures is a custom design & development agency focused on building WebRTC applications. They are part of AgilityFeat, which is one of our development partners at TokBox. Jean Lescure from their team wanted to share their experiences using our new API for detecting call quality.
Back in August TokBox announced their new Pre-Call API, for testing out bandwidth conditions, and posted a repository on github with a proof of concept. At WebRTC.ventures we saw a great opportunity to build upon that project and got working on creating a demo app out of it, including a server implementation in NodeJS which is compatible with Heroku.
As much as WiFi and cellular network reliability has improved over the years, it’s not uncommon to find yourself in a situation where connectivity drops or is spotty at best. Somehow in our overconnected world, “offline” mode still exists. When you’re using real-time communications technology, poor service or connection quality can be particularly disruptive.
That’s why we’re excited to introduce our Pre-Call Test tool – a set of tools that will determine if an end-user’s OpenTok-powered call will be successful given their network conditions. The Pre-Call Test can be integrated into your application’s workflow so that your end-users can run the diagnostic test before they even join the session. Based on their test results, you can implement business logic that determines whether a particular user is allowed to publish a stream to the session with video, audio-only mode, and more.
The OpenTok.js SDK integrates beautifully into current HTML elements, providing a great variety of layouts and styles. But why should we stick to the traditional 2D design? Modern browsers offer us the power of 3D visualization with WebGL, a technology that has already opened up a new world of interaction and presentation of data within the browser domain.
With an objective to take advantage of the possibilities of 3D within the browser, we created the OpenTok 3D demo. The OpenTok 3D demo is a multi-party video application which shows how we can integrate the OpenTok.js API with WebGL technology using the three.js library. One of the objectives of this demo application is to inspire people building on top of the OpenTok.js SDK, showing them the beginning of endless possibilities on how we can present the video screens in a true 3D world. Cameras, lights, textures, rendering effects, and more, can be leveraged to enrich the final experience.