Hello, I want to create a socket api for mobile app and I test it with wscat libe in terminal, but after seconds it shows me a Disconnected (code: 1000) and it is closed if I don’t push anything to client.
how can I keep it alive in phoenix socket client (terminal), for example I should push a massage like string “ping” to my client?
No, just a proper client for the channel. wscat just connects on a websocket and you need to talk raw. If you never send a heartbeat, the phoenix will eventually disconnect you, depending on the timout settings.
"heartbeat" events in the "phoenix" topic - should just emit an OK reply
"phx_join" on any topic - should join the topic
"phx_leave" on any topic - should leave the topic
should I create a handle_in like
def handle_in("heartbeat", _payload, socket) do
{:reply, :ok, socket}
end
or I need to send
send(self, :after_join)
and create a loop with send after like
def handle_info("heartbeat", socket) do
broadcast!(socket, "ping", %{})
Process.send_after(self, {:heartbeat}, 2000)
{:noreply, socket}
end
The JavaScript client already implements sending heartbeats. If you want to write a client in another language, you need to implement the heartbeat there.
The heartbeat is a low level protocol message, you’ll never see it in a way that you could see it in handle_* functions on the server side.
Little word of caution - implementing a client might not be as easy. I was working with a very competent android developer and the channel implementation was a constant source of bugs and problems. Especially if the app is sometimes supposed to sleep keeping the connection alive around OS energy optimization can be pretty rough.
I’ll never forget the joy in the devs eyes when we switched to a simple REST API instead of channels
Heartbeat is already built into phoenix channels and pjoenix.js and they do it automatically. Most of us have never sent one manual. You can read their implementation code to see what when and how they do it.
Heartbeats do not need to be implemented server side, they are already there and part of the channel protocol, you need to implement them Clientside if you are writing your own client.
You might look into your client languages ecosystem if there are already clients available.
Thanks, I will use phoenix.js then! I was wondering - will Android keep the client on for a longer duration than 30 minutes ? WIll it not kill it / sleep it for battery optimization ? For a use case, I need the client connected to phoenix socket for 2 hours.
in my experience android keeps the websocket going in the background, for how long I don’t know - might have changed depending on your android version etc etc.
(ios kills the connection when backgrounded after 10-15 secs)
In my react native app I have calls doing a disconnect when the app is backgrounded, and connect again when it’s resumed…
Thanks for the response! Keeping the app in foreground for 2 hours would mean keeping the screen on for 2 hours and that will kill the battery . As per my observation, i think android kills it in 30 mins or so.
Connect when resumed would not work for me because I wish to receive message from phoenix socket 1 or 2 hours after joining and then showing a notification, all this while the app is in background and phone screen locked. Anyway, I will try and see what happens.
Now I am wondering is it even possible to build a react native app that shows notification many hours after joining a socket, even when the app is in background and screen is off. (Like chat apps - they show notification upon receiving a message even when they are dead)
Actually, I have tried react-native-push-notification in a react native app that didnt have a back-end and it didnt work as expected when screen is turned off. Android just pauses the handy timer function included in react-native-push-notification until it is back in foreground. I will try the other 2 packages.
Pigeon seem to work only with native apps. Ill have a look.