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.
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'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've read and re-read the documentation but I'm still now sure if using a service (and how) is the right way to keep a timer running.
I basically want to have a countdown timer, but I want it to run uninterrupted even if the app gets closed (and show up as an ongoing notification). When a certain activity in the app gets opened (resumed, opened, launched from clicking on the notification), I want it to be able to get the current value from the timer (no more frequent than once per second). If the app got closed, I still want the timer to be able to use/launch activities or other services (or access the database) of my app.
So if I understood the Android developer docs correctly, I should use a service that is started (because when started it should be able to do its thing even in the app gets closed) and bound (so an activity can get data from it). Then I searched Stack Overflow for similar topics and some people are recommending using IntentService (but can it send data to an activity?), or Handlers or even AlarmManager.
I'm really confused and I'd prefer to be able to pick the right approach from the start (rather than finish the app and then realize my approach wastes a lot of battery or something). The problem with documentation is it answers questions it thinks I have, so I have to ask a real person.
My suggestion is:
When user starts your timer save current system timestamp.
In your UI: Every N milliseconds just read saved value and compare it to current timestamp. This give you a diff = elapsed time.
You do not need any timer/service/alarm manager. Every time user has return to your app you just do step №2 to show elapsed time.
I have made an application in which alarms for various events are stored by the user. This app runs on both android and i-devices. So, the app raises an alarm when the event occurs. But if I close the application, obviously it doesn't remind me of the alarms. I want that even if the user closes the application, he should be informed of the alarm.
From what I understand, there are two ways this could happen.
1 -> Either run the application (using threads) in background.
2 -> As soon as user initiates any alarm, this gets stored in a database, and every time application runs and new alarms are installed, database keeps getting updated. But then again I have to make another app for database separately and that would be running in the background.
I just want to avoid it running in the background. Is there any feasible solution for it?
Thanks
On iOS you can only run very specific background tasks.
Depending on when an alarm is needed you could use local notifications or push notifications, see: Apple Documentation
In my Android app, I have some data that needs to be synced daily but also needs to be updated every hour when a user is inside the app.
I have already implemented a service that gets called from an alarm for the daily update. Im having a problem with developing a strategy to do the hourly sync. I could use an hourly alarm too and fire the same intent, but since your app can be killed at any time, there would be no way to cancel it (and since they use the same Intent, doing a cancel would cancel ALL alarms including my daily sync, so that's probably not good).
The other option is to use a Timer that's set when inside the app, and have that fire my Intent when inside the app. Im assuming all Timers get cancelled when an app is killed right? But my app consists of several activities and I want the timer to work across all activities, how do I do that? I dont want to duplicate code - we're already using a subclass for Activity and ListActivity.
I have some data that needs to be
synced daily but also needs to be
updated every hour when a user is
inside the app.
The solution seems easy: drop the second requirement. Few apps are used continuously for hours on end, since people tend to use their Android phones for other things (e.g., phones), so your update-hourly-if-used-all-the-time code will probably never run.
I could use an hourly alarm too and
fire the same intent, but since your
app can be killed at any time, there
would be no way to cancel it
FWIW, your app will not be killed while it is on-screen. And, while it is not on-screen, you don't want the updates going hourly.
Im assuming all Timers get cancelled
when an app is killed right?
Apps generally are not "killed". We expect you to clean up after yourself when your activities are called with onDestroy(). If you set up the Timer with a daemon thread, you will need to terminate that thread.
But my app consists of several
activities and I want the timer to
work across all activities, how do I
do that?
Bind to your service from each of your activities. If it is started by your alarm Intent, have it do normal update processing. If it is started due to a binding request, just have it make sure its hourly Timer is running. When it is called with onDestroy() (e.g., after all activities have unbound), have it stop the Timer.
You might be able to have a Timer run in a background service (which get killed less than activities) but there is still no guarantee that Android won't kill your service either. And running something like this is the background might use a lot of battery.
What about doing the hourly sync in a background thread that get's created in onResume? And just save the last time the user did the sync, and if it has been > an hour just do the sync. Because I don't think there is any reason to eagerly sync data that the user is never going to see.