Qu'est-ce qu'un init coder aDecoder ?

Question

J'apprends le développement iOS dans le cadre d'un cours en ligne et chaque fois que je crée une vue personnalisée (cellule de vue de table personnalisée, cellule de vue de collection, etc.), l'instructeur met toujours en œuvre cet initialisateur :

required init?(coder aDecoder: NSCoder) {
    super.init(coder: aDecoder)
}

Pourquoi est-ce que je dois toujours appeler ça ? Que fait-il ? Puis-je mettre des propriétés dans l'init ?

Answer 1

Je vais commencer cette réponse par la direction opposée : que faire si vous voulez sauvegarder l'état de votre vue sur le disque ? C'est ce qu'on appelle sérialisation . L'inverse est désérialisation - restauration de l'état de l'objet à partir du disque.

El NSCoding définit deux méthodes pour sérialiser et désérialiser les objets :

encodeWithCoder(_ aCoder: NSCoder) {
    // Serialize your object here
}

init(coder aDecoder: NSCoder) {
    // Deserialize your object here
}

Alors pourquoi est-il nécessaire dans votre classe personnalisée ? La réponse est l'Interface Builder. Lorsque vous faites glisser un objet sur un storyboard et le configurez, Interface Builder sérialise l'état de cet objet sur le disque, puis le désérialise lorsque le storyboard apparaît à l'écran. Vous devez indiquer à Interface Builder comment procéder. Au minimum, si vous n'ajoutez pas de nouvelles propriétés à votre sous-classe, vous pouvez simplement demander à la super-classe de faire l'emballage et le déballage pour vous, d'où l'utilisation de l'option super.init(coder: aDecoder) appel. Si votre sous-classe est plus complexe, vous devez ajouter votre propre code de sérialisation et de désérialisation pour la sous-classe.

Cela contraste avec l'approche de Visual Studio, qui consiste à écrire du code dans un fichier caché pour créer l'objet au moment de l'exécution.

Answer 2

La nécessité de mettre en œuvre cet initialisateur est la conséquence de deux choses :

1. El Principe de substitution de Liskov . Si S est une sous-classe de T (par ex. MyViewController est une sous-classe de ViewController ), alors les objets S (instances de MyViewController ) doivent pouvoir être remplacés par des objets T (instances de ViewController ) sont attendus.

2. Les initialisateurs ne sont pas hérités dans Swift si des initialisateurs sont explicitement définis dans la sous-classe. Si un initialisateur est explicitement fourni, alors tous les autres doivent être explicitement fournis (qui peuvent alors juste appeler super.init(...) ). Voir cette question pour le raisonnement. C'est en Java, mais ça reste valable.

Par le point 1, tout ce que l'original ViewController peut faire, le MyViewController La sous-classe devrait pouvoir le faire. L'une d'entre elles est de pouvoir être initialisée à partir d'une classe donnée. NSCoder . Au point 2, votre MyViewController n'hérite pas automatiquement de cette capacité. Vous devez donc fournir manuellement l'initialisateur qui répond à cette exigence. Dans ce cas, il suffit de déléguer à la superclasse pour qu'elle fasse ce qu'elle ferait normalement.