À la découverte de Core Data et CloudKit, la gestion native des données dans les apps
Quand on conçoit une app, on doit souvent gérer et stocker des données, que ce soit sur l’appareil de l’utilisateur ou en ligne. Pour répondre à ces problématiques, Apple propose deux solutions pour les développeurs : Core Data et CloudKit. Le binôme est totalement intégré aux systèmes d’exploitation du constructeur et suit chaque année les évolutions technologiques.
Dans cet article, nous allons présenter rapidement chaque framework et leurs avantages.
Core Data : la meilleure solution fournie par Apple pour stocker des données
Core Data est apparu avec Mac OS X 10.4 (Tiger), puis il est arrivé sur iPhone avec iOS 3, avant d’être intégré à watchOS 2 et tvOS 9 en 2015 afin de compléter la panoplie. Il est désormais disponible sur tous les appareils conçus par Apple.
À quoi sert Core Data ? Pour le savoir, prenons un exemple concret : vous souhaitez concevoir un gestionnaire de projet et de tâches sur iPhone. Si vous ne stockez les tâches que dans la mémoire vive, les informations disparaîtront à chaque fois que l’app sera entièrement fermée. Il faut stocker ces données dans l’espace de stockage de l’appareil, c’est ce que l’on appelle la persistance des données dans le jargon des développeurs.
Plusieurs solutions existent pour ce stockage à long terme. Le moyen le plus naturel de stocker des informations est d’utiliser des fichiers. À chaque fois, l’app va encoder et décoder les données dans une version standardisée qui peut être stockée dans un fichier, par exemple au format JSON.
Ahhh Core Data… qu’est-ce que j’ai pu m’amuser avec. Excellent framework.
Merci pour l'article.
En revanche, par rapport à des développements ultra modestes sous Windows ou linux, j'adore sqlite mais il est limité mono-utilisateur et à chaque fois que j'essaie de développer avec une base de donnée "standard" mysql ou postgresql je galère sous mac. En php, Delphi, Visual Basic, etc... pas de soucis mais avec Swift à chaque fois j'ai l'impression de devoir apprendre une montagne bien trop haute par rapport à mes connaissances et besoins (des années passées sans développer un truc un peu costaud n'arrange rien, sur ce point j'ai vraiment l'impression de régresser depuis mon passage tant désiré sous mac).
Autrement dit, si par hasard l'idée d'un article sur une passerelle "directe/odbc" entre swift et un autre SGBD vous trotte dans la tête, merci de ne pas hésiter.
@cv21
Au 1er abord je dirais qu’il te faut une api rest entre les 2 (dans le langage de ton choix).
J’ai n’ai pas de grosse expérience sur les techno mobile, mais une connexion direct au SGBD ne semble pas prévu pour (chiffrement connexion, port utilisé, deserialization de tes modèles, etc…), en tout cas loin d’être la voie la plus simple.
@cv21
Sur Mac, on utilise en général Core Data pour les apps.
Si plusieurs ordinateurs doivent partager une base de données, on peut utiliser :
PostgreSQL :
https://github.com/vapor/postgres-nio
MySQL :
https://github.com/vapor/mysql-nio
MongoDB :
https://github.com/mongodb/mongo-swift-driver
CoreData < Realm
CloudKit, un des éléments qui rendra l'ouverture à d'autres app stores plus compliqué si je ne me trompe pas...
@Link1993
Ça fait partie du package. Pas d’App Store = pas de CloudKit.
Aujourd’hui, on peut utiliser CloudKit hors App Store si on a une app. Par exemple, pour proposer une version web. Mais l’expérience utilisateur est moins bonne, forcément.
Le zéro connexion pour synchroniser les données est un énorme levier offert aux développeurs. Créer un compte, c’est toujours pénible.
@Link1993
Nul doute qu’Apple saura trouver la parade et faire payer ce stockage qui aujourd’hui est compris dans les 99€/an. Beaucoup réaliseront que ça leur coûtera plus que 99/€, parce que le stockage en ligne, ça revient vite cher quand on a du volume à mettre en place.
Mais bon, tout ça, la plupart des détracteurs l’ignorent complètement. Ils ne voient que les 30% et le bénéfice que fait Apple, du coup, c’est trop cher.
Ils n’ont pas su tort que ça, puisque Apple est passé à 15%, mais ça n’est clairement pas objectif.
@Nesus
Et clairement, l'app store a ses limites arbitraires, où je comprends du coup que les développeurs en ai marre de cette plateforme (typiquement, le paiement, surtout s'ils n'utilisent pas les outils d'Apple à côté), et le type d'application autorisé, mais ce sont en fait les seuls critiques de cette plateforme finalement. Des trucs qu'Apple pourrait facilement relâcher.
@Link1993
En tant que développeur, ça ne me pose aucun soucis qu’Apple gère les taxes des différents pays, le paiement via canal unique, le remboursement des achats, le support technique, le juridique et tout ce qu’un petit développeur ne peut clairement pas s’offrir.
Sans ça, on a accès à un marché très restreint, comme autrefois.
@Link1993
Sur le changement d’avis de l’équipe de validation d’Apple, je suis moyennement d’accord. Il y a beaucoup de délires sans logique, mais c’est aussi une équipe qui change rapidement d’avis. Du coup, ça l’avantage de l’inconvénient. Avec une bonne raison, ça fini par passer.
Par contre pour le paiement, je ne suis absolument pas d’accord. Si Apple arrête le système actuel, on va se retrouver à devoir donner nos codes à l’ensemble des développeurs. Et vu le nombre de vols, de hack, d’erreurs humaines qui pullulent sur les coordonnées bancaires, je préfère que ce soit une entreprise qui gère. Une qui a sa réputation en jeu et les poches largement assez plein pour éviter au maximum les erreurs (ce qui ne nous met pas à l’abris pour autant).
@Nesus
N'étant pas dev, je suis sur les témoignages. Et c'est vrai qu'apparemment, quand ça marche, c'est nickel, et ils sont sinon ouvert. J'ai quand même entendu quelques rares témoignages (typiquement, l'équipe de Floatplane Club pour Linus Tech Tips) où ils ont galéré pour des bêtises.
Sinon, sur le payement, oui, je suis aussi d'accord avec toi, c'est pour ça que le bon compromis à mon avis, c'est d'avoir obligatoirement l'AppStore, et à côté, le paiement indépendant, pour que l'utilisateur ai le choix. Apple peut aussi proposer une interface générique qui doit s'afficher avant que le paiement s'effectue, qui peut être une autre solution.
Savez-vous s'il est possible de partager des données entre utilisateurs (qui se l'autorisent) avec CloudKit ?
Concrètement, Alice stocke des informations sur son application (dans votre exemple des projets et des tâches) et elle aimerait que Bob ait accès à toutes ou parties de ces informations (à un projet en particulier et ses tâches, par exemple). Est-ce que CloudKit permet de le faire ? Ou faudra-t-il passer par la mise en place d'une infrastructure serveurs pour gérer le partage (donc une API) et potentiellement le stockage des données partagées hors CloudKit du coup ?
@sigmanet15
Le partage entre utilisateurs est géré. Avec différents droits. C’est même automatiquement synchronisé avec Core Data dans iOS 15.
Un exemple de code est fourni :
https://developer.apple.com/documentation/cloudkit/shared_records/sharing_cloudkit_data_with_other_icloud_users
Ça reprend le même procédé que pour partager une note dans iOS par exemple. Ou un album photo.
@FloMo
Excellent ! Merci pour l'info.
Ce point-là est vraiment puissant pour les développeurs. Il leur évite justement tout le travail de backend, et les frais en découlant !
@sigmanet15
Sachant que les URLs de partage peuvent être personnalisées pour proposer un onboarding qui va permettre de présenter l’app avant de l’installer… ou bien proposer une app web qui utilisera CloudKitJS en alternative. Il me semble que c’est ce que font les apps comme Pages, Numbers et Keynote.
Q'appelez-vous données publique?
Mes flux rss synchronnisés sur iCloud, préférences d'apps, etc, sont toute des données privé non?
avez vous un exemple? ;)