Un framework pour exposer une base CoreData via une API REST
yoann
Membre
Pour ceux que cela peut intéresser, je suis actuellement en train de travailler sur un framework libre (licence Apache v2.0) qui a pour objectif de simplifier l'utilisation en réseau d'une base de données CoreData.
Ceux qui se sont déjà prêtés au jeu de CoreData en réseau (avec des objets distribués ou pas) savent que ça peut être cool comme outil bien que plus réservé aux développeurs Mac.
Ce framework bien qu'assez avancer pour la partie serveur est encore loin d'être parfait dans ma vision des choses.
Actuellement, le serveur est viable bien qu'il ait besoin de stress test pour être vraiment validé.
Côté client il me reste encore beaucoup de boulot pour obtenir quelque chose d'assez transparent.
Si certains veulent forker et proposer des améliorations, n'hésitez pas !
https://github.com/ygini/ObjectiveREST
Ceux qui se sont déjà prêtés au jeu de CoreData en réseau (avec des objets distribués ou pas) savent que ça peut être cool comme outil bien que plus réservé aux développeurs Mac.
Ce framework bien qu'assez avancer pour la partie serveur est encore loin d'être parfait dans ma vision des choses.
Actuellement, le serveur est viable bien qu'il ait besoin de stress test pour être vraiment validé.
Côté client il me reste encore beaucoup de boulot pour obtenir quelque chose d'assez transparent.
Si certains veulent forker et proposer des améliorations, n'hésitez pas !
https://github.com/ygini/ObjectiveREST
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Non dans le sens ou RESTKit propose un client REST relié à du CoreData pour le cache. Ce que je vise ici c'est une mise en réseau d'une base CoreData existante. Tu as une application monoposte qui utilise du CoreData, tu veux passer à un mode client serveur, actuellement soit tu joue avec des Distribued Object et c'est bancale, soit tu vire tout CoreData et tu passe en SQL...
L'idée derrière ObjectiveREST c'est de partir d'un modèle CoreData peu ou pas modifié et de l'exposer via HTTP/S pour en faire un serveur.
Une fois que je suis satisfait du serveur la phase 2 sera le client. Tu as ta même application monoposte et sa version serveur. Proposer quelque chose qui se sert du modèle CoreData pour aller récupérer les données sur le serveur sans rien avoir à configurer tout en proposant un cache local géré automatiquement.
L'avantage en partant de CoreData c'est qu'on retire toute la complexité de gestion d'une base de donnée et d'un mapping d'objet manuel de RESTKit.
Pour ma part, je n'ai jamais touché à CoreData (et j'ai mes raisons), mais ça viendra p-e un jour !
Je viens de finir une nouvelle version de mon framework ObjectiveREST. C'est toujours à l'état de PoC mais j'ai ajouté un client, un custom AtomicStore pour CoreData qui permet de lire directement les données du serveur tout en ayant du CoreData en mémoire coté client.
La démo que je fournis est un player MP3 que j'utilisais pour des cours. J'ai simplement repris cette application monoposte, sur le serveur j'ai donnée à ObjectiveREST mon MOC et sur le client, j'ai juste changé le type de persistantStore son URL.
Pour les infos c'est toujours sur https://github.com/ygini/ObjectiveREST
Je viens de finir mon app ou toutes les données sont enregistrées dans une base Core Data et j'ai été attiré par un cloud pour la version online.
Cependant cette techno pourrait certainement éviter de passer par un cloud non ?
La base pourra être stocké par exemple sur un iphone "père" ? et distribuer un "identifiant" aux iphone voulant profites de la bdd?
Serait t'il aussi possible de pouvoir receptioner les nouvelles entrées a la base de donné directement sur tout les iphone mais sans avoir besoin de "refresh"
A moins que le frame soit plus dédié au partage de donnés statiques? et pas a des entités mises a jours.
Théoriquement je supporte la lecture écriture (j'ai juste un bug actuellement sur les relations en to-many).
Aussi il faut que je réécrive le coté client avec un NSIterativeStore au lieu d'un NSAtiomicStore.
Je te donne plus d'info dans la semaine prochaine si tu veux.
Par contre prévois-tu une gestion des données de manière asynchrone.
Je m'explique .
Je travaille sur la base de donné et je voudrais que les données se mettent a jour
(par exemple dans une TableView: la page se "recharge" automatiquement et UNIQUEMENT si il y a une nouvelle entrée pour après display la row et etc...)