Approach
Prototyping
Our initial engagement started with evaluating the existing solution, which was a set of two native mobile apps. The primary goal was to improve the stability of call connection and allow technicians to answer calls in a similar manner as in other video apps, such as Zoom or Skype.
First major decision was to choose a platform that would become a foundation for handling video calls. We have assessed the existing solution and compared it to other frameworks: Twilio, Zoom, QuickBloxand Jitsy. In the end we chose Twilio Video, due to its stability, mature native SDKs with extensive documentation and features with a great potential for growth of the Plunjr app (i.e. recording, ability to integrate video calls with web apps, etc.).
Second biggest decision was the choice between supporting two native code bases (for iOS & Android) and a hybrid mobile app. In just a few days we prepared a prototype built with Flutter, but ultimately we confirmed the app to require more native integrations specific for each platform. Twilio SDKs for iOS and Android differed heavily, and as hared Flutter library wrapping both of them under a single interface (being in alpha stage at the time) proved not to be a stable, production-ready solution.
Each of these decisions were made by building very simple proof-of-concept apps demonstrating framework capabilities, assessing its documentation and ease of use of SDKs, and determining other barriers toentry (platform sign up, verification process, pricing, etc.). Each prototype took less than 2 days of development effort, which allowed us to provide the right guidance to our client at a minimal cost.
First major decision was to choose a platform that would become a foundation for handling video calls. We have assessed the existing solution and compared it to other frameworks: Twilio, Zoom, QuickBloxand Jitsy. In the end we chose Twilio Video, due to its stability, mature native SDKs with extensive documentation and features with a great potential for growth of the Plunjr app (i.e. recording, ability to integrate video calls with web apps, etc.).
Second biggest decision was the choice between supporting two native code bases (for iOS & Android) and a hybrid mobile app. In just a few days we prepared a prototype built with Flutter, but ultimately we confirmed the app to require more native integrations specific for each platform. Twilio SDKs for iOS and Android differed heavily, and as hared Flutter library wrapping both of them under a single interface (being in alpha stage at the time) proved not to be a stable, production-ready solution.
Each of these decisions were made by building very simple proof-of-concept apps demonstrating framework capabilities, assessing its documentation and ease of use of SDKs, and determining other barriers toentry (platform sign up, verification process, pricing, etc.). Each prototype took less than 2 days of development effort, which allowed us to provide the right guidance to our client at a minimal cost.
.png)
.svg)
.svg)
