The ideal systems’ team hopes that 2019 has been a successful year for you. For 2020, we wish you and your organization a prosperous and happy year!
6 years ago when ideal systems started to develop mobile apps, there was not much choice regarding development platforms. More specifically, platforms that allowed to handle multiple target platforms like iOS, Android and Windows, while using the same codebase. Therefore, after an analysis of development frameworks, we chose Cordova as our platform.
There was not really a problem using Cordova for small apps. However, we noticed that when the apps became more complex, the single JavaScript threading model reached its limits. As a result, the performance was slow and the behaviour was sluggish. The main reasons why we chose Cordova at first was:
As we kept in mind what we had learned so far, we conducted in 2016 a new analysis regarding the new available platforms and chose React Native.
Through the development of our first app, we encountered some restrictions of the framework (at least we thought so at that time):
In order to solve these ‘shortcomings’, we looked at the community for solutions. As a result, we chose Redux for state management.
The advantage of Redux is that the state of the object can only be changed through an action. This means that there is no two-way communication between the layout and the store. All communication follows the same pattern. This results in clean code, easy debugging and above all no ‘magic’ happens behind the screen when syncing store fields and layouts. An additional advantage of Redux is the characteristic of forcing its users to work with some kind of skeleton. This skeleton includes actions, reducers, components,… which results in a more legible code.
After a rewrite of our initial app, using Redux instead of Flux, we finally got a clear understanding about the advantages of React Native.
As soon as the skeleton was in place and the basic framework functions had been implemented (network on/off, device foreground/background, REST functions, push notifications,…) we rapidly advanced in developing the user interface. Once you get the hang of it, the development goes really quick and the multi-platform aspect was also straight forward.
Next step was making our own native modules based on external SDK’s (like WebRTC). With some of the SDK’s we encountered some issues preventing them to be integrated in React Native. Mainly the SDK’s including visual layout could be an issue. SDK’s that only provide functions – without layout – did not cause any problems.
One of the shortcomings of the React Native bridge component is that all communication with the native components are done asynchronous. This means that if you need to wait for results from the native side and then want to continue in the app, there is no solution at the moment. The React Native team is working on a new architecture (code name Fabric) that allows synchronous communication. Moreover, it will also be possible to hook your own JavaScript engine! This brings us to the next part of the story, React Native’s version management.
Each month there is a new version of React Native. This implies that, if you want new features and bug fixes, you need to keep up with your code to get it running with the newest version. Additionally, the current version 0.X is not officially supported. The first official supported version (as seen on Facebook’s blog) will be the 1.X version including the new architecture. This new version will probably be launched in 2019. Although, no official word on this topic yet.
At the moment, we have a full-grown application build on top of React Native that is working at 60 fps, where this was previously the bottleneck when working with Cordova (and the reason why we chose React Native).
In summary, I would say that we have made the right decision and are very thrilled with the next developments that are going to happen. Even now, when other frameworks like Flutter pop up, we are still convinced about our decision and will continue using React Native.
Article written by Dirk Slootmaekers (CTO at ideal systems)
WebRTC has been around for some time now. However, it has never been easy to set up, configure and eventually make it work. That also applies when WebRTC is set up with Genesys PureEngage contact centre software. This article describes our experience and findings with WebRTC and making it work with Genesys PureEngage and mobile devices.
Genesys contains a WebRTC Gateway server that connects with their SIP server. To make this work, you need to place the WebRTC server inside the DMZ. With this architecture, the setup of the call path requires additional STUN and TURN servers. Due to the need for TURN servers, the overall solution becomes more complex and requires additional hardware. In case you need transcoding, all voice streams go through the TURN servers, creating a potential bottleneck.
Another problem is that only a JavaScript SDK is available and therefore this WebRTC architecture cannot be deployed on mobile devices.
We therefore decided to abandon this path and look for an alternative solution.
After scanning several options, we finally came up with the Audiocodes SBC, which has a WebRTC gateway embedded. The advantage of this setup is the simplicity of the architecture. Since the WebRTC gateway is online (SBC works as a firewall), there is no need for additional TURN servers. You only still require a simple STUN server (we took the easy road and used one from Google).
After configuring the SBC to work with the SIP server from Genesys, we are now able to setup WebRTC calls with SIP enabled agents. On top of that, iOS and Android SDK’s are recently available, next to the existing JavaScript SDK.
Our Mobile Office solution now also embeds these mobile SDK’s. Hence Mobile Office is now fully supporting WebRTC call functionality for contact centre agents using the Genesys PureEngage platform.
Article written by Dirk Slootmaekers (CTO at ideal systems)