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.
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.
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.
I've just been reading about adding a service to my application, and since 7/8 there are now service restrictions to improve phone performance.
I've seen that the recommended approach is to use a job scheduler, but will that not just periodically start a new listener if I did that?
Basically I update my database, and using a snapshot listener I want to update my user in real time. When the app is closed, I'd like to send a notification.
My issues (if I'm correct) are that constantly making a new Firestore request will eat through my request allowance.
Also, if its a job scheduler it won't quite be real time?
I've read that you can use a foreground service, but this doesn't really seem like that task that needs a permanent notification and would annoy the user.
Anyone got any tips on how I'd implement this?
Thanks
Using a listener after an android application is closed
You can use a listener after an android application is closed, by not removing it. Once you are using a listener, you also need to remove it according to the life-cycle of your activity. But this will work only for a shot period of time because Android will stop your service if the app is not in the foreground. It does this to save resources when the app isn't being used. It also might stop your app from doing any networking, or even kill the app process completely. There's nothing you can do to prevent this, other than making it a foreground service, as you already mentioned.
A foreground service is probably not the best thing to do for your case, nor is it the best thing for your users. Read more about limitations on background services.
My recommendation is to use Firebase Cloud Messaging to notify your app when something has changed that it might be interested in. So your users will recieve notification even if they will keep their app closed.
I'm new to firebase realtime database, and have a basic question I cannot seem to find the answer to.
I need my Android app to keep track of changes in the database, so I understand I need to use addValueEventListener, with the onDataChange method. However will the method onDataChange, be called even if the app is destroyed? I need to be able to access the changes of the information in the database even if the app isn't running in the background, (for example the user force quits the app). This is because when the values reach a certain point, I want to show a pop up notification, so I need to able to read the values even when the app isn't running.
If the onDataChange is called even when the app is in the background, will this drain battery use since the phone is always listening for changes.
Sorry for the basic question, but I couldn't find the info.
Thanks!
...when the app is dead, is the EventListener still listeneing, and will onDataChange be called?
Event listeners are only active while the context they run in is active. For listeners you attach in an activity, that means they're active while the app is running. Even then Android might kill the listeners (or more accurately: the socket they use for communicating with the server) if the user isn't actively using the app.
If you want the listener to stay active longer, you can indeed consider managing the listeners in a background service. But even there, Android might close the listener to preserve battery life. That is the one thing to always keep in mind: if your use-case interferes with the user's preference (and most users are likely strongly prefer longer battery life over any specific app feature), it's unlikely to continue working in the long run.
A better approach is to combine listeners with Firebase Cloud Messaging for sending messages. FCM messages are more likely (though still not guaranteed) to be delivered when the user is not actively using the app, and you can use them to run some code of your app when they arrive. You'll want to use FCM's data messages for this, which is how most app deliver background updates.
You can also use an FCM data message to just wake up your own code, then have that code attach a listener, and get its updates. This type of behavior is known as sending a tickle, since all the data message does is waking the application code up.
When a Server wants to contact a client, though the corresponding app is inactive or off, he can do this via Google Cloud Messaging. My little application runs in combination with a webserver which I do not own and only runs php on, so actively contacting a client is impossible.
Now there are apps with probably similar problems, such as the Email apps. Mailservers never manually contact their clients, when a new message was received, so they check for new messages every, say, 30 minutes.
My question is: Is it possible to run such a background task? And is there a way to do this in iOS, too?
Thanks in advance!
If there is something you want android to do when the user is not interacting with the widget/application, you should use a service.
Android Service
It is meant to be used for tasks that require no user interaction and is especially great for checking something over and over. No guarantee that the os still wont kill it eventually, but it kept alive as long as possible. You can also create a service to be restarted anytime it dies, if you really want to do something long term.