mendhak
Feature Request: Websocket support
Would love to see websockets support. Since you use OkHttp for your URL logger, and since OkHttp supports websockets, it looks like a modification of the CustomUrlLogger could make this happen.
I'm no a Java programmer, so it will be a challenge for me to try this on my own. Any advice and I would give it a try.
The main reason regular HTTP connections have been chosen for CustomUrlLogger is around how the jobs are scheduled. The CustomUrlJob is 'stored' using Android Job Queue to disk. This allows for the CustomURLJob to be executed or re-executed when the service is killed and reopened, or when the user has no data connection for several days. So of course the regular HTTP Request fits this nicely and in a safe manner.
WebSockets should also be able to work here; theoretically once the handshake has occurred then there is no need for it to happen again, so it should be a matter of implementing and trying it with the various conditions. Queue up several sends, then kill the app. Turn mobile data off for a few hours then abck on. Restart the phone and reopen the app. So this is where it's new ground for me. I don't know what caveats and gotchas will occur as a result of the assumption of a persistent connection vs the real world conditions of usage.
In terms of code-flow... I think if the user enter ws:// or wss:// in the Custom URL preference screen then that should be how the code decides to use the WebSocket code. I'd not like this to be a separate checkbox. It can be a separate CustomUrlWebSocketJob if necessary, the decision can be made in CustomUrlLogger.
It's also important that the current TLS certificate validation still occurs. Right now a user can enter https://example.com with a self-signed certificate, then press 'Validate' to go through a validation workflow; so that would still need to be preserved and the user's certificate trusted.
As for starting, probably worth having a go at this and this to get an idea of its workings, there's a websocket echo service at wss://echo.websocket.org which can serve as a test area.
So once that's done... then it's a matter of plugging it into the existing workflow. Make a copy of CustomUrlJob, call it CustomUrlWebSocketJob. Branch into it from CustomUrlLogger if the user has used wss:// in their URL and then start sending data from there.