I've found that my application stops its timer when the device goes to the lock screen on actual device, but it works perfectly on the simulator.
Is that because I haven't released the app, so an actual device won't let me keep working on the lock screen? Or is it a bug in my code?
I've written an NSLog() statement to monitor my application's timer action, it keeps working when the simulator goes to the lock screen,
but on an actual device it stops.
I'm so frustrated because I don't know why there are these differences between the device and the simulator, and I don't know how to solve it.
What you need to do is implement applicationWillEnterForeground and applicationDidEnterBackground to persist the state of your timer, and resume it whenever the app opens again.
You may also want to use UILocalNotification to schedule a notification when your timer finishes.
Here is another post about using UILocalNotification with timers that you may find useful.
Related
I have a Swift iOS app consisting of 3 view controllers – the initial one with a tableview, the second one with the chosen element and ability to create a new time session and the third one with the actual timer for the session (let’s call it the timer vc).
In this case, the focus is the timer view controller. However, the question is not about the timer itself. It works both in foreground and background mode. The problem is this:
The app goes background. Then over a certain fixed period of time, it receives a local notification – a reminder to go back to the timer vc and save the results. Most of the time, it works fine but sometimes when you go back to the app (through notification), it opens the initial vc with the tableview instead of the timer vc, which seems like the system terminates the background app after a while and then reopens it when you go back through the notification. In this case, all the data from the timer vc are obviously lost since the app logic requires that the user save the data after the session is finished.
What I think, the essence of the problem may have to do with how long the app can stay in the background without being terminated or suspended (If I’m not mistaken, in this state, all the current data associated with the app are removed from the memory). I mean, when you set the notifications to be triggered like every 1, 5 or 10 minutes, everything seems to be fine. However, when the notification is set for 30 minutes or more, the mentioned bug seems to appear from time to time (especially when testing on an actual device instead of a simulator). For the most part, it appears if the device storage is almost full - under 1Gb of free space). Which leads me to believe that this may also be a memory management issue.
How to make this timer vc run in the background as much time as needed? Also, does anybody know how much time an iOS app is guaranteed to stay in the background without being removed from the memory? Thanks a lot.
There is no guarantee of your's app execution time when it is in background mode. The operating system can suspend it anytime, Operating system has the responsibility only to notify your app which you will receive in the app delegate.
For setting up the local notification, you need to get the help from OS only. You can't rely on your app's execution in the background thread. For scheduling and handling of local notifications, you can go through the following documentation.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/SchedulingandHandlingLocalNotifications.html#//apple_ref/doc/uid/TP40008194-CH5-SW1
I started a timer when app goes into background when selector method called app got crashed in background. I am not sure does code works in defined conditions.
In background mode, when your app is not running, timers will just not fire. A timer will fire at the earliest time it can (for example just after your app is activated again). If a repeating timer should have fired more than once, only the last "fire" will happen.
This shouldn't make your app crash; whatever goes wrong is something else.
Timers only run in the background if you app supports running in the background, like when tracking location, playing music, etc.
We've been using the AIR sound API, building for iOS, with no problems till now, the problem is that the sound works until iPad goes to sleep and there's no sound from our app when iPad is woken back up.
Note: we have the app set to exit on suspend, and we don't have this problem when user suspends -- i.e, hits the button and goes back to desktop.
We only have it when iPad goes to sleep (screen goes dark but app is still running). As far as I can tell our app is not receiving any events from iOS when the iPad goes to sleep or wakes back up. Once this has all happened and the game has no sound, but exiting and restarting makes it work again.
We are getting an activate event from the native application object when iPad is woken up, I'm also checking (just because it sounds useful) the value of SoundMixer.areSoundsInaccessible, but that's way off base. I do get a soundchannel object back when I play a sound while the problem is in effect, I just can't hear it.
We were having a similar problem with audio not playing (roughly half the time the device had been asleep), and fixed it with this:
// AudioPlaybackMode.MEDIA is the default value
SoundMixer.audioPlaybackMode = AudioPlaybackMode.AMBIENT;
Once that was done, audio came back immediately after the app woke up.
Note that AMBIENT's behaviour depends on whether the microphone is being used.
I have a timer in my app, and I want it to appear to be running while my app is on the background. I'd like that if the user presses the home button when the timer shows, for instant "01:11:11" and then goes back to the app and it becomes visible to him 10 minutes later, to see the timer as "01:01:11", however I get a split second where it shows the last state when the app went to the background ("01:11:11") before it starts updating from the correct time.
I assumed that I could correct this by updating the state of my timer in "applicationDidBecomeActive" and it did work on my simulator in Xcode but not on my Ipad.
I'm using cocos2d for my drawing and this is what I'm doing in my applicationDidBecomeActive:
CCScene *s=[director_ runningScene];
GameLayer *l=[(GameLayer*)[s getChildByTag:GAME_LAYER_TAG];
if (l!=nil) [l myUpdate];
I don't think it's relevant to the problem though because myUpdate does get called but I still have that split second glitch on my Ipad, as if it starts back from its last state no matter what.
In apples clock app, in applicationDidEnterBackground it hides the timer text, so that when the app comes into the foreground you see a blank UI for the split second where your app is loading the new timer data in the UI. Also, you may want to call some of your applicationDidBecomeActive code in applicationWillEnterForeground, which is called first. But keep in mind, applicationWillEnterForeground is not called when the app first launches.
There will always be a delay between when your app comes into the foreground, and when the UI updates. Theres no way to fix that, so you might as well use what apple uses to get around the issue.
Well I tried to hide my UI in both applicationWillResignActive and applicationDidEnterBackground. Since applicationWillResignActive is called first and before going into preview (double click on HOME) it causes a "not so pretty" preview but I thought at least it would solve my original problem. It didn't (not, on my IPad). It looks like the system takes the screen shot even before applicationWillResignActive.
I checked the timer in the official clock app and I see the clock is updating even when the app is in the background (in preview), so they "cheat" anyway...
What delegate is called in this situation if I have an app running.
Over time, if iPad is set to lock after 2 mins, what is its state? Does the app still run? or does it suspend?
I'd like to know thanks
If the iOS device automatically locks after a period of inactivity, the same thing happens as when it's locked by pressing the lock button: the app briefly goes into the background before being suspended. (Unless of course it is an audio-playing app or other app that requests extra execution time, in which case it may stay in the background longer, or indefinitely, without being suspended).
In terms of UIApplicationDelegate methods, applicationWillResignActive: will be called first, followed by applicationDidEnterBackground:.