Tout d'abord, si vous êtes un développeur iOS enregistré, vous devriez avoir accès aux sessions de la WWDC 2010. Une de ces sessions couvrait un peu de ce dont vous parlez : "Session 117, Building a Server-driven User Experience". Vous devriez être en mesure de Retrouvez-le sur iTunes .
Une combinaison intelligente de REST / JSON / Core Data fonctionne comme un charme et constitue un énorme gain de temps si vous prévoyez de réutiliser votre code, mais elle nécessite des connaissances sur HTTP (et des connaissances sur Core Data, si vous voulez que vos applications soient performantes et sûres).
La clé est donc de comprendre REST et Core Data.
-
Comprendre REST signifie comprendre les méthodes HTTP (GET, POST, PUT, DELETE, ...HEAD ?), les codes de réponse (2xx, 3xx, 4xx, 5xx) et les en-têtes (Last-Modified, If-Modified-Since, Etag, ...).
-
Comprendre le Core Data signifie savoir comment concevoir votre modèle, établir des relations, gérer les opérations qui prennent du temps (suppressions, insertions, mises à jour), et comment faire en sorte que les choses se passent en arrière-plan pour que votre interface utilisateur reste réactive. Et bien sûr, comment faire des requêtes locales sur sqlite (par exemple, pour récupérer à l'avance les identifiants afin de pouvoir mettre à jour les objets au lieu d'en créer de nouveaux une fois que vous avez obtenu leurs équivalents côté serveur).
Si vous envisagez de mettre en œuvre une API réutilisable pour les tâches que vous avez mentionnées, vous devez vous assurer que vous comprenez REST et Core Data, car c'est là que vous ferez probablement le plus de codage. (Les API existantes - ASIHttpRequest pour la couche réseau (ou toute autre) et toute bonne librairie JSON (ex. SBJSON ) pour l'analyse syntaxique fera l'affaire.
Pour qu'une telle API soit simple, il faut que votre serveur fournisse un service RESTful et que vos entités possèdent les attributs requis (dateCreated, dateLastModified, etc.) afin que vous puissiez créer des requêtes (facilement réalisables avec ASIHttpRequest, qu'il s'agisse de GET, PUT, POST, DELETE) et ajouter les en-têtes Http appropriés, par exemple pour un GET conditionnel : Si-Modifié-Depuis.
Si vous vous sentez déjà à l'aise avec les données de base, que vous savez manipuler JSON et que vous pouvez facilement effectuer des requêtes HTTP et gérer les réponses (là encore, ASIHttpRequest est très utile, mais il en existe d'autres, ou vous pouvez vous en tenir aux classes NS d'Apple de plus bas niveau et le faire vous-même), il vous suffit de définir les bons en-têtes HTTP pour vos requêtes et de gérer les codes de réponse HTTP de manière appropriée (en supposant que votre serveur soit REST).
Si votre objectif principal est d'éviter de mettre à jour une entité Core-Data à partir d'un équivalent côté serveur, assurez-vous simplement d'avoir un attribut "last-modified" dans votre entité, et faites un GET conditionnel au serveur (en définissant le Http-Header "If-Modified-Since" à la date "last-modified" de votre entité. Le serveur répondra avec le Status-Code 304 (Not-Modified) si la ressource n'a pas changé (en supposant que le serveur est REST-ful). Si elle a changé, le serveur définira le Http-Header "Last-Modified" à la date de la dernière modification, répondra avec le Status-Code 200 et livrera la ressource dans le corps (par exemple, au format JSON).
Donc, comme toujours, la réponse à votre question est probablement "ça dépend". Cela dépend surtout de ce que vous souhaitez mettre dans votre couche de données de base/de repos réutilisable et polyvalente.
Pour vous donner des chiffres : Il m'a fallu 6 mois (sur mon temps libre, à un rythme de 3 à 10 heures par semaine) pour que le mien soit là où je voulais qu'il soit, et honnêtement, je suis encore en train de le remanier, de le renommer, de le laisser gérer des cas d'utilisation particuliers (annulation de demandes, retour en arrière, etc.) et de fournir des rappels à grain fin (accessibilité, couche réseau, sérialisation, sauvegarde des données de base, etc. Mais c'est assez propre, élaboré et optimisé et, je l'espère, correspond aux besoins généraux de mon employeur (une place de marché en ligne pour les petites annonces avec plusieurs applications iOS). Ce temps a inclus l'apprentissage, les tests, l'optimisation, le débogage et le changement constant de mon API (d'abord en ajoutant des fonctionnalités, puis en les améliorant, puis en les simplifiant radicalement, et en les déboguant à nouveau).
Si le délai de mise sur le marché est votre priorité, il est préférable d'adopter une approche simple et pragmatique : Ne vous préoccupez pas de la réutilisabilité, gardez simplement les enseignements à l'esprit et refactorez dans le projet suivant, en réutilisant et en corrigeant le code ici et là. Au final, la somme de toutes les expériences peut se matérialiser par une vision claire de la façon dont votre API fonctionne et de ce qu'elle fournit. Si vous n'en êtes pas encore là, n'essayez pas de l'inclure dans le budget du projet et essayez simplement de réutiliser le plus possible d'API tierces stables.
Désolé pour la longueur de la réponse, j'avais l'impression que vous vous lanciez dans quelque chose comme la construction d'une API générique ou même d'un framework. Ces choses demandent du temps, des connaissances, de l'entretien et un engagement à long terme, et la plupart du temps, c'est une perte de temps, car on ne les termine jamais.
Si vous souhaitez simplement gérer des scénarios de mise en cache spécifiques pour permettre une utilisation hors ligne de votre application et minimiser le trafic réseau, vous pouvez bien sûr implémenter ces fonctionnalités. Il suffit de définir les en-têtes if-modified-since dans votre requête, d'inspecter les en-têtes last-modified ou les etags, et de conserver ces informations de manière persistante dans vos entités persistet afin de pouvoir les resoumettre lors de requêtes ultérieures. Bien sûr, je recommande également de mettre en cache (de manière persistante) des ressources telles que des images localement, en utilisant les mêmes en-têtes HTTP.
Si vous avez le luxe de modifier (de manière REST) le service côté serveur, alors tout va bien, à condition de bien l'implémenter (par expérience, vous pouvez économiser jusqu'à 3/4 du code réseau/parsing côté iOS si le service se comporte bien (renvoie les codes d'état HTTP appropriés, évite les vérifications de nil, les transformations de nombres à partir de chaînes, de dates, fournit des lookup-id au lieu de chaînes implicites, etc...).
Si vous n'avez pas ce luxe, soit ce service est au moins REST-ful (ce qui aide beaucoup), soit vous devrez corriger les choses côté client (ce qui est souvent pénible).
