URLConnection as Client for Server-Sent Events?

Before I build the experiment, does anyone know if URLConnection can be used as a client for server-sent events? Wondering if, after the initial async Send, the connection remains open and I’d be able to parse the events using the ReceivingProgressed event?

I can tell you we’ve tried but where unable to get more ContentReceived events than once.
However it would be possible to request it as a feature in Feedback.

The only other option is a TCPSocket or SSLSocket.

Yes I’ve had this in production for a number of years now in our iOS app so that the app knows when data has changed and needs to be refreshed locally or when some other event has happened that the app is interested in. It works very well. The connection stays open but it can drop under some scenarios. The solution I use to keep the channel open is a regular “heartbeat” call every 50 seconds (because the timeout on the channel is 60 seconds by default) using the heartbeatUrl value returned by our SSE service in the response to the successful initial connection. If the channel ever disconnects (and it will from time to time) you just go through the initial service call again as though you were establishing the channel and restart the “heartbeating” timer.

That’s good to know – much appreciated!

Interested in this. What is the server-side scheme to manage these connections that you’re using @JasonTait ?

Steve

That is not how it’s suppose to work. It should maintain the connection reconnecting is costing resources for nothing. Xojo can implement this maybe, if you put it in an FB request

Unfortunately I won’t be of much help in this as we have a team that looks after the services. We use Angular.

In iOS, apps are suspended when they are backgrounded. In that scenario, the heartbeat does not continue to run. Depending on how long the user has been away from my app the authentication refresh token might have expired and I also need to get changed data and deleted (tombstones) data and update the local cache. Having to reconnect to the SSE channel is trivial against all of that. :slight_smile:

sse send data when the sever wants to do so. If you have to reconnect every … seconds you gonna miss data. The specs suggest that the connection (can) be kept alive. Still you may miss data if you reconnect every … seconds unless you server has specific (url) parameters to send from a specific point or you dont need to receive all.

It only has to reconnect periodically, as I’ve explained, when the app is backgrounded for more than 60 seconds or in other cases such as when the device has no data connection for a time (eg user is in an underground carpark). It’s not possible to guarantee a permanent internet connection on a mobile device. But it’s fine for my app because I don’t use SSE to sync data. I only use it to reflect live updates to data while the app is foregrounded for the user. So if you change something on your device and I’m looking at it, then it will also virtually instantly change on my device.

Has anyone been able to do this with Xojo server-side ?

In my reading of the spec, reconnection is accounted for and you use the Last-Event-ID header from the client to figure out where the stream left off.