2.3 Clients

What can be the problem or challenge that we might be facing? Well, let’s look at it that way. We’ve got different chipset vendors. Specifically, we’ve got Intel architectures, and then arm architectures. We have multiple mobile platforms, Android and iOS. If you go to the desktop, or laptops, then we’ve got Windows, Mac, and Linux, different operating systems for the desktop. Then we have different browsers, which sometimes support browsers directly. So Chrome, Firefox, Safari and edge. On top of that, we have different cross platform development frameworks, like flutter or react. And then there is Coco’s and Unity, which are used for gaming and 3D. And we have peripherals, USB ones and Bluetooth ones.

Each and every one of these icons here and many others, are going to affect the amount of headache that we are going to have in our development. Just to give an example, let’s take Android. I like this slide because it shows the different fragmentation or the different Android devices that are available out there. This is from a few years ago, it’s not new. Today, the fragmentation might be even higher than that. Android devices are different from one another, by the version of Android, they support the chipset that they have the memory and CPU that they have on the device, hardware acceleration is it available or not for the different activities that we need to run in real time engagement platforms, and the peripherals that you connect to them. I can connect one Bluetooth device, you can connect the different type of headset…there are devices that going to the audio jack, okay. All of that is going to affect the experience of the user. And we need to test for that.

What are the differences that you can expect across devices? And not only on Android. There’s the operating system that might be different. And within an operating system, the versions are different as well. And that’s going to affect the different API’s that are going to be available for us as developers, programming languages are different across devices. Not all of them are capable of running or are able to run different languages, the different frameworks, cross platform frameworks that we might want to use. And they might be available on different devices, Again. The chipset of the device is specific to that device. That also means the device drivers that are going to be there and the OEM version of the whole solution, the package of that specific device. And then there are the peripherals that we connect to them, and the codecs that are going to be supported. So, what are we to do with so many devices? We need to think first of all about what is the first set of devices that we want to support, these are going to be the hardest for us to handle. Because each new device is going to be a new kind of world and domain that we are going to deal with, we’re going to deal with new problems each time. Now there’s a learning curve here. Okay, so the more devices we support, the less investment with that will be required from some given point in time. But the first few devices are going to be the hardest.

So, let’s summarize this. What you need to do is to decide on your client devices in advance. Why do you want to do that? The more devices you have, the more work you will have to do. So, limiting that number, at least in the first phase will help you out with this challenge. You need to have the team scaled appropriately with these operating systems and devices, you need to have the devices in place and you need to figure out your testing strategy. Are you going to purchase all of these design devices and test them in your lab? Do you want to test it in the cloud? Let your users test them for you crowdsource the testing for that, not test and see what happens when people complain? All of these are valid approaches. You just need to decide which one you’re going to use. Thank you.