Develop Reference

How to run a For Loop for 60 seconds maximum irrespective of the size of the loop and complete all the iterations

for(i=1;i<list.size();i++){
//do something
//For Eg: move marker to a new position on the map
}
I want the above loop to complete all the iterations irrespective of the size of the list and also want the entire task to run for 1 minute. (60 seconds)

I don't really know if this is what you want but I hope this helps.
import java.util.concurrent.TimeUnit;
for(i=1;i<list.size();i++){
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
// Execute thing you want to be executed every second
}
As explanation: you iterate through the for loop and the thread waits for one second before executing the code after the TimeUnit.SECONDS.sleep(1);.
If the list's size is 60 it would therefore take a minute for the loop to end.
Edit: It has occurred to me that it might be smarter to do a try-catch around the sleep function.

You can, for example, use System.nanoTime() to measure the duration of your loop, and then use TimeUnit.NANOSECONDS.sleep(...) to make it wait for the rest of time like this:
long start = System.nanoTime();
long desiredDuration = 60 * 1000 * 1000;
// your loop goes here
long duration = System.nanoTime() - start;
if (duration < desiredDuration)
TimeUnit.NANOSECONDS.sleep(desiredDuration - duration);

The best possible solution is to compute the desired time first and then run the loop to that extent.
long finish=System.currentTimeMillis() + 60000;
while(System.currentTimeMillis() != finish)
{
//statements;
//statements;
}
If you are trying to equip the CPU and keep it idle for this time the process is known as busy waiting but is not considered convenient in many cases so i recommend to use Thread.sleep(duration) for this purpose.
Would like to receive further queries from your side.

To spread N amount of invocations uniformly across a minute, you'll have to set the delay in between the invocations to the value 60/(N-1). The -1 is optional but causes the first and last invocations to be exactly 60 seconds apart. (just like how a ladder with N rungs has N-1 spaces)
Of course, using sleep() with the number calculated above is not only subject to round-off errors, but also drift, because you do stuff between the delays, and that stuff also takes time.
A more accurate solution is to subtract the time at which each invocation should occur (defined by startTime + 60*i/(N-1)) from the current time. Reorder and reformulate those formulas and you can subtract the 'time that should have elapsed for the next invocation' from the already elapsed time.
Of course 'elapsed time' should be calculated using System.nanoTime() and not System.currentTimeMillis() as the latter can jump when the clock changes or the computer resumes from stand-by.
For this example I changed 60 seconds to 6 seconds so you can more easily see what's going on when you run it.
public static void main(String... args) throws Exception {
int duration = 6; // seconds
List<Double> list = IntStream.range(0, 10).mapToDouble(i->ThreadLocalRandom.current().nextDouble()).boxed().collect(Collectors.toList());
long startTime = System.nanoTime();
long elapsed = 0;
for (int i = 0; i < list.size(); i++) { // Bug fixed: start at 0, not at 1.
if (i > 0) {
long nextInvocation = TimeUnit.NANOSECONDS.convert(duration, TimeUnit.SECONDS) * i / (list.size() - 1);
long sleepAmount = nextInvocation - elapsed;
TimeUnit.NANOSECONDS.sleep(sleepAmount);
}
elapsed = System.nanoTime() - startTime;
doSomething(elapsed, list.get(i));
}
}
private static void doSomething(long elapsedNanos, Double d) {
System.out.println(elapsedNanos / 1.0e9f + "\t" + d);
}
Of course when the task you preform per list element takes longer than 60/(N-1) seconds, you get contention and the 'elapsed time' deadlines are always exceeded. With this algorithm the total time just taking longer than a mnute. However if some earlier invocations exceed the deadline, and later invocations take much less time than 60/(N-1), this algorithm will show 'catch-up' behavior. This can be partially solved by sleeping at least a minimum amount even when sleepAmount is less.

Check out this.
long start = System.currentTimeMillis();
long end = start + 60*1000; // 60 seconds * 1000 ms/sec
int i = 0;
while (System.currentTimeMillis() < end)
{
// do something, iterate your list
i++;
if (i == list.size()) { // check size of the list if iteration is completed
// if time has not yet expired, sleep for the rest of the time
Thread.sleep(end - System.currentTimeMillis());
}
}
Do not forget checking size of the list.

How do I end a method in Java after a certain amount of time?

