Les ViewControllers ne sont pas destructeurs

Question

J'ai un problème sérieux avec mon application iOS.

J'ai une logique de connexion dans mon application. Lors de la connexion et de la déconnexion, certains contrôleurs de vue ne sont pas destructeurs. Cela provoque certains problèmes, par exemple, certains événements que j'émets en utilisant NSNotifcationCenter sont émis plusieurs fois. Ces problèmes sont évitables, mais je veux vraiment une solution pour éviter que certains contrôleurs de vue restent ouverts en arrière-plan sans que je ne les contrôle.

La façon dont contrôler la logique de connexion est la suivante:

Dans le délégué de l'application fonction de démarrage, si l'utilisateur est déjà connecté, régler le régulateur de vue racine au contrôleur principal de vue utilisable. Par conséquent, je ne fais rien et le contrôleur de vue racine est défini sur le contrôleur de navigation du contrôleur de vue de connexion via le storyboard. Lorsque l'utilisateur se déconnecte, j'utilise une synchronisation modale pour ramener le contrôleur de vue sur le contrôleur de navigation du contrôleur de vue de connexion. Comme vous pouvez le comprendre, j'utilise des storyboards, swift et le tout dernier iOS.

Mon code est Segue que la déconnexion me prendre au LoginViewControler:

self.performSegueWithIdentifier("Logout", sender: self) 

Mon application Code délégué:

if (userDefaults.valueForKey("uid") != nil) { 
    let tabBarView = UIStoryboard(name: "Main", bundle: nil).instantiateViewControllerWithIdentifier("TabBarViewController") as! TabBarViewController 
    let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate 
    appDelegate.window?.rootViewController = tabBarView   
} 

Qu'est-ce que je fais mal?

Je vous serais reconnaissant de l'aide :)

EDIT

J'ai même essayé de mettre juste le contrôleur de vue racine dans l'action et fermeture de session n'a pas aidé non plus. Comment est-ce possible?

Voici comment je fais la fermeture de session maintenant:

let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate 
let newRootViewController = self.storyboard?.instantiateViewControllerWithIdentifier("LoginNavigationController") as! UINavigationController   

appDelegate.window!.rootViewController = newRootViewController 

Answer 1

Si le connecté écran présente la connexion écran et l'connexion écran présente l'connecté écran alors vous aurez un cycle qui continue à empiler sur de nouveaux contrôleurs de vue. Pour résoudre cela, il ne faut pas présenter l'autre, mais se détendre. Une autre possibilité est de tenir des instances de chacune comme singletons et de ne les présenter que.

Answer 2

Adam H. a raison. Si cela ne fonctionne pas, vérifiez les IBOutlets et les délégués qui ont des relations fortes et remplacez-les par des relations faibles. c'est-à-dire

@IBOutlet weak var collectionView: UICollectionView! 

Sans le mot clé faible, le contrôleur de vue ne sera jamais éliminé.

Selon la façon dont votre projet est configuré, si vous utilisez un contrôleur de navigation (que je recommande) chaque fois que quelqu'un se connecte à vous mettre

dispatch_async(dispatch_get_main_queue()) { 
    self.navigationController.popToRootViewControllerAnimated(true) 
} 

Ce sautera tout de la pile de navigation, qui sera disposer de tous les contrôleurs de vue (sauf si vous avez des relations fortes, alors ils ne seront pas éliminés)

Answer 3

Peu importe comment vous choisissez de gérer vos transitions, n'oubliez pas d'ajouter/supprimer l'observateur à chaque apparition du contrôleur de vue/disparaître.

Answer 4

J'ai implémenté quelque chose comme ça il n'y a pas si longtemps et pour moi, il semble que vous abusiez du cycle de vie de UINavigationController. Après avoir lu votre question deux fois, si je la comprends correctement, il semble que vous initialisiez votre contrôleur de vue de connexion en tant que UINavigationController qui empile les contrôleurs de vue. Une fois que l'utilisateur se déconnecte, vous gardez la pile, en ajoutant plus de ViewControllers à la pile en utilisant la fonction performSegue. Vous pouvez l'éviter en utilisant deux scènes différentes - 1) Login View Controller qui est autonome. 2) Flux principal de votre application - peut commencer avec UITabController/UINavigationController, les deux ou quoi que ce soit.

Dans AppDelegate, vous cochez - Si l'utilisateur est connecté - faites vos logiques et réglez l'application rootVC sur le flux principal vc. Sinon, vous définissez loginVC (UIViewController) comme racine. Cela vous permet également d'insérer le VC de connexion n'importe où dans le flux principal, si nécessaire, sans interférer avec le flux principal. Dans votre cas, loginVC est toujours la racine de UINavigationController, donc vous devez popToRootVC à chaque fois que vous voulez le voir ou effectuer une Ségrégation qui est pire parce que vous créez alors une autre instance d'UINavigationController et les ressources ne sont jamais désallouées. Il est évident qu'en programmation, dans la plupart des cas, il existe de nombreuses solutions à un problème. Je suis sûr que votre problème peut être résolu en utilisant votre flux. Je pense juste que c'est une mauvaise expérience pour empiler un loginVC sur un contrôleur de navigation.

