I am making an app that tells users the time until the next bus comes. As the time changes it will be different to the time that was registered in viewDidLoad. How can I constantly update the time?
Related
So like I want to allow my app to check if one week has passed, and if that is true, Increase a certain variable, while at the same time, checking if the user has opened the app in that one week. If the user hasn't opened the app in the one week that passed, the app sends a notification to the user to open the app.
I've thought of using NSTImer to do this but I'm worried that the timer would stop when the user closes the app
Is there a way for an iOS app to keep track of real-time without using NSTimer?
These are different issues:
if one week has passed, and if that is true, Increase a certain variable
Store a UserDefault with the starting date. When you launch, check the value. And observe significantTimeChangeNotification to see date changes while the app is running. In either case, if a week has passed, update your variable and the UserDefault.
If the user hasn't opened the app in the one week that passed, the app sends a notification to the user to open the app.
Completely separate issue. This is done by scheduling a LocalNotification periodically for 1 week in the future. Periodically (i.e. during app launch and significantTimeChangeNotification) reschedule it. When it fires, it will show your alert.
I'm working on an application notifying Muslims at prayer time. Every day, five different notifications need to be set, notifying the users it's time to pray.
I was able to schedule notifications for one day, but how can I set them every day again? The 5 times need to be changed every day without user interaction or having to open the app.
Is there some kind of callback when the last notification fires, so I can setup notifications for the next day?
One way is to schedule notifications for a week (5*7) if you can get their times correctly , on the basis of that the user may open your app at least once/week
Other way is to make use of background fetch capability where IOS wakes your app to run at any time On the assumption that you re-schedule them for a week from the launch time
I am developing an iOS application for iPod Touch in which my application displays the server time always. I always sync the application time with server time whenever the application comes to foreground by making a web service call to the server. If there is a connectivity loss between my server and client for few hours I wont be able to sync the application time. I read iOS does not support running a timer when the application is in background other than few limited cases mentioned below:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
So how can I keep track of application time? Whenever the user switches to my application he needs to look at the server time so I need to run a timer to update the last synced server time.
A combination of other answers, create a class in charge of obtaining the server time and maintaining the last time the application was synced to the server using a combination of NSDate* lastSync and applicationDidBecomeActive. For example:
-(void)applicationDidBecomeActive:(UIApplication*)application {
[ServerTimeSync sharedInstance] resync];
}
ServerTimeSync will maintain an NSDate* property with the last sync time (you'll want to convert what the server gives you to an NSDate*).
You can store the NSDate when the app goes into the background. When it resumes, get the current NSDate again, and add the difference to your stored server time.
You don't need a timer for this at all.
I would suggest that when you sync time with your server, you have it return its current UNIX timestamp. You can then do:
[[NSDate date] timeIntervalSince1970];
...to get the device's current UNIX timestamp. Then what you can do is store the difference between these two timestamps. This is the clock skew between the server time and the device time.
You can now compute the server's approximate time by taking the device's current UNIX timestamp and adding the clock skew to it. Adjust for time-zone when displaying it (if you want), and you're done. Whenever you sync time with the server, you can just refresh the stored clock skew value.
If you want to get fancy, you can also attempt to measure and take network latency into account when determining the clock skew.
This approach should work much better than trying to store the server's absolute timestamp and then track how much time has elapsed using a timer (or any other mechanism).
I am developing an enterprise app which has a lot of dynamic content. Is there a way to have the app auto update the content(new stories, download new videos, etc) at 3am every Sunday.
Is this possible?
While it’s not possible to do this when the app isn’t running, you can do it fairly easily at launch or while running (if it’s going to be running at 3 AM). Here’s what I’d do:
Store an NSDate using NSUserDefaults for the last time you updated.
At launch, if a 3 AM period has passed since that date, initiate a sync.
Also at launch, start an NSTimer with a long interval—5 minutes or so. At each firing, check if a 3 AM period has passed and if it has, initiate a sync. You could even roll the last bullet’s code into this NSTimer’s firing method and just run it once at launch. Just be sure to update the NSDate object each time.
In the application delegate, in the methods called from returning from the background, check the time and sync if necessary—or just start the NSTimer and have it fire immediately first.
That should cover all of the scenarios where you need to update the app.
Is there a way I can easily set up a notification when the minutes change on the system time for iOS devices?
I need to do some UI updates for time changes. I'd like the UI to update exactly on minute changes, not just every 60 seconds through an NSTimer trigger.
There are no notifications provided by the API but you could roll your own by having a background thread polling the system time and then sending a custom notification to the UI on the main thread.
However, I wouldn't bother. You can't manage time "exactly" on any device with a software UI. The best you can do is get the UI updates to occur below the threshold of user perceptions. Humans can't really perceive time intervals of less than 100-200 milliseconds (1/10th second). Any UI more precise is wasted. A NSTimer can very reliably hit a 100 millisecond window as long as some other part of the app doesn't hang or bog.
Unless you've tested the interface using a NSTimer and found it wanting, I wouldn't go looking for adding complexity.