i'm looking at displaying the current time in HH:mm format, and ive been checking around for the best way to do this.
Most examples have a Timer being executed every second, updating a textlabel for example.
Now, i'm imagining that this might drain a bit of battery if it's to run every second, which seems like overkill if all i'm displaying is hours and minutes. On the other hand, i don't want the minute-switch to happen 30 seconds later than the actual minute switch...
Is there some way to get a call when the phone clock changes minute or something like that?
Don't worry about the battery. NSTimer exists for this purpose. Use it!
Here's an idea:
Calculate the time interval between now and the next minute start
schedule a one off NSTimer to fire after that time interval
update the display when it fires
Go back to step 1.
Related
I have a timer app, it counts up for an indefinite amount of time (until the user stops the timer). It works much like the default iOS clock stopwatch.
I have read the articles about being a responsible background app. I don't have any UI changes happening and stop the timer when the app goes in the background and resume the timer upon returning to foreground. The app does send a local notification every 30 minutes or so to remind the user to take a break.
Problem: Without fail my app is terminated after a few hours (between 2-6 or so hours) and the current timer and info is lost.
Things I've tried:
-As aforementioned I changed my app to follow the guidelines of being a responsible background app (before I had the timer UI counting up and also the timer running, even while in background). I thought this would solve the problem since my app isn't using up much memory or doing any intensive tasks.
-I also have tried saving out the data of the current timer (to NSUserDefaults) in ApplicationWillTerminate and then restore it on DidFinishLaunchingWithOptions. It doesn't seem to work. It's almost like my app is force quit or something because if ApplicationWillTerminate was being called then it would save the data and restore it upon the app launching again. Mystery.
-Currently I'm saving an NSDate of the start time of the NSTimer on ApplicationDidEnterBackground, invalidating the timer, and starting the timer and restoring the start time upon ApplicationWillEnterForeground. Still no luck.
The thing is this is affecting a very small percentage of my users--so it's not like it's a problem for everyone, which makes it more confusing. I still want to fix it of course because it's a pretty lame bug--and I've encountered it myself (on an iPhone 5), so it's not necessarily an old iPhone low memory somethingorother problem.
This has really boggled me, I've done my research and also scoured fairly well the stack overflow questions and don't seem to find much of anything to help me.
Any help would be appreciated, feel free to ask more questions or tell me to clarify.
applicationWillTerminate is basically never called. It will not be called when your app is in the background and it gets removed from memory. You should expect your app to be removed from memory if it hasn't been used for a while. How long "a while" is depends on what else the device is doing at the time... Best to use applicationDidEnterBackground: or applicationWillResignActive:.
When your app goes into the background, record your timer's elapsed time (eg: in NSUserDefaults or however you prefer). Also record the current time. When the app comes back into the foreground, look at the two values you recorded and update the elapsed time accordingly, ie:
elapsedTime = savedElapsedTime + (currentTime - timeWentIntoBackground)
There's really no reason your app needs to remain active in the background burning the user's battery just to keep track of seconds ticking by.
Also, don't rely on applicationWillTerminate. Use applicationWillEnterBackground.
I'm working on an app that has an event timer that times an event (duh!) that can last a long time.
I've done other apps with timers over a fairly extended time period and never come across this problem before.
Basically, what's happening is that when the app launches, I set an NSDate value with [NSDate date]. Then, I have a scheduled NSTimer object that fires regularly and checks how much time has elapsed by comparing the current [NSDate date] value against the original one.
As far as I know, that's the correct way to do this sort of thing, but please correct me if I have a faulty assumption in the above paragraph.
Anyway, when testing on my new iPad over the last few weeks, I've variously (and randomly) caught a few times where it appears that my system time is jumping around a good bit. In one instance, the time seems to have jumped 64 seconds! This meant that my timer label displayed '00:03' and then immediately displayed '01:08' (add a second correctly and then 64 incorrectly)!!! At other times, it has resulted in a negative event duration.
It's an intermittent occurrence, so I'm basically asking whether this could be:
An iOS 5.1 bug
Something to do with the hardware specific to the new iPad (never had this issue on iPad 1st Gen, 2nd Gen, several iPhone/iPod Touch versions, etc...)
Bad Code (I'll admit this is possible, but it's not like the NSDate value ever becomes something other than an NSDate value, and I've checked every place in my project where this singleton value is set.
Has anyone had any similar experience? Can anyone help?
This is not a iOS device or OS version bug.
The NSDate API is not guaranteed to be consistent, or even monotonic, as you have found. It drifts (depending on temperature and such) and then gets corrected from either cellular or NTP sources, after which the date and time value can jump.
For a monotonic local timer, you can try the functions in mach_time.h . For a better absolute time reference, your app can try polling a network time source. Or you can tie your own time function to some combination of both.
I am writing an iPhone game. When the user makes his first move a timer kicks of with an interval of 0.01 seconds. A UILabel displaying the time also gets updated every time.
I noticed when testing on an iPod touch 2nd gen and an iPhone 3GS that the iPod was slower (after 20 seconds the iPhone displayed 00:20,00 and the iPod displayed ~00:10,00). Is there a way to make this more reliable? If I'm correct, the NSTimer should run on its ow thread and should not be blocked by user interaction.
JNK
The NSTimer documentation states:
Because of the various input sources a
typical run loop manages, the
effective resolution of the time
interval for a timer is limited to on
the order of 50-100 milliseconds. If a
timer’s firing time occurs while the
run loop is in a mode that is not
monitoring the timer or during a long
callout, the timer does not fire until
the next time the run loop checks the
timer. Therefore, the actual time at
which the timer fires potentially can
be a significant period of time after
the scheduled firing time.
So accuracy can be as bad as 0.1, not 0.01 seconds. Not to mention if your thread is blocked for some reason. So if your firing time is crucial you should be looking at other things. Read this SO post for kick-off. Apple had a metronome sample code (in which, obviously, timing is crucial) but I can't find it just now.
In any case, if you are implementing a timer with NSTimer, you should record your start time. Then, whenever you update your interface, simply take the difference of the current time and your start time (with NSDates).
make sure you're not basing a timer off of sleeps or delays. You should always update a timer based on things like number of clock ticks since program start or current time
sorry I'm not more familiar with your language
You can't rely on a timer to run exactly at the specified time intervals, so the time you are displaying should always be calculated by taking time interval differences. And I doubt that a timer on the iPhone can run every 1 ms, in Quartz it is possible to get a timer call every 16 ms or so, making 60 fps - so scheduling it at 1ms probably means "run as soon as possible", which might be quite different on different hardware.
I'm trying to create my own loadbar; It consists of 5 bars, sliding in from the bottom from the left to the right, then sliding out to the top in the same order. There should be a fixed amount of time (say, 0.2 seconds) between all of them sliding in.
Currently, i'm using a timer to start them one by one, and then let themselves repeat. However, if there's some lag during start or something, they get messed up. The first two or sometimes 3 bars go almost simultaneously, the gap is bigger, just name it and it happened. I currently just set fixed times when each animation should start, but some lag makes them go bogus.
Any given bar moves up in about 0.3 seconds, waits there for 0.2 seconds, then moves further up in 0.3 seconds. They start 0.2 second after their left neighbour, from left to right. Once they started, they just repeat it.
So, what could i use to coordinate them in such a way, that there will always be the same amount of time between them?
Other things i have considered was just using a lot of images (but that will need lots of images i suppose), or using Key Value Observing (KVO) to see when the previous bar is at the desired height.
According to the NSTimer documentation, NSTimer objects are not guaranteed to be realtime accurate on iOS.
A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed. Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds. If a timer’s firing time occurs during a long callout or while the run loop is in a mode that is not monitoring the timer, the timer does not fire until the next time the run loop checks the timer. Therefore, the actual time at which the timer fires potentially can be a significant period of time after the scheduled firing time.
It's an issue that effects NSTimer as well as OpenGL based games. Michael Daley mentions something similar in his book about how to set things up properly for an openGL based game. I suspect that this is suffering from the same similar situation.
That said, I would suggest preloading those images a adding them to the view just outside the bounds or frame of the visible view before you need then so that they are immediately available when you need them.
Addendum:
After thinking about this, I'm wondering if the C function wait() will help you here. It's a long shot, but perhaps it's worth a try. If not, then the answer may very well be that there is none.
Addendum 2:
I have no idea if this is going to help you either, but I found this page, which discusses pausing a program for less than a second.
This is an embarrassing question but it involes Xcode and the iPhone SDK.
Why would I need to set more than one timer? And do 2 timers take up more 'tics' than 1 timer or are they all based on the same master internal clock?
Is it better to add 1 timer routine and just have it call all the things I need to make happen or have 5 or 6. I'm not new to programing but I'm completely new to xCode and just trying to wrap my head around it.
Eg. If I have a timer updating the clock on the screen, and I also want to update the GPS position, is there any reason not to have the same timer update both?
Thank you.
One is that timer delegate will operate in separate threads. So in your case, when only one timer is used, if the GPS acquisition takes to much time, your screen will feel unresponsive because the clock will be unregularly updated.