iOS: Comment vérifier si les UIViewControllers déchargent? (Rapide)

J'utilise un UISplitViewController chaque fois que je clique sur une ligne dans le VC principal, je peux voir que viewDidLoad() est exécuté dans le VC de détail.

Cela signifie-t-il que je crée une nouvelle instance de Détail VC à chaque clic de ligne?

Si oui, comment puis-je vérifier que le VC Détail déchargent correctement et que je ne crée pas seulement de plus en plus de nouveaux VC de Détail?

Je suis un peu perdu ici à Swift. Auparavant, je pouvais NSLog dans dealloc () et voir le déchargement UIViewController correctement.

Je ici Swift a une fonction deinit mais ce n'est jamais appelé:

 deinit { println("\(__FILE__.lastPathComponent)) : \(__FUNCTION__)") NSNotificationCenter.defaultCenter().removeObserver(self) } 

1) Où devrais-je retirer mes observateurs?

2) Lorsque je regarde dans le browser de debugging dans Xcode, l'utilisation de la memory ne cesse de monter et de ne jamais baisser.

Mise à jour: Détail VC est appelé comme suit:

 if segue.identifier == "addEvent" { if let controller = (segue.destinationViewController as UINavigationController).topViewController as? ManageViewController { controller.manageEvent = nil controller.navigationItem.leftBarButtonItem = self.splitViewController?.displayModeButtonItem() controller.navigationItem.leftItemsSupplementBackButton = true } } 

Je ne fais rien de différent de beaucoup d'exemples que j'ai vus, mais je m'inquiète de deinit pas être appelé

Mise à jour: Travailler maintenant – Le problème était que le délégué deinit être appelé (voir la réponse ci-dessous)

Mon code original non-fonctionnel était:

 protocol ManageViewDelegate { func pressedButton(sender: AnyObject) } class ManageView: UIView { var delegate: ManageViewDelegate? = nil ... } 

Nouveau code de travail:

 protocol ManageViewDelegate: class { func pressedButton(sender: AnyObject) } class ManageView: UIView { weak var delegate: ManageViewDelegate? = nil ... } 

Vous avez une vue avec une propriété delegate qui renvoie au controller de vue. Cela se traduira par un cycle de reference fort (précédemment connu sous le nom de cycle de rétention) car le controller de vue maintient une reference forte à sa vue de niveau supérieur qui, à son tour, maintient une reference forte au controller de vue.

Dans la section Résolution des cycles de reference forts entre les instances de class du langage de programmation Swift: Comptage automatique des references , Apple explique comment résoudre ce problème:

Swift propose deux methods pour résoudre les cycles de reference forts lorsque vous travaillez avec des propriétés de type class: les references faibles et les references non référencées.

Les references faibles et non référencées permettent à une instance d'un cycle de reference de se référer à l'autre instance sans la conserver fermement. Les instances peuvent alors se référer les unes aux autres sans créer de cycle de reference fort.

Utilisez une reference weak chaque fois que cela est valable pour que cette reference devienne nil à un moment donné au cours de sa durée de vie. Inversement, utilisez une reference unowned reference lorsque vous savez que la reference ne sera jamais nil une fois qu'elle a été définie lors de l'initialisation.

Ainsi, vous pouvez résoudre votre cycle de reference fort en définissant le delegate comme étant weak :

 weak var delegate: ManageViewDelegate? 

Pour que cela fonctionne, vous devrez peut-être spécifier votre protocole pour être un protocole de class:

 protocol SomeDelegateProtocol: class { // your protocol here } 

Cela permettra de résoudre le cycle de reference fort et élimine le besoin d' nil manuellement le delegate afin de résoudre le cycle de reference fort.

Aussi, si vous utilisez des blocs, vous devez append [self faible], sinon, la vue ne sera pas détruite

  setupObserve(postID) { [weak self] chatRequest in self?.update() } 

La fonction deinit devrait fonctionner