I'm building a flutter app where I want to restrict some of the users for a week and also show them the remaining time in days and hours so when the apps get close the timer should never get stopped. and also the date and time should not depend on the device time (if they change device time it should not affect the countdown)
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 try to make an app which can assume the sleeping time of the user.
Samsung devices (samsung health) can assume the sleeping period based on yesterday last, and today first interaction. The app no needs to run into background. So I think, that it reads somehow from the relevant device data.
Is there any way to get the time when the user uses his/her phone in Swift?
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 interested in building a Timer Based game such as mafia wars or soemthing like that. I'm stuck on one question.
What would be the best way to retain a timer, even if the app is closed?
Should I do this based on the Device Clock? or should I set a time to a server, and get the time when the device starts up?
If any one knows a better way for this,
let me know.
Thanks.
#lessfame
I'll interpret your question as "What's the best way to measure elapsed time between app launches?" instead of "How do I make a timer fire when my app is closed?".
There's no reliable and accurate way to measure time when the device is powered off (remote servers might not be reachable, astronomical measurements might not be possible if it's cloudy, ...). Don't bother.
That said, most CF/NS APIs use CFAbsoluteTime/NSDate (namely, CFRunLoopTimerGetNextFireDate() and -[NSTimer fireDate]). I'm not sure what they do if the system clock changes.
You can use mach_absolute_time() (and it's used internally by some things), but that's just system uptime, so it fails if the phone reboots. I'm not sure if you can get the boot UUID in order to find out if the phone has rebooted.
At the end of the day, CFAbsoluteTimeGetCurrent() or (equivalently) [NSDate date] is probably enough; just make sure that your app behaves sensibly if the time suddenly changes by a day or two in either direction.
Yes, the user can game the system by setting the system clock. You can mitigate this to some extent by occasionally syncing with the server, and keeping track of game time elapsed between syncs. If the difference between elapsed game time and server time is small, then just speed up or slow down the game appropriately to bring elapsed "game time" to real time. If the change is large, you can restore from the last save point on the server, or make the user wait until the elapsed game time has elapsed in server time, or a bunch of other things. This means you can't start playing until the initial sync, but the user has to be online to download the app anyway, so it's not a major problem.
If you only need to retain the time and show how much time elapsed since the game was closed (i.e. you don't need to notify the user when the time is up), you can use the [NSDate timeIntervalSinceNow] method to determine the amount of milliseconds that passed between two times.
If you are saying you want to just know time elapsed since some event, all you do is log the initial time, and then log the final time and compare the difference.
If you need a countdown timer to some event then what you do is set up a local push notification set to go off at the end time.