Push Notifications or Socket.io?, or Both?

16,764

You have listed the pros and cons accurately. Using both will give you more work in terms of maintenance, and also more complexity, but will give you the flexibility you're after. It will boil down to your requirements.

Also you will probably find that having a socket.io connection open in a iOS background process will be troublesome. iOS is much more restrictive in what tasks can run in the background than Android.

Share:
16,764
PDK
Author by

PDK

Updated on June 06, 2022

Comments

  • PDK
    PDK almost 2 years

    I'm developing a chat system for web, Android and iOS. Doing my research I've found differences on how GCM and APNS handle the Push Notifications.

    If I send a Push Notification to a Android Device through the GCM, the device its able to decide if it notifies the user about it, or if its not necesary, it doesnt tell the user. It could be just an update of data that the user doesn't need to be notified. On the other hand, if I send a Push Notification to an iOS Device through APNS, the device is not able to decide whether to show or not the notification, the notification must be shown. Also, when an iOS Device receives the notification, the notification data must contain the string that is going to be shown to the user. On Android, the device can generate that string.

    So, I wanted to create a system that works the same way for both iOS and Android, and also for the website (API based). Thats when I found Socket.io. Socket.io gives me the freedom to send data to the device (no matter if its iOS or Android) so that the device decides whether to show or not the changes made (could be an update of a user, a new message, an invitation, or many other "events"). But, doing my research I found some cons about using Socket.io. The Device must be connected to the socket so that the information flows between the client and the server, but a smartphone, in the real world, connects and disconnects all the time to different networks, and that breaks the socket connection. Also, by having the connection open, on the background, there is a ping pong between the server and the client to verify that the connection is still open, and that ends up consuming megas (In my country, we pay for every mega we use, we don't have a flat rate yet) and also batery life. I don't know for sure if that consumption is significant or not.

    On the web side, it must work with Socket.io, so thats not a problem at all.

    Finally, knowing the pros and cons of both alternatives, I found that I can mix both options and that might end up being my best option. For example, when the app is open it uses Socket.io and when is closed use the APNS or GCM (depending on the device OS). But, is it a good practice? Or will it be better to stick just with 1 solution instead of mixing both and why?

    Thanks a LOT for taking your time on reading this and even more for answering.

  • PDK
    PDK about 8 years
    Thanks for your answer, is good to hear that I'm heading the right direction.
  • Tank12
    Tank12 over 2 years
    I know this is an old post, but I am in a similar situation here. do you have any documentation that details the limitations that apple puts on background processes?