Une bonne façon de quitter l'application iPhone?


277

Je programme une application iPhone et je dois la forcer à quitter en raison de certaines actions de l'utilisateur. Après avoir nettoyé la mémoire allouée à l'application, quelle est la méthode appropriée pour appeler pour terminer l'application?


34
Il n'y a qu'une seule façon appropriée - bouton Accueil ..
béryllium

5
La seule situation que j'imagine que quiconque envisage de quitter par programme est le scénario suivant: l'application démarre, affiche les conditions d'utilisation, refuse d'accepter puis quitte l'application. C'est quelque chose que les marques font parfois pression sur le développeur. Mais c'est faux.
Daniel

6
@Daniel Normalement, vous mettez votre avis de non-responsabilité / conditions d'utilisation (CLUF) sur itunes connect lorsque vous téléchargez l'application. Si l'utilisateur télécharge votre application, cela signifie qu'il a accepté votre CLUF
Paul de Lange

8
Il y a des raisons tout à fait valables de devoir forcer la fermeture d'une application iOS. Mon cas est que je distribue des versions bêta de pré-lancement de mon application. Les versions bêta ouvrent tous les IAP gratuitement. Celles-ci ont un délai et doivent expirer après quelques semaines. J'utilise donc la réponse ci-dessous pour tuer l'application une fois la période bêta terminée. Je vais supprimer cela dans la version LIVE. Mais la réponse m'a quand même aidé et est correcte!
badweasel

5
Une raison valable pour quitter une application est qu'il s'agit d'une application d'exécution en arrière-plan de longue durée et que l'application entre dans un état où elle n'a plus besoin de s'exécuter en arrière-plan. Par exemple, l'utilisateur se déconnecte. Dans ce cas, il serait judicieux de quitter afin que lorsque l'application démarre ensuite, elle démarre proprement. Cela servirait de filet de sécurité contre les fuites de mémoire, entre autres raisons. Notez que dans ce cas, l'application quitterait l'arrière-plan , de sorte que l'utilisateur ne remarquerait rien de mal.
frankodwyer

Réponses:


217

As-tu essayé exit(0)?

Alternativement, [[NSThread mainThread] exit]même si je n'ai pas essayé, cela semble être la solution la plus appropriée.


85
Étant donné que cela est un non-non d'Apple (peut entraîner le refus de votre application dans l'App Store pour une interface non standard), considérez la réponse d'Août comme "la bonne". Pour info, cette réponse (Brett's) est correcte pour TOUS les programmes C, et NSThread pour tous les programmes Cocoa.
Olie

21
Dans Tech Q&A QA1561, Apple décourage fortement l'utilisation de exit car cela donne l'impression que l'application s'est bloquée. developer.apple.com/iphone/library/qa/qa2008/qa1561.html
progrmr

8
[[NSThread mainThread] exit] provoque le blocage de votre application, car exit n'est pas une méthode d'instance. exit (0) enverra l'application en arrière-plan dans iOS 4. L'appel à nouveau à exit (0) le fera planter. Au moins dans le simulateur.
user123444555621

10
Je comprends pourquoi tant de gens déconseillent cela, mais que diriez-vous de donner aux développeurs un certain crédit? Nous sommes tous des adultes ici et nous voulons en savoir plus sur cette fonctionnalité. Je le trouve très utile pour les builds internes de QA et, lorsque je l'ai recherché pour la première fois, j'étais heureux de voir cette réponse "incorrecte".
evanflash

7
@Kevin "Ne fais pas ça" n'est jamais la bonne réponse. Donnez des avertissements et des clauses de non-responsabilité si vous le souhaitez, mais la seule bonne réponse à «comment faire cela» est «voici comment procéder». Si je cherche comment faire quelque chose (peut-être que je veux le forcer à quitter pendant le débogage), les gens déclarent avec droit "vous ne le faites pas!" et essayer d'enterrer la réponse dont j'ai besoin est une perte de temps. Cependant, de nombreuses personnes peuvent avoir de mauvaises raisons de faire quelque chose, la bonne réponse StackOverflow est celle qui répond à la question, car les personnes ayant de bonnes raisons chercheront également leur chemin.
Glenn Maynard

