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.
Related
I am making an Android application where I schedule alarms in AlarmManager that trigger notifications to the user and need to go off at rigid specific times.
When a user uses a task killing program (usually from a chinese phone and ROM), the alarms are killed as well.
This is troublesome, because after this happens, no more notifications are launched untill I re-open the app or restart the phone. This is not trivial to the target user that is a layman.
These alarms are supposed to work offline, so using GCM to re-up the alarms through a network listener is not an option. I actually need some "unkillable" service on the phone that checks if the alarms still exist and reschedule them if they don't. Is this possible?
I found this post here, but the last answer was in 2012: Keep android alarms alive, even after process killed by a task manager
Is there currently a solution to this?
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.
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
I'm new to Android so I want to make sure that the following solution is the correct one.
The problem:
I want to sync the device's local database with a database on my server, via a webservice, every 10 minutes. I already have a web service call that I can make that returns the new/updated records. What I'm wondering is what is the best way to schedule this task. I want the databases to sync even when the application is not running.
My solution (is this the correct route to go?):
I will have one BroadcastReceiver that listens for android.intent.action.BOOT_COMPLETED, in it's onReceive I will create an AlarmManager that sends a message to MyReceiver (via a PendingIntent) every 10 minutes. Also, in my application's startup I will do the same (create an alarm to send messages to the MyReceiver via a PendingIntent) - Since both alarms are sending messages to MyReceiver and their corresponding PendingIntents are initialized with PendingIntent.FLAG_UPDATE_CURRENT will the new alarm override the old one? (this is what I want to do, in case for some reason the alarm gets cancelled after device boot it should be restarted when the application starts).
In MyReceiver's onReceive() I will create a MyIntentService (this instance will make the webservice call and update the local database).
Is this a good solution? Any suggestions?
Thanks
Solution is fine...Actually all the AlarmManager instances get cleared when device turned off and rebooted.
The simple way is that...
First create AlarmManager when application started.
Second in onReceive of BOOT_COMPLETED BroadcastReceiver.
Its enough, PendingIntent.FLAG_UPDATE_CURRENT will make sure of having only one activated alarm at a time.
In this way, alarm registered when your application started. There will be no issue if its already registered via BOOT_COMPLETED. Activated alarm will deactivated when you turn off your device, but BroadcastReceiver to BOOT_COMPLETED will take care of registration new alarm at next boot.
If you decide that this answers your question, please mark it as "accepted". This will raise both your and my reputation score.
Also you need to review your interval to use network, it might be very resource consuming for device and user. One policy might be to have longer period of interval and check for update when user starts your app (this might not be user friendly but can save many system resources and battery power as well). Try to find some better policy according to your needs.
Using FLAG_UPDATE_CURRENT in that manner will override the existing PendingIntent if one exists. I'm not positive but I believe that as soon as you get into onReceive, the PendingIntent is consumed so it's no longer there to be overridden. In either case, it sounds like this is the functionality you are looking for and yes it's a good way to solve this kind of problem. My only other suggestion would be if the 10 minute interval timing is not absolutely critical then use one of the INTERVAL_ schedules (INTERVAL_FIFTEEN_MINUTES for example) in your AlarmManager to help conserve battery life; basically it lets allows all apps that run on intervals to "batch" their work together and wake the device up less frequently.
I want to create Event Reminder App, I search and found that I need to use a service and broadcast receiver.
But it is not clear for me what is the role of each components ?
As I understand-but I am not sure- that the App needs an Activity that when starts, it runs the service ( which check the current time with times are stored persistently , for example in database !). when the two times match , the service create a broadcast, and our broadcast receiver receives it and create Alert.
My questions are:
Does this inception is correct ?
How to make the service running and always check the time ( do we need some infinite loop?!!)
thanks in advance,
Activities and Services can be killed off without notice anytime system decides it's low on resources. There is no guarantee that your Service would run all the time. Also, if phone is in sleep mode, your code stops executing.
So:
The premise is wrong, for the reasons stated above.
You cant guarantee that Service would be running all the time.
For your purpose you should be using AlarmManager. It is garanteed to call your code when alarm is triggered. Also important - AlarmManager survives device restarts.