Research

Existing alternatives to our app

Some of the solutions that already exist to solve the problem we want to solve are the classic, traditional assistive devices for visually impaired people. Those can include canes or dogs. Both of them are well known and have been working very well for many years. Still, both of them have many limitations. They could not get environmental feedback to the blind user. Some apps try to solve this problem as well, one great example would be “Step-Hear” but it just tells the user the location and maybe some tourist spots from there. It also works only in certain zones (our app can work with the “remote” setting anywhere). However, it warns the user if there are cars that can pass through the zone where the user is located or it tells the visually impaired person about some access points in some buildings. These are some features that should be added to our system in the future. [1]

Existing solutions

---

Connection between C++ server and NodeJS client

Short Polling

When short polling is used, requests are processed as they come on the server. It creates much traffic (uses resources, but frees them as soon as a response is sent back). This was a good alternative some time ago, but now it is rather dead.[2]

Long Polling

Long polling sends requests to the server and the client is waiting for the response to come until timeout. So the traffic is smaller, but resources are blocked for some time. Its best advantage is that it is very versatile, it works in every environment. However, it’s harder to starve the server of TCP connections and its lack of “real timing” made us not choose this alternative. [2][3]

WebSockets

WebSockets enable the server and the client to send messages to each other at any time. The connection is established only once at the beginning, and after that, there is an open channel for sending and receiving data. After some research, we found out that, to achieve real-timing, most of the developers best choice is WebSocket, so, we have decided to use this one. [2][4]

---

Getting the messages to the mobile app

WebSockets

Firstly, WebSockets seemed like the best alternative. We could use them and also get rid of the NodeJS client. Seems good, right? Unfortunately not. By using WebSockets for this part of the system we would have had limitations. One of them is that there was no good way to implement the “static” feature. So we kept searching.

Bluetooth

Again, we thought that we found the best option, and it may be. However, there were downsides because the NUC computer would need a Bluetooth adaptor. Besides that, the fact that the visually impaired person would have to connect the phone to the static systems each time he/she would want to use it would be quite inconvenient. [5]

Using a database

We are talking about the Firebase Realtime Database. When you’re connecting your app with Firebase, you’re not connecting through standard HTTP. You’re indeed connecting through WebSockets under the hood. You do not have to configure all that real-time stuff on your own. It may not be the best option as a system as this one should not use “cloud”, but it does not store any data from the user. After experimenting, we concluded that this is what we need. It worked smoothly with both the static and the remote parts of the system and we had no problems with it when testing. [2]

Related Technologies

As the C++ Server was already done when the project was handed to us, we did not change that at all. What we did change was the React (old front-end part). We transformed that into the NodeJS Client. We thought a lot about what to use here.

---

PHP vs NodeJS

We had no experience with NodeJS or PHP. We found out that PHP would be an easier option as it is easier to be learnt. “There’s not much to PHP: a few variables and basic functions for juggling strings and numbers”. Although this aspect can be quite important, we think that it is better to build a better and faster application than to build one in an easier way. So, because NodeJS is better regarding the speed of the app we decided to go with this one. “Writing JavaScript code is a bit harder when you’re counting curly brackets and parentheses, but when it’s done, your NodeJS code can fly.” [6][7][8]

Regarding the app, we had to choose between the well-known rivals React Native and Flutter.

React Native vs Flutter

Flutter gives developers an easy way to build and deploy visually attractive, natively-compiled applications for mobile (iOS, Android), web, and desktop – all using a single codebase. React Native is an effective framework for cross-platform development, building mobile apps using JavaScript language and developing applications for both Android and iOS using a single codebase. React Native uses JavaScript: a programming language that many developers know well and so do we because we used it in our NodeJS Client. However, Flutter uses the “Skia Graphics Library”. Thanks to this, the UI is redrawn each time when a view changes. Most of the work is done on GPU; that’s why Flutter UI is smooth and delivers 60fps, so the app works faster and faster is what we want. [9][10][11]