274

Sur l'iPhone, il n'est pas question de quitter une application. La seule action qui devrait provoquer la fermeture d'une application est de toucher le bouton Accueil du téléphone, et ce n'est pas quelque chose auquel les développeurs ont accès.

Selon Apple, votre application ne devrait pas s'arrêter d'elle-même. Étant donné que l'utilisateur n'a pas appuyé sur le bouton Accueil, tout retour à l'écran d'accueil donne à l'utilisateur l'impression que votre application s'est bloquée. Ceci est un comportement déroutant et non standard et doit être évité.


13
Comme je l'ai dit, c'est un comportement non standard et doit être évité. Les applications iPhone ne sont pas des applications de bureau. Ne les traitez pas comme tels.
août

8
Je peux comprendre l'opinion d'Apples mais j'ai une situation similaire, mon application nécessite un accès Internet, si elle n'est pas disponible, ils devraient pouvoir quitter l'application au lieu de simplement avoir un message d'erreur
Anthony Main

22
Nous avons des applications qui aident les gens à dormir. Ils veulent que l'application se termine après une période définie pour réduire la décharge de la batterie. Je pense que ce cas est acceptable - car l'utilisateur est, espérons-le, endormi et ne peut pas quitter l'application manuellement.
JamesSugrue

36
Je ne suis toujours pas d'accord. Lorsqu'ils se réveillent, l'application est «partie», laissant l'utilisateur se demander ce qui s'est passé. Au lieu de cela, définissez une minuterie dans votre application, puis lorsque le temps est écoulé, mettez l'application en veille - aucune activité. Une application qui ne fait absolument rien ne videra pas la batterie.Le Springboard est également une application - elle ne s'arrête pas juste pour économiser de l'énergie. Au lieu de cela, il attend simplement l'entrée de l'utilisateur.
Août

8
Cela ne répond pas vraiment à la question. Il est exact à 100%, mais je pense que l'idéal aurait été un commentaire soit sur la question du PO, soit sur la réponse acceptée.
Ben Zotto

49

exit (0) apparaît à un utilisateur comme un plantage, affichez donc un message de confirmation à l'utilisateur. Après confirmation, suspendez (appuyez sur le bouton d'accueil par programme) et attendez 2 secondes pendant que l'application passe en arrière-plan avec l'animation, puis quittez la vue de l'utilisateur

-(IBAction)doExit
{
    //show confirmation message to user
    UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Confirmation"
                                                 message:@"Do you want to exit?"
                                                delegate:self
                                       cancelButtonTitle:@"Cancel"
                                       otherButtonTitles:@"OK", nil];
    [alert show];
}

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
    if (buttonIndex != 0)  // 0 == the cancel button
    {
        //home button press programmatically
        UIApplication *app = [UIApplication sharedApplication];
        [app performSelector:@selector(suspend)];

        //wait 2 seconds while app is going background
        [NSThread sleepForTimeInterval:2.0];

        //exit app when app is in background
        exit(0);
    }
}

1
Apple approuvera-t-il cette "sortie (0)"? Parce que certaines personnes disent qu'Apple rejettera votre application lorsque vous utiliserez la sortie 0.
Gajendra K Chauhan

2
@GajendraKChauhan exit(0)n'a pas d'importance. Le point est que votre application a un "comportement de fermeture". Quitter le comportement lui-même est interdit dans l'AppStore, à l'exception de quelques applications créées par des tiers très importants. De même, l'imitation du comportement du bouton d'accueil peut également être rejetée.
Eonil

41

Consultez les questions et réponses ici: https://developer.apple.com/library/content/qa/qa1561/_index.html

Q: Comment quitter par programme mon application iOS?

Il n'y a pas d'API fournie pour terminer gracieusement une application iOS.

Sous iOS, l'utilisateur appuie sur le bouton Accueil pour fermer les applications. Si votre application présente des conditions dans lesquelles elle ne peut pas fournir la fonction prévue, l'approche recommandée consiste à afficher une alerte pour l'utilisateur qui indique la nature du problème et les actions possibles que l'utilisateur pourrait entreprendre - activer le WiFi, activer les services de localisation, etc. Autorisez l'utilisateur à résilier l'application à sa seule discrétion.

