Anyone have experience with sending notifications to a Xojo Mac/PC app?
I’m looking for a solution so that my sync service knows there’s something new so that it can contact the server.
I’m not referring to visible user notifications.
If your sync service is using PostgreSQL, take a look at Notify and Listen capabilities. I use the MBS ones.
Alas, no. SQLite using Zumero for the heavy cloud lifting.
I’m just looking for a way for a Xojo app to keep a connection open so that any popular push service like PubNub can always talk to it.
The easiest (and potentially safest) way is for the client to connect to the server periodically and check for messages. Which could be a SQLite database (or CGI protected SQLite Database).
Ah, thats what Im currently trying to avoid as my server is getting hammered with thousands of requests to check if anything is new.
I see… The trouble is, going t’other way invokes a bag of pain as the server then needs to bust through firewalls to reach the clients, Not to mention that your server then needs to start initiating connections to client, whom may no longer be connected. Wasting resources and bandwidth.
If it’s possible perhaps coalesced some messages, and reduce the frequency of the clients checking. I don’t know how time critical the messages are for the clients.
Another possibility is to create another server specifically for notifications, when the main server needs to send some thing, it sends it to the notification server, which in turn awaits a connection from the client to pass it on. This way the “Notification” server has a minimal workload, which should reduce the amount of each time a client needs to be connected and should reduce the workload of the main server.
Or… If you want to keep it all on one server, perhaps you could cache your messages, so you get the same benefit as the suggestion above i.e. reduced workload for handling Notifications, more time for main work.
Just a couple of ideas, I hope that they’re useful somehow.
Just out of curiosity, how much does your server have to do to respond to that request? Maybe the solution is to add a table that just includes a userID and a last message number so the request could be very simple and the response would be completely empty except for the status of 304 which means Not Modified or nothing new.
The thing is though that it is a basic principle for security guys not to allow servers to initiate communications with clients and they go to a lot of trouble to make sure that does not happen. And that would come after the task of trying to find the devices in the first place - some people have static addresses while others have dynamic, some accept broadcast messages, some dont.
Maybe trying to move that functionality to a separate server might be the best option.
I understand and traditionally always thought the whole notion of maintaining a constant connection to the server was difficult. However push notifications to apps have become common place and there’s many web services such as PubNub that do nothing but push out notifications to clients. Almost every app that syncs these days receives a notification PUSHED from the server that something has changed. You can see this in the responsiveness of apps where you make a change on one and it’s reflected within seconds on another device which is simply not realistically possible for clients to query the server that fast and continuously.
So how is it that the other apps are able to get notified easily without fighting through firewalls? Is Xojo any different?
Yes there is some notification capability on most platforms by now, I guess that there has not been the demand from XOJO developers to have it exposed in XOJO. It works best on mobile devices, because it is just the accepted thing. This is not the case on desktops - corporates and users turn it off for security reasons.
I did a bit of exploring of it for a bank a while back and it did not work out, even in the control group there were too many people having problems with it and of course they started to flood the help disk with calls and bad mouthing the application for not working… in the end they went with a simple check on login and once every 15 minutes while logged in. The just told people that prices etc were delayed and if you needed realtime hit the refresh button.
If your server app can write to an area that is also served by a web server such as Apache this might help:
-
Get your server to write a status file to the web server when messages are changed. This should be the same file each time and with a value that is different to what was previously in the file (for example, microseconds).
-
Client App
a) Within your apps permanent storage (eg: preferences) implement the ability to store a status value string.
b) Get your client app to perform a standard HTTP GET request to download the status file.
c) If the status value you downloaded is different to what you have stored in your permanent storage perform the request to get the messages and update your permanent storage with the new status value.
This should reduce overall load as most of the requests will become lightweight GET requests which will be handled by the web server. The much heavier request to get messages should now only occur when the client thinks something has changed.
An even more lightweight request would be a HTTP HEAD rather than a GET but that will rely on you using the response headers to determine that something has changed.
If your messages are user specific it might be more efficient to have a status file per user. Be careful with this approach though as you dont want your server app to write thousands of status files to the same directory,
I think you’re referring to WebSockets. Basically this is achieved by the client opening a special connection to a server, but then the connection sits idly waiting for the server to send something. Both the client and the server must support the WebSocket protocol. I don’t think just any standard client and/or server can do this.
But for the client-side in Xojo, the first thing that comes to mind is trying to use an HTMLViewer to monitor for a WebSocket message (because most browsers now support this). I found this brief discussion on it https://forum.xojo.com/41660-websocket-in-htmlviewer-not-working
And then there is also this to see GitHub - ktekinay/Xojo-WebSocket: A WebSocket class for Xojo
I hope that helps.
[quote=482299:@Stephen Dodd]Alas, no. SQLite using Zumero for the heavy cloud lifting.
I’m just looking for a way for a Xojo app to keep a connection open so that any popular push service like PubNub can always talk to it.[/quote]
PubNub has a couple of blog articles you may find interesting on WebSockets and Long Polling and another on just how Long Polling works. I’m guessing it would be easier for you to implement Long Polling in your Xojo apps, provided of course you also control the server side code.
Also, if you have access to the XDC 2019 videos, you may want to check out @Tim Dietrich’s session “Get Hooked on WebHooks” which includes sample Xojo code for implementing webhooks.
Or do generic web searches on webhooks, websockets, and long polling to give you more ideas.
What about MQTT?
So you found in corporate environments that incoming notifications were being blocked by firewall/security settings? (And just to be clear, we’re not talking about user visible text notifications)
That would be a problem for me as it’s a business app.
That sounds ideal if push notifications aren’t otherwise viable. Certainly seems like a simpler setup at least with my experience.
[quote=482553:@Douglas Handy]Also, if you have access to the XDC 2019 videos, you may want to check out @Tim Dietrich’s session “Get Hooked on WebHooks” which includes sample Xojo code for implementing webhooks.
Or do generic web searches on webhooks, websockets, and long polling to give you more ideas.[/quote]
Thanks Douglas! Looked at Tim’s stuff. Handy. And I didn’t know about long polling before! New stuff every day after all these years.
[quote=482540:@Scott Cadillac]But for the client-side in Xojo, the first thing that comes to mind is trying to use an HTMLViewer to monitor for a WebSocket message (because most browsers now support this). I found this brief discussion on it https://forum.xojo.com/41660-websocket-in-htmlviewer-not-working
And then there is also this to see https://github.com/ktekinay/Xojo-WebSocket [/quote]
Cool! Very helpful. Thanks!
[quote=482745:@Stephen Dodd]So you found in corporate environments that incoming notifications were being blocked by firewall/security settings? (And just to be clear, we’re not talking about user visible text notifications)
That would be a problem for me as it’s a business app.[/quote]
Yes in bot the financial services and pharma business, think about it for a minute, any security officer that would allow an unknown service from outside their environment interact with a workstation on their network would be leaving them very exposed and probably would not have a job for very long. They always start from the other side - close everything down and up stuff only when it has be justified and approved by the powers that be.