I have a web socket that I need to receive information from in my android app. Would keeping a single web socket open at all times drain the battery on my android device? I expect that this web socket will only send notifications once every 24-hours, which is why I would like to close the connection, and somehow convert the web socket into a push notification. But, then I also need to be able to send from the android app to subscribe to the web socket and receive push notifications. How can I go about doing this?
I recommend using push notifications, which consume less battery of your phone and even more if you only send data once every 24 hours.
What technologies you plan to use?
Related
Currently I am working on an alert app, which receives push notifications from a server. Reading a lot about that topic on the internet lead me to firebase which can be used to achieve that.
Now I was wondering: Are Whatsapp, Signal and other messengers using firebase or do they have any other solution to receive messages from servers even if the app is not active opened?
They use push messaging. It might be firebase, it might be another provider. MQTT is popular. All any of those things do is open up a persistent socket connection to a server and listen for messages. The trick is that whatever process is doing that needs to be whitelisted from power management restrictions, because you don't want to delay your message notifications for 15 minutes.
Now if you're writing something that's supposed to be robust queueing on the server side and deduping on the client side would be a good idea. But the basics is open socket connection and block on it on a thread.
I was wondering how the actual request from Server get routed to the Application if the browser is not running. Also, does the service workers maintain an active connection to the server so that it receives the push notification whenever the server publishes something?
I think for every iOS device, Apple keeps a socket open between that device and the Apple Push Notification Service. Which essentially acts as a router for all notifications across all apps and all devices. So your server can send messages to APNS saying "yo, hit up this guy with this message", and APNS will use the socket it has open with every device to send the notification.
Also check out https://developer.apple.com/notifications/.
And https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server
iam developing a chat application and now am on it's push notification part.. And now am in a big confusion.. because in my previous application iam using Google's GCM like, whenever i get a notification from the GCM server i pull data from my server.But in this case i think it's not the right way for a chat because if i try to do like this i have to connect the socket again and user will become in online status.And also am using raw socket for my application.
is there a better way for accomplishing this?
thank you
I am using web socket for push notifications. In my android application (client side) I use Autobahn web socket client. It works fine, but if you want reliable solution then I think you can go for Azure Push Notification Service. But I think you can only send/receive few push notifications using their free service. To scale further you need to pay.
But using web socket you can send as many number of notifications as you want. Further, you can keep the connection always on, so that you don't need to reconnect the socket connection every time. But to ensure the active web socket connection you need implement PingPong. And that PingPong might use some the bandwidth.
I want to have an active service on my android phone.
This server will be available from clients in my local network.
Communication can be any (for example a rest api service on android)
In other words I want my service to handle external push notification but from local network not GCM.
What are know approaches to achieve this?
As part of an Android app I'm developing there is a chat room feature. We have a server which can process the incoming messages and store the messages. Is it better to keep a socket connection open between the phone and the server so the server can send any new messages to the phone, or is it better for the phone to poll the server for new chat messages?
It is bad solution with poll for app that have randomly posting data. What I want to say is that polling data is useful when you have something that is happening discrete like every 5 minutes or something like that. this is not the case with chat, some user can post something ones in a hour , some can post 30 times in 2 minutes
so keep your sockets open
Polling lacks real-time connection and a persistant connection is battery draining. I think that what you are looking for is a combination of "push"-ing and persistant connection. You would wake your phone via push, and then establish a connection via sockets to handle chat.
I suggest reading this article.
I'm not sure if it mentions c2dm, the google push service.
I would keep the socket open if you are worried about instant messaging, it takes time to setup the socket connection especially if you are using the GSM connection. I have seen it take 10 secs or more to open up a socket on 3G, much less if on WiFi.