Is there any reason that my app would get reset entirely by the iPhone?
I have a timer app that has timers with notifications for each timer. Occasionally, (it may be related to charging the phone) the app gets reset entirely, all timers stopped and reset as if the app had never been run before.
Is there a time when apps get a call to nil-out? Should I be storing the timer start times and a BOOL saying a timer is running in NSUserDefaults (or similar)?
Thanks in advance,
Michael.
Applications can be killed at any time both by the OS and the user, thus leaving us developers in a constant state of worry about hard data like yours. If you must, save it to an NSUserDefault for the next launch of your app.
Related
In my app i need to update locally settled alarms with local notifications, after 64 has been fired then set new 64 is remaining even though app is killed by user.
This means it needs to update alarms while app is killed.
In iOS that is not allowed, but
Some applications like Alarmy, Alarm Clock Pro, dozen are doing some what like this.
So is there any way to get this?
Any help will be appreciated
Thanks
I've encountered the same problem. What I've done was to create a queue and on every launch of application I rescheduled notifications based on the queue. 64 can be scheduled and the others are in the queue according to their fire date. I've also created silent push notifications that would arrive every n hour in order to force my app become active. With this approach, I could take care of that queue even if the user doesn't open the app. Your goal can be achieved but it is really difficult to implement.
After all, iOS ecosystem does not let third-party apps that have the same functionality as OS 's default apps to thrive. So basically if you're creating an alarm app you should better think again.
I am working on an app that, among other things, provides alarms in emergencies. Users can toggle a setting to have alarms be put through even if their iPhone is muted, but this service has another hurdle to leap: when the app has been force quit, it cannot receive (content-available) notifications until the app is relaunched by the user.
There is a geofencing event in place which buys me some processing time even if the app has been force quit, and in that time, I would like to check if such a block is in place, and if so, request the user to open their app again, and not aggressively force-quit in the future. (Many people still think it's just a way to keep things clean, even though it actually costs you battery life to not just leave apps in the background)
SO THE CORE OF THE PROBLEM: I need an (API call? Something else?) that will tell me whether the app is in such a 'force quit, cannot receive notifications' state, assuming that I do have processing time to do this check.
Anything is welcome, I have not been able to find proper Apple documentation on the notifications block.
Thank you very much.
While there is no API I am aware of to find state after, you can infer the state just before the application is terminated, and record that.
Code
applicationDidEnterBackground
will be called when an app has received a terminate signal.
More Info
This question describes what lifecycle functions to use, and
I'm creating an application which should count how long the user stays without using his device.
For that, I have a timer which stops when the app become suspended. But, before stop the timer, I need to test two things:
Incoming Call: The user can answer or reject the call. If he rejects the call, the timer will keep counting. Otherwise, the timer will stop, and when the app becomes activated again, it will show an alert.
The iOS system alerts: Reminders, Calendar events, Low Battery, etc. I need to identify if the app become suspended by one of these kind of alerts.
The app already handles the first case. Everything is working for Incoming Calls.
The problem is that I don't know how to check for the second case. How can I identify if the app became suspended by one iOS system alert? Is there any way of doing this?
I am developing an app (iPAD only) which shows user a pop up box after every 3 days (business requirement) from the "First" time he has installed the app. I am using NSTimer to do it. The implementation breaks if the user deletes the app and reinstalls the app before three days period. In this case the counter for 3 days restarts. I know using Date might not be a good idea because user can change it from settings.
Is there a way I can keep the NSTimer (or anything similar) to keep running even after app is deleted?
NSTimer* msgTimer = [NSTimer scheduledTimerWithTimeInterval: 259200 target: self selector: #selector(showMsg:) userInfo: nil repeats: NO];
The only way I can think of doing this is every time the app is closed save a string representation of the last notification time in the keychain. The keychain is not cleared when the app is removed. Although this is technically a misuse of the keychain it would probably work and I doubt you would have any store submission problems.
Whenever the app is launched check if it is the first time it is launched since last installation (save this information in defaults). If it is the first time, check the keychain timestamp, compare against the current timestamp and go from there.
Say the user deletes the app and installs it the next day. Check keychain and you would see it was deleted 23 hours ago, then start your timer with 23 hours subtracted (so it will notify in 2 days 1 hour). Hope that all makes sense.
Otherwise if the app is generally connected to the internet you could use some sort of server.
No your app is sandboxed anything you do is gone when the app is deleted. You would need the help of some kind of web service to acheive your desired behavior
I don't believe so but I could be wrong (someone can be correct me). Even if it is possible though this sounds like bad way to do something like this.
How about using Local Push Notifications to achieve something like this? Seems ideal for the situation.
Relevant Appl docs for setting up scheduled notifications
You can also use iCloud's key-value data storage to store the initial install date. If you store the date both locally and sync it from iCloud, then it will be difficult for the user to avoid getting the update unless they stay off the Internet.
This, of course, is dependent on them being logged into iCloud on the device and requires iOS 5 or greater.
I am working around for a while with GameKit. Almost everything works fine. I have a major Problem with the session:peer:didChangeState: Method not beeing called after resuming.
In the Apple example GKRocket the session is destroyed if the app suspends(willTerminate) and setup when it comes back(willResume). For my app it would be nice to keep the session up.
In the Logs i can see, that session:peer:didChangeState: with state GKPeerStateUnavailable is called when the app suspends, but after resuming the call with GKPeerStateAvailable doesnt show up. The session is available. But even new clients cant find the device.
I use the SessionModes Server/Client.
Thanks in advance for your help!
I was playing with sessions some time ago, but have some suggestions...
-after resuming, what happens if you try to send packed from device which was sleeping to device which was awake? does it go through ?
-do you need GKPeerStateUnavailable / available ? From my experience all you need to use are applicationDidBecomeActive and applicationWillResignActive methods: when going to sleep you send GAME_PAUSED to other device, when awake - GAME_UNPAUSED. If user puts app to sleep and then closes it - well, bad luck, the other player will sit there forever (so you can give him an option to quit to main menu). This approach works with apple (in terms of approval) - tested on two apps.
Regards!