Reputation: 1445
I am working on a Objective C project on Xcode6 beta 2 running on an iOS8 device. I am printing the backgroundTimeRemaining in the method: applicationDidEnterBackground.
- (void)applicationDidEnterBackground:(UIApplication *)application
{
NSLog:(@"Background time remaining %f seconds", application.backgroundTimeRemaining);
NSLog:(@"Background time remaining %f seconds", application.backgroundTimeRemaining);
NSLog:(@"Background time remaining %f seconds", application.backgroundTimeRemaining);
}
The results I received were:
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000 seconds
9.995252 seconds
9.991967 seconds
Why does it output this big value on the first log (1797693...) ?
Thanks
Upvotes: 6
Views: 553
Reputation: 2228
The backgroundTimeRemaining
will return to you a NSTimeInterval
, which is really just a double
value.
I believe therefore, before it can register the time interval (it is returning to you the remaining time "too quickly") it will give you the maximum value that a double can represent.
The `double` data type gives a range of approximately 1.7E–308 to 1.7E+308 for type double.
...which is why you are getting that ridiculously lengthy value.
Happy coding! :)
Upvotes: 0
Reputation: 1445
I found out a quick and dirty fix that seems to work. Make the thread sleep a bit before requesting applicationTimeRemaning:
- (void)applicationDidEnterBackground:(UIApplication *)application
{
[NSThread sleepForTimeInterval:.01];
NSLog:(@"Background time remaining %f seconds", application.backgroundTimeRemaining);
}
But this is obviously not an ideal solution.
Upvotes: 1