[Feature-13190]How to terminate perspective session from mobile?

That would be an additional property, but not as useful for what he wants because you have to infer yourself whether it's alive or not.

We know when the WS is closed definitively.

2 Likes

Trying to detect the websocket status isn’t going to be reliably helpful for the reasons already discussed: there is no way for the session to know if it was closed because the user was done with the app, or because of a network hiccup.

I think a geolocation ‘mode’ makes sense. It would be set on geolocation’s configuration properties, maybe something like ‘request’ vs ‘subscribe’. The request mode would change the way that geolocation info is collected such that rather than subscribing to the devices location and storing it in session props it (as @waldner suggested) would work more like barcode data handling does. In this mode, the value will be triggered from the device directly, but rather than written to session props, it is submitted to the gateway on a push-basis. Result being that you only receive values when the device submits them, which would prevent the issue of stale values in the session props as the props aren’t held anywhere persistently. Session props are extremely convenient for easily binding to, and there are use cases for this more persistent location data, but I understand how that might not be ideal in all scenarios.

Thoughts on the mode idea?

A websocket connection status property may be useful, so we do have a feature ticket for that, but I wouldn’t suggest it for this case. Same with @pturmel 's suggestion of a lastMessageReceived timestamp - definitely useful, but probably not ideal here.

I like the idea of request vs. subscribe. Maybe there could be an event when coordinates come in, in either mode. That would be less noisy than a packet timestamp but yet convey a truly current value. A similar event could handle a list of collected timestamp, coordinates pairs from offline mode, whenever y’all get around to that.

Perhaps something could be learnt from PubNub’s session management using heart beat message between client and server to detect network failure.

Perhaps reporting data on exception basis when client detects in a periodic cyclic loop (say every 5 seconds) its own coordinate changes to the gateway.

1 Like

In this case, I don't really mind; as long as the websocket is closed (for whatever reason!), I don't want GPS coordinates since they will be stale, period.
And as I said earlier, another nice feature to have would be a way to access session properties from gateway scripts directly, without having to use message passing.

# made-up pseudocode for gateway script
session = system.perspective.getSession(session_id)    
if not session.props.is_websocket_down:
  # read coordinates directly from the session...
  lat = session.props.geolocation.data.latitude
  ...

I like the idea. It could be useful for more than just my use case, and surely would give better control over coordinates collection.

This feature was added in the nightly build that was uploaded today (5/2).