OK, this is pretty basic but I've read the documentation over and over and want to be sure I've got this right. In plain language, my watchkit app will be shut down by some user interaction exiting the app that's external to my code, right? I don't need to clear or reset the screen with any kind of close procedure that sets it up for another run? I don't need to build an "Exit" or "Close app" routine, right? It's confusing because the documentation implies the app will deactivate once it's no longer on screen (presumably by a user action like swiping to another app) and that this will call the didDeactivate function. But the documentation also claims:
In iOS Simulator, WatchKit calls the didDeactivate method for the current
interface controller when you lock the simulator by selecting Hardware > Lock.
When you subsequently unlock the simulator, WatchKit calls that interface
controller’s willActivate method again. You can use this capability to debug
your activation and deactivation code.
But the simulator doesn't appear to deallocate memory or reset variables or reset my app in any way. It remains persistent on screen in the state at the time of the lock, and it comes back in that state when I unlock. What worries me is that if I've got this wrong, I have an app built for one run. But I don't see routines for shutdown, screen clearance, or any of the elements you'd expect in a conventional shutdown routine.
I agree that the documentation can be confusing. The easiest way to think about it is that willActivate is called whenever your interface controller is displayed/activated. Likewise, didDeactivate is called whenever it is hidden/deactivated. So, if you're flipping through pages of controllers, each will receive a willActivate when it shows up and a didDeactivate when it disappears. Similarly, if a controller is deactivated because the app is no longer visible (e.g. it was suspended), didDeactivate will be called. If the user then raises their wrist to resume the app, willActivate is called, because the interface controller is being displayed.
There is no promise about whether your WatchKit app will be suspended or terminated (it's up to the OS), so you have to consider both possibilities. Based on experience, I know that dropping your arm will call didDeactivate before suspending your app. If you then raise your wrist, the app will resume and call willActivate. In my testing, the app was simply suspended (not terminated) in this situation.
You're correct that there is no built-in method that is called when the app is terminated. However, iOS 8.2 added four notifications that can be used to monitor the app/extension's state:
NSExtensionHostDidBecomeActiveNotification
NSExtensionHostDidEnterBackgroundNotification
NSExtensionHostWillEnterForegroundNotification
NSExtensionHostWillResignActiveNotification
Related
Can anyone tell how the OS invoke the application in iOS.
User Taps an icon --> UIApplicationMain() function called --->Did finish launching called.
Is this the sequence? I tried to search but haven't got any clear explanation.
When your app is launched, it moves from the not running state to the active or background state, transitioning briefly through the inactive state. As part of the launch cycle, the system creates a process and main thread for your app and calls your app’s main function on that main thread. The default main function that comes with your Xcode project promptly hands control over to the UIKit framework, which does most of the work in initializing your app and preparing it to run.
Figure shows the sequence of events that occurs when an app is launched into the foreground, including the app delegate methods that are called.
For more Details look this: https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/StrategiesforHandlingAppStateTransitions/StrategiesforHandlingAppStateTransitions.html
I am in the middle of development of an iOS OpenGL based game. So far I was not very concerned with the app states change and life cycle - background, foreground, suspended, terminated etc. Now I wanted to add support to moving the app into a suspended mode (after pressing home) and then nicely recuperate it after restarting it.
My problem is that after pressing home button, the app always gets terminated (the application delegate always reaches -applicationWillTerminate:)
The documentation mentions that in order to prevent termination it is important to clear as much memory as possible, stop any timers etc. Doing this did not help to prevent termination, so I tried to experimentally copy the app delegate form an Xcode template app, with completely NO initialization of my app objects after launch/activation, no storyboard, nothing special in main.m.
While the template (I used an Xcode game template) is never terminated after pressing home, it ends at -applicationDidEnterBackground:, my app despite of the fact that is uses less memory and starts completely no tasks is always terminated.
What may be the reason. Included but inactive frameworks ? I have no clue.
I would like to perform a different action when my app moves to the background depending upon if its moving to that state because there is an incoming phone call, or if its moving to that state because the user has hit the home button.
In both cases the app delegate receives a willResignActive:, then a didEnterBackground: call. Therefore from the app delegate calls alone it would appear its not possible to determine the difference.
Is there some way?
UIApplicationDelegate Protocol has a variety of methods for Monitoring Application State Changes.
Unfortunately (for you), going into the background is going into the background, there is no differentiation as to why. Given Apple's app design of walling everything off (for security reasons) I don't see them providing you details about what's going on on the phone outside your application.
I would certainly question the need for different behavior in those two cases, but I don't know the details of your app.
I'm currently working on a change request for our iPad app that requires that I handle the resuming of the app in two different ways depending on whether the app returned from multitasking (the user was active in another app or on the homescreen and came back to the app) and standby (the iPad was switched to standby either through the standby button on top or by closing the Smart Cover)
In both cases the following methods are called in my AppDelegate:
applicationWillResignActive followed by applicationDidEnterBackground when I hit the homebutton to get tot he home screen or close the Smart Cover
applicationWillEnterForeground and applicationDidBecomeActive when I come back.
As the same methods are called I am a bit lost on how to detect where I come from on resume. All four methods have a single parameter passing in the UIApplication. I looked at its interface, but didn't find any useful clues.
Is there a way to differentiate between resuming from multitasking or standby?
There is no public api method to define why application did become active
I my testing, when I exit (by pressing the home button) my app, it still is "running" in the background, thanks to the multitasking feature. However, I would like it to quit when the home button is pressed. Is this only happening to me?
Anyway, I have tracked it down to the applicationWillResignActive and the applicationDidBecomeActive methods in the app delegate. These get called for multitasking, but when I want to terminate, the app "resigns active." Any guidance on this issue is greatly appreciated!
Your application can opt out of multitasking (see the appropriate section in the iPhone Application Programming Guide) by adding the UIApplicationExitsOnSuspend key to your Info.plist and setting its value to YES.
In practice, Apple strongly recommends you not do this unless you have a very good reason for this behavior.
I think it's more efficient to suspend an app, when pressing the "Home" button. There's overhead in constantly launching and terminating apps. It's worse for the iOS operating system, and it's worse for user experience - because they need to wait for the app to launch again. Not sure what benefits you gain from terminating an app. If it's for simulation testing, my advice is to avoid that functionality, because your testing environment should be as realistic as possible. If your purpose is to clear cache or to make updates - that can all be done programmatically from subroutines.
Exiting subroutines
applicationWillResignActive
applicationDidEnterBackground
applicationWillTerminate
Entering subroutines
applicationDidBecomeActive
applicationWillEnterForeground
applicatonDidFinishLaunching
If you still insist on terminating an app when the user presses the "Home" button, despite the costs mentioned above - then set the UIApplicationExitsOnSuspend to true in your Info.plist as suggested by Brad Larson.
I wouldn't recommend trying to control the user's HOME button... deciding for them "exit" or "suspend".
I WOULD like to have HOME do an instant EXIT in the iPhone simulator... but haven't found any way to do that.