Ce type de service web qui fonctionne le mieux avec iOS?
Je vais être la création d'une application pour iPhone et iPad qui permettra de garder une trace des appels de vente, les citations, photos et dessins pour les citations. Je suis toujours dans le concept de la phase de conception et je suis en train de lire sur les différentes façons de communiquer entre mon application et le service web. Bien évidemment puisque ce sera surtout utilisé sur les réseaux 3G ou ... de Bord, je veux un protocole efficace donc, ma réaction instinctive est de rester loin de XML en fonction des choses comme XML-RPC ou SOAP. Je voudrais utiliser PHP et MySQL sur le serveur et le plan sur l'utilisation de Données de Base sur iOS.
J'ai donc quelques questions spécifiques:
- Quel régime dois-je utiliser pour la performance?
- Quel régime dois-je utiliser pour la facilité de travailler avec sur le serveur?
- Quel régime dois-je utiliser pour la facilité de travailler avec sur iOS?
- Quel régime dois-je utiliser considérant l'ensemble du projet?
- Est à l'aide d'une base de XML schéma de mieux, en dépit de la surcharge du réseau? Pourquoi?
- Je suis intéressé à l'issue de cette discussion, je vais être face à la même situation plutôt vite.
- Si vous avez l'intention d'éviter XML, vous pouvez enquêter sur les JSON. Il y a bibliothèques pour manipuler du JSON en Objective-C.
- Je ne suis pas l'intention d'éviter XML, en fait de la lecture, je l'ai déjà fait j'aime RPC XML cependant, je suis conscient qu'il en coûtera sur la bande passante. Donc, je suis curieux de voir si le coût en vaut la peine à l'aide de XML ainsi que le type de système serait meilleur et le ou la plus facile.
- Ce n'est pas juste que XML est plus costaud que JSON, il est également plus difficile à analyser (mémoire, temps) que JSON sur l'appareil.
- Si les données est énorme alors l'objet jSon peut prendre beaucoup de mémoire sur l'appareil tandis que l'utilisation de certains analyseurs vous pouvez analyser uniquement des morceaux de code xml à la volée afin d'économiser de la mémoire sur l'appareil.
Vous devez vous connecter pour publier un commentaire.
Compte tenu de la façon dont vous avez posé plusieurs questions, vous avez probablement réaliser que l'ultime solution que vous utilisez sera une question d'équilibre entre des objectifs concurrents.
1: Vous devez définir la "performance" de mieux. Je suppose que vous faites allusion à la transmission sur le réseau de temps qui consiste à tenir serveur de latence faible et le nombre d'octets transmis faible. L'ultime est probablement un binaire fil de protocole qui a également été analysés pour la compressibilité et de la compression appliquée le cas échéant (par exemple, répété des chaînes ou des séquences). L'inconvénient de ce protocole est qu'il sera probablement plus difficile de code sur le serveur & client puisque vous ne serez pas en mesure d'utiliser le SDK de soutien pour les encodages, et, sauf si intelligemment conçu protocoles binaires ont tendance à être fragiles pour appuyer les futures modifications et d'extensions pour votre application.
En outre, vous devriez considérer comment vous définissez les transactions de votre protocole, même avec un codage efficace si votre protocole nécessite de nombreux allers-retours par rapport à un seul aller-retour, vous aurez toujours lent.
Enfin en fonction de la taille des données que vous envoyez, la charge d'un codage peut être négligeable par rapport à la taille des données.
Je vous recommandons d'adopter un format de codage normalisé qui peut être analysé avec la bibliothèque de support, ce qui réduit le champ des deux grammaires: XML ou JSON.
2: XML et JSON les deux sont bien pris en charge dans le serveur de cadres. Lors de l'utilisation de XML services, je recommande un RESTE de style motif qu'ils sont généralement faciles à construire et vous n'avez pas à se conformer à votre demande à quelqu'un d'autre de style.
Je voudrais rester à l'écart de services web basés sur SOAP, même si la construction peut être bien pris en charge (en particulier sur les plates-formes Windows), en raison de la complexité de faire un plein de SAVON à base d'analyser sur le client mobile est élevé et n'est pas bien pris en charge là. Je ne trouve pas généré automatiquement sérialisation d'un objet par WSDL compilateurs pour être un grand gagnant pour gagner du temps lors du codage, il est généralement assez facile de sérialiser un RESTE de style XML ou souvent même plus simple pour JSON.
3: iOS prend en charge un pare-SAX style XML parser, et il y a une variété de bibliothèques de classes qui prennent en charge en mémoire DOM mises en oeuvre avec des caractéristiques différentes et des niveaux de vitesse. Choisissez le meilleur pour vos besoins. Personnellement, je préfère TBXML qui est rapide, assez léger, et facile à programmer, mais parce qu'il ne permet pas de valider les schémas et c'est en mémoire de l'arbre, il n'est pas approprié dans certaines situations. Voici une fusillade de iOS XML performances de la bibliothèque.
Il y a plusieurs JSON bibliothèques disponibles pour iOS si vous avez autour de Google. Ou regardez dans cette réponse.
SAVON n'est pas bien pris en charge et il y a peu de choix de la bibliothèque. Vous pouvez toujours la main-d'analyser les réponses SOAP généré par un serveur, mais il est fragile à côté serveur, les modifications juridiques SAVON (par exemple, différents préfixes d'espace de noms) qui pourraient briser une codé en dur analyseur XML.
4: Difficile de répondre sans en savoir plus sur votre projet en détails, mais j'aimerais me pencher vers un JSON ou XML simple de codage basé sur parce que: les deux sont généralement faciles à programmer sur le client et le serveur, à la fois peut être fait avec une efficacité raisonnable sur le fil, et sont susceptibles d'être extensible pour l'avenir de l'app itérations.
JSON a des avantages d'être un peu plus simple à analyser, peut-être moins verbeux, et peut aussi être plus facile de re-tâche pour d'autres fins, telles que la création d'un client web Ajax sur le dessus de vos services.
5: XML vs JSON vs d'autres codages? Je pense que c'est une question de préférence personnelle. XML peut être plus auto-descriptif de JSON, mais est susceptible d'être plus de travail à analyser. JSON peuvent être réduits en raw octets et est facile à analyser. De nouveau le codage de surcharge peut être importante ou peut-être négligeable selon la taille de votre contenu. Aussi, vous pouvez appliquer une compression externe, en tout cas.
http://code.google.com/p/json-framework/C'est tellement simple à utiliser à la fois côté client et serveur.Mise à JOUR: iOS5 inclut désormais intégrée dans la prise en charge de JSON avec la nouvelle NSJSONSerialization classe.
Vous pouvez lire un tutoriel sur l'utilisation de JSON avec iOS5 ici:
http://www.raywenderlich.com/5492/working-with-json-in-ios-5