Please any one can tell me what is the exit point of application?
I have developed an app, in this app I have passes an array in all views(used in whole application), an its running perfectly.
But I want to release this array when app exits.
Thanks.
In iOS with multitasking, you don't have a clear exit point. You application can be killed at any time without notice if it is in the background. So if you have settings to save, you need to do so in the app delegate methods applicationWillTerminate: (iOS without multitasking) and applicationDidEnterBackground: (iOS with multitasking). It's also a good idea to save on applicationDidResignActive:. See the UIApplicationDelegate reference.
Note that all of these events also post NSNotifications to which you can subscribe to in any class you like. See the notifications section in the UIApplication reference.
As for releasing your array: you should release all your data in your classes' dealloc methods (yes, same applies for the app delegate).
- (void)applicationWillTerminate:(UIApplication *)application {
/*
Called when the application is about to terminate.
See also applicationDidEnterBackground:.
*/
}
this in your app delegate class.
The dealloc in your App delegate should do it. Just add
- (void)dealloc
{
[yourArray release];
}
in your app delegate....
The array will be automatically released when the app exits, as the system reclaims all the app's memory. You don't need to worry about it.
Related
Flurry docs recommend placing the startSession call in applicationDidFinishLaunching:.
Two problems with this...
- (void)applicationDidFinishLaunching:(UIApplication *)application
{
[FlurryAnalytics startSession:#"AWESOMEAPIKEY"];
// ...
}
1) Isn't application:didFinishLaunchingWithOptions: the new approved launch point?
2) This is only called once on launch, but don't we want session info every time a user opens or switches back to the app? Or does Flurry handle all that on their own by listening to some event or NSNotification?
Wouldn't a better place to put the startSession call be in applicationDidBecomeActive: or applicationWillEnterForeground:, like so?
- (void)applicationDidEnterBackground:(UIApplication *)application
{
// ... Flurry AppCircle setup
[FlurryAnalytics startSession:#"AWESOMEAPIKEY"];
// ... your setup
}
for your case 1)
correct place to put [FlurryAnalytics startSession:#"SOMESESSIONKEY"]; is
application:didFinishLaunchingWithOptions:
you can place it there without worries. I have done this by myself and the app is working awesome at appstore and providing the stats perfectly.
for case 2), your secession will be automatically resumed when app returns to foreground so you dont have to do any special handling here.
I was real curious about this too. I looked at my inherited code for my app and didn't see any flurry activity in didbecomeactive, foreground, etc. I only saw the startsession in didfinishlaunchingwithoptions. I saw the below on the flurry site re: startsession, but i still don't get how it works, just behind the scenes stuff the flurry library does? #samfisher, can you elaborate?
"This method serves as the entry point to Flurry Analytics collection. It must be called in the scope of applicationDidFinishLaunching. The session will continue for the period the app is in the foreground until your app is backgrounded for the time specified in setSessionContinueSeconds:. If the app is resumed in that period the session will continue, otherwise a new session will begin."
FlurryApi.h shows the default as 10 for setSessionContinueSeconds so I guess Flurry handles it, I'm just looking for more confirmation.
http://support.flurry.com/sdkdocs/iOS/interface_flurry_analytics.html#a78b0b92085b38875d51f1ca0d699849a
Whether plist that I created, and made changes while app running, will be saved even after killing the app? Or for saving data this way, I have to use CoreData, sqlite3 and stuff like that? Regards.
To save the plist when the app goes to the background, you have to add the code to save the plist in - (void)applicationWillResignActive:(UIApplication *)application method in app delegate.
After your app has been killed you cannot do anything. That's like After my death, I want to build a house which you obviously can't do.
Quoting myself from an earlier question:
If have important things to save, you need to do so in the app delegate methods applicationWillTerminate: (iOS without multitasking) and applicationDidEnterBackground: (iOS with multitasking). It's also a good idea to save on applicationDidResignActive:. See the UIApplicationDelegate reference.
Note that all of these events also post NSNotifications to which you can subscribe to in any class you like. See the notifications section in the UIApplication reference.
How can I retain the state of an iPhone after it has exited. What is the easy way to do it?
The first question is when do you save? The answer is in two places (assuming you want to support 3.x and 4.x devices).
First, for OS 3.x devices (and OS 4 devices that don't multi-task):
- (void)applicationWillTerminate:(UIApplication *)application
And second, for OS 4.x devices:
- (void)applicationDidEnterBackground:(UIApplication *)application
You need to do this on iOS4 devices because if the app is shutdown while it's in the background it is just killed; you never see the applicationWillTerminate message.
As for the how, well it depends on how complex your app is. I created a simple protocol that I implement for each view controller that might want to save its state:
#protocol SaveState
- (NSData*) saveState;
- (id) initWithSaveState:(NSData*)data;
#end
It saves the state by looping through view controllers in the main navigation controller and calling the save state method. It then does the reverse in the applicationDidFinishLaunching: method. More information on my blog.
In your application delegate, you can define the -applicationWillTerminate: method to include code to save application state data.
- (void) applicationWillTerminate:(UIApplication *)application {
// save state to data model here...
}
Your data model is up to you. For example, this could be a set of user defaults or a Core Data store.
The next time the app is started, you could check for saved state data in -applicationDidFinishLaunching: and initialize the app appropriately.
If you are using iOS 4 and your application supports multitasking features, you will get some of the state saving functionality "for free" because the app resigns focus, instead of terminating.
The applicationWillTerminate delegate method is not getting called in iOS 4.0
When I hit the Home button I am seeing the applicationWillResignActive and applicationDidEnterBackground delegate methods getting called.
- (void)applicationWillResignActive:(UIApplication *)application
{
NSLog(#"Application Did Resign Active");
}
- (void)applicationDidEnterBackground:(UIApplication *)application
{
NSLog(#"Application Did Enter Background");
}
And when I double Tap the Home button and again launch the Application the i find the applicationWillEnterForeground and applicationDidBecomeActive delegate methods are getting called.
- (void)applicationWillEnterForeground:(UIApplication *)application
{
NSLog(#"Application Will Enter Foreground");
}
- (void)applicationDidBecomeActive:(UIApplication *)application
{
NSLog(#"Application Did Become Active");
}
But I want to know when the applicationWillTerminate delegate method will be called , where I do some DB/file backup routines.
- (void)applicationWillTerminate:(UIApplication *)application{
}
I even tried to hit the minus sign and deleted the App running in the Background , but still it did not call any delegate method.
Any Ideas ???
From the iPhone Application Programming Guide:
Even if you develop your application using iPhone SDK 4 and later, you must still be prepared for your application to be terminated. If memory becomes constrained, the system might remove applications from memory in order to make more room. If your application is currently suspended, the system removes your application from memory without any notice. However, if your application is currently running in the background, the system does call the applicationWillTerminate: method of the application delegate. Your application cannot request additional background execution time from this method.
So yes, applicationWillTerminate: will generally not be called very often in iOS 4. If you have to save data, you should do so in both applicationWillTerminate: and applicationDidEnterBackground:.
The WWDC 2010 Session Adopting Multitasking on iPhone OS (Part 2) explains the application state transitions extremely well.
I got one solution for terminating apps when user hits the Home button in iOS4.
This will call the applicationWillTerminate delegate method instead of entering into background process.
Open your info.plist file
Add The Key UIApplicationExitsOnSuspend
Set the new key to YES
Actually you can also use this step to do so.
Open your info.plist file
Add The Key -> Application does not run in background
Set this key value to YES
I have put NSLogs in all my classes including my UIApplicationDelegate subclass. I am curious - and a bit nervous - about why I am not seeing them echo anything when I press the home button. I am running in the XCode simulator.
Since iPhone/iPad runs a single app at a time, doesn't hitting the home button discard all traces of the running app?
Thanks,
Doug
Chuck is correct, the dealloc's don't matter at that point. If you want to do something as your app is expiring, implement this in your app delegate class:
- (void)applicationWillTerminate:(UIApplication *)application {
// goodbye...
}
When an app is terminated, its memory is simply freed. Dealloc is not called, it does not pass go or collect $200. This is normal and intended.
You should implement -(void)applicationWillTerminate:(UIApplication*)application{
}
this method will get called when user hit home button.
You might also want to think about the additional multitasking support that has been announced. Obviously the details are still under NDA, but pushing Home does not necessarily stop your app.
And think about the various circumstances where your app may already be terminated quickly (e.g. if a call comes in and the system runs out of RAM). Do your cleanup with the application lifecycle messages.