How to make independent push notification on mobile? By independent I mean not relying on Google Firebase cloud messaging. Since GCM was depreciated I would like to make a solution not dependent on mobile devices vendors.
Talking about Android in particular
Using Push Notifications without using any Google's/Firebase service would be a bit tricky. Since GCM/FCM service, keep on running on the device at all times, hence there is guarantee that their notifications will definitely be delivered.
However, for your use case, if you really want to implement your own custom Push Notification Service, you can follow these steps:
Implement a background service which keeps on running in the background. Your service could be killed sometimes, due to various factors of the android device, hence, you may need to implement an AlarmReceiver to restart your service if it is killed, from time to time.
In your background service, you must either ping your server, at certain intervals, passing a unique ID, maybe a user Id, or device Id or any other uniquely identifiable ID for each device/user, to check if there are any notifications or not. This could further be implemented in various ways, like using Socket Connection, or via APIs etc. You will have to find the best solution to minimize the number of requests on the server.
If there are any notifications, based on the passed (queried) parameters, the server should send the response with the content. Otherwise, do nothing.
Once you receive a valid (with content) response from the server, you can create a notification to remind the user about the same.
Please note, this may not be the best solution to perfectly suit your requirements on both Android and iOS, however, this is a general process of receiving a notification from the server (implementing a two-way communication at certain intervals).
You must focus on creating a service which keeps on running in the background at almost all times, to be able to use push notifications in real-time.
Related
I have been exploring launching an app with no servers(just an app on android phone), but when a user reboots his phone, he loses the reminder notifications that were set previously in my app which is not opened that often as it is more a reminder app. I have this previous post that I just added a bounty too
https://stackoverflow.com/questions/63293900/code-in-trying-to-reschedule-previous-alarm-notifications-in-android-after-a-reb
BUT I am starting to wonder and have a second question. SHOULD I instead change my architecture such that I have to have a server portion and fire notifications through Google FCM api instead to send notifications to my app every day to potentially reschedule alarms that are dead since the phone rebooted. Is there even a way to see if my notifications are still scheduled and will go off at the correct times?
thanks,
Dean
I put a very detailed answer on your mentioned question, but I will also chime in here.
SHOULD I instead change my architecture such that I have to have a server portion and fire notifications through Google FCM api instead to send notifications to my app every day to potentially reschedule alarms that are dead since the phone rebooted.
Short answer, no.
Long answer, if you are using FCM to trigger a daily check to ensure that all notifications are scheduled, then why not just use it to trigger the reminder notifications themselves? FCM has high-priority messages that will wake the phone and allow your application to execute some code. However, if you are planning on releasing this application to the public, this ends up creating a privacy issue that isn't present if the application keeps all information local. If you are the only user, then it makes even less sense to use a server to handle anything. If it is for a couple of friends, then a server MIGHT be an option, but I would still recommend against it even if they are fine without a privacy policy and the such because it is an unnecessary additional cost to the application.
Is there even a way to see if my notifications are still scheduled and will go off at the correct times?
If my answer above didn't already take care of this, while it might be technically possible to discover whether or not your application has any pending Alarms set with AlarmManager, it is not feasible to do so. AlarmManager does not provide any sort of visibility to any set alarms (see this answer). You would have to figure out some way to keep track of this yourself, but like I mentioned in the first part, if you are going to us FCM to trigger a job to schedule the notifications you may as well use FCM to trigger the notifications.
I am creating an android app which has a chat feature. I would like to create a notification if a new message arrives when the chat is not open. My messages are stored in a firebase database. I see two options for creating these notifications. One is to use the firebase function to trigger a firebase cloud message. The other is to use an Intent Service which runs an onChildAdded Event handler. The Intent Service seems much easier to me. Am I missing something? What would be a good reason to use Cloud Messaging over an Intent Service with the event handler running?
If you're worried your Service will keep running all the time (and draining your battery), then that's a good reason to use the cloud function. Moreover, there are chances are that your service might get killed.
Because only a few processes are generally
visible to the user, this means that the service should not be killed
except in low memory conditions. However, since the user is not
directly aware of a background service, in that state it is considered
a valid candidate to kill, and you should be prepared for this to
happen. In particular, long-running services will be increasingly
likely to kill and are guaranteed to be killed (and restarted if
appropriate) if they remain started long enough.
Finally, all the fuss you'd have to go through to deliver the results to an activity might be as painful as developing a cloud function.
In the company I work we decided to use the cloud function and it was pretty easy. We only needed to keep track of the FCM token of the devices and our function would monitor a certain node in our Real Time database. Every time somebody wrote there we'd get warned and would be able to act on it (grab the node, identify sender and receiver and with the saved FCM token send the notifications). We've used this tutorial to achieve what we wanted. Some links on how to write the cloud function, here, here and a So question that I also used here. The official docs too.
i was thinking if there is anyway to sync android app with a web/website account. Basically, if the user logs in through the web, i want the android app to log in/start up/show notification. Should i use a background service in android to monitor the account or something else
Please help
Thanks
As far as I can see, you have a couple of options:
Use a background service (as you suggested) which is constantly running and checking. This will be battery consuming.
Use the AlarmManager to schedule a repeating alarm to check on a scheduled interval. This will be less battery consuming but also less immediate (unless you set a low interval which will consume a lot of battery).
Use a push message. This will be the most accurate and least battery consuming for your phone, but it's also the most advanced (difficult) to set up.
Based on your requirement, optimized solution is to use GCM - Push Notification. Based on the whatever action occurs at web, you just need to send a push notification to clients. Based on the push notification IDs, client needs to perform appropriate action.
I cannot use GCM and I am looking for solutions to support Push service in my application.
I saw PPNS from Parse.com and I am now using it. I starts a consistent websocket connection and checks the connection every 15min. And it also checks it on every device wake-up.
What is the approximate battery impact of just this PushService system?
Is anyone using it and tested it?
TL;DR: That's how push notification works. Don't worry about the battery usage if it's a required feature in your app.
Long version:
From what I understand (and indeed, have developed on my own App using my own MQ), that's what most/all other APIs that handle push notifications do, i.e. they maintain a persistent connection to an MQ of sorts (ActiveMQ, MSMQ, etc.) and subscribe to a specific topic which "pushes" messages to clients.
All of them require a WakeLock in order to keep this connection live in the event the phone is "sleeping" or network connection is recovered in order to make sure notifications are delivered. Some of them even maintain some level of persistence in case a message arrives when connection is lost so that they can playback the messages when they reconnect (although this would be an expensive feature in terms of server resources).
Your users most likely already have a WakeLock in one/many of their installed apps (WhatsApp, Skype, etc. -- You can check this by looking at the permissions WhatsApp requires for instance. One of them would be "preventing the phone from sleeping").
This in turn means that adding an extra WakeLock will have no material effect as the phone never REALLY goes to complete sleep anyway. If yours is the only app that has this WakeLock, then there would be a real cost to the battery but it's unavoidable unless you make sure you persist messages in the queue and only display notifications when the user unlocks the phone which is (1) expensive to maintain on your queue and (2) not very convenient as the user will miss notifications unless they're already actively using the phone so background notifications will go amiss.
I also don't imagine battery life would be hugely impacted if you're simply pinging the server every 15 minutes or so (the interval is usually the keep-alive time for the underlying message queue).
This link should help you understand how a local implementation for messaging works and should give you an idea why the ping is necessary and why you would want to maintain that WakeLock:
http://dalelane.co.uk/blog/?p=1599
edit: added TL;DR
I'm writing a small chat client for android. So the behaviour I want is, that my application is listening in the background for new messages and shows them in the notification area (only the icon of my app). Listening for incoming messages should be a really long term thing - maybe over days after closing the ui thread
My question is: How to do it? Should I have a service with it's own process? should I start an AsyncTask for the Listener? Or are there much better ways to do it? And if I use a new Service Process, do I need to use AIDL?
How to do it?
Have your chat server use GCM to push chat messages to the device.
Should I have a service with it's own process?
No.
First, it would not need to be in its own process.
Second, this would require you keep the service running all of the time, which many users dislike.
Third, this would require you to keep the device powered on all of the time with the WiFi radio powered on all of the time, which users will not appreciate. The exception: if you are running on a device supporting mobile data (e.g., a phone), and you are very very careful, you can maintain an open socket connection to a server while the device is asleep. This is difficult to get working properly.
should I start an AsyncTask for the Listener?
Probably not.
Or are there much better ways to do it?
Have your chat server use GCM to push chat messages to the device.
Or, possibly, change your chat server to work on a queuing model, so you can poll periodically (on a user-configurable interval) to pick up available messages.
And if I use a new Service Process, do I need to use AIDL?
No.