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.
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.
Sometimes, when the app I'm working on comes out of suspended mode, I need to make sure it does not respond to the notifications iOS has saved for it while the app was suspended. Where's the right place to perform this cancellation where I can be sure my response code won't run?
I'm hoping that putting removeObserver is applicationWillEnterForeground would do the trick, but I couldn't find anything about this in the NSNotification doc.
Edit:
Let me add the details of the scenario:
The app I'm working on checks for changes to calendar events for the range of the next 7 days. It refreshes it's data (requeries eventStore) at two times:
1. When an NSNotification comes from the iPhone calendar about changes.
2. The first time the app is able to on a new day, because the 7 day range has changed.
The design challenge I'm having is the case where both scenarios are true at the same time (the app returns from being suspended and it's a new day, and calendar events were modified while the app was suspended ). I only want to requery the event store one time in that case. My thought is to, in applicationWillEnterForeground, on the case that it's the first launch of the day, tell the app to ignore or drop any notifications.
I'm getting the impression my assumptions about how NSNotifications would work in this case might be off. Any guidance would be great!
Why not remove the observer from the notification centre in -applicationDidEnterBackground:?
Then you can start observing again in -applicationWillEnterForeground:.
What NSNotifications come in while you’re suspended? Are you running a background task?
I can’t really think of a case where not responding to an NSNotification would be a good idea. They are effectively messages like any other, just with a different routing mechanism.
UILocalNotification would be a different issue.
I'm working on an alarm/reminder application and want to show a custom alarm view when specified time is reached.
From what I understand, there are various (real and hypothetic) ways of doing it:
UILocalNotification. It would be perfect, but alert customization features are insufficient, e.g. I can't show a custom alert view, I can't play a sound for more than 30sec etc.
Keep application in the background and use NSTimer or other means to schedule execution after some time. Most likely won't work as the app may be killed any time.
Start my app at specified time to receive the notification. As far as I know it's not allowed at all.
After spending several days searching for a solution, I would give up and stick with UILocalNotification, but I DO know an app that shows custom alert view at specific time AND is available in AppStore. The app is named "Alarmed" and from what it looks like (last app view shown on alarm time before an actual alert; alarm still triggers even after the device is restarted) they found a way to start their app at specific time and still pass Apple's review.
Any ideas how this can be done?
Thanks.
It's not possible to show notifications other than what UILocalNotification offers you, unless the app is running in the foreground. (I just tried to install "Alarmed" and it uses a regular UILocalNotification like you'd expect).
I have an app that requires me to take an action after some period of time. For example, if an user hasn't been inside the app in few weeks, when the user eventually starts the app, I have to ask them to put in a special code that was given to them when they installed this app. (this is an in-house app and i am being required to do this due to security concerns)
I am using the [NSDate date] method to retrieve the date when the user logs in and save it into a database. I compare this saved date next time they open up the app and see how long its been since their last login. The problem is that [NSDate date] gives the time that is effected by the time settings that can be changed manually by the user in the native settings app. As you can probably tell, this causes lots of problems to my situation. If the user is suppose to be put the special code after 3 weeks of inactivity, he can cause the app to show this screen by modifying the time in the native settings app or worse, get away from it by setting the time to a previous date that will be within 3 weeks of his activity.
Is there a way to get the "system time" instead of the "user time"? I have looked into mach_absolute_time() but this gets reset after restart of the device. Since the time of inactivity I will be comparing against is pretty large, chances are device would have been restarted by then. I also thought of using network connection to get the time from servers outside the app, but lots of users won't have access to wifi where they use their iPads. That will be my last resort solution if i can't find anything else. Because of their location during usage, I am trying to use everything on the device itself.
Am I overlooking something simple here? this seems too simple of a problem to not have an answer. Please guide me toward the right direction. Thank you in advance.
Why not query a remote server for the time - lots of NTP servers about or just make a simple HTTP request to a php script on your own server. Of course if your app is likely never to be connected to the internet that could be a problem, but once you have a 3rd party time its quite easy to guess if the user has been playing with the clock.
If this is an inhouse app (so you aren't constrained by Apples approval process), you could mark your app as doing some background stuff (voip or receiving location updates), so that the app will always be active and you'd be able to update some sort of an "unused" counter. Voip app will even be restarted by the OS after device reboot.
But of course it'll drain the battery somewhat.
Either: make having the actual time an essential feature of your app. This way the users will have a need to keep the time of the device current and can't go back three weeks
Or: mark the code as expired and save this information before the app informs the user. This will stop most user from setting the time back. Most will try once or twice, see that the app stays disabled and will give up.
You can also save the timestamp of the last successful execution and if that is more than a reasonable time frame in the future (remember summer/winter time) then consider it a "hack attempt". Put a CRC check (or whatever obscure idea you come up with) on that timestamp and save it too and you will stop a large number of script kiddies.
You can never stop the diehard hacker who search actively for every trick you might have put into the app. Just focus on the "average" user.
Was reading through the iOS4 documentation for multitasking, and couldn't figure it out.
I basically need to update the badge count on my app's icon after midnight each day as long as the app is running in suspended mode (with multitasking).
I know this has to be possible, just can't figure out the best way to do it.
Thanks.
iOS "multitasking" is very specific. There's an important distinction between states here:
Suspended: Your app resides in memory, but does not receive any execution time. This is really only useful for fast app switching.
Background: In a few particular cases, you can request that the OS to run your app in the background. (Playing audio, location, finishing a long task, voip.)
So, the short answer to your question is, "you can't."
Here are a couple useful links on iOS multitasking, such as it is.
Understand an Application's States and Transitions
Executing Code in the Background
You could use a UILocalNotification to set the badge (without an alert) but you can't increment the badge because you're app does not have the opportunity to execute any code when the notification fires.
You can schedule up to 64 notifications in advance, one at midnight for the next 64 days, each one setting a new badge number. It would make a lot more sense to schedule a repeating notification but since your app can't execute code it can't increment the badge number that doesn't work.