Ni SQLite ni Core Data : pour l'instant rien que des Classes qui ont implémenté NSCoding et que je charge via NSKeyedUnArchiver. Apple déconseille de commencer par Core Data et après avoir tâté de la migration de modèles j'ai préféré aussi ! C'était à mes débuts, maintenant que je me sens plus à l'aise je pense que je passerais à Core Data quand le besoin s'en fera sentir. En fait je n'avais pas encore mis d'uid parce que NSKeyedArchiver permet de stocker et retrouver toutes les liaisons entre les objets mais les factures sont à part. Les fichiers qui les constituent sont manipulés souvent par l'autre application, c'est plus simple de les créer à partir de chaque lancement de l'application ou de les recréer si le fichier a changé que d'archiver des objets qui les représenteraient mais que je devrais synchroniser à chaque événement. Avant l'uid je gardais une référence de chaque fichier créé depuis une ordo dans un tableau membre de l'ordo et au rebours je cherchais dans les tableaux de toutes les ordos celui qui contenait la référence à la facture sur le disque pour retrouver l'ordo correspondante. C'est plus simple en écrivant une string uid dans le fichier et pour gagner encore en rapidité j'ai testé les blocks et les predicates, avant j'utilisais seulement les predicates.
<br />//refURL est déterminée au chargement du fichier: c'en est l'URL ...<br />NSPredicate *facturePredicate = [NSPredicate predicateWithFormat:@"factures contains %@", self.refURL];<br />NSArray *aResult = [appOrdos filteredArrayUsingPredicate:facturePredicate];<br />
C'était sensiblement plus long mais avec l'uid c'est redevenu plus qu'assez rapide aussi je vais me donner encore un peu de temps avant de passer à Core Data et de repenser à l'architecture de tout ça à la lumière de ce que j'ai appris au cours de ces derniers trimestres...
C'est plus simple en écrivant une string uid dans le fichier
Heu attends ton uid est une string ? Pourquoi ce n'est pas un NSUInteger plutôt ? Les comparaisons entre entiers sont carrément plus rapides que les comparaisons entre chaà®nes, donc tu devrais y gagner sur ce point
Heu attends ton uid est une string ? Pourquoi ce n'est pas un NSUInteger plutôt ? Les comparaisons entre entiers sont carrément plus rapides que les comparaisons entre chaà®nes, donc tu devrais y gagner sur ce point
Parce que si c'est un entier je devrais garder une variable globale pour l'incrémenter, m'assurer de l'atomicité lors de l'attribution et, idéalement, vérifier qu'il n'a pas déjà été attribué au cas où j'aurais fait le tour du compteur. Bref, coder et risquer d'oublier des cas limites. Alors qu'avec [tt][[NSProcessInfo processInfo]globallyUniqueString][/tt] je suis assuré par Apple de ne pas avoir de doublons et tout tient en une ligne de code.. Surtout qu'à l'usage ça ne semble pas pénalisant, ça m'a paru plus simple et donc plus sûr..
Réponses
Apple déconseille de commencer par Core Data et après avoir tâté de la migration de modèles j'ai préféré aussi !
C'était à mes débuts, maintenant que je me sens plus à l'aise je pense que je passerais à Core Data quand le besoin s'en fera sentir.
En fait je n'avais pas encore mis d'uid parce que NSKeyedArchiver permet de stocker et retrouver toutes les liaisons entre les objets mais les factures sont à part. Les fichiers qui les constituent sont manipulés souvent par l'autre application, c'est plus simple de les créer à partir de chaque lancement de l'application ou de les recréer si le fichier a changé que d'archiver des objets qui les représenteraient mais que je devrais synchroniser à chaque événement. Avant l'uid je gardais une référence de chaque fichier créé depuis une ordo dans un tableau membre de l'ordo et au rebours je cherchais dans les tableaux de toutes les ordos celui qui contenait la référence à la facture sur le disque pour retrouver l'ordo correspondante.
C'est plus simple en écrivant une string uid dans le fichier et pour gagner encore en rapidité j'ai testé les blocks et les predicates, avant j'utilisais seulement les predicates.
C'était sensiblement plus long mais avec l'uid c'est redevenu plus qu'assez rapide aussi je vais me donner encore un peu de temps avant de passer à Core Data et de repenser à l'architecture de tout ça à la lumière de ce que j'ai appris au cours de ces derniers trimestres...
Parce que si c'est un entier je devrais garder une variable globale pour l'incrémenter, m'assurer de l'atomicité lors de l'attribution et, idéalement, vérifier qu'il n'a pas déjà été attribué au cas où j'aurais fait le tour du compteur. Bref, coder et risquer d'oublier des cas limites.
Alors qu'avec [tt][[NSProcessInfo processInfo]globallyUniqueString][/tt] je suis assuré par Apple de ne pas avoir de doublons et tout tient en une ligne de code..
Surtout qu'à l'usage ça ne semble pas pénalisant, ça m'a paru plus simple et donc plus sûr..