ns operationqueue

• CTO Youboox • @vdaubry •  iOS et RoR

Vincent Daubry

A quoi ça sert ? •  Gérer le multithreading, ne pas bloquer le main thread

•  Cas d'usage numéro 1 : appels réseaux

•  Article de Jeff Lamarche de 2010 qui déconseille l’utilisation de thread pour lancer des appels réseaux synchrone

•  « This is Apple's polite way of saying "don't use threads for networking, you idiot". »

18/2/13 Copyright © 2012 Youboox.fr | Design by Youboox 2

* h;p://iphonedevelopment.blogspot.fr/2010/05/downloading-‐images-‐for-‐table-‐without.html

A quoi ça sert ? Les frameworks « modernes » utilise des operations pour faire les appels réseaux. On utilise donc des appels assynchrone pour lancer… des [NSURLConnection sendAsynchronousRequest] ?


A quoi ça sert ? •  Il y a 2 raisons :

La performance : « Event-driven code is more complex than code using blocking threads, but it delivers the highest network performance. »

Mais surtout :

–  Une queue permet un contrôle très fin sur les appels : priorité, dépendances, appels concurrents, etc


Un peu de théorie •  Lancer des thread à la main est facile


•  Mais : –  Ce n’est pas scalable (gestion du CPU et de la mémoire) –  Pas adapté aux CPU multicoeurs

•  A réserver à des cas très particulier d’appli temps réels…

•  En conlusion : Please don’t do it.

Un peu de théorie

•  La bonne façon de faire est d’utiliser les queue fournit par le SDK : dispatch queue et operation queue

•  Dispatch queue (GCD) : approche bas niveau •  Operation queue : approche haut niveau

•  Les operations sont des simple objets •  On peut faire pleins de choses sympathiques avec ça


NSOperation •  NSOperation : moyen recommandé de gérer les appels en tache de

fond

•  Une operation est une sous-classe de NSOperation


NSOperation •  Une operation a une methode main


NSOperationQueue •  Une job queue : NSOperationQueue •  Un simple array d’operation

•  Par défaut les operations sont exécutées dans l’ordre dès qu’on les ajoute à la queue


Dans la vrai vie : les blocks


C’est tout ;)

Le sucre •  La queue offre un contrôle très fin sur les operations :

–  Choisir le nombre d'operations simultanées

–  Priorité d’exécution des jobs

–  Mettre en pause le démarrage de nouvelles operations

•  Une operation est KVO compliant :

–  Etat du job (isCanceled , isConcurrent, isFinished)

–  Completion block

•  Une operation peut avoir une liste d’operations dont elle dépend


AFNetworking

•  Chaque appel est une operation

•  Une queue pour lancer les operations

•  Chaque operation ouvre une connection assynchrone

•  Operations et blocks = callbacks


AFNetworking


•  Exemple : enqueueBatchOfHTTPRequestOperationsWithRequests

•  Pour chaque requête il y a un completion block (suivre l’avancement)

•  Chaque requête est ajouté comme une dépendance du batch

Attention au MainThread… •  Penser à lancer vos opérations de mise à jour de l’interface sur le

main thread !


Attention à la mémoire…

•  Chaque opération retient les objets qui sont alloués durant son exécution

•  Quand on définit des dépendances entre opérations la mémoire n’est libéré que lorsque toutes les opérations soient terminées


MKNetworkKit

•  Et si votre appli fait des appels long en tache de fond ? (ex: téléchargement)

•  3G = 2 connexions concurrentes max … (edge 1 connection)

•  La queue est placée dans un singleton, toute l'appli a accès les appels réseau

•  Permet de faire varier le nombre d'appels concurrent en fonction du reseau

•  Permet d'affecter un niveau de priorité aux appels


MKNetworkKit

•  La queue est en mémoire

•  On ne peut pas sérialiser un block (?)

•  Mais on peut serialiser une opération!

•  Pourquoi faire ? –  Exemple : Quand on perd le réseau les operations sont sauvés

et executés quand on revient online


MKNetworkKit


ns operationqueue

Technology