Pourquoi utiliser les blocks ?
AP
Membre
Bonjour,
Connaitriez-vous un bon article expliquant le pourquoi et l'utilisation des blocks en objective-c?
J'ai trouvé quelques articles en anglais mais ca reste très obscur.
Merci pour votre aide
Connaitriez-vous un bon article expliquant le pourquoi et l'utilisation des blocks en objective-c?
J'ai trouvé quelques articles en anglais mais ca reste très obscur.
Merci pour votre aide
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
As tu regardé sur le site developer.apple.com
A short Practical Guide to Blocks Donne une réponse au pourquoi:
Et la page Blocks Programming Topics: Using Blocks donnerait plutôt une réponse au comment.
Que te manque t'il ?
EDIT: mets toi sur la page d'accueil du forum, puis fais une recherche avec "blocks" en haut à droite, il y a environ une 15aine de discussions où on les évoque dans des cas précis.
http://cocoaheads.fr/2011/05/slides-de-la-session-davril-a-rennes/
Les 20 premières minutes parlent de pourquoi et comment utiliser les Blocks!
Non c'est plus entre une fonction et un objet:
plus puissant qu'une fonction car un block peut gérer des données, plus léger qu'un objet (à utiliser, car en réalité un Block est un objet).
Tu étais aux CocoaHeads Rennais ? ou tu as juste vu la vidéo?
Et dire qu'il y a de "pov' applis" dont l'objectif est d'afficher des données dans des tableViews qui sont compatibles iOS 4.0 et + seulement à cause des blocks...
Tu veux dire à cause des APIs utilisant les Blocks,
car les Blocks en eux mêmes ont une compatibilité inférieure à iOS 4.0 !
@Buno & Shadow
Moi pas connaitre IOS et pas vouloir connaitre! Moi, vieux Mac Enthousiaste, commencé avec "Apple IIE" ( ~1985?). Aucun intérêt pour objets inutiles et chers.
Ce n'est que ma session qui n'a pas pu être mise en vidéo car pas de son (donc autant filer les slides que de faire une vidéo muette de slides qui avancent)
Recherche sur PommeDev j'ai parlé pas mal de fois des gros avantages des blocks (même sans parler de GCD). Tant pour les animations des vues que, surtout (c'est là où je les utilise le plus) pour implémenter des callbacks.
- UIAlertViewEx et UIActionSheetEx : 2 classes utilisant les blocks pour simplifier grandement l'écriture des alertes et actionsheet et la gestion de leur retour (quel bouton cliqué). Plusieurs avantages expliqués dans le post
- Une classe OHURLLoader qui montre l'intérêt d'utiliser les blocks, dans cet exemple pour un téléchargement asynchrone de données. Là encore, avantages expliqués dans le code, y compris la différence entre si tu devais faire sans blocks ou quand tu fais avec blocks (tu verras à quel point le code est plus simple à utiliser avec blocks bien sûr)
Et j'en passe.L'Apple IIe, le truc qui valait 3x le salaire moyen en 1985 ?
@Aligator
Ok, j'ai téléchargé les deux, je vais jeter un oe“il (rassures toi je le récupère après). Ce qui m'embête, ce sont tout ces iBidules que je ne connais pas et n'ai jamais utilisé!
T'es trop sénile :P
C'est un exemple typique d'utilisation des blocks, à savoir pouvoir fournir directement le code de la callback en paramètre lors de l'appel de la méthode. (Sur le même principe que ce que j'ai implémenté dans les 2 exemples iOS cités plus haut, sauf que là c'est une méthode Apple du SDK)
Ainsi, avec cette méthode du SDK 10.6, au lieu de devoir passer un didEndDelegate et un didEndSelector et implémenter du code ailleurs dans ton fichier .m pour gérer le retour de ton NSSavePanel et récupérer les chemins de fichiers qui ont été choisis par l'utilisateur (code qui sera donc ailleurs, rendant la lecture du code moins lisible), comme on le faisait avant 10.6 sans les blocks, bah là tu passes juste directement le code... en paramètre !
Ainsi, sans les blocks ça donne : Du coup tu peux voir un peu les inconvénients : faut passer un didEndDelegate et un didEndSelector (un peu fastidieux) mais surtout, faut implémenter une méthode à côté, ailleurs dans le code (pas top pour la lisibilité pour comprendre la logique d'enchaà®nement des actions), et en plus faut gérer le contextInfo si tu veux passer des paramètres pour pouvoir récupérer un objet après l'appel asynchrone à "beginSheet..." et qu'il soit disponible lorsque le didEndSelector est appelé et penser à le retain puis à le release...
Alors qu'avec les blocks, le code à écrire est vachement plus compact puisque ça donne : Plus besoin de didEndDelegate, ni de didEndSelector, plus besoin de gérer toi-même le contexte puisque les blocks gèrent tout seul les objets à retenir ou relâcher le temps nécessaire où le block en a besoin, et en plus le code est centralisé, tu as le code qui affiche le SavePanel et celui qui est appelé de façon asynchrone plus tard tous les deux centralisés au même endroit, ça éviter de scroller partout dans ton .m pour trouver où est cette satanée méthode didEndSelector, etc.
Tu utilises juste les nouvelles méthodes permettant de passer directement le code (le "block") en paramètre y'a pas plus de question à se poser :P Quant à la réponse à la question "pourquoi utiliser les blocks" à l'origine de ce post (plutôt que les anciennes API sans blocks)... je pense qu'elle est évidente avec mon exemple maintenant non ?
Moins de code, moins de méthodes : le code au même endroit qui concerne la même chose.
C'est d'autant plus utile dans les classes qui vont appeler plusieurs OpenPanel ou plusieurs ActionSheet... (qu'il faudrait identifier avec l'ancienne méthode).
Moi à l'époque je n'étais qu'un jeune chiot scolarisé et désargenté, contemplant avec tristesse l'Apple II derrière la vitre des boutiques.
La vie est une grande roue qui tourne et il faut savoir cultiver notre jardin, en plus ça permet de faire de bonnes soupes :-*
Les blocks c'est bien
J'ai voulu trouver la méthode la plus rapide de trouver une Ordo dans un NSArray *ordos (il y en a 258 actuellement)
voilà le code en cherchant successivement via
Le tableau de prédicats est construit dans une boucle séparée pour ne pas imputer à la recherche le temps de création. ça ne sert à rien c'est pas là que je perds vraiment du temps ...
Première conclusion: ça va tellement vite qu'on ne voit pas la différence à l'oeil nu quelque soit la méthode !
Seconde conclusion: énumération + break < blocs < predicates..
Si les blocks sont un chouà¯a plus lents que l'énumération rapide ils sont plus rapides à écrire et relire (quand on a pris l'habitude) et bien plus rapides que les predicates..
Cette classe a été spécialement implémentée pour effectuer, entre autres, des cherches d'un objet à partir d'une clé
Mais effectivement un moment je me suis demandé si je n'aurais pas pu/dû faire plutôt des NSDictionaries que des Class, avec les catégories on doit pouvoir leur ajouter des méthodes ....
Mais en effet, si tes "ordos" sont identifiées de façon uniques pas un uid, et qu'en plus tu manipules souvent cet uid, plutôt que stocker tes objet Ordo dans un NSArray, j'aurais stocker ces objets Ordo (donc tu gardes toujours des classes), dans un NSDictionary, indexé par leur uid (c'est ce pense ce que voulais dire Flo, pas remplacer tes classes par des NSDictionary, mais stocker ces instances de classes dans un NSDictionary pour avoir un accès indexé à ces objets).
Ainsi tu aurais [tt]Ordo* o = [ordos objectForKey:uid];[/tt] pour récupérer un objet Ordo en connaissant son UID. Et bien évidemment, cet objet [tt]Ordo* o[/tt] aurait sa propriété o.uid qui vaudrait l'UID demandé, celui correspondant la clé... mais aurait aussi lui toutes les autres propriétés.
PS j'ai pas trop compris ton algo avec les NSPredicates, si tu veux juste ordonner un ensemble d'objet Ordo par uid ?!
ouep
J'utilise ces Ordo* dans d'autres cas et je ne me sers (pour l'instant) de leur uid que pour faire le lien avec des objets Facture* que je recrée à partir de fichiers générés par une application tierce d'après les renseignements que je fournis.
Les ordos n'ont pas qu'un lien avec des factures mais aussi avec des (ABPerson*) patients, des prescripteurs, des rendez vous iCal. des copies scannées sur le disque... Un dictionnaire ne serait pas pratique pour gérer tout ça !
Il va falloir que je creuse cette piste qui me semble très prometteuse. Pour les factures un dictionnaire suffirait bien en effet et m'éviterait d'avoir à charger l'ordo pour mes états de sortie.. Il suffirait d'un NSArray des clefs pour créer un dictionnaire à la volée ..
Le predicate ne peut ramener qu'une ou zéro ordo car une uid n'existe pas dans plus d'une ordo, en demandant lastObject j'ai nil ou la seule ordo qui m'intéresse. C'est mieux que faire objectAtIndex:0 si le tableau est vide
Bon après le backend de ton modèle c'est quoi ? Une base SQLite ? du CodeData ?
Parce que pour tout l'aspect relationnel, ça peut valoir le coup de se poser la question de plutôt faire une requête avec des jointures plutôt que de gérer les jointures côté modèle en RAM ?