Dilemme sur AFNetworking à cause d'un crash
chatonSauvage
Membre
Bonjour (et bonne année 2015)
Je suis confrontée à un problème embêtant qui génère des crashs sur mon application (qui est malheureusement déjà en ligne donc les retour clients .... mauvais ... bref).
L'application génère des "Received memory warning." et en voici le crashLog :
0 CoreFoundation 0x26eec5f2 __exceptionPreprocess + 122
1 libobjc.A.dylib 0x3475ec72 objc_exception_throw + 34
2 CoreFoundation 0x26eec078 __NSFastEnumerationMutationHandler + 124
3 UIKit 0x2a672594 -[UIViewController _traverseViewControllerHierarchyFromLevel:withBlock:] + 152
4 UIKit 0x2a6725bc -[UIViewController _traverseViewControllerHierarchyFromLevel:withBlock:] + 192
5 UIKit 0x2a67281c +[UIViewController _traverseViewControllerHierarchyWithDelayedReleaseArray:block:] + 468
6 UIKit 0x2a6729a0 +[UIViewController _traverseViewControllerHierarchyWithDelayedRelease:] + 120
7 UIKit 0x2a5fb950 -[UIApplication _performMemoryWarning] + 200
8 libdispatch.dylib 0x34cbf40a _dispatch_client_callout + 18
9 libdispatch.dylib 0x34cd4704 _dispatch_source_latch_and_call + 616
10 libdispatch.dylib 0x34ccdf38 _dispatch_source_invoke$VARIANT$mp + 208
11 libdispatch.dylib 0x34cca030 _dispatch_main_queue_callback_4CF$VARIANT$mp + 324
12 CoreFoundation 0x26eb262c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 4
13 CoreFoundation 0x26eb0d4c __CFRunLoopRun + 1508
14 CoreFoundation 0x26dfdb2c CFRunLoopRunSpecific + 472
15 CoreFoundation 0x26dfd93e CFRunLoopRunInMode + 102
16 GraphicsServices 0x2e1dd04c GSEventRunModal + 132
17 UIKit 0x2a3f36ec UIApplicationMain + 1436
...
Bien entendu je ne me suis pas arrêter là pour venir vous voir.
J'ai donc dans le Thread 13 de ce même crash logo un lien vers ceci :
+ (void) __attribute__((noreturn)) networkRequestThreadEntryPoint:(id)__unused object {
do {
@autoreleasepool {
[[NSRunLoop currentRunLoop] run];
}
} while (YES);
}
Après quelque recherche j'ai vu que d'autre personne avait eu le souci et que la librairie avait été corriger en ce sens (AFNeworking). Cependant seul la v2.0 (master) est a jour avec cette correction et je me rend compte que le prestataire a qui j'ai eu affaire a utilisé la version 1.X .
En sachant que mon application ne supporte plus iOS 5 depuis un moment et voulant aller au plus vite pour corriger le problème, je me rend bien compte que changer toute les requêtes de mon application n'est pas vraiment le moyen le plus rapide (bien que la migration vers la v2.0 me semble obligatoire le passage en 64Bits n'est vraiment pas prêt et limite donc beaucoup le temps disponible pour une mise à jour).
Que me conseillez-vous de faire ?
Réponses
Utiliser temporairement le pattern Adaptateur pour transformer tous les appels 1.X en appel 2.0 en attendant de migrer et tester complètement l'application.
Tu as un exemple qui traine quelque par a ce sujet ? Histoire que je ne fasse pas n'importe quoi
D'abord ce n'est pas Façade mais Adaptateur qu'il faut utiliser (je corrige le post). Les deux sont assez proches mais autant être précis.
On trouve le principe sur Wikipedia
Faire un adapteur sur AFNetworking ça risque d'être rock and roll...
C'est d'ailleurs assez étonnant que rien n'ai été fait de la part des concepteurs et de la communauté à ce niveau là . C'est pas la première fois que je vois des gens embêté face à la migration AF v1 vers v2.
C'est gentil de me rassurer ...
Bon ben je crois que j'ai du boulot
De toutes façons je ne vois pas d'autre alternative : portage ou adaptateur
L'intérêt de l'adaptateur c'est qu'une âme charitable pourrait le partager.
Cela dit je n'ai jamais travaillé avec AFNetworking. J'ai eu la chance de disposer déjà de NSURLSession lorsque je me suis mis à ce genre de trucs un peu sérieusement.
Une autre possibilité d'ailleurs pourrait être de faire un adaptateur de AFN v1 vers NSURLSession.
Quitte à écrire du code, autant écrire du code qui fait vraiment le travail, qui crée de l'avenir en utilisant une API récente et qui donne du potentiel d'évolution ; plutôt qu'un code qui adapte du vieux.
Donc, si ton app est testable, il faut faire un portage vers du standard : NSURLSession.
Après l'app utilise peut-être des features de AFNetworking qui n'existe pas dans NSURLSession, à voir, mais dans ce cas tu pourras toujours adapter ces partie là (je pense à l'interface qui permet de charger une image en prévoyant l'activity indicator pendant le chargement).
Le pattern adapter, c'est bien quand on ne peut pas changer la partie adaptée. Soit parce que c'est une API externe, soit parce que c'est du code commun avec autre chose, soit parce que c'est vraiment gros, pas testable et mystérieusement en marche. Le cas du planning serré est rarement une bonne raison, mais tout le monde ne peut pas le comprendre.
La prochaine fois, tu mettras dans ton cahier des charges : "l'utilisation de bibliothèque externe est interdite sans accord préalable du donneur d'ordre". C'est mieux d'être un peu psycho-rigide au départ et de relâcher la pression après, plutôt que le contraire.
Parenthèse :
devoir faire vite, c'est souvent une excuse pour faire mal ou limiter les choix. Des organisations entières s'arrangent pour se mettre en retard pour avoir à faire vite afin de ne pas avoir à se demander comment faire bien.
Autant à l'échelle individuelle, cela peut marcher d'attendre le dernier moment pour mobiliser l'énergie du stress, autant à l'échelle d'une organisation, ou d'un projet ça donne rarement des bons produits (même si cela peut fonctionner au niveau d'une équipe restreinte).
Les seules vraies raison de faire vite sont rares : un salon (ça doit être prêt pour le CES par exemple), une demo client/investisseur.
Les mauvaises raisons : la peur du chef/client, arriver après le concurrent.
Deuxième parenthèse.
Est-ce vraiment important la distinction entre les différents pattern adapter/façade/décorateur/proxy ?
Selon moi, l'important concernant ces pattern c'est d'avoir en tête le principe qui consiste à mettre quelque chose devant autre chose pour changer son interface.
Voilà pourquoi je me méfie des design patterns : d'emblée y'en a trop et on passe plus de temps à les distinguer plutôt qu'à les comprendre.
Je trouve l'approche agile plus intéressante : on part de constations pour bâtir 4 valeurs, puis 12 principes puis des méthodes selon les goûts et les situations.
Avec les design patterns, on est directement dans la complexité de la méthode, et donc chaque fois qu'un maniaque dérive un nouveau pattern à partir d'un autre, sous prétexte qu'il a une caractéristique différente selon un certain angle, cela rend le tout plus complexe.
D'autant que ces différences d'implémentation, d'objectif ou de contexte entre patterns voisins ne résistent pas toujours à la projection de ces patterns dans la réalité d'un langage donné.
En deux mots, c'est 20% de génie, 80% de branlette intellectuelle.