AVERTISSEMENT: n'appelez pas la exitfonction. Les applications appelantes exitapparaîtront à l'utilisateur comme ayant planté, plutôt que d'effectuer une terminaison gracieuse et de revenir à l'écran d'accueil.

En outre, les données peuvent ne pas être enregistrées, car -applicationWillTerminate:des UIApplicationDelegateméthodes similaires ne seront pas appelées si vous appelez exit.

Si, au cours du développement ou des tests, il est nécessaire de mettre fin à votre application, la abortfonction ou la assertmacro est recommandée


2
Vous venez d'ajouter un AlertView sans boutons pour vous y conformer. Facile.
Schultz9999

Excellente réponse, je viens de travailler avec la sortie (0) et je ne savais pas qu'elle appartenait à l'api privée
Alex Cio

39

Ce n'est pas vraiment un moyen de quitter le programme, mais un moyen de forcer les gens à arrêter.

UIAlertView *anAlert = [[UIAlertView alloc] initWithTitle:@"Hit Home Button to Exit" message:@"Tell em why they're quiting" delegate:self cancelButtonTitle:nil otherButtonTitles:nil];
[anAlert show];

2
Au moins sur le simulateur, si vous faites cela, l'alerte sera toujours là lorsque l'utilisateur rouvrira l'application. Ainsi, je suggère de leur donner au moins un bouton.
cheshirekow

Utilisez la réponse de Kalyan pour que l'application se ferme lorsque vous appuyez sur le bouton d'accueil.
Timur Kuchkarov

Le problème avec cela est qu'il ne quitte pas réellement l'application, donc tout ce que le développeur peut vouloir accomplir en quittant (jeter une interface utilisateur invalide / ancienne, effacer les constantes, etc.) ne sera pas exécuté à moins que l'utilisateur ne glisse l'application fermé.
Ben Leggiero

Cela ne tue pas l'application.
Dustin

38

Accédez à votre info.plist et vérifiez la clé "L'application ne s'exécute pas en arrière-plan". Cette fois, lorsque l'utilisateur clique sur le bouton d'accueil, l'application se ferme complètement.


1
Mais le processus d'arrière-plan est également rejeté.
Gajendra K Chauhan

17

Ajoutez une UIApplicationExitsOnSuspendpropriété application-info.plistà true.


Ce paramètre peut-il être modifié au moment de l'exécution? Je veux dire, je veux vivre en arrière-plan, sauf lorsque mon application CHOISIT de quitter lors de la prochaine suspension - auquel cas je veux introduire UIApplicationExitsOnSuspend. Est-ce possible?
Motti Shneor

13

