I'm working on an app where I have to read data from multiple sensors and send it to a remote server every 15 minutes. This has to be done when the app is closed/killed as well and I also have to be sure it always executes. I also want to be sure it happens (almost) exactly every 15 minutes (+-1 minute difference is the upper limit).
At this point, I've found 3 options: using Workmanager, Alarmmanager or using a foreground service. Following the documentation, Workmanager seems the way to go for background tasks, however, after having done some reading, Alarmmanager seems to be a safer choice (Workmanager sometimes has troubles with doze mode, and the timing isn't exact because it uses a flex period of at least 5 minutes). And a foreground service is not really allowed for this kind of task (it's not really long running, it's just a periodic task) and is being limited in newer Android versions. Do you think it would be a good idea to use an Alarmmanger for this task, or should I use something else? Thanks!
TODO Background scheduling.. You can use this method todo your stuff..
KOTLIN;
val service = Executors.newSingleThreadScheduledExecutor()
val handler = Handler(Looper.getMainLooper())
service.scheduleAtFixedRate({
handler.run {
// Do your stuff here, It gets loop every 15 Minutes
}
}, 0, 15, TimeUnit.MINUTES);
JAVA;
ScheduledExecutorService service = Executors.newSingleThreadScheduledExecutor();
Handler handler = new Handler(Looper.getMainLooper());
service.scheduleAtFixedRate(() -> {
handler.post(() -> {
// Do your stuff here, It gets loop every 15 Minutes
});
}, 0, 15, TimeUnit.MINUTES);
Related
I want to make 8 squares change colors between red/black periodically.
I acomplish this using timer.schedule with period time in milliseconds and it work
BUT then I realized that I need to use small time between this transitions (example nanoseconds).
To accomplish that I wrote this code:
timerTask = new TimerTask() {
public void run() {
handler.post(new Runnable() {
public void run(){
//CODE OF THE TASK.
}
});
}
};
//To make schedule this task in 5 nanoseconds I use this!
exec = new ScheduledThreadPoolExecutor(1);
exec.scheduleAtFixedRate(timerTask, 0, 5, TimeUnit.NANOSECONDS);
But when I run this, the UI is not updating (seems to be stuck), but in logcat, all the logs are printing very fast. How can I achieve to make a task periodically x nanoseconds?
The entire Android UI runs at 60Hz- 60 updates per second. This means the minimum time between redraws is 16 ms. You cannot run it at a higher framerate. Nor are human eyes capable of seeing changes at a much higher frequency than that.
iOS and most video game consoles also work on a 60 Hz refresh rate. You'd find very few to no systems that go faster.
I'm not sure what exactly you're trying to accomplish, but I'm fairly certain you're trying to do it the wrong way.
ALSO: I notice your timer task posts to a handler. That means your timer task is going to tell the main thread to run something, and the timer task is running in nanoseconds. YOu're basically going to choke your main thread full of "run this task" messages, then eventually crash with an OOM error when the event queue becomes so massive it can't add any more (which may take several minutes), because there's no way you're processing them fast enough with the thread switching overhead.
After doing a lot of research, I realized that in order to get the view to refresh so quickly, I needed the use of SurfaceView and a Thread to make the UI redraw very fast, I really had no knowledge of this. Thanks for the help
is it possible to create under Android a real time (timer) task?
I need a high performance timer which runs every 20 ms (without pause).
My Use-Case: Create an audio handler which puts every 20 ms an audio packet into the audio buffer. The audio data will be received in an UDP socket.
I used and testet different timer implemenations.
For example: ScheduledExecutorService, Timer/TimerTask, Handler, pure Loop (with Thread.Sleep), CountDownTimer.
No of this solutions works well for me :(
Example dummy implementations with ScheduledExecutorService and Timer/TimerTask (totally easy, see this code):
Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(new Runnable()
{
#Override
public void run()
{
// TODO here is my timer code
}
}, 0, 20, TimeUnit.MILLISECONDS);
new Timer().schedule(new TimerTask()
{
#Override
public void run()
{
// TODO own Code here
}
}, 0, 20);
My problem is:
Number1: No real time guarantee, my timer will be paused sometimes for 100-200 ms (IMHO the garbage collection or other OS services ...)
Number2: If my timer is in foreground, it works very well (except problem #1), but if my App is in background, the timer interval will be increased to 60 ms (not 20ms)
I've tested it on different android versions (5.x, 6.x, 7.x), on Marshmallow it sometimes works (maybe it depend on vendor driver?)
Some ideas? Or is that not possible under Android?
Hello Guys
I want to create an alarm which run every second . I have searched many code but fond no solution , Please suggest some references .
Thanks
Amit Sharma
You can do this, create a CountDownTimer , say how long you want it to last for in the first param (in milliseconds), then set a period of time to run a piece of code in the second param. In the onTick() method, this is the code that will run in the interval specified in the second param, onFinish() is called when the period of the countdown is finished. Call the start() method on the CountDownTimer object when you want it to run.
int howLongTimerLastsInMilliseconds = 3000 // 3000 milliseconds
int tickEverySecond = 1000 // 1000 milliseconds == 1 second
CountDownTimer countDownTimer = new CountDownTimer(howLongTimerLastsInMilliseconds,tickEverySecond ) {
#Override
public void onTick(long millisUntilFinished) {
//do some work every second
}
#Override
public void onFinish() {
//do something when the time is up
}
};
countDownTimer.start();
According to the documentation:
Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS
will shift alarms in order to minimize wakeups and battery use. There
are new APIs to support applications which need strict delivery
guarantees; see setWindow(int, long, long, PendingIntent) and
setExact(int, long, PendingIntent). Applications whose
targetSdkVersion is earlier than API 19 will continue to see the
previous behavior in which all alarms are delivered exactly when
requested.
Also this question was rised at code.googls.com and here is an explanation of it:
Suspiciously short interval 5000 millis; expanding to 60 seconds
This is working as intended, though is at present inadequately
documented (and we're aware of that side of the problem). Speaking
very generally: short-period and near-future alarms are startlingly
costly in battery; apps that require short-period or near-future work
should use other mechanisms to schedule their activity.
So, there is no inbuild way how to solve your issue using Alarm. And you should look out for another mechanisms or (very rough solution) use 60 independent alarms
I have a problem with this code used for Android (Java)
handler.postDelayed(new Runnable(){
public void run(){
// Your code goes here...
}
}, 500);
If the delay is about 500ms then the program seems to repeat the task at 0.5s, but if I change to less than 100ms or even less it does not follow any more. I test the brightness change and for a while it can repeat the change of brightness at that rate, but then slow down and come back to normal flash rate again. It seems unstable. Do you have any code that give exact delay regardless of the load of the phone's CPU.
Many thanks
Not from Java, no; stock Java isn't a real-time system.
Timing precision is subject to the whims of the JVM and the OS's scheduler. You may be able to get incrementally more precise, but there's no guarantee of the kind of precision you're looking for.
You might be able to do something more precise if you use a CountDownTimer which has a periodic tick. Essentially you set it to count down for a period which can be hours if need be, and there are two methods one method is called on each tick, and the other at the end of the timer at which point you could start another one. Anyway you could set the tick to be very fast, and then only kick off the code at the delay point by check the actual time difference in the click. I think thats about the best you could do. Essentially inside the tick you would issue a signal if the right amout of time had actually passed. That signal would either kick off the thread or release something the already running thread was waiting on. What is the value of the CountDownTimer, I guess its just that you can do a very frequent polling, and elapsed time check. Although its not guaranteed, the time between the ticks you can set it to a high frequency and check/poll very frequently. This could lead to a smooth performance not unlike a realtime system. Its more likely to be accurate because its just issuing a signal and not taking up the resources of threading just to issue the signal. You might also try an IntentService to perform the tasks and just call startService(intentToIntentService) each call. See if the threading works better inside a service like IntentService which does queue them up I believe.
Date startDate = new Date();
long startTime = startDate.getTime();
// Tick called every 10th of a second. OnFinish called at Signal.
CountDownTimer ctDownTimer = new CountDownTimer(30000, 100) {
long startIntervalTime=startTime;
public void onTick(long millisUntilFinished) {
Date now = new Date();
long nowTime = now.getTime();
if ((startIntervalTime - nowTime) > 100)
{
issueSignal();
intervalStartTime=nowTime;
}
now=null;
}
public void onFinish() {
Log.d("MyClass", "Done") // Maybe start out.
}
}.start();
I have an app that plays an mp3 file and I'm trying to update a custom field in synchrony with certain times we have tabulated for the sound playback (kind of like a karaoke effect). I'm using a Handler to schedule these updates. In my custom field class, I define a Runnable that is supposed to run the update at the right time:
private final Runnable mTrigger = new Runnable() {
#Override
public void run() {
int now = mPlayer.getCurrentPosition();
if (mState == STATE_PLAYING && mUpdateAction != null) {
if (mTriggerTime - now > MAX_PREMATURE_TRIGGER) {
// Sound is lagging too much; reschedule this trigger
mHandler.postDelayed(this, mTriggerTime - now);
} else {
// Run the update
mUpdateAction.run();
}
}
}
};
When I call mPlayer.start() I schedule the first update by calling mHandler.postDelayed(mTrigger, timeToFirstUpdate). Each update action decides what the next update will be and schedules it (by calling mHandler.postDelayed(mTrigger, timeToNextUpdate)). The updates times are typically a few hundred milliseconds apart.
The problem is that, while some updates are happening promptly at the scheduled times, others can be delayed by 200 milliseconds or more, which is quite noticeable to the user. I'm not doing anything in my app between these updates other than playing the sound. (No background worker threads; no other display updates.) The delays appear to be random and vary considerably each time through.
I didn't think that the timing for postDelayed would be this imprecise! I don't know if this is an emulator issue or a problem with my approach. Does sound playback screw up the timing of the UI thread loop? Should I move the timing into a background thread (and is it safe to call mPlayer.getCurrentPosition() from a background thread)? Something else?
After much experimenting, it seems like the problem is the emulator. When I ran everything on a speedier workstation, the problem seems to have gone away.