Synchronisation iCloud
muqaddar
Administrateur
Un petit point fait par MacGénération.
http://www.macg.co/unes/voir/132044/icloud-reste-un-casse-tete-pour-les-developpeurs
Cela vaut le coup d'oeil, et certaines réactions aussi...
/evil.gif' class='bbc_emoticon' alt='>:D' />
http://www.macg.co/unes/voir/132044/icloud-reste-un-casse-tete-pour-les-developpeurs
Cela vaut le coup d'oeil, et certaines réactions aussi...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Mais sur Twitter, j'ai lu énormément de messages de développeurs chevronnés allant dans ce sens. iCloud semble être un vrai casse-tête et surtout pas fiable.
A part Parse ou une solution perso mêlant JSON et son propre serveur, je ne vois pas trop.
CoreData c'est de la balle, surtout avec MagicalRecord.
C'est l'utilisation d'iCloud pour partager la base CoreData qui est foireuse, car iCloud est pensé pour partager/sauvegarder des documents/fichiers, pas une base de données.
J'ai jamais testé le couple "CoreData sur iCloud" donc je ne peux pas tester, mais ça ne m'étonne pas que ça puisse être catastrophique. Par contre même si ce problème iCloud+CD est désastreux et qu'il faut le faire savoir pour que ça change, faudrait pas que ça vire en "iCloud c'est nul" ou en "CoreData c'est nul" hors contexte en n'en citant qu'un seul sans le 2e, alors qu'indépendement ce sont plutôt de bons produits dans l'ensemble.
Du coup, ça fonctionnerait un peu à la manière des bases NoSQL.
C'est vrai. Mais pour parler de Core Data, il est vrai aussi que les derniers ajouts à ce framework ne sont pas très heureux. D'ailleurs, la notion de parent/child context n'est quasiment pas documentée (!), il n'y a qu'un malheureux sample code Apple sur la synchro Core Data et iCloud et, si je me souviens bien, UIManagedDocument n'y est même pas utilisé.
L'impression globale est une mise à disposition (depuis iOS 5) de nouvelles API pas finies.
J'ai spécialement créé des projets pour tester ces nouvelles APIs et me suis arraché les cheveux : deadlocks, ID permanent impossible à récupérer... et je n'ai pas été le seul dans ce cas là .
À part ça, Core Data rempli parfaitement sa fonction et je le met en oeuvre avec bonheur au quotidien.
Ca me semble être un processus long et fastidieux à faire soi-même. Un exemple est la société Cultured Code qui a développée sa propre techno de synchro avec Core Data (car, si je ne dis pas de bêtise, leur appli. Things utilise Core Data). Ils ont été raillés pendant longtemps car leur projet n'avançait pas. Finalement ils n'ont pas eu tord de s'affranchir d'iCloud : leur système semble maintenant fonctionner à merveille mais le chemin à parcourir fut long.
ça marche globalement, mais ce n'est pas l'idéal.
Je veux essayer de faire mieux pour la V2.
Mais surtout, j'utilise CoreData à travers MagicalRecord dans le gros projet (le datamodel est conséquent, et le nombre d'écrans indépendants avec des contextes indépendants) et ce système parent/child justement qui m'arrange bien, et en plus est très puissant.
http://inessential.com/2013/03/27/why_developers_shouldnt_use_icloud_sy
Justement... MagicalRecord a été patché suite à un bug concernant les ID permanents et les child context.
Je n'ai pas inventé les problèmes rencontrés. Et je ne dénigre absolument pas Core Data. J'utilise les child context mais, comme pour MagicalRecord, suis obligé d'ajouté quelques lignes pour que ça fonctionne vraiment (avec une baisse de perfs du coup).
Un certain nombre de bugs ont été remontés chez Apple mais il y a semble-t-il très peu de retour de leur part.
p.s. Hé non, je n'utilise pas MagicalRecord, pas taper. :-)
Sur GitHub, il y a la classe TICoreDataSync.
https://github.com/nothirst/TICoreDataSync
A voir.....
Donc oui il y avait ce bug, mais Apple ne fait pas la sourde oreille et les corrige au fur et à mesure.
Je dis pas qu'il n'y a pas de bug du tout sur ce système de childContext & co, il y a sans doute un ou 2 trucs par ci par là qui ont encore des améliorations à faire, mais ça reste quand même plutôt bien ficelé et quand il y a des bugs suite à ces nouveaux systèmes dans CoreData, jusque là ils sont pris en compte et corrigés.
Donc non, ce n'est vraiment pas le sujet de ce grondement sur la toile, le sujet de mécontentement c'est pas CoreData, c'est la gestion de CoreData sur iCloud pour synchroniser des bases (mais y'a le même problème si tu utilises une base SQLite, au passage)
Le fait d'avoir très peu de visibilité sur le fonctionnement de CoreData m'a toujours rebuté. Son utilisation est simple, mais j'en ai juste peur
Pouvoir ouvrir une base de données CoreData avec un éditeur de BdD comme SQLite Data Browser m'a beaucoup rassuré. Non seulement, c'est standard, mais en plus c'est propre.
Franchement j'aurai dû mal à m'en penser maintenant.
Si je veux ! :-)
Je fais même de la synchro sur une base données en MySQL via un webservice en XML avec injection de data depuis plusieurs iPhone avec gestion de conflit qui repose sur des UUID pour les enregistrements.