Answer 5

Une partie du problème est que la définition d'un nouveau rootViewController sur le UIWindow ne supprime pas la hiérarchie de vue de l'ancien contrôleur de vue racine. Cela laisse toutes sortes de références fortes en suspens, et si vous utilisez le débogage d'affichage de Xcode, vous pouvez voir que l'ancienne hiérarchie d'affichage est toujours là, derrière la nouvelle hiérarchie d'affichage de rootViewController.

Quelque chose comme cela devrait résoudre le problème pour vous et permettre à votre vue contrôleurs deinit:

let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate 
let newRootViewController = self.storyboard?.instantiateViewControllerWithIdentifier("LoginNavigationController") as! UINavigationController   

appDelegate.window??.rootViewController?.view.removeFromSuperview() 
appDelegate.window??.rootViewController?.dismissViewControllerAnimated(false, completion: nil) 
appDelegate.window??.rootViewController = newRootViewController  

Answer 6

Vous devez retirer votre:

self.performSegueWithIdentifier("Logout", sender: self) 

Au lieu de cela, vous pouvez redéfinissant cette Segue méthode, cela suffit:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) { 
     userDefaults.removeObjectForKey("uid") 
     if segue.identifier == "Logout" { 
      let newRootViewController = segue.destinationViewController 
      // newRootViewController is optional in case you want to pass vars 
      // do whatever you want with your newRootViewController 
     } 
} 

À propos de votre NSNotification il y a deux méthodes pour le supprimer:

NSNotificationCenter.defaultCenter().removeObserver(self, name: "NotificationIdentifier", object: nil) 
NSNotificationCenter.defaultCenter().removeObserver(self) // Remove from all notifications being observed 

Swift, vous pouvez mettre les removeObservers dans le deinitmethod nouvelle et spéciale.

Answer 7

se débarrasser du fichier ARC par fichier dans les paramètres de construction ou de gros par projet (il semble que vous pouvez avoir projet non ARC, mais ont des références faibles tout ce: non sportif je suppose mais vous pouvez avoir les deux).

Ensuite, remplacez conserver et relâchez dans le contrôleur de vue problématique et voyez qui détient la référence supplémentaire en rompant dans la priorité retenez et relâchez. Ce devrait être une expérience éducative. L'approche paresseuse consiste à tuer ARC uniquement pour le VC en question.

Je serais curieux de voir comment cela fonctionne pour VCS en rapide ;-)

moi pense que c'est encore une autre raison de rester dans un domicile objc alors plus jusqu'à ce que/si compilateur rapide et solidifie exécution (si jamais).

J'espère que cela aidera tout le monde. PS: Il faut une éternité pour compiler un fichier rapide dans mon projet et je n'ai pas d'idée quel fichier swift est à l'origine de ce problème. Duh.

Answer 8

Comme indiqué précédemment, il n'y a pas beaucoup d'informations pour fournir correctement la solution à votre question. Je peux vous suggérer de changer votre approche. J'ai fait un flux de travail similaire en utilisant un UINavigationController (NavigationController) lancé à partir AppDelegate, à l'intérieur si nous sommes connecté je mets comme ViewControllers:

(où auto est navigationController et RootViewController est un autre UINavigationController)

self.setViewControllers[loginViewController, rootViewController] 

Si vous n'êtes pas connecté vous mettez seulement loginViewController:

self.setViewControllers[loginViewController] 

dans ce cas vous pouvez mettre le rootViewController où l'utilisateur est connecté. Ceci est mon 2cent.

Answer 9

J'aime avoir une racine VC qui est juste vide. Lorsque l'application démarre, la racine VC affiche immédiatement login VC en tant que VC enfant de la racine VC. Lorsque l'utilisateur authentifie avec succès, le VC de connexion notifie la racine VC, qui ajoute principal VC en tant que fils de racine VC, transitions (avec une belle animation) de connexion VC à VC principal (en utilisant [self transitionFromViewController: toViewController: duration: options: animations: completion:]), puis supprime Connectez-vous VC comme un enfant et le rejette. Lors de la déconnexion, le VC principal notifie la racine VC qui fait ensuite la même chose à l'envers. Donc, la plupart du temps, vous n'avez que VC de connexion ou VC principal instancié; la seule fois où ils sont tous les deux instanciés est pendant la transition.

Je trouve que les segments sont utiles pour construire des prototypes rapides, mais pour les applications de production, je préfère ne pas les utiliser.

Answer 10

Je suppose que la pile ViewControllers vous sera comme ceci: - 1er lancement: LoginVC - Après connexion: LoginVC - TabarVC - Cliquez sur Déconnexion: LoginVC - TabarVC - LoginVC ....

Alors votre code ci-dessous devrait fonctionner:

let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate 
let newRootViewController = self.storyboard?.instantiateViewControllerWithIdentifier("LoginNavigationController") as! UINavigationController   

appDelegate.window!.rootViewController = newRootViewController 

mais il ne :(à mon avis, vous devriez toujours laisser le tabarVC RootViewController et l'enregistrement TabarVC, si l'utilisateur ne loged-ou fermeture de session a appuyé sur, le présent loginVC.. et le rejeter au lieu de performSegue