Après quelques tests, je peux dire ce qui suit:

  • en utilisant l'interface privée: [UIApplication sharedApplication]l'application semblera plantée, MAIS elle appellera - (void)applicationWillTerminate:(UIApplication *)applicationavant de le faire;
  • l'utilisation exit(0);mettra également fin à l'application, mais elle semblera "normale" (les icônes du tremplin apparaissent comme prévu, avec l'effet de zoom arrière), MAIS elle n'appellera pas la - (void)applicationWillTerminate:(UIApplication *)applicationméthode déléguée.

Mon conseil:

  1. Appelez manuellement le - (void)applicationWillTerminate:(UIApplication *)applicationsur le délégué.
  2. Appelle exit(0);.

Apple dit de ne pas utiliser exit parce que "les applications appelant exit apparaîtront à l'utilisateur comme ayant planté, plutôt que d'effectuer une terminaison gracieuse et de revenir à l'écran d'accueil" developer.apple.com/library/ios/#qa/qa2008/ qa1561.html
MickyD

8

Votre ApplicationDelegate est informé de la fermeture intentionnelle de l'utilisateur:

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

Quand je reçois cette notification, j'appelle

        exit(0);

Qui fait tout le travail. Et la meilleure chose est, c'est l'intention de l'utilisateur de quitter, c'est pourquoi cela ne devrait pas être un problème pour l'appeler là-bas.

Sur mon application audio, il était nécessaire de quitter l'application après que les gens synchronisaient leur appareil pendant que la musique était en cours de lecture. Dès que la synchronisation est terminée, je reçois une notification. Mais quitter l'application juste après cela ressemblerait en fait à un crash.

Au lieu de cela, j'ai défini un indicateur pour vraiment quitter l'application lors de la prochaine action de mise en arrière-plan. Ce qui est correct pour actualiser l'application après une synchronisation.


1
Ce n'est pas une bonne solution car l'application démissionnera active pour d'autres raisons, comme un appel téléphonique entrant.
frankodwyer

La solution consiste à ajouter un chèque qui ne sort que s'il est utile de le faire. Par exemple, si l'utilisateur est sur l'écran de démarrage. Ensuite, c'est ok même si un appel téléphonique arrive. Apple n'a pas rejeté cela depuis iOS 2 dans mes applications. stackoverflow.com/a/43906936/712124
cat

6

Mon application a été rejetée récemment car j'ai utilisé une méthode non documentée. Au sens propre:

"Malheureusement, il ne peut pas être ajouté à l'App Store car il utilise une API privée. L'utilisation d'API non publiques, comme indiqué dans la section 3.3.1 du contrat de licence du programme pour les développeurs iPhone, est interdite:

"3.3.1 Les applications ne peuvent utiliser les API documentées que de la manière prescrite par Apple et ne doivent pas utiliser ou appeler des API privées."

L'API non publique incluse dans votre application est terminateWithSuccess "


6

Apple dit:

"Avertissement: N'appelez pas la fonction de sortie. Les applications appelant exit apparaîtront à l'utilisateur comme ayant planté, plutôt que d'effectuer une terminaison gracieuse et de revenir à l'écran d'accueil."

Je pense que c'est une mauvaise hypothèse. Si l'utilisateur appuie sur un bouton Quitter et qu'un message s'affiche disant quelque chose comme: "L'application va maintenant se fermer.", Il ne semble pas être bloqué. Apple devrait fournir un moyen valide de quitter une application (pas de quitter (0)).


3
Ils l'appellent le bouton Accueil, il peut être situé au bas de n'importe quel iDevice. Donc, à cause de cela, il n'est jamais nécessaire de créer votre propre bouton Quitter.
Popeye

4

Cela a obtenu une bonne réponse mais a décidé de développer un peu:

Vous ne pouvez pas faire accepter votre application sur l'AppStore sans avoir bien lu les directives relatives à l'interface humaine iOS d'Apple. (ils se réservent le droit de vous rejeter pour quoi que ce soit contre eux) La section "Ne pas quitter par programme" http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices. html est une indication exacte de la façon dont vous devez traiter dans ce cas.

Si vous avez un problème avec la plate-forme Apple, vous ne pouvez pas facilement trouver de solution, consultez HIG. Il est possible qu'Apple ne veuille tout simplement pas que vous le fassiez et ils le font généralement (je ne suis pas Apple donc je ne peux pas toujours garantir) dans leur documentation.


3

Hm, vous devrez peut-être quitter l'application si, par exemple, votre application nécessite une connexion Internet. Vous pouvez afficher une alerte puis faire quelque chose comme ceci:

if ([[UIApplication sharedApplication] respondsToSelector:@selector(terminate)]) {
    [[UIApplication sharedApplication] performSelector:@selector(terminate)];
} else {
    kill(getpid(), SIGINT); 
}

9
Non, vous n'avez pas à y mettre fin. L'application iTunes, par exemple, lorsqu'elle ne parvient pas à détecter une connexion appropriée, affiche simplement un écran indiquant qu'elle n'est pas connectée. Il ne se ferme pas, il informe simplement l'utilisateur de ce qui se passe. L'utilisateur quitte ensuite en appuyant sur le bouton d'accueil.
août

1
Cependant, l'application boussole se ferme si elle ne fonctionne pas.
Josh Lee

3

Nous ne pouvons pas quitter l' application à l' aide exit(0), les abort()fonctions, comme Apple a fortement l'utilisation découragea de ces fonctions. Bien que vous puissiez utiliser ces fonctions à des fins de développement ou de test.

Si pendant le développement ou les tests, il est nécessaire de mettre fin à votre application, la fonction d'abandon ou la macro d'assertion est recommandée

Veuillez trouver ce fil Apple Q&A pour obtenir plus d'informations.

Lorsque vous utilisez cette fonction, créez une impression comme si l'application se bloquait. J'ai donc reçu une suggestion comme si nous pouvions afficher une alerte avec un message de résiliation pour informer l'utilisateur de la fermeture de l'application, en raison de l'indisponibilité de certaines fonctionnalités.

Mais la directive d'interface humaine iOS pour démarrer et arrêter l'application , suggérant que n'utilisez jamais le bouton Quitter ou Fermer pour terminer l'application. Ils suggèrent plutôt d'afficher un message approprié pour expliquer la situation.

Une application iOS n'affiche jamais une option Fermer ou Quitter. Les gens cessent d'utiliser une application lorsqu'ils passent à une autre application, reviennent à l'écran d'accueil ou mettent leurs appareils en mode veille.

Ne quittez jamais une application iOS par programme. Les gens ont tendance à interpréter cela comme un crash. Si quelque chose empêche votre application de fonctionner comme prévu, vous devez informer les utilisateurs de la situation et expliquer ce qu'ils peuvent y faire.


2

En plus de ce qui précède, bonne réponse que je voulais juste ajouter, pensez à nettoyer votre mémoire.

Après la fermeture de votre application, l'iPhone OS nettoie automatiquement tout ce que votre application a laissé derrière, de sorte que libérer toute la mémoire manuellement peut simplement augmenter la durée de fermeture de votre application.


Veuillez modifier votre réponse dans le scénario actuel d'IOS4.0 et UP ..: P
rptwsthi

2
- (IBAction)logOutButton:(id)sender
{
   //show confirmation message to user
   CustomAlert* alert = [[CustomAlert alloc] initWithTitle:@"Confirmation" message:@"Do you want  to exit?" delegate:self cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];
   alert.style = AlertStyleWhite;
   [alert setFontName:@"Helvetica" fontColor:[UIColor blackColor] fontShadowColor:[UIColor clearColor]];
   [alert show];
}
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{

   if (buttonIndex != 0)  // 0 == the cancel button
   {
      //home button press programmatically
      UIApplication *app = [UIApplication sharedApplication];
      [app performSelector:@selector(suspend)];
      //wait 2 seconds while app is going background
      [NSThread sleepForTimeInterval:2.0];
      //exit app when app is in background
      NSLog(@"exit(0)");
      exit(0);
  }
}

1

J'ai utilisé l'approche [[NSMutableArray new] addObject: nil] mentionnée ci-dessus pour forcer la fermeture (crash) de l'application sans effectuer d'appel de fonction d'exit (0) révélateur.

Pourquoi? Parce que mon application utilise l'épinglage de certificat sur tous les appels d'API réseau pour empêcher les attaques de l'homme du milieu. Il s'agit notamment des appels d'initialisation que mon application financière effectue au démarrage.

Si l'authentification par certificat échoue, toute mon initialisation appelle l'erreur et laisse mon application dans un état indéterminé. Laisser l'utilisateur rentrer chez lui, puis revenir dans l'application n'aide pas, car à moins que l'application n'ait été purgée par le système d'exploitation, elle n'est toujours pas initialisée et n'est pas fiable.

Donc, dans ce cas, nous avons jugé préférable de déclencher une alerte informant l'utilisateur que l'application fonctionne dans un environnement non sécurisé, puis, lorsqu'il clique sur "Fermer", forcer la fermeture de l'application en utilisant la méthode susmentionnée.


Je ne vois pas ce qui vous empêche d'afficher une seule alerte banale en plein écran, disant à l'utilisateur que l'application n'est pas utilisable pour ces raisons "d'épinglage de certificat", et c'est tout. L'utilisateur fermera éventuellement l'application. Vous ne le savez peut-être pas, mais iOS se réserve le droit de tuer votre processus (en maintenant son état) et de le restaurer plus tard, et le "cycle de vie" de l'application iOS n'est pas vraiment entre vos mains. Votre crash - est tout simplement un crash, et le système d'exploitation peut choisir de faire revivre l'application de toute façon.
Motti Shneor

Wow, poste de trois ans. Quoi qu'il en soit, la nouvelle architecture de l'application le fait à peu près, avec un bouton de nouvelle tentative qui réessaye l'API et supprime l'écran de blocage ou les renvoie à l'écran de blocage avec une nouvelle erreur.
Michael Long

L'ancienne structure de l'application ne permettait pratiquement pas de réessayer les appels de l'API de démarrage et l'application était dans un état incohérent sans eux. Nous aurions pu utiliser un écran de blocage permanent, mais cela nécessitait que l'utilisateur force lui-même la fermeture de l'application et il a été décidé que tous les utilisateurs ne savaient pas COMMENT double-cliquer et forcer la fermeture des applications. Plus facile aujourd'hui, mais assez caché il y a trois ans.
Michael Long

1
[[UIApplication sharedApplication] terminateWithSuccess];

Cela a bien fonctionné et appelle automatiquement

- (void)applicationWillTerminateUIApplication *)application delegate.

