Recommandation de cadre pour le développement d'applications iPhone/iPad distribuées

Question

Existe-t-il une infrastructure d'application distribuée (commerciale aussi) qui prend en charge l'iPhone/iPad?

Ce que je suis à la recherche dans le cadre:

• me permet de vous concentrer sur la logique de l'application
• Je n'ai pas le code de programmation du réseau « bas niveau » (je l'ai fait trop de fois que je ne veux pas le faire à nouveau = p)
• Faudrait-il maintenir (populaire serait activement agréable)

Fondamentalement, je peux alors développer plus rapidement.

Nous prévoyons de développer une application client/serveur TCP/IP souple en temps réel où de nombreux clients iPhone/iPad (30+) sont connectés à un seul serveur sur un réseau local. Le serveur exécutera très probablement Windows (à moins que le framework ne le supporte pas).

J'ai regardé autour et je vois: (semble encore assez brut)

• MonoTouch WCF
• RemObjects (Mono + Objective-C)
• Cocoa Distributed Objects
• ZeroC Ice Touch (Objective C)
• RakNet (? Inclus car il mentionne l'iPhone, mais devra utiliser C++)
• Bien sûr, il y a aussi la possibilité d'utiliser la plaine ancienne MonoTouch System.Net.Sockets
• Ou, CFNetwork (je ne l'intention d'utiliser celui-ci)

Je suis toujours à déterminer si vous souhaitez utiliser Objective-C ou MonoTouch , mais en se penchant vers MonoTouch puisque nous obtiendrons le framework .NET, et ne serons pas uniquement liés au monde Mac.

S'il vous plaît n'hésitez pas à commenter si j'ai ajouté quelque chose qui n'est pas lié à ma question --- Je suis nouveau sur le monde iPhone/iPad.

Answer 1

Nous avons utilisé WCF/Monotouch avec beaucoup de succès - il y a des zones du f/travail qui ne sont pas 100% mais pour la plupart des cas, vous devriez trouver le travail avec WCF sur monotouch un jeu d'enfant. La possibilité de partager toutes nos données de synchronisation, de modèle, de tests, etc entre monodroid et monotouch et wm7 est vraiment cool (avec un peu de travail - c'est facile - vous aurez besoin de gérer plusieurs fichiers prj).

Veillez à gérer correctement les appels aux services wcf, conservez-les au minimum, gardez l'archétecture simple. Nous nous sommes retrouvés avec un dto assez complexe pour minimiser le nombre d'appels aux services wcf pour synchroniser les données - cela en valait la peine car le temps nécessaire pour synchroniser un appareil à partir de zéro est maintenant une fraction de ce qu'il était. L'utilisation de SSL pour communiquer avec le serveur est un PITA mais je pense que c'est plus un cas de la façon dont Apple l'a géré.

Answer 2

Vous devez être un peu plus explicite sur vos besoins. Si vous n'avez besoin que d'une sérialisation d'objet (déshydratation/hydratation) via l'API REST, tout ce qui prend en charge POX ou JSON fonctionnera parfaitement pour vous. Cependant, si vous avez besoin d'invocation de méthode de type RPC, d'authentification, de cryptage/signature numérique, de transactions, etc., vous avez besoin de l'un de ces frameworks listés ci-dessus. Si vous avez besoin d'un framework, personnellement, je pencherais vers le WCF MonoTouch, car il vous donne la possibilité de déplacer votre client vers d'autres plateformes plus tard (Windows Phone 7 par exemple). Là encore, comme vous l'avez dit, c'est un peu difficile en ce moment, et si l'équipe Mono décide à l'avenir de ne pas avoir les ressources nécessaires pour le maintenir, vous devrez peut-être passer à un autre cadre. Bien sûr, il y a aussi l'inconvénient que vous devez utiliser MonoTouch pour votre application et que vous ne pouvez pas utiliser Objective-C. Accordé, avec les récents changements dans l'accord de développeur iOS, ce n'est pas vraiment un problème, mais il est toujours quelque chose à garder à l'esprit.

(Disclaimer: Je travaillais dans l'équipe de WCF de Microsoft, donc je suis biaisé vers le produit lui-même)

L'autre option, je pencherais pour, serait cacao objets distribués. Cependant, ce serait mon choix si le serveur fonctionne aussi sur OS X. Je sais qu'il y a Bonjour pour Windows, mais je doute qu'il soit optimisé pour les scénarios de serveur, et je ne sais pas non plus à quel point l'implémentation RPC d'Apple est riche. pour la plate-forme Windows. Donc, je ne resterais avec la technologie d'Apple que si je construis exclusivement pour la plate-forme d'Apple. Notez que WCF et les objets distribués vous donneront des fonctionnalités de type RPC, mais ils ne vous aideront pas avec des scénarios particuliers. Si vous avez besoin d'un niveau d'abstraction encore plus élevé, par exemple si vous avez besoin d'informations de présence ou d'un chat multi-utilisateur, vous devrez toujours les implémenter vous-même. Il pourrait être utile à ce stade de regarder les cadres qui fournissent ces fonctionnalités pour vous. Un exemple serait RakNet (que vous avez énuméré ci-dessus), qui résume le niveau d'accès à distance et construit des fonctionnalités supplémentaires par-dessus.

Answer 3

Vous pouvez utiliser les tampons de protocole Google pour implémenter RPC, mais vous devrez quand même effectuer une programmation réseau pour le transport de vos messages. Il prend en charge la génération d'interface pour C++, Java, Python et Objective-C et .NET afin que vous puissiez créer un seul ensemble de messages RPC et obtenir du code pour travailler avec eux pour presque n'importe quelle plate-forme mobile. Couche de transport sur vos plates-formes mobiles, vous devrez vous implémenter.

http: // code.google.com/apis/protocolbuffers/ - page principale Protobuf (C++, Java, Python) http: // code.google.com/p/protobuf-net/ - Protobuf .NET mentionné dans l'un des commentaires http: // code.google.com/p/metasyntactic/wiki/ProtocolBuffers - Protobuf pour Obj-C

Answer 4

vous pouvez utiliser JSON tactile + Vitche PHP Emission Framework qui fournit tout côté serveur dont vous avez besoin. Vous pouvez également utiliser ce cadre pour accéder aux services SOAP (WCF, Axis, etc.) existants.