I would like to force a method to end after a certain amount of time even if it has not completed its task. How would I go about doing this?
Edit (added clarification and code):
I am programming a robot using Android Studio for the FTC (First Tech Challenge) robotics competition. To control the robot, I am using the FTC SDK (see https://github.com/ftctechnh/ftc_app).
The method works fine for going a particular distance and then stopping but after it stops by setting the power of all the motors to zero, it appears to get hung and no subsequent methods are invoked. Currently, it is only supposed to have the motors be stopped for one second before exiting but it appears to still get stuck on the first invocation of the method that sets the motor power to zero (setPower). For this reason, I would like to be able to terminate setPower after it has been running for a certain amount of time so that my method can exit and subsequent methods can be invoked.
Here is my method:
public void moveLine(DcMotor m1, DcMotor m2, DcMotor m3, DcMotor m4, double distance /* distance to move in meters */, double motorPower /* power to set the motors */) {
final double SPROCKET_CIRCUMFRENCE = Math.PI * 0.0652; //calculates the circumference of the sprocket
final int ENCODER_CPR_NR60 = 1680; //encoder counts for NeveRest 60
//final static int ENCODER_CPR_NR40 = 1120; //encoder counts for NeveRest 40
double amountOfRotationsCalc = distance / SPROCKET_CIRCUMFRENCE; //calculates the amount of rotations to move to reach the target distance
double amountOfEncUnitsCalc = ENCODER_CPR_NR60 * amountOfRotationsCalc; //calculates the amount of encoder units to move
//this gets the sum of the encoder positions of the drive motors
int currentEncPosSum = m1.getCurrentPosition() + m2.getCurrentPosition() + m3.getCurrentPosition() + m4.getCurrentPosition();
//this gets the average encoder position
int currentEncPosAvg = currentEncPosSum / 4;
//if the robot is supposed to be moving forward (positive distance), the motors will be set to positive values
if (distance > 0) {
//it may make sense to make this a while loop. Will this fix the issue?
if (currentEncPosAvg < amountOfEncUnitsCalc) {
m1.setPower(motorPower);
m2.setPower(motorPower);
m3.setPower(motorPower);
m4.setPower(motorPower);
} else {
//these stop the robot. Without them, it continues to move.
long start = System.currentTimeMillis();
long end = start + 1000;
while (System.currentTimeMillis() < end) {
m1.setPower(0);
m2.setPower(0);
m3.setPower(0);
m4.setPower(0);
}
return; //this is supposed to exit this method
}
} else {
//this is essentially the opposite of the code for going forwards
if (currentEncPosAvg > amountOfEncUnitsCalc) {
m1.setPower(-motorPower);
m2.setPower(-motorPower);
m3.setPower(-motorPower);
m4.setPower(-motorPower);
} else {
//these stop the robot. Without them, it continues to move.
long start = System.currentTimeMillis();
long end = start + 1000;
while (System.currentTimeMillis() < end) {
m1.setPower(0);
m2.setPower(0);
m3.setPower(0);
m4.setPower(0);
}
return;
}
}
}

long beginning = System.currentTimeMillis();
long end=beginning + yourTimeInMilliseconds;
while (end > System.currentTimeMillis()){
//your code here
}
I believe this is what you mean.
Some clarification, if you need any:
beginning is the current time in milliseconds.
end is obviously when it ends. (Start time plus delay)
While the time is still less than the set end time, the code keeps going.

I know this question is a bit old, but in the latest ftc_app Android SDKs it is recommended that for time aware methods and procedures that teams use the ElapsedTime class.
The most important thing to consider when pausing an opmode is that you can still shut it down when the stop button is pressed on the driver station app. you can make sure of this by including the opModeIsActive() method in your while condition
On our team we have a method for pausing OpModes that looks something like this. we have this declared in a separate class used for library purposes.
public static void pauseOpMode(LinearOpmode op, ElapsedTime et, double waitTime){
double startTime = et.milliseconds();
while (op.opModeIsActive() && et.milliseconds() < startTime + waitTime){}
}
Now that this method exists, in our OpMode we can create an Elapsed time Object and pass the necessarry parameters to the function required to pause the OpMode
class someOpMode extends LinearOpMode{
ElapsedTime gameTimer = new ElapsedTime();
#Override
public void RunOpMode(){
//pause program for 5 seconds
pauseOpMode(this,gameTimer,5000);
}
}

Execute in future - time doubles somehow

I am very sorry to ask this question but something is going wrong with my code. Currently I am playing around with Command Patterns and I want a command class to execute code in the future - lets say 2 seconds in the future. The problem somehow is that the command gets executed in 5 seconds, not in 2??? Each call decreases a time variable until the variable is <= 0:
// 2 seconds in nanoseconds
private long timeLeft = 2000000000;
public boolean execute(final long delta) {
this.timeLeft -= delta;
if (this.timeLeft <= 0) {
// execute
this.timeLeft = 2000000000l;
return true
}
return false;
}
With lastExecution = System.nanoTime(); and then for each command delta = System.nanoTime() - lastExecution;
Full src on github: https://github.com/Sheldor5/JavaGPP

Instead of decrementing a countdown timer value by inaccurate deltas, calculate the target time and check for it, and use milli-time, not nano-time, to prevent sign issues.
long targetMillis = System.currentTimeMillis() + 2000; // 2 sec
while (System.currentTimeMillis() < targetMillis) {
// do something while we wait
}
// 2 secs elapsed, may be a bit more

Would this lower frame rate?

I am making a game, and the requirement is to make it have at least 30FPS and shouldn't drop below. Would what I have below achieve this? Or am I off somewhere? Much help would be appreciated.
private long period = 6 * 1000000;
private static final int DELAYS_BEFORE_YIELD = 5;
long before, after, difference, sleep, oversleep = 0;
int delays = 0;
while (running)
{
before = System.nanoTime();
after = System.nanoTime();
difference = after - before;
if (sleep < period && sleep > 0)
{
try
{
Thread.sleep(sleep / 35000L);
oversleep = 0;
}
catch (InterruptedException e)
{
}
}
else if (difference > period)
{
oversleep = difference - period;
}
else if (++delays >= DELAYS_BEFORE_YIELD)
{
Thread.yield();
oversleep = 0;
delays = 0;
}
else
{
oversleep = 0;
}
}

You can set an upper bound to frame rate but not a lower bound that is guaranteed to be always followed.
You can make a function be called no more than 30 times per second but you can't be sure it will be called at least 30 times per second. At 30 fps you have 0.03s of time that will be distributed between your threads and usually the drawing one is the heaviest between them all (unless you have complex operations like AI or whatever but that should be solved by lowering their rate or precomputing what can be precomputed).
If time of draw + time of logic > 0.03 then there is no way to make your game run at least at 30fps.

Good that you are asking early, because one better uses a timer I think. And that turns things inside out. (It could be done your way though.)
Sorry for this non-answer, but I think it is a worthwhile advice.
Look into some game/animation frameworks for their approach.

Frequency from binary input

Background: I have a IOIO which I am using to measure the output from an photodiode, this is the converted into a digital output. I need to find the frequency at which the signal changes between 1 and 0. Everything I have tryed so far has hanged my test app, any suggestions?
current code:
if(diode == 1 && frequencyFound == false){
startTime = System.currentTimeMillis();
while((frequencyFound == false)){
if(diode == 0){
while(frequencyFound == false){
if(diode == 1){
double endTime = System.currentTimeMillis();
time = endTime - startTime;
frequency = (long) (1.0 / time);
frequencyFound = true;
}
Thread.sleep(100);
}
}
Thread.sleep(100);
}
}

There are a couple of issues here.
First, Android is a multi-tasking system, and you could find your timing thread put to sleep long enough to miss some signal transitions. Is there no way to be notified of a leading (or trailing) edge transition rather than sampling the input in a loop?
What sort of frequency are you looking at? Will a 100 ms sampling interval be fine enough?
Don't count on Thread.sleep() to sleep for exactly the time you specify. If the interval is too short, the system might decide to return immediately or it might round the sleep time up to a larger amount.
Your timing loop won't record the time to any precision better than 100ms (at best), so your estimate for the frequency will be very poor.
Zapl is right, you MUST run this from a separate thread from your UI thread.
Watching for a single transition will give you a very imprecise estimate of the frequency. Try something like this instead:
// Find frequency to the nearest hz (+/- 10%)
// It's assumed that some other process is responsible for updating the "diode"
// variable. "diode" must be declared volatile.
long duration = 1000; // 1 second
final int interval = 100; // sampling inteval = .1 second
int oldState = diode;
int count = 0;
final long startTime = System.currentTimeMillis();
final long endtime = startTime + duration;
while (System.currentTimeMillis() < endtime) {
// count all transitions, both leading and trailing
if (diode != oldState) {
++count;
oldState = diode;
}
Thread.sleep(interval);
}
// find the actual duration
duration = System.currentTimeMillis() - startTime;
// Compute frequency. The 0.5 term is because we were counting both leading and
// trailing edges.
float frequency = 0.5 * count / (duration/1000);

Two more extreme suggestions for working around some of the timing accuracy concerns Edward raised:
Do the measurement of interval times on the IOIO board under interrupts, where you can presumably accomplish (at least near-) real time operations. Report these time measurements to the Android device.
Skip the ioio board and build something simple to route the signal into the headset connector as a tone that turns on or off. Record audio using the built-in timing guarantees of the audio system, and then analyze the audio buffers (real time no longer required) to determine the intervals from the number of intervening audio samples times in units of the (relatively reliable compared to anything you could do in an android app) audio sample rate. You can also get an analog input easily by using the light sensor to vary the frequency of an audio oscillator.