pour supprimer l'avertissement de compilation, ajoutez ce code

@interface UIApplication(MyExtras)
  - (void)terminateWithSuccess;
@end 

5
Il s'agit d'une méthode privée, Diego Mercado a expliqué ci-dessus que son application avait été rejetée, alors pourquoi prendre un tel risque.
RVN

Utiliser une API privée fera rejeter l'application par Apple.
ZYiOS

2
pour les applications d'entreprise - cela peut être une solution.
user1140780

- (IBAction) exitApp: (id) sender {SEL selector = NSSelectorFromString (@ "terminateWithSuccess"); [self performSelector: sélecteur withObject: [UIApplication sharedApplication]]; }
unom

@unmircea a-t-il réussi l'examen?
Awesome-o

1

Vous ne devez pas appeler directement la fonction exit(0)car elle quittera immédiatement l'application et ressemblera à votre application qui est en panne. Il vaut donc mieux montrer aux utilisateurs une alerte de confirmation et les laisser le faire eux-mêmes.

Swift 4.2

func askForQuit(_ completion:@escaping (_ canQuit: Bool) -> Void) {
    let alert = UIAlertController(title: "Confirmation!", message: "Do you want to quit the application", preferredStyle: .alert)
    alert.addAction(UIAlertAction(title: "Yes", style: UIAlertAction.Style.default, handler: { (action) in
        alert.dismiss(animated: true, completion: nil)
        completion(true)
    }))
    alert.addAction(UIAlertAction(title: "No", style: UIAlertAction.Style.cancel, handler: { (action) in
        alert.dismiss(animated: true, completion: nil)
        completion(false)
    }))
    self.present(alert, animated: true, completion: nil)
}

