Can i use elixir channels to push notification to android or IOS device like how google firebase do??
1 Like
You would have to write a transport [0] (or something like that) for push notifications, probably (which are usually http/2 now) since they are different from websockets and long poll with which channels work right now.
It would be easier to just use one of the libraries made exactly for push notifications [1][2][3] and call their functions from within your channels.
You might also want to consider using something like a queue or a genstage [4].
[0] https://hexdocs.pm/phoenix/Phoenix.Socket.Transport.html
[1] https://github.com/inaka/apns4erl – ios only (supports http/2)
[2] https://github.com/codedge-llc/pigeon – ios and andriod (supports http/2)
[3] https://github.com/chvanikoff/apns4ex – ios only (http/1.1 only?)
[4] https://blog.discordapp.com/how-discord-handles-push-request-bursts-of-over-a-million-per-minute-with-elixirs-genstage-8f899f0221b4
2 Likes
Thank you 
I wonder if Android lets its apps keep tcp connections open when the apps are not active. If not, that might not work.
I think Apple doesn’t allow this, so to deliver a push notification to an iPhone when the app is not active you have to go through APNs.
You would have to write a transport [0] (or something like that) for push notifications, probably (which are usually http/2 now) since they are different from websockets and long poll with which channels work right now.
Actually, here’s how you can do it https://youtu.be/engXVCCk9bg?t=582
Still, I would just use a library.
But for both Android and IOS there is only one way that is codedge-IIc/pigeon
Check my answer on the same topic. Many answers here are not battery friendly.
1 Like
How exactly is mqtt more battery friendly than something like apns? Both of these require a persistent tcp connection, do they not?
1 Like
I went through the Pigeon library’s docs. It uses HTTP2. FCM too relies on persistent HTTP connection. Below I have attached a comparison of HTTP and MQTT.
MQTT was designed for connecting devices, sensors, etc. over an unreliable network. It has a low network overhead. Thus, keeping persistent TCP connection is more battery efficient. Further MQTT was built for remote sensors which don’t have huge power backups available. Read the articles below as they have done a better job at explaining the why and how.
But there might be other reasons as to why you wouldn’t want MQTT. If you or your organization is reluctant to monitor security at ports other than 80 or you already have running infrastructure over HTTP2 or other preferences then you wouldn’t want to run MQTT.
And there is a good use case where a firm opted out of MQTT.
I for one feel there are too many benefits with MQTT along with customisability to overlook. MQTT gives necessary autonomy and fliexibility to build a highly customised mobile app, IoTproduct.
2 Likes
I do like mqtt as well, but the overhead from ws/mqtt/http2 is negligible in comparison with that of tcp, so I don’t think there is much difference in practice.
1 Like
There is also a library to connect kotlin client with phoenix channels:
