Open tijaska opened 2 years ago
Github is mainly an open source code repository, but it does allow projects to publish their web pages via the Github site, e.g. https://tijaska.github.io/sossms/ No guarantees on uptime. The open source projects may include server-side code, but it isn't available on the free Github hosting facilities.
As it stands, my sossms apps don't need their own server-side code. They hitch a ride on SMS, which is woven into the fabric of the cellular networks, or WhatsApp, which Facebook provides free of charge. It does mean that the users need to hit the Send button twice, once in the app and a 2nd time in SMS or WhatsApp, but it's a low volume application so this isn't a big concern. But the stranded driver may inadvertently break the link that's embedded in the SMS or WhatsApp by adding extra text while the message is on display.
I would like to add a notification push facility to the apps, particularly to the stranded driver's app. It would gather the inputs and send them to the host web server to an app that uses push notification to send the info to the rescue hub's app, in the same way that an SMS or WhatsApp message gets pushed to the recipient's phone. It makes a noise of your choice, raises an alert symbol at the top of the phone screen, and when you drag it down it shows you the outstanding alerts. Click on any one to view it. This approach would give the stranded driver less opportunities to louse things up by changing the text of the message or forgetting to press the second Send button, thinking that the first Send did the job.
This would only work if the rescue hub operator installs the hub app, which is easy to do, and I will make sure that the app encourages them to do so rather than just running it in a web page each time it's invoked. If they fail to do so and a stranded driver tries to push a notification directly to them I will give the driver feedback that the push failed, and advise them to click the SMS or WhatsApp buttons that will still be available.
Similarly the rescue vehicle drivers could be encouraged to install the rescue driver app on their phones, but rescue drivers is a role rather than a career. A driver may fall ill or suddenly take leave, and another person gets drafted in. They may not be told to download and install the rescue driver's app before hitting the road, so we can't assume that it will be there. The rescue hub app could be changed to allow the hub to push direct notifications to rescue drivers. If they work, well and good, otherwise the hub will be informed that the selected rescue driver doesn't have the app installed and enabled to receive direct messages, and they will have to fall back to SMS or WhatsApp. The rescue driver will get this message, open it, click the link, and their app will run in a web browser page. That's the beauty of progressive web apps - you can start simple and build up.
Since the free Github web app hosting doesn't include server-side web app coding, we need a service that does. Google provides web app hosting through a service called Firebase:
https://firebase.google.com/products/hosting
It's free for small to moderate volume web apps, then charges kick in. Clearly they hope that you will succeed and become wildly popular. A vehicle rescue app is unlikely to become high volume, but you never know. Firebase allows you to include server-side app coding in your web app. So I will work towards that goal.
But the downside of a push notification is once the rescue hub has clicked on the notification and the sossms app has opened, the notification is gone forever. The hub operator may get an urgent phone call immediately after opening the help request, and in answering it and looking up some info asked for, inadvertently close the open help request. The it's gone, together with the name and phone number of the stranded driver. The rescue hub app does keep a log of all rescue requests opened, so the hub operator could open the log and click on the dropped request, which should be top of queue. It would open again, and the hub operator could deal with it.
The innate advantage of using SMS or WhatsApp to send rescue requests to the rescue hub is the SMS/WhatsApp remains after the link within it has been clicked and the rescue hub app has opened. Failing all else, the hub operator could return to the original SMS/WhatsApp and click the link within it again to reopen the request.
Another potential drawback of using server side push notifications instead of piggybacking on SMS or WhatsApp is it opens the door for prank calls. A caller could stop at a quiet spot, scan a QR code to get help request open, enter false name, phone number and other fields, drive off with the help request SMS still open, then send it. The rescue driver would drive to the quiet spot and find no one – a great waste of time and resources. Even if we require the caller to install the help request PWA, a PWA can't get the caller's phone number. It would have to be a fully fledged phone app in order to do so. The caller would have to find the app, install it, then get an invitation to request help from the rescue hub and open it in the app. This would make getting help a lot more time consuming with more opportunities to get things wrong, when the user is already under stress. A benefit of requiring the stranded driver to piggyback on SMS or WhatsApp is the rescue hub will get a copy of the caller's number that can't be forged from the messaging system used.
Currently sossms asks the stranded drivers to send their help requests to the rescue hub via SMS or WhatsApp. The sender has to click Send twice, once in the app and once again in SMS or WhatsApp. The sender may not have WhatsApp installed, must then use SMS which imposes a message length maximum of 160 characters, although almost all phones will automatically segment longer messages and reassemble them at the far end, but each segment is charged for.
We could implement a notification push service for sossms so that help requests flow to the sossms web server, and it pushes a notification to the nominated rescue hub. The stranded driver would pay only data costs, typically 1/1000 that of an overseas SMS.
The sossms apps are coded in HTML and JavaScript. Many different languages could be used to code the server notification push, including JavaScript in NodeJS. The advantage of NodeJS is that only one language would be used for the entire system, reducing the need for diverse coding skills.