/// Will quit the application with animation
func quit() {
    UIApplication.shared.perform(#selector(NSXPCConnection.suspend))
    /// Sleep for a while to let the app goes in background
    sleep(2)
    exit(0)
}

Usage:

self.askForQuit { (canQuit) in
     if canQuit {
         self.quit()
     }
}

0

L'utilisateur doit décider quand une application se ferme. Je ne pense pas que ce soit une bonne interaction avec l'utilisateur lorsqu'une application se ferme. Il n'y a donc pas de bonne API pour cela, seul le bouton d'accueil en a un.

S'il y a une erreur: mieux l'implémenter ou avertir l'utilisateur. S'il doit y avoir un redémarrage: implémentez-le mieux de notifiez l'utilisateur.

Cela semble stupide, mais c'est une mauvaise pratique de quitter l'application sans laisser l'utilisateur décider et sans l'avertir. Et comme il existe un bouton d'accueil pour l'interaction avec l'utilisateur, selon Apple, il ne devrait pas y avoir 2 choses pour la même fonction (quitter une application).


0

Quitter une application autrement que par le bouton d'accueil n'est vraiment pas iOS approche .

J'ai fait cet assistant, cependant, qui n'utilise aucun élément privé:

void crash()
{ [[NSMutableArray new] addObject:NSStringFromClass(nil)]; }

Mais toujours pas destiné à la production dans mon cas. C'est pour tester les rapports de plantage ou pour redémarrer rapidement après une réinitialisation des données de base. Juste fait en sorte de ne pas être rejeté si la fonction reste dans le code de production.


0

Swift 4.2 (ou plus ancien)

La bibliothèque appelée Darvinpeut être utilisée.

import Darwin

exit(0) // Here you go

NB: Ceci n'est pas recommandé dans les applications iOS.

Cela vous donnera un journal des plantages.


0

Dans iPadOS 13, vous pouvez maintenant fermer toutes les sessions de scène comme ceci:

for session in UIApplication.shared.openSessions {
    UIApplication.shared.requestSceneSessionDestruction(session, options: nil, errorHandler: nil)
}

Cela fera appel applicationWillTerminate(_ application: UIApplication)à votre délégué d'application et mettra fin à l'application à la fin.

Mais attention à deux choses:

Plus d'informations sur les scènes dans iOS / iPadOS 13: https://developer.apple.com/documentation/uikit/app_and_environment/scenes


-1

Quitter une application d'une autre manière

J'ai fait cet assistant, cependant, qui n'utilise aucun élément privé:

Sortie (0);


-1

Il peut être approprié de quitter une application s'il s'agit d'une application à longue durée de vie qui s'exécute également en arrière-plan, par exemple pour obtenir des mises à jour d'emplacement (à l'aide des mises à jour d'emplacement fonction d'arrière-plan des pour cela).

