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
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.
Currently I have written custom LiveData class, which adds snapshot listener to document reference while being observed, thus providing easy way to update UI. I want to continue listening to the same document after app closes, and show updates in notification.
What would be a good way to do that? I have little experience with services, etc. but if I understand corectly, I should use either WorkManager or foreground service. Is there a solution which would allow to use the same listener for UI and background?
Most answers to similar problems suggest using FCM + Cloud Functions to send updates, but for my purposes I would like to have ongoing notification and also I've experienced delays with cloud functions, so I'd like to avoid going this way.
The way you'd like it to work is simply not possible anymore these days.
When your app is backgrounded on Android, the operating system will reduce its resources usage over time. This means that you can't rely on Firestore's usual mechanism to receive updates from the server, not even in a background service.
The idiomatic way to deliver updates to an app that is not active in the foreground is (as you've found) to send FCM messages to that app from a server or Cloud Functions. If you're having trouble making this work, we'll be better able to help if you post the minimal, complete/standalone code with which we can reproduce where you got stuck.
I am trying to build an IM using Smack Library. I did it correctly and its working fine in foreground and I could start a STICKY service which can look for the message in the background. My issue is that I don't want a persistent service in the background, because it will eat up the battery of the android device, instead I want some broadcast to be fired up when the XMPP message comes with some events.
Is there any way I could achieve this? I have tried looking for example with the search term and I found nothing so I did not achieve any sort in this particular context so does not have any relevant code.
I think that all depends on what you want to archive.
If you need fast direct message arrival when the 2 clients are online, I think that the persistent service is the only solution with smack xmpp . With solid code development it should not eat up much battery...
If you don't really care if the message arrives after 2 minutes for example, you should use an intentservice (connect/get messages/disconnect) & a timer (e.g. every 2 mins) as long as the app is running.
What you describe (some broadcast to be fired up when the message comes) is more similar to PUSH mechanisms like Google Cloud Messaging...
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)