J'utilise les structures par défaut lorsque cela est possible,
Quelle est la meilleure pratique pour mettre à jour l'instance de structure d'origine, une copie de celle-ci a été transmise à une autre variable.
disons que j'ai une structure Post
struct Post {
let title: String
let likes: Int
let viewsCount:Int
var comments:[Comment]
}
et que nous avons un simple écran principal-détails
en poussant l'écran des détails, nous copions le post dans la scène des détails, et là les données peuvent être modifiées comme des incréments de likes, des commentaires ajoutés, etc.
Ainsi, lorsque pop This ViewController, vers le nouveau modèle de données pour mettre à jour le modèle d'origine dans le Master ViewController.
quelles sont les solutions possibles et les meilleures pratiques pour cela?
en supposant que nous utilisons MVC ou MVP
4 Réponses :
Vous pouvez créer une classe de modèle partagée commune qui est responsable de la conservation des données de publication et que les deux contrôleurs de vue pourraient utiliser et observer.
Je créerais des fonctions d'assistance et les ferais muter. par exemple.
mutating func incrementLikes() {
likes += 1
}
Assurez-vous que vos propriétés sont var.
Cela n'a vraiment rien à voir avec les structures; c'est simplement le problème habituel de transmettre des données dans un contrôleur de vue lors de la création et de renvoyer des données depuis ce contrôleur de vue lors de la destruction. Il arrive que dans votre cas, vous posez qu'il s'agit des «mêmes» données - c'est-à-dire que vous transmettez un message au contrôleur de vue détaillée et que vous renvoyez un message du contrôleur de vue détaillée - mais ce n'est qu'un fait contingent.
Donc, pour répondre à la question telle que formulée, vous utiliseriez l'une des techniques habituelles. Le contrôleur de vue de détail doit renvoyer le message modifié au contrôleur de vue maître. Il pourrait utiliser une notification ou (plus directement) vous pouvez utiliser l'architecture standard de protocole et de délégué.
D'un autre côté, si Post est la base des données de votre application, il ne serait pas déraisonnable de soutenir que la prémisse elle-même est imparfaite: cela aurait dû être une classe depuis le début, pas une structure, exactement pour que les données peut être conservé dans un endroit central et les références à celui-ci peuvent être conservées à différents endroits.
En effet, si les choses sont plus complexes, vous pouvez faire en sorte que les données de l'application (y compris le message) vivent dans un troisième emplacement dans l'espace de données modèle et que tous les contrôleurs de vue envoient une notification up aux données lorsqu'ils les modifient et que les données envoient une notification down à tous les contrôleurs de vue en réponse (c'est ce que la réponse de Ralf Ebert suggère assez raisonnablement). Ce genre de chose est beaucoup plus facile de nos jours car (dans iOS 13) nous avons des objets observables et le framework Combine.
Idéalement, les classes sont les meilleures pour le rôle que vous avez décrit comme étant le maintien de l'identité des objets. Chaque message a une identité. Selon la documentation Apple, "utilisez des classes lorsque vous devez contrôler l'identité des données que vous modélisez" Lorsque vous partagez une instance de classe dans votre application, les modifications que vous apportez à cette instance sont visibles par chaque partie de votre code qui contient une référence à cette instance. Utilisez des classes lorsque vous avez besoin que vos instances aient ce type d'identité. Classes vs strut
Renvoyez la structure modifiée avec l'une des méthodes décrites ici . Sinon, utilisez une classe.
J'ai posé à peu près cette question exacte, mais elle a obtenu un -1 et a été supprimée lol stackoverflow.com/q/58809724/3141234
@ Alexander-ReinstateMonica Argh. La suppression semble avoir été automatique (car la question a été rejetée et est restée inactive). Voyons si nous ne pouvons pas remédier à cela.
@matt C'est dommage qu'il ait été voté. C'est un peu verbeux, mais je pense que c'est une question assez claire et bien raisonnée 🤷♂️