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.
Related
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
I want to push notification from GAE backend to Android application. I've successfully implemented communication from this link: https://github.com/GoogleCloudPlatform/gradle-appengine-templates/tree/master/GcmEndpoints
But, I'm confused about logic here.
In this example, we have executed client registration to GCM, but via AsyncTask. I want to notify users when some code finishes execution on GAE backend, but without need to call some AsyncTask from Android. All I need is to receive message from GAE when this code finishes it's execution. Is this possible? I just don't know how workflow should be here.
Also, what needs to be done on client side, so that it will "listen" for new messages? Some service task which always runs in background? Or is this already done with public class GcmIntentService extends IntentService from this example, and I just need to identify message type?
If someone could explain this workflow to me, and some code examples would be nice too.
You should really go through the GCM guide, getting GCM running is not hard but it requires a series of steps that cannot be skipped.
In this example, we have executed client registration to GCM, but via AsyncTask. I want to notify users when some code finishes execution on GAE backend, but without need to call some AsyncTask from Android
A complete GCM implementation requires the client to register to GCM servers in order to get its unique ID and YOUR server to store that ID in order to contact that client directly, thats why you need at least one connection to send over this data to your server. you could get around this by using a new feature called topics, that way as soon as the client is registered it could suscribe to a topic and your server wouldn't need to know the specific GCM keys for any of your clients. I wouldn't recommend this last approach as it's not as scalable and will disable any 1 on 1 communication with your server.
Also, what needs to be done on client side, so that it will "listen" for new messages? Some service task which always runs in background? Or is this already done with public class GcmIntentService extends IntentService from this example, and I just need to identify message type?
You need to setup a broadcast reciever to handle incoming messages to your app (all detailed in the guide) from there you get the raw messages and you can do whatever you want with it, includng running it through an intent service as you state or processing it directly on the reciever (not recommended). Yes, you can discriminate message types and execute the logic accordingly.
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.
i have applied the demo code of GCM for server side on appache server and for client side on android device and it is working great; but i need to activate this service in my application as follows:
i have a database on SqlServer and need to automatically send a push notification to android phone whenever some certain data gets modified, i think i should use an after update and after insert trigger to do this, but i don't know how to do it.
any help will be appreciated, thanks in advance.
You should not do it from a trigger. Adding the latency of a GCM push to each table update will quickly bring the performance to unbearable lows. You have to decouple the trigger from the GCM call, and the best way to achieve it is via a queue.
You can use a table as a queue and have an external process monitor the queue and handle the GCM call.
You can use Service Broker and deliver the GCM call from an internal activated procedure or from an external process that monitors the queue
You can use MSMQ and monitor an NT queue from an external process.
My recommendation would be to go with first option as is the simplest and has the inherent robustness of simplicity. Read the linked article to understand what is required to use tables as queues, and do not cut corners.
All options still rely on a trigger to enqueue the notification, but it will be a local enqueue, not a GCM call.
I'm sure someone will think of the naive solution of invoking GCM from the trigger itself using SQLCLR: don't do it.
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)