1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Mountain Lion : la revue de Ars technica (11)

Là où Lion a trébuché, Mountain Lion regroupe et va de l'avant.

Par John Siracusa, 25 Juillet 2012


Core Data.

Core Data, introduit à l'origine dans Mac OS X 10.4 Tiger est le framework d'Apple pour la gestion graphique des objets et leur persistance. Il fournit à une application une manière de mettre en place la partie "modèle" du patron de conception model-view-controller .

Bien que Core Data ait de nombreuses caractéristiques, la plus importante (et la plus pertinente pour iCloud) est celle qui fournit un moyen pour les objets de persister même quand ils ne sont pas en mémoire, ou quand l'application qui les a créés a cessé de tourner. Il n'est pas surprenant qu'il fasse cela en écrivant les objets sur le disque.

Les détails de ce processus sont largement cachés aux développeurs par le framework Core data. Il y a en fait quelques choix peu nombreux pour le mécanisme de stockage mais la plupart des applications qui envisagent de gérer une grosse quantité de données ont utilisé un élément de sortie basé sur SQLite.

iCloud, et le besoin qui l'accompagne d'un accès simultané à des données d'appareils multiples entraîne des complications importantes au processus déjà compliqué de gestion du graphe des objets persistants.

Bien que Core Data stocke l'information dans des fichiers, les techniques de détection et de résolution de conflit basées sur les versions de fichiers utilisées pour le stockage d'un document iCloud ne conviennent pas pour Core Data. Les fichiers créés sur le disque comme élément de stockage d'un objet persistant de Core Data ne peuvent pas être mises en versions, et associés comme des fichiers de documents normaux. Et rappelez-vous, le mécanisme effectif de stockage est supposé être un détail de mise en place qui n'est pas visible du développeur, de toute façon.

A la place, quand Core Data est utilisé avec iCloud, les conflits sont gérés sur la base des enregistrements. Par exemple, un carnet d'adresses créé en utilisant Core Data peut stocker l'information de centaines de personnes en utilisant un petit nombre de gros fichiers de données sur le disque, mais le système de détection de conflit considèrera l'information de contact de chaque personne comme un enregistrement individuel.

Comme avec le stockage de document, iCloud va détecter les conflits, et choisit automatiquement un "gagnant". Core Data va une étape plus loin et fournit automatiquement une fusion triple des enregistrements. Il peut procéder ainsi parce que, à la différence de l'API de stockage de document, Core Data a une connaissance profonde de la structure des données qu'il enregistre. Il gère des enregistrements, des champs, et des relations plutôt que des objets binaires opaques.

Les applications reçoivent des notifications de changements quand elles deviennent disponibles sur le nuage. Elles peuvent choisir comment prendre en compte ces changements, éventuellement en utilisant une logique de fusion plus complexe. La même chose intervient pour des enregistrements dupliqués, quand la même information a été ajoutée à partir de multiples appareils. En réponse à l'assignation d'ID d'un enregistrement Core Data, deux enregistrements "identiques" peuvent sembler distincts. C'est à l'application de décider s'ils sont effectivement semblables (par exemple le premier et le dernier mot sont les mêmes dans les deux enregistrements) et comment gérer la situation.

Comme vous pouvez l'imaginer, les bases de données Core Data peuvent devenir énormes. Une fois encore, la connaissance par Core Data de la structure des données vient à la rescousse, et permet de formuler et de transmettre seulement les modifications incrémentales de données sur le réseau. De la même façon, l'information explicite de Core Data sur le schéma de données permet à iCloud de dominer des changements incompatibles (par exemple des données entrées dans une nouvelle version d'application, qui n'ont pas leur place dans le schéma de données de la version précédente) et de ne les envoyer que quand le schéma sur l'appareil récepteur est compatible.

Vue d'ensemble sur iCloud

Pourquoi s'embêter à décrire ces trois mécanismes différents du stockage des données pour iCloud ? La première raison, est de mettre en lumière la quantité de travail qu'Apple a accomplie pour rendre le stockage des données dans le nuage plus facile pour les développeurs. Les trois systèmes de stockage différents cherchent à fournir tout juste le bon degré de sophistication pour la tâche en cours. Avoir à se colleter avec quelque chose d'aussi complexe que Core Data simplement pour stocker quelques préférences utilisateur serait idiot. Et ni le système primitif de stockage par valeur de clé ni le moteur de base de données de Core Data n'est bien adapté au stockage traditionnel de document.

Ces divers frameworks iCloud et les démons qui leurs sont associés gèrent aussi tous les détails gênants comme de savoir si une connexion de réseau est disponible, ou quand un appareil a changé de mode de connexion (par exemple s'il est passé de WiFi à 3G), et propagent les modifications même quand les applications ne tournent pas, tout en réduisant l'utilisation de bande passante en coupant les données en petits blocs, et en ne transmettant que les morceaux qui ont changé.

En dépit de tout cela, croyez-moi si je vous dit que cette brève vue d'ensemble des trois façons de stocker des données en utilisant iCloud ne fait que gratter la surface des problèmes qui se posent. Pour donner seulement un exemple auquel vous pouvez n'avoir pas pensé, que se passe-t-il quand un utilisateur sort d'un compte iCloud et rentre dans un autre pendant qu'une application tourne ? Et que se passe-t-il si l'application était en cours de notification à ce sujet, et en train de gérer la fusion de certaine données modifiées dans le nuage ?

Le nombre de manières dont les choses peuvent tourner terriblement mal pour des applications utilisant iCloud est astronomique. Apple a fait un travail qui mérite le respect en créant les APIs de stockage de données d'iCloud et le services iCloud lui-même, mais même si on suppose que ces choses là sont sans bogues, c'est encore du ressort des développeurs d'applications d'utiliser correctement ces nouvelles APIs.

Tout cela est vrai de tout nouveau framework complexe, mais cela mérite un respect particulier dans le cas de iCloud du fait de l'étendue du service. Comme nous le verrons dans la section suivante, Apple pousse très fort iCloud dans Mountain Lion.