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.
Related
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.
We are designing an app that users use on a subscription basis. When the user pays for a particular period, a receipt is issued from our server valid for the duration. The app is designed to be used "offline", so it will only be connecting with the internet to get the receipt from the server.
When in "offline" mode, the app waits for the paid duration #-of days until it requires the user to pay again. We are having problems implementing this.
We first tried to use an always running background service. But after reading https://stackoverflow.com/a/2682130/5753416, http://www.androidguys.com/2009/09/09/diamonds-are-forever-services-are-not/, we decided to use AlarmManger to schedule periodic alarms to check for the payment.
We are now facing problems with the alarm when the user changes the time/date. We are listening to Intent.ACTION_TIME_CHANGED and Intent.ACTION_DATE_CHANGED broadcast, but that isn't being broadcast when setting the date to the past.
My question is what is the right way of implementing a similar functionality. Any advice is appreciated.
edit
issues with the broadcast
ASOP bug issue
There is one solution what you need to do is check phone up time so you can schedule alarm for some time like may be an hour or depending on your freq. So what you need to do is check phone uptime + duration for which the user is paid if that passes then cancel his subs. The only extra thing u need to check is if phone restarts once net should be connected to access your service.
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 would like to notify my users of new content available in the latest version of my android game without using an external service like Push Notifications.
What I would like to do as a first step to achieve this is to just create a standard notification on application update.
This brings me to my question: is it possible to start a service the first time a user launches the game and then just keep it running indefinitely? I want to even keep it running after an update completes. Since it is possible that the code for the service may have changed between versions, would I need to stop the old version of the service manually and start the new version? Is it possible to even do something like this where the event that drives initiation of the service is the completion of an app upate?
My plan is to have this service check some persisted data about the last time the user was notified about new content and based on this I will be able to determine if a notification should be created for them after they update.
It's important that they are not required to go back into the game after update in order for the notification to be created. This is the problem that I am having now. Auto-updates occur and they don't know and hence also don't know that there are new stages, etc, available so they never go back into the game if they were already done with the previously available content.
It seems that games like Family Guy have got this approach working, but I am not sure if they implemented it in this way. Even after I update it, I will still get notifications even if I have not actually executed the app since update.
Services are mostly killed when other process needs the resources. Therefore use
startForground(...)
for running Services indefintly on background.
See here: http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)
What you can do is use the AlarmManager in your service that notifies you at certain time. Start the service, do the task and set again an alarm to notify you. In this way, you'll be able to run your service infinitely at periodic time.
I started redacting this answer on GameDev Stack Exchange before you
deleted the question. Unlike the guy who told you to delete, i thought it was an interesting question even for game dev stack exchange.
What you describe is a bad practice on android. I don't believe any game do that. What's more, android require "service" app to run as ForegroundService (This force you to display you app icon in the notification bar, so that users are always aware of running services) It can also be randomly be killed when the system lacks memory. However it can be implemented nicely using Alarms and AlarmManager.
Services and Notifications :
You can however schedule intents when the app is running, with AlarmManager, this is the good practice. Let's take a simple exemple : Candy Crush.
In Candy Crush, when you lose your last life, every 30 minutes you regain one, and have a limit of 5 lives. You want to notify the user when all his lives are back. How to do that ?
Exemple 1 :
When the user lose his last life or quit the game, schedule an intent with AlarmManager in (5-number_of_life)*30 minutes that will fire a local notification.
Exemple 2 :
Schedule an intent with AlarmManager every 30 minutes to check the number of lives, and fire a notification when the user have 5 lives again.
Using a Boot receiver may also allow you to schedule things as soon as the device boot.
However, users expects to be able to disable this kind of features.
Updates :
If you want your app to notify users when an update is available, you'll need to somehow check on the internet with a request on your server. You may schedule an intent again with alarm manager to check regularly if the update is available. If the user is ingame, you can also check it more regularly.
A lot of "online" games do that, and simply force the user to download the new update from the Play Store, before they can play again.
Take the Gmail app as an example. Whether the phone is on or not, it polls every 10 minutes or so to download new emails which may have arrived since you last checked.
I know how to create a new service and bind to it. But I can see a few ways to accomplish this:
Bind once, and have the service run in an infinite loop, sleeping for 10 minutes between each loop
Bind and unbind right when it's done, scheduling the next bind somehow in 10 minutes
Using the AlarmManager class to schedule future polls
What are the trade offs? How does the Gmail app accomplish it?
Thanks!
Gmail app uses pushing, not polling. I suggest using this technique instead, polling is a battery killer in mobile devices.
To implement pushing, take a look at C2DM.
If you still want to poll, the recommended way would be to set up a periodic alarm in the AlarmManager.
UPDATE: Google has deprecated C2DM and replaced it with Google Cloud Messaging (GCM)
UPDATE: Google has deprecated GCM and replaced it with
Firebase Cloud Messaging (FCM)
For a continuous, but not intensive poll like the one you comment (in the range of minutes between polls), I would implement it with AlarmManager. That way you make sure the phone wakes up to poll without the need for a wakelock, which would destroy your battery. As CommonsWare pointed out, you will still need to implement a wakelock for the time your code is executing, but you can release it as soon as the code is done, avoiding keeping the phone on while just waiting. See his comment for an example on how to implement it.
I would use a Service if, instead, you need faster polls during a shorter period of time (seconds between each poll), since setting alarms does not make sense to such short periods, and the battery would drain anyway.