Par exemple, supposons que l'utilisateur se déconnecte de votre application basée sur la localisation et pousse l'application en arrière-plan à l'aide du bouton d'accueil. Dans ce cas, votre application peut continuer à fonctionner, mais il peut être judicieux de la fermer complètement. Ce serait bon pour l'utilisateur (libère de la mémoire et d'autres ressources qui n'ont pas besoin d'être utilisées), et bon pour la stabilité de l'application (c.-à-d. S'assurer que l'application est redémarrée périodiquement lorsque cela est possible est un filet de sécurité contre les fuites de mémoire et autres faibles mémoire) problèmes).

Cela pourrait (mais ne devrait probablement pas, voir ci-dessous :-) être réalisé avec quelque chose comme:

- (void)applicationDidEnterBackground:(UIApplication *)application
{
    if (/* logged out */) {
        exit(0);
    } else {
       // normal handling.
    }
}

Puisque l'application sortirait alors de l'arrière-plan elle ne serait pas fausse pour l'utilisateur et ne ressemblerait pas à un plantage, à condition que l'interface utilisateur soit restaurée la prochaine fois qu'ils exécuteraient l'application. En d'autres termes, pour l'utilisateur, cela ne ressemblerait pas à une interruption de l'application déclenchée par le système lorsque l'application est en arrière-plan.

Néanmoins, il serait préférable d'utiliser une approche plus standard pour faire savoir au système que l'application peut être interrompue. Par exemple, dans ce cas, assurez-vous que le GPS n'est pas utilisé en arrêtant de demander des mises à jour de position, notamment en désactivant l'affichage de la position actuelle sur une vue de carte, le cas échéant. De cette façon, le système se chargera de mettre fin à l'application quelques minutes (c'est-à-dire [[UIApplication sharedApplication] backgroundTimeRemaining]) après que l'application entre en arrière-plan. Cela aurait les mêmes avantages sans avoir à utiliser de code pour mettre fin à l'application.

- (void)applicationDidEnterBackground:(UIApplication *)application
{
    if (/* logged out */) {
       // stop requesting location updates if not already done so
       // tidy up as app will soon be terminated (run a background task using beginBackgroundTaskWithExpirationHandler if needed).
    } else {
       // normal handling.
    }
}

Et bien sûr, l'utilisation exit(0)ne serait jamais appropriée pour l'application de production moyenne qui s'exécute au premier plan, selon d'autres réponses qui font référence à http://developer.apple.com/iphone/library/qa/qa2008/qa1561.html

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.