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
Related
I'm writing my first independent Android app. It will sit in the background and respond to a few events generated by the OS, somewhere between a few times a day to a few times a week depending on the user.
Coming from a PC programming background, I thought I might need a service, but Android Developers > Service says:
What is a Service?
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
The app should not need to consume any resources unless one of the events it's listening for happens. The user should also not need to actively use the app after it's been set up, only if they want to change its settings.
I have games that seem to do something similar to what I want. They sit in the background and can receive messages (e.g. it's now my turn), and when I click on the notification it loads the game into memory, which takes a few seconds longer than if it was already in memory.
If the user hasn't used the app's interface for a month, I want it to still be in operation (even if the device has been power-cycled) and respond to events but not to appear in the list of recent apps (assuming a month is long enough to push it off the end). Ideally, I want it to respond to the events within one second; it doesn't have to be near-instant. What's the normal way this is done?
An app (occasionally used) and a separate "service" process/thread (persistent)
A combined app and "service" (persistent)
A combined app and "service" (loaded into memory by events)
Not enough reputation to comment, but just to tell you that nothing prevent Android to kill your service, To restart your service after the user reboot its phone you can add a broadcast receiver and listen to
https://developer.android.com/guide/components/broadcasts
.Also, if you don't want to display a notification while your service is running you will have to use a background service instead of foreground one. Hope this help.
I have written an android app that uses firebase anonymous authentication and writes to the firebase database from a foreground service. I am using onDisconnect().removeValue() to cleanup data created by my app when the websocket is closed. When a user is actively engaging with the app, the onDisconnect() call triggers as expected (meaning my security rules are OK). However, when the foreground service is left running for a long period of time (e.g. overnight, screen turns off, etc.), the onDisconnect() call is never triggered again. The app continues to function upon wakeup (communicating with firebase server, etc.) but when it comes time to close the app (following a period of idle time), it seems that the onDisconnect() call has been lost somehow.
I have read that anonymous authentication sessions are quietly refreshed by the firebase SDK every hour. Is it possible this is happening in the activity (and being killed by the OS, but keeping the foreground service alive), therefore causing the server to discard the callback to onDisconnect? If so, can this functionality be preserved within the foreground service?
Firebase has had a bug recently (not sure if it's been fixed), where when it reauthenticates every hour, it loses the onDisconnect() because it no longer has permission to alter that node. This then causes the duplicate.
Some possible solutions:
Attach a timestamp and check if the last timestamp is over an hour, and if it is, then delete it when adding the new one.
Remove authentication requirements for writing in the node to keep track of the disconnects (this would not be secure though, depends on your needs).
Here are some more alternatives, and a better explanation of the problem from a member of the Firebase team: here.
Android application processes can live indefinitely. When the user stops using an app, Android may continue to keep the process alive, in order to make it load faster if and when the user comes back. You can think of this is an optimization, and you should expect this to happen sometimes. You shouldn't try to control this behavior - let Android manage this for you.
Your connection to the database is not being closed because the app is still alive and holding on to its connection to the database. I suggest you track for yourself when the user stops using your app, and force a cleanup at an appropriate time after that, without assuming that Android will ever kill your app's process.
I am developing an app that connects to and modifies data in a database by executing php files.
If I need to make changes to the database or php files, this may cause old versions of the app to behave unexpectedly and crash. For this reason, I want to force users to update the app when such changes are made.
Right now, I have a method that connects to the database and compares the apps version to the databases version. This works fine but I call it every time I access the database (very often) which significantly slows down the usage of the app. Is there a better way to do this? I have read that I could use an AlarmManager or BroadcastReceiver to check for updates every X amount of hours. But what if the user closes and doesn't use the app for a few days. Will these timers get called as soon as the user starts the app and thus be able to force an update?
The Android AlarmManager is an API that let you communicate and program alarm with the Android Alarm Service. Think of it as similar to a Linux Cron job. As soon as the alarm is programmed, then it'll be triggered even if your app isn't running, because the alarm is triggered by the alarm service and not by your app. For instance, the only thing you need to do is to program your alarm. It's important to note that when you restart your device then your alarms are cleared, so you need to reprogram then in every reboot. You can do this by capturing the BOOT_COMPLETED broadcast, so you can reprogram your alarm every time the device boots up. Check out the definition of the Android AlarmManager. A common pattern to do what you want is to program an alarm that sends a broadcast or starts a service, then in that service you can query your server. You need to consider that when the device is sleeping then the alarms couldn't be sent, so you need to work with wakelocks. This class will help you with that, check it out.
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.
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.