In my application i want to run an internal clock in background mode [while application is not running in foreground].
The whole functionality will be like this:
I think there are 2 ways you can go about solving your problem.
Never use system time. In other words, never call [NSDate date] in your code. When you need the current time, call an NTP server. This will of course cause latency in your app, but will guarantee accuracy.
When the app launches, or enters foreground, verify that the system time is reasonably accurate against an NTP server. If the system time is off by more than your tolerance level, then do not let them continue running the app until they address it. If the system time is okay, then start monitoring to ensure they don't change the system time while running the app (NSSystemClockDidChangeNotification). If they pass the initial check, but the move the clock forward, you can catch that and disable the app til they change it back to being accurate.
Here is an iOS NTP implementation which could be helpful in implementing either solution above. http://code.google.com/p/ios-ntp/
EDIT: The Ticketmaster app uses technique #2, so this seems like a reasonable solution for a ticketing app that requires your system time to be correct.
so my suggestion: do the logic server side with push notification
apple is support small task for background mode which will work for approximate 10 sec only.
so you can do one thing when app is active then get time form server and update your local time according that.
Update: Sorry to say my original answer isn't correct. When the device goes to sleep (can happen sometime after it's locked) the internal CPU clock stops ticking, and mach_absolute_time
won't update either. Theoretically it will return the exact same value if you call it right before the device went to sleep, and after it awakes.
The best available way I know of to check for date changes is kern.boottime
, it holds the boot time, and is modified whenever the system time changes. Among other things, kern.boottime will be updated if the user changes the time, or if the OS changes the time itself according to info from cell towers.
So, in your case, you can take the original time you calculated and modify it according to the modifications in kern.boottime. If you see kern.boottime changed significantly, it may mean that the device was turned off, and in this case you will need to contact the server to ask it for the time until the flight.
Relevant code:
time_t getBootTimeSecs(void)
{
struct timeval boottime;
size_t size = sizeof(boottime);
int ret = sysctlbyname("kern.boottime", &boottime, &size, NULL, 0);
assert(ret == 0);
return boottime.tv_sec;
}
Original (incorrect) answer: You can use mach_absolute_time
which isn't affected by date changes made by the user.
When you book the ticket, get the correct date from the server and record mach_absolute_time
. Now you will always be able to call mach_absolute_time
whenever you want, calculate the difference from the one you recorded initially, and display the correct date.
This will only work as long as the device wasn't shut down, in that case it makes sense for the app to re-connect to the server to get the correct date.
You can also either Local or Push Notifications to alert the user when the target date is getting closer, even if the app isn't running.
I think that you can only detect that the date of the iOs device has been changed (using NSSystemClockDidChangeNotification). I guess you to use this notification and force reload the real date of your application from your server (With a WebService).
EDIT: You can use the systemUptime in NSProcessInfo:
NSLog(@"ProcessInfo System uptime: %f",[NSProcessInfo processInfo].systemUptime);
but it will not solve your problem if the Device is restarted.