I'm looking for some timer alternative, since timer dies with app, is limited, and every timer launches own thread.
Sometimes I need to launch about 20-30 timers.
I need to set some event, in time, and when it comes display app screen. Is it possible?
This may or may not be possible depending upon your definition of "dies with app".
You can use AlarmManager to schedule PendingIntents to be invoked at specific times in the future. Those PendingIntents can launch activities. This will work if your app "dies" from ordinary causes.
However:
If the user force-closes your app via Settings, your alarms are unscheduled, and there is nothing you can do to stop this (nor do you have any alternative to AlarmManager that somehow survives this)
Please allow the user to determine whether or not you display an activity or raise a Notification at these times, as users may not necessarily appreciate having their game, navigation, video, or phone call interrupted by your activity.
You should use AlarmManager.
As CommonsWare says that there are some limitation of it, but that is ok, if an user force closes your application it means he doesn't want to use your application (any more or due to sort of memory)....
And I have a solution (but may be not the best), because you can not listen if user force closes your app, so one way is that you can re schedule your event on each start of your application. I know this is not a good solution but ..... we have no any other way yet
Here is a good example.
Related
I need my app to open at a scheduled time. I've searched for the best way of doing this and have got quite confused.
I'm currently using BroadcastReceiver to respond to onBoot. That works fine but which way is best to go next?
Should I set up an AsyncTask
..or..
should I set up a Service.
Then should I use AlarmManager or a TimerTask to trigger the Main activity to start?
Or should I even use AlarmManager/TimerTask in the BroadcastReceiver?
Which course would be best practice and why?
If exact precision is not required, use AlarmManager as this will have the least user impact. Otherwise, I would personally use a service. One case to consider is that the user may open the app and navigate to another activity before your time. Also, the user could open your app and leave again before the time.
I want the user to start a timer in the app. It will put out notifications at minute intervals. During this time, user should be able to switch to different activities, leave the app to home screen or go to a different one. Even if app ends, it'd be nice that the timer continues giving notifications until user explicitly stops the timer. Opening app again should allow them to stop it. From what I can tell, sounds like I should go with AlarmManager? If this thinking is correct, would anyone happen to have a great tutorial that would suit my example well? Thank you!
EDIT: I didn't have this initially mentioned, but there also needs to be a timer display on the main activity, so some sort of UI interaction is needed. There will be other activities user can go to, but the main activity timer should stay running.
It depends how precisely and how often you shoot your events.
This can be solved by:
1) creating a service, and let it run in the background. Google has nice tutorial here http://developer.android.com/guide/components/services.html .What you are looking for is Service not IntentService. This approach will consume a lot of resources.
2) Using Alarm manager (or if u target Android L you can use the Alarm schedulers)
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
AlarmManager.INTERVAL_HALF_HOUR,
AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);
again google has a good tutorial https://developer.android.com/training/scheduling/alarms.html
Hope it helps
I have an App where the user can create multiple countdown alarms. Each one has it's own name, time to count, ringtone, etc.
I extended the CountDownTimer to hold each alarm setup and created a Singleton manager to manage all the alarms.
Everything is working fine until I leave the App.
The counters don't actually die. They have a weird behavior. After starting a counter:
1) if I press back key until the home screen and then power off the screen the alarm will trigger as it should.
2) if I press the home button then turn off the screen it will trigger only if I open the app.
3) if I just turn off the screen while still on the app it will trigger as soon as I turn on the screen.
I expected trouble because for that kind of thing I need to use Services, Handlers or other stuff like these.
The problem is, I'm new to Android and after reading a lot about it, I couldn't find a solution.
As far as I understood I should use Services, but it can have only one instance. How would I work with multiple alarms?
Is there other way of doing it?
I need a way to start each alarm and tell the system to keep counting no matter what happens! (and to call an Activity when it finishes)
Any help?
Is there other way of doing it?
If your goal is to alert the user of events in the future, regardless of whether your app is running, dump all your CountdownTimer logic, and switch to AlarmManager. It is specifically designed for this sort of scenario. You can set up an AlarmManager event for each timer, to get control when the end time is reached.
Also note that you will need to maintain information about your registered events in a file or database:
so users can add and remove them, and
so you can set up AlarmManager again if the user reboots their device
and to call an Activity when it finishes
Users may reject your app for that behavior. Not everyone wants to be interrupted in the middle of what they are doing with their device. Please allow this to be configurable, so the user can opt for something less intrusive, like a Notification.
You should replace your CountdownTimers with AlarmManager (as in CommonsWare's answer), after setting it up it will trigger your function to execute on specified time, here is official guide:
http://developer.android.com/training/scheduling/alarms.html
Soon you will find that after device reboot your alarms are lost, you need to restart them by catching android.intent.action.BOOT_COMPLETED broadcast.
Also you should not do a lot of work in your alarm onReceive, you should pass information to some other component like IntentService, to make it safe while device is asleep you should use WakeLock (sample project).
[edit] ---- you should also store your alarm/ringtone related data in some persistant storage, you can use for it shared preferences, or (more work) sqlite database.
I you really want to use timer (i.e. when you want to show countdowns on screen):
You don't have to have multiple timers to show multiple countdowns.
Everything you have to do is just put the target time into some collection, or event put it into the View.setTag().
Then you have timer (let say 1s tick) - on every single tick you have to iterate over all your gauges, check the target time and current time, parse the number and adjust the gauge.
However - as the timers works on separate (non main) threads - you will have to use handler or something like that.
If you want to just set some alarms - take the CommonsWare's answer - it's good one.
I am using a timer in my application for repeated task. By default, the timer should repeat the task with a delay of one second. I am starting the timer when the application Starts. All this is works perfectly. Also,When I came out of my application and open some other application, the timer keeps running.
When I open Google Maps application, my timer stops running. I don't know why this is happening. I googled and found from the activity life cycle that, if other applications needs memory, all processes will be killed. This is what happening in my case, I guess.
I do not want my timer to stop. It must run always till the user uninstall my application.
Why the above problem occurs?
How to achieve my requirement?
Does Using services will solve the problem? If so, Is there any way to keep timer always ON without using services?
Does Alarm Manager be helpful? Even if the user restarts the phone, the timer should work properly.
Yes, a service will solve your problem. The persistence of an Activity is governed by its lifecycle, so in the end, you have no control of its execution. A service is persistent in that it will not be shut down by the system. If you are doing extensive calculation, however, be warned that the OS will not be as generous with resource allocation as it is with an on-screen activity.
In short:
1) Well, from the information you've given, I suppose you drew the right conclusions.
2) Through a service.
3) Yes, it will solve your problem, no, I don't think there is another way to do that, at least not from within an activity.
4) If you're not actually asking about the persistence of a Java.util.Timer but for a way to have a piece of code executed at certain times, this might be the better (/easier) solution. I don't know how well it works for rather frequent timings, though. A service can be resumed on system restart, so no worries about phone shutdown. You can subscribe to the startup event.
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.