i need to build a app to do live reporting, can you suggest a solution that enables real-time communication? I'd like to go with long-polling this approach.
It will be an Android native app, not a web app.
Is there something already written so I do not need to implement it from very beginning.?
I'm a django, python developer.
This is not a polling solution but when I needed something like this I created a foreground service that creates a persistent socket connection to my server. I then registered with some broadcast receivers to maintain my service, on BOOT_COMPLETED and CONNECTIVITY_CHANGE. This worked better for me then C2DM because I had more control of the system and was virtually real time. C2DM is a fire and forget system and is not guaranteed to be reliable. You will have to manage the socket between changes in connections, and maybe hold some kind of wakelock.
For a polling solution, you could also build a web server and poll with http requests. This will avoid the need to manage the socket between connection changes but is not a real time solution.
On the receiving end, there is the Android Cloud to Device Messaging Framework (Google's implementation of push notifications): http://code.google.com/android/c2dm/
Note: this requires Android 2.2 and up (~84% of users as of today)
Related
I want to implement a long running service to receive push messages from emqx server (even when the program is not running). If I use android Service or JobIntentService, it will be necessary to display a notification which is not intended. If I use WorkManager, The minimum repeat interval that can be defined is 15 minutes. For some reason we do not want to use Firebase. Is there a solution to this issue?
"Push Notification" means "the server triggers your App", so there are two main methods:
use native Android Firebase Messagging create
a persistent connection between all Clients and your Server
First option uses a single connection which is managed by Android for all (or most of) Apps, so the energy compsumption is very low and Connection/Network events are managed by Android itself.
The Second option requires heavy work about Connection/Network re-connections and some work on Server-side. Your server should hold and manage many Client connections for how log it's needed. Moreover the Server should know Client's TCP/UDP handler to know which Client to send message at.
This way drains more battery energy than the first one.
If you intend "Push Notification" as "polling the Server to know if some Notification is ready", then you're misunderstooding "Push" word and you can ONLY create a persistant Service WITH notification icon (this behaviour is mandatory starting from SDK 26).
As you mentioned, in new versions of android, there are many restriction on using background services. Therefore, I suggest you using a hybrid approach if you can. Your server informs the client for new messages using google-fcm service and whenever the client received it, on WorkManager establish a connection to the emqx broker in order to get the actual messages. In this approach you can connect to your broker whenever the app is on the foreground and also you do not send your messages through the fcm but using it as an alarm to clients for new messages.
for my android app i need to receive some notifications from a server. The notifications are by no mean time critical and it would be enough to check for new notifications when the user opens the app, so no background activity at all.
I noticed, that it is recommended to use a service like FCM (Firebase Cloud Messaging) for any kind of notifications. However, I feel that I would introduce quite a big library for a very simple task with FCM, potentially causing worse battery life than just using simple sockets to ask the server for new notifications.
So I wonder if its better to use a service like FCM or just do simple pulling for notifications in my case.
I feel that I would intodruce quite a big libary for a very simple task with fcm, potentally causing worse battery life than just using simple sockets to ask the server for new notifications.
FCM uses one shared long-lived socket for all apps. There is a fat chance some other app on your phone is already using FCM, so having your app use the socket connection as well would not increase the battery usage at all.
So I wonder if its better to use a service like fcm or just do simple pulling for notifications im my case.
Although your app does not require any background push messaging, I would still advise you to use FCM to inform the app of any events instead of asking the server every time you start the app. The general principle of polling versus eventing apply here. FCM is not difficult to implement.
Well as I know , FCM never force to run a background service to receive Push notification, you may simply adapt it in your project and its simple to use.
Even I saw in may sites that using FCM increases the users by sending them promotions and offers using push message.
You may read more at FCM
This may be duplicate question but am still having doubt am a beginner in android application i have a couple of doubts my primary doubt is:
I have made one application which will communicate with server when network available it will work as it is. when network is not available data will save in sqlite and later when network is avail need to sync that data to server how can i achieve this.
Whenever there is new update is made with server need to get notification how can i do this
For this one which will be the best approach syncadapter or server or intent service with broadcast receiver which would be opptimized solution for the above requirement
These are all my doubts i would be very glad if someone helps me !!!
If you want an Android app to be notified when something happens on a server you control (without having the app to constantly poll the server to ask for changes), the usual solution is to use Google Cloud Messaging to allow the server to send a notification to the app to tell it to refresh data.
It is kind of complicated to implement, but is the best way to do what you want and is standard practice for mobile apps.
If you need to know when the network becomes available, to reach your server for synchronization, implement connectivity change listener, as discussed in this question.
This does not allow to send messages from the server easily, but if the server messages are not of high urgency, maybe you can simply check for them periodically.
This would allow to use less Google specific infrastructure and change the cloud providers easier.
I need to write phonegap(ios and android) app that in background listen websockets connection and notify user.
Is any plugin for that, exist? Or any other way to do it ?
I'm pretty sure that the network stack (and therefore WebSocket connectivity) is interrupted when an application goes into the background. I think all you really have time to do is register an APNS / GCM handler when the OS tells you to suspend your application.
You might want to ask this question on the Kaazing Website (there are a few folks there who know this stuff) to confirm this.
This plugin https://github.com/mkuklis/phonegap-websocket adds basic web sockets functionality to phone gap on android. In addition, you can use also socket.io if you want a more elaborate javascript API that what vanilla web sockets provide.
I need to open and keep long term connection with server to send messages, recieve response. Also sometimes server sends information without user request, so android device should listen to the server and react.
There are AsyncTasks, where I can implement socket connection, but main problem is that I know only one way - to send request and recieve response once. Then AsyncTask (and connection) is closed.
I have also read about services (that I never used).
Is it possible to make long term (1-4 hours) connection with server that keeps connection alive, listens for user commands (for example, need to send data to server when button is clicked) and recieves response or requests from server (and then changes UI).
Will service (and connection) be killed when phone fall asleep, needs more memmory or other? Is it big cost to the battery?
Maybe there are other ways? Thank you in advance for all your answers
P.S. sorry for poor english skills, hope you understood :)
You should probably use a Service, running in background.
Also, you really need not keep the service always alive with a network connection. You can opt for Google Cloud Messaging, which supports 2-way communication via the XMPP protocol. Using this protocol you can:
Receive notifications from server, start the service and do necessary processing.
Send notifications to server, upon which server does any necessary work.
These notifications are short 4kb messages , so they are better used as "commands" of a publish/subscribe model, which initiate other network heavy connections such as uploads and downloads. Rest of the time the service can be inactive to reduce resources consumption.
According to Android API Reference
"A Service is an application component that can perform long-running operations in the background"
And yes it consumes battery and you have to stop it by yourself:
" It's important that your application stops its services when it's done working, to avoid wasting system resources and consuming battery power"
So I think Services fit your needs.
If you need to communicate with the server when you want to send data to the server you can do it and wait for answer. If you need to send data from server to the device then take a look at push notifications.