0

is their any better way to quit the application programmatically?

recently i made a radio application that have a user setup to set a time using NSTimer for quit the app process ( i mean sleep time). when the time reaches the app should be stop its process and quit.

i used these statements to quit the app when time reaches,

  [[UIApplication sharedApplication] suspend];
  [[UIApplication sharedApplication] terminateWithSuccess];

theTimer=[NSTimer scheduledTimerWithTimeInterval:(1.0/1.0) target:self selector:@selector(countTime) userInfo:nil repeats:YES];

counter-=1;
timeLeft.text=[NSString stringWithFormat:@" %d",counter];
if (counter==0.0) {

    [theTimer invalidate];
  [[UIApplication sharedApplication] suspend];
  [[UIApplication sharedApplication] terminateWithSuccess];

is their any problem by using [[UIApplication sharedApplication] suspend]; [[UIApplication sharedApplication] terminateWithSuccess]; methods

any other better way to quit the app, or at least freeze the app process.. i need help?

Neeraj Neeru
  • 570
  • 8
  • 28

3 Answers3

2

Apple will not approve any application that deliberately suspends or terminates itself. You may use only those methods listed in the official documentation, which does not include suspend or terminateWithSuccess.

Tommy
  • 99,986
  • 12
  • 185
  • 204
  • tanq for your replay, any other way to freeze the application process, can you please tell me any solution..my client have these requirements.. – Neeraj Neeru Mar 16 '12 at 08:14
  • The iPhone metaphor is that all these apps exist and you hop in and out of them at will. The user isn't meant to think about whether specific individual apps are running, and returning to the home screen is always meant to be at their command. So per Apple's guidelines, I guess you'd just have to stop the audio and throw up a screen explaining that the radio has gone to sleep with a button or something to go back to listening to the radio (or, ideally, go back to an earlier screen before the audio started). It may feel silly, but that's Apple's attitude to interface guidelines for you. – Tommy Mar 16 '12 at 18:42
  • We were terminating our app after updating content, as a workaround to get a UIWebView to re-read the files (which we could not get it to do any other way). After accepting the app for more than a year with this approach, Apple has just started rejecting it. We OEM our app to another company, and Apple rejected it for them, too, so I know this isn't just a random rejection. It appears that they are now rejecting any app that exits. (The rejection forced us to spend a few more day looking for a workaround to the UIWebView problem, which we eventually found.) – Joshua Smith Jun 27 '12 at 14:11
0

I've always used exit(0). I suppose that if you have to run code before the app quitting you should call it before exit(0).

Apple discourages the use of exit() because from the user point of view it looks like a crash. But they also say there is no API call to gracefully terminate your app.

If you're looking for a way to terminate your app without the user pressing home, during sleep time, I assume he won't confuse it with a crash, since he won't be paying attention to your app and exit() leaves no crash log.

So, your options are:

  • Forget this and just beep after some time to remind him to close the app. (terrible!)
  • Close the app using your private calls and risk Apple's rejection.
  • Close the app using exit() and stick with POSIX (accepted) calls.
fbernardo
  • 10,016
  • 3
  • 33
  • 46
  • so you are telling that using exit(0); is not a problem, but someone said that using exit(0) is not approved by apple! – Neeraj Neeru Mar 16 '12 at 08:17
  • I never had any problem with it, and it's a documented and used by Apple API call. – fbernardo Mar 16 '12 at 08:33
  • so can i call like if (counter==0.0) { exit(0); – Neeraj Neeru Mar 16 '12 at 09:25
  • If this is the right answer please mark it and close the question, if not, what is the problem? – fbernardo Mar 16 '12 at 10:25
  • 1
    In Tech Q&A QA1561, Apple strongly discourages use of exit as it makes the app appear to have crashed. developer.apple.com/iphone/library/qa/qa2008/qa1561.html – Neeraj Neeru Mar 16 '12 at 10:47
  • You're taking it out of context, Apple says that the back to Springboard animation won't happen, but you said you want to exit the app during the user sleep time, and if you use exit(0) it won't produce a crash log, so, can you please explain, under this situation, how would it appear to have crashed? – fbernardo Mar 16 '12 at 10:51
  • 1
    And btw, your alternative is explained by Apple on that Q&A, "There is no API provided for gracefully terminating an iPhone application" or exit(), which is discouraged. Private API's will possibly get your app rejected. – fbernardo Mar 16 '12 at 10:52
0

tanq for your replays, so i just forget about quitting my application programatically. next way is to stop playing my MPMoviePlayerController object. got the next level problem

my settings page for sleepTime and music playing pages, both are different viewControllers so i can't access MPMoviePlayerController object directly in time settings page, so i created a method on music playing page

MPMoviePlayerController *player=[[MPMoviePlayerController alloc]initWithContentURL:[NSURL URLWithString:@"http://www.radioparadise.com/musiclinks/rp_64aac.m3u"]];
[player prepareToPlay];
[player play];

- (IBAction)StopPlay:(id)sender 
{   
 [player stop];
}

so i created an object for music playing page and i called this method from settings page., this is my code in settingsPage

@class MusicPlayingPage;
 @interface secondView : UIViewController
{
MusicPlayingPage *audio; 
}

and called the method in settingsPage

[audio stopPlay];

control reaches correctly to streamingPage, but it seems like player is not stoping play, i can't access any of these player options [player stop]; , [player pause];

any problem for this method in musicPlayingPage 

- (IBAction)StopPlay:(id)sender 
{   
 [player stop];
}

sorry if my question is not understandable.

Neeraj Neeru
  • 570
  • 8
  • 28