Is there a way by which using the android chronometer class to set base of the chronometer in 15 minutes and from that period the times goes down until 0 seconds?
I have tried with setBase(60000) but this isn't work.
Check out this thread Android: chronometer as a persistent stopwatch. How to set starting time? What is Chronometer "Base"? as well as this thread Android - Get time of chronometer widget. Neither answers your question directly, but the nuggets there should lead you to an answer.
In general the chronometer works like this (if you would like to set the Base to a specific nr):
mChronometer.setBase(SystemClock.elapsedRealtime() - (nr_of_min * 60000 + nr_of_sec * 1000)))
what you are asking can be done through a countdown (http://developer.android.com/reference/android/os/CountDownTimer.html)
Or create your own countdown by using the chronometer like this (more work should be done cause i just wrote this and did not test it yet)
private OnChronometerTickListener countUp = new OnChronometerTickListener(){
#Override
public void onChronometerTick(Chronometer chronometer){
long elapsedTime = (SystemClock.elapsedRealtime() - mChronometerCountUp.getBase()) / 60000;
Log.v("counting up", elapsedTime);
// you will see the time counting up
count_down--;
if(count_down == 0){
mChronometerCountUp.stop();
}
// an int which will count down,
// this is not (very) accurate due to the fact that u r using the update part of the chronometer
// u just might implement the countdown i guess
// or 2 chronometers (one counting up and an other counting down using the elapsed time :p)
// just remember programming is creating ur solution to problems u face its like expression urself
};
};
http://developer.android.com/reference/android/widget/Chronometer.html
For set the base time you can use elapsedRealtime(), and you can output format with setFormat()
Related
for a school project i'm making an app. The app is supposed to keep track of the time that you spend working on something specific. For example when i'm going to start my work shift, I would press a (start)button so the timer starts off and counts how much I've worked until i press a stop button.
I've got the xaml ready with all the buttons and labels.
My main problem is the timer. I would like to have a stopwatch underneath my start button, that shows the elapsed time. I've been looking for many many hours on github, stackoverflow, google and youtube and haven't found a solution.
If it isn't easy/possible to implement a stopwatch, i would at least need the app to check for the system time when the start and stop buttons are clicked, to calculate the difference in time.
So far I haven't been able to get any of those functions working.
Thanks in advance! - MagSky
.NET has a built in Stopwatch class you can use
Stopwatch stopWatch = new Stopwatch();
stopWatch.Start();
// do some work here
stopWatch.Stop();
// Get the elapsed time as a TimeSpan value.
TimeSpan ts = stopWatch.Elapsed;
to display a Timer in the UI, use System.Timers.Timer instead
int secs = 0;
// fire an event every 1000 ms
Timer timer = new Timer(1000);
// when event fires, update Label
timer.Elapsed += (sender, e) => { secs++; myLabel.Text = $"{secs} seconds"; };
// start the timer
timer.Start();
Let's say I have this variable:
long myMillis = 20000;
This means that I want my Chronometer to start at exactly 20 seconds (00:20).
I tried doing this:
chronometer.setBase(myMillis);
But it doesn't work. It dosn't start with 20 seconds. It starts with some weird time that doesn't make sense.
In general the chronometer works like this (if you would like to set
the Base to a specific nr):
mChronometer.setBase(SystemClock.elapsedRealtime() - (nr_of_min * 60000 + nr_of_sec * 1000)))
so make it:
mChronometer.setBase(SystemClock.elapsedRealtime() - (2* 60000 + 0 * 1000)))
For Kotlin,
To start Chronometer with starting time 20 seconds, you can use
val timeInMilSeconds = 20000
chronometer.base = SystemClock.elapsedRealtime() - timeInMilSeconds
chronometer.start()
This will start Chronometer with starting time 20 seconds i.e. 00:00:20
Its Late but may help others.
I have used following code in first fragment
chronometerTimer.setBase(SystemClock.elapsedRealtime());
chronometerTimer.start();
and then move on some condition to next fragment where chornometer should start at same time of previous chornometer ends, i get elapsed time using this code.
long elapsedMillis = SystemClock.elapsedRealtime() - chronometerTimer.getBase();
and i send elapsedMilis in next fragment and use following code
chronometerTimer.setBase(SystemClock.elapsedRealtime() - elapsedTime);
chronometerTimer.start();
it worked perfectly.
I have a problem in my app. I want to turn off immunity time after 10 seconds, so I measure the time passed like this: I have a startTime variable on create method and it gets value System.currentTimeMillis(). After this I check on render function that System.currentTimeMillis() - startTime > 10000. This doesn't work very well, it takes much longer than 10 seconds. Also, when I print to log System.currentTimeMillis() - startTime, it firstly show me for a while "0" then it changes... Any advice?
libGDX has classes for what you want.
I suggest you use the Time.Utils calss :
onCreate(){
startTime = TimeUtils.millis();
}
render(){
if(TimeUtils.millis() - startTime > 10000){
//Do your stuff
}
}
Ok guys, I somewhat finally figured out by myself. I need to use long to hold that size of values. It was kind of obvious.
EDIT: I've posted my solution below, (basically, ListViews are very slow for some reason), and will try to update it further if I can clarify why exactly a ListView is so awful in this situation.
Objective:
Get 7 ListView objects showing 7 independently set clocks/timers which update/tick every second. These clocks are just Strings with a calculated elapsed time shown (SystemClock.ElapsedRealTime() - stored ElapsedRealTime() of when the object was instantiated.)
The problem:
Basically, 8 minutes into these 7 clocks ticking away - my program is essentially useless.. the information presented is inaccurate, the UI is pretty much unresponsive, etc. Here are some results of testing against the benchmark of a physical stopwatch:
At 04:00, clocks are slipping 1 second, and updating every 4 seconds.
At 06:00, clocks are slipping 3 seconds, and updating every 5 seconds.
At 08:00, clocks are slipping 6-7 seconds, and updating every 6 seconds.
At 16:00, clocks are slipping 7 seconds, and updating every 10 seconds.
What I have so far:
I have a custom class, ActivityTimer, with a stored long representing the SystemClock.ElapsedRealTime() of when each ActivityTimer was first instantiated. By clicking on a Button 7 times, I instantiate 7 of these, each of which are added to an ArrayList
I have a compound view, ActivityTimerControl, which is passed an ActivityTimer upon instantiation, and then presents data elements of my ActivityTimer in UI elements (such as the ticking clock.) My ArrayAdapter handles this instantiation and works fine. As per this fine tutorial I have a _Handler in this ActivityControl, which upon construction of the ActvityControl posts this:
private Runnable _timerUpdateTask = new Runnable()
{
public void run()
{
final long start = _ActivityTimer.getStartTime();
long millis = SystemClock.elapsedRealtime() - start;
int seconds = (int) (millis / 1000);
int minutes = seconds / 60;
seconds = seconds % 60;
if (seconds < 10)
{
_tglActivityPauseButton.setTextOn(""+minutes+":0"+seconds);
}
else
{
_tglActivityPauseButton.setTextOn("" + minutes + ":" + seconds);
}
_tglActivityPauseButton.setChecked(true);
_timerUpdateHandler.postDelayed(this, 1000);
}
};
Other than what I've described my project really doesn't do anything yet, as I've been stuck on this fundamental issue so far. So I haven't posted any other code because I just don't think its relevant beyond the summaries I've given above - but if anyone feels some other part of the project is relevant just let me know and I'll post the detailed code for it. I'm presenting my final String into the SetTextOn() of a ToggleButton, but testing has shown that this isn't a significant factor - it doesn't matter whether I'm setting the Text of a normal TextView, or what, no matter what I've tried my results are always roughly the same, with noticable lag on each clock and eventually the UI becoming unresponsive completely.
My understanding is that a Handler is supposed to be the most efficient way of updating a UI element on a consistent and frequent basis, replacing java.util.Timer, but despite this my code starts out slow and just gets worst the longer I let it run.
Even upon increasing the postDelay to 5000ms, the same problems still occured and the app still force closed after 49 minutes. Since I would have thought this test would have extended the time til force-close by 5, if not fixing it altogether (at the detriment to the functionality I want), I'm suspecting that something isn't recycling right with the handler or some other component.
My Questions:
I suspect my problem is in having 7 objects (ActivityControls), each of which has its own Handler constantly cycling the update of the corresponding time that's displayed. Does anyone have experience to say if this would be the case?
Is there a way I can have a single Handler that calls upon each ActivityControl in my ListView to update its time?
Does posting a message to the Handler leave some memory trace that doesn't dispose automatically, or might benefit from being forced to dispose?
Does anyone else have other ideas about the most efficient way of running constant UI updates on multiple objects?
you are delaying by 1sec
_timerUpdateHandler.postDelayed(this, 1000);
You have not allowed anytime for your code to run.
Ugh.. wouldn't you know it.. this isn't a problem with my Handler, or anything else like that. It's either an inefficiency with a ListView, or some funkiness that takes place in an ArrayAdapter (the one I was using was as simple as it gets though.) I made a sandbox project (below) and instantiated my 7 ActivityTimers right into an ArrayList, and then iterated through that array using each object to instantiate an ActivityControl that's passed a copy of that ActivityTimer from the array. Everything I was doing previously, but replacing the ListView with a LinearLayout contained in a ScrollView. After 16 minutes I've got 7 ActivityControls ticking away roughly every single second, and keeping accurate time. Even after 30 minutes, showing no slight hint of problems (as it should be!) Here's what I did:
public class Sandbox_Experiments extends Activity {
ArrayList<com.maxx233.Sandbox.ActivityTimer> _ActivityTimers = null;
#Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
_ActivityTimers = new ArrayList<com.maxx233.Sandbox.ActivityTimer>();
View myLayout = findViewById(R.id.Info);
com.maxx233.Sandbox.ActivityTimer act1 = new com.maxx233.Sandbox.ActivityTimer();
com.maxx233.Sandbox.ActivityTimer act2 = new com.maxx233.Sandbox.ActivityTimer();
com.maxx233.Sandbox.ActivityTimer act3 = new com.maxx233.Sandbox.ActivityTimer();
com.maxx233.Sandbox.ActivityTimer act4 = new com.maxx233.Sandbox.ActivityTimer();
com.maxx233.Sandbox.ActivityTimer act5 = new com.maxx233.Sandbox.ActivityTimer();
com.maxx233.Sandbox.ActivityTimer act6 = new com.maxx233.Sandbox.ActivityTimer();
com.maxx233.Sandbox.ActivityTimer act7 = new com.maxx233.Sandbox.ActivityTimer();
_ActivityTimers.add(act1);
__ActivityTimers.add(act2);
__ActivityTimers.add(act3);
__ActivityTimers.add(act4);
__ActivityTimers.add(act5);
__ActivityTimers.add(act6);
__ActivityTimers.add(act7);
for (int i = 0; i < __ActivityTimers.size(); i++)
{
ActivityControl ac = new ActivityControl(this, (com.maxx233.Sandbox.ActivityTimer)__ActivityTimers.get(i));
ac.setLayoutParams(new LinearLayout.LayoutParams(LinearLayout.LayoutParams.FILL_PARENT, LinearLayout.LayoutParams.FILL_PARENT));
((LinearLayout)myLayout).addView(ac);
}
}
}
So I'll work on figuring out what spcifically it is about having a ListView in the equation that causes such a problem, and then I'll update this thread in case anyone else is having a similar problem ever. Unless someone else out there happens to already know why a ListView would make updating a handful of objects each second so much more resource intensive?
im working on a audio profile switcher for android and as part of the entire project, i have a service that is running in the background using the following timer code:
timer.scheduleAtFixedRate( new TimerTask() {
public void run() {.....}, 0, nextUpdateInterval);
what im noticing is that the timer is not honoring the dynamically generated next update interval period...the nextUpdateInterval is declared as private static long which is initialized to 30000 (30 seconds) for the first run....then once a profile is found, i do some math and update the nextUpdateInterval...i have converted the nextUpdateInterval value back out to hours/minutes for debugging purpose, and the calculation is working as expected...like it shows me in hours and minutes, when the next timer execution should take place...
nextUpdateInterval calculation: long entirePeriodDiff = toTimeMiliseconds - fromTimeMiliseconds;
then once a profile is found, i calculate the elapsedTime like so: long elapsedTime = rightNowDate.getTime() - fromDate.getTime();
and then i update the nextUpdateInterval: nextUpdateInterval = entirePeriodDiff - elapsedTime;
one example scenario: Profile of 'Work' is set from 9AM to 4:30PM, the service/app is executed at 2:02PM (EST), my toast message is executing constantly and is acting as a count down telling me how much time is left...in this case 2:28 and decreasing...ideally this should not display until the 2:28 is up...any ideas?
As per android doc:
With fixed-rate execution, the start time of each successive run of a task is scheduled without regard for when the previous run took place. This may result in a series of bunched-up runs (one launched immediately after another) if delays prevent the timer from starting tasks on time.
I think that could be the reason, may be you need to consider alternative 'fixed period'