PDA

View Full Version : Can I disable the rapid-application-switching feature for OS4?




adrian.oconnor
Jul 8, 2010, 04:33 AM
Hi all,

I've written a little iPhone app that needs to constantly poll a web service on a timer. Occassionally, something gets in a bit of a pickle and the timer seems to die. I want it so that if the user clicks the home button and re-opens the app it will do a force-quit and everything will get loaded from scratch. Unfortunately, since OS4, that doesn't happen -- it just reloads in the same stuck state! Does anybody know of a delegate method I can use to tell the app to quit instead of sleep?

I admit I haven't checked the SDK docs yet. I'll do that now and post back if I find anything. Google didn't help because of all the news and blog articles from the past month about iOS4 and multitasking...



adrian.oconnor
Jul 8, 2010, 04:42 AM
OK, I guess I've neglected to stop my timers etc in applicationWillResignActive, which is why things are getting a bit out of sync when it wakes up. I'd still rather just quit the app, so I've now got this:

- (void)applicationWillResignActive:(UIApplication *)application {

exit(0);

}

That seems to work, but I'm not sure if this goes against all good practice. Any thoughts?

robbieduncan
Jul 8, 2010, 04:51 AM
I admit I haven't checked the SDK docs yet.

Then go and do so. There is a well documented key you can put in your Info.plist to opt your application out of fast task switching. I've posted a link to it on these forums once in the last week or so if you can't find it in the documents yourself.

PhoneyDeveloper
Jul 8, 2010, 07:57 AM
exit is considered a private API and isn't allowed (AFAIK).

But this does illistrate a problem with the fast app switching. I don't think there is a way for a user to kill an app directly. If an app has a bug that requires restarting it to avoid the bug I don't think there's a way to do that.

dejo
Jul 8, 2010, 09:16 AM
But this does illistrate a problem with the fast app switching. I don't think there is a way for a user to kill an app directly.
Oh, but there is. Tap and hold the app in the fast-switch bar and then click the minus (-) button that appears.

PhoneyDeveloper
Jul 8, 2010, 10:34 AM
I read that tapping the minus button only removed the app from the recent apps list. I don't really know. I don't have a device that supports fast app switching yet.

Trying this in the 4.0 Sim suggests that you're right, but it's a little bit muddled. An app appears in the recent apps list if it has been run. It might be backgrounded or it might not be. Tapping the red minus button both removes it from the list and kills it if it is backgrounded. That's better than I had thought.

bredell
Jul 8, 2010, 01:42 PM
exit is considered a private API and isn't allowed (AFAIK).

Actually, the exit() call is documented and specified as available for iPhone, so it shouldn't be a private API. Apple might still not want you to use it for other reasons, I guess.

adrian.oconnor
Jul 12, 2010, 04:00 AM
Then go and do so. There is a well documented key you can put in your Info.plist to opt your application out of fast task switching. I've posted a link to it on these forums once in the last week or so if you can't find it in the documents yourself.

Awesome, that's what I needed. Thanks for the pointer.

admanimal
Jul 12, 2010, 09:55 AM
Actually, the exit() call is documented and specified as available for iPhone, so it shouldn't be a private API. Apple might still not want you to use it for other reasons, I guess.

Using exit is bad form because it will make the user think that the app has crashed. The only way a user should be able to exit the app is via the Home button (or task switcher).

tdog09
Jul 12, 2010, 10:00 AM
Using exit is bad form because it will make the user think that the app has crashed. The only way a user should be able to exit the app is via the Home button (or task switcher).

Using the exit() function is not bad form when used appropriately (like anything). As long as you alert the user that the application is closing and not crashing, then it's perfectly fine. How many comp apps tell you it's going to close, and then closes. Just make sure you alert the user before doing so, and all should be well. I do so in my app and it was approved just fine.

I should also point out that I use when the exit function when a certain resource doesn't exist, as it's needed for the app to continue.

PhoneyDeveloper
Jul 12, 2010, 10:28 AM
What apple recommends in the case that an app can't continue is to show an alert with no buttons on it. The user can then only hit the home button, which is how they normally quit all apps.

It is possible that with fast app switching this should be revised but I'm not sure how.

bredell
Jul 12, 2010, 12:37 PM
Using exit is bad form because it will make the user think that the app has crashed. The only way a user should be able to exit the app is via the Home button (or task switcher).

Yes, but in this case the original poster wanted to call exit() after the user had pressed the home button.

admanimal
Jul 12, 2010, 08:45 PM
Yes, but in this case the original poster wanted to call exit() after the user had pressed the home button.

Well in that case he is better off just disabling multitasking for his app via the Info.plist.

Luke Redpath
Jul 13, 2010, 10:37 AM
Using the exit() function is not bad form when used appropriately (like anything). As long as you alert the user that the application is closing and not crashing, then it's perfectly fine. How many comp apps tell you it's going to close, and then closes. Just make sure you alert the user before doing so, and all should be well. I do so in my app and it was approved just fine.

I should also point out that I use when the exit function when a certain resource doesn't exist, as it's needed for the app to continue.

FWIW I have had an app rejected for using exit() so I would not recommend using it at all. It wasn't picked up by the reviewer until my third release so just because you have had an app that uses it approved doesn't mean it will in the future.