Ceci est une question «meilleure pratique» que je ne peux pas sembler trouver une bonne réponse pour en ligne. Je crée une bibliothèque de code statique, qui fournit plusieurs méthodes de déléguement pour avancer les commentaires entre autres choses.
La bibliothèque gère ses propres files d'attente, des choses comme des téléchargements ne sont pas faits sur le fil principal évidemment, mais ma question est de savoir que mes méthodes de délégation sont toujours appelées sur le fil principal ou sont-elles acceptables de les appeler de la Des threads en file d'attente que j'utilise? et s'appuyer sur le développeur qui utilise la bibliothèque pour vérifier qu'il est sur le fil principal s'il veut faire des mises à jour de l'interface utilisateur dans mes méthodes de délégation?
acclamations, Sam
3 Réponses :
Évidemment, vous devez appeler des méthodes de déléguement dans le fil principal, car si je ne me trompe pas, vos méthodes de délégation seront transmises à un objet de délégué (classe d'utilisateur).
Supposons que vous téléchargiez des données dans une file d'attente, lorsque les données sont téléchargées, vous appellerez une méthode de déléguée en le transmettrai à un certain objet de la classe de l'utilisateur, il doit donc être dans le fil principal.
Quand tu dis "évidemment" ... Pourquoi est-ce évident? Les méthodes déléguées sont toujours retombées à l'objet délégué correctement même si elles ne sont pas sur le fil principal, cela signifie simplement que la classe de l'utilisateur doit s'assurer qu'elle fonctionne sur le thread principal s'il souhaite mettre à jour l'interface utilisateur? (Fyi, ce n'était pas moi qui a bownvothed ta réponse!)
Je voulais dire si vous l'avez laissé pour l'utilisateur, alors il rend l'utilisateur à parcourir le code de votre bibliothèque pour savoir s'il devrait appeler sur un fil principal ou une autre.
Bien que je ne sois pas génie, mais quelle que soit mon expérience, vous devriez rendre les utilisateurs à travailler facilement avec cette bibliothèque. (Et j'ai suscité votre question, j'attends aussi que les autres réponses, bon point que vous avez soulevé).
Ok, merci ... Donc, cela ressemble à ce que cela dépendra vraiment du niveau de documentation que je fournis et que la meilleure pratique est considérée comme facilitée pour le développeur qui la met en œuvre, plutôt que des règles définies à suivre.
Vous pouvez le faire de toute façon; Vous avez juste besoin de documenter cela bien.
Certaines API vous rappelleront sur le fil principal, certains sur le fil (ou Runloop) que vous aviez l'habitude de commencer le travail, et d'autres ne font pas de garanties du tout. Certains vous permettront même de passer dans une file d'attente GCD utilisée pour tous les rappels.
N'oubliez pas que le délégué / rappel pourrait bloquer une quantité de temps non triviale, de sorte que votre API doit reprendre le travail dès que possible, vous souhaitez certainement être envoyé à un autre fil ou à une autre file d'attente.
Cela dit tout cela, à moins que la performance ne soit critique pour vous ou les utilisateurs de votre API, j'irais avec le plus pratique du développeur qui serait le fil principal.
Merci de votre réponse, il semble que la «meilleure pratique» dans ce cas dépend vraiment du scénario.
Cela dépend vraiment. Mais je recommanderais de toujours utiliser une file d'attente "interne privée" pour exécuter les blocs du client. C'est le seul moyen fiable d'éviter les verrous accidentellement morts par le code de l'utilisateur lorsqu'il appelle une Dispatch_Sync () quelque part dans le bloc.
Merci, oui, j'utilise des files d'attente privées internes dans la bibliothèque.
Lorsque j'ai fait mon propre gestionnaire de téléchargement, j'ai gardé la méthode de déléguée appelant sur le thread secondaire qui exécutait des instances d'objets de connexion, mais c'est parce que j'ai eu un "contrôleur" qui envoie des blocs de réussite sur le fil principal. À mon avis dépend de quel niveau votre bibliothèque est impliqué, si vous pensez que la plupart des délais délégués appelleront une méthode avec des sous-routines impliquant des objets Uikit, car ils ne sont pas en sécurité, je choisirai de les envoyer sur le fil principal. Si vous pensez qu'après que le délégué, l'utilisateur de votre bibliothèque puisse effectuer une élaboration ultérieure sur les données, je choisirai de rester sur un autre fil, mais indiquant que clairement la documentation. Il y a un autre point: vitesse, en fonction de trois priorités, un fil secondaire pourrait être vraiment lent.
[Modifier]
Dans un gestionnaire de téléchargement, KVO ou notification est un meilleur moyen de gérer les connexions, comme indiqué par Quinn un ingénieur Apple dans une vidéo WWDC.
Merci pour vos commentaires ... Premièrement, Quinn est une légende! Deuxièmement, le problème que j'ai, c'est que ma bibliothèque fait beaucoup plus que d'agir en tant que gestionnaire de téléchargement, infecte le gestionnaire de téléchargement est un composant de la bibliothèque. Je voulais donc éviter d'utiliser des kvo / notifications pour un aspect et de déléguer des méthodes d'un autre ... mais sinon oui, je suis d'accord avec vous.
Oui "The Eskimo" est un super héros, il est vraiment un gars sympa, explique toujours des trucs.