Je travaille avec une petite start-up avec le but de créer une application iPhone. Les programmeurs de notre équipe connaissent tous C et Java, mais nous n'avons aucune expérience OBJC / C # / iPhone - nous apprendrons quelque chose, peu importe quoi. Toutes les questions que j'ai vues sur ce sujet ont été du point de vue d'un programmeur C # entrant dans iOS, donc je n'ai aucune information sur les mérites relatifs de l'apprentissage de l'un ou de l'autre.
Donc, ce que je veux savoir, ce sont les mérites relatifs de C # et de l'objectif-C pour les nouveaux programmeurs, en ce qui concerne ces éléments:
En outre, écrire à MonoTouch a des avantages pour le développement inter-plate-forme avec Android?
4 Réponses :
Objectif C est un superset strict de C, donc si vous comprenez les caractéristiques de performance du code C compilé C sur bras, vous pouvez simplement utiliser ce sous-ensemble C avec lequel vous êtes familier, à l'exception de l'interface utilisateur IOS.
Il semble exister des rapports que les programmeurs de C ont commencé à se mettre à la hauteur des applications IOS d'écriture dans l'objectif C dans l'ordre de 2 semaines. Mais, bien sûr, apprendre de vastes cadres et API dans un processus d'apprentissage continu, quelle que soit la langue.
Si l'objectif de votre démarrage est de créer une application iPhone, vous devez évidemment apprendre que les applications iOS de langue sont construites avec, objectif-c. Votre équipe a déjà de l'expérience avec C, il convient donc de démarrer très facile. Les Big Nerd Ranch Books vous mèneront dans une semaine ou deux (je ne suis pas associé à Big Nerd Ranch, je pense juste qu'ils sont géniaux).
Je ne comprends pas pourquoi vous apportez monotouch, compte tenu de votre équipe n'a pas d'expérience C # /. NET. Il y a des tonnes d'autres cadres tels que MonoTouch, y compris Titane SDK (JavaScript), rubymotion (ruby), et ainsi de suite. Tous sont excellents, mais comme je le vois, ils sont principalement destinés à ceux qui possèdent de l'expérience avec leurs langues respectives. Ils vous permettent d'écrire des applications iOS à l'aide d'une langue que vous connaissez plus, mais avez les inconvénients suivants:
- (bool): (uiapplication *) Application DidfinishlaunchingwithOptions: (NSDictionary *) Launchoptions Méthode sur le lancement, mais vous devrez en outre vous rappeler comment Traduisez cela dans la méthode appropriée pour MonoTouch: Supprimage public Supprimez Bool SupplémentLanching (application uiapplication, options Nsdictionnaires) . Le SDK IOS est massif et la plupart des développeurs iOS comptent sur la documentation d'Apple pour une idée. Donc, vous examinerez les documents de l'API, écrit pour objectif-c et traduire des méthodes dans le cadre de votre choix.
- L'écosystème de l'objectif-c évolue constamment, avec de nouveaux projets cool tels que cocoapodes , Bwokoke , etc. Ceux-ci sont principalement développés avec Objective-C et Xcode à l'esprit. Les configurer pour travailler avec votre cadre de choix vous causeront presque invariablement plus de temps et de travail.
Les points ci-dessus m'ont généralement empêché de trop développer dans l'un de ces autres cadres. Ils sont tous très cool, mais leur principal mérite en adoption semble faciliter le développement des personnes ayant des compétences profondes en dehors de l'objectif-c ou permettant de développer une plate-forme inter-plate-forme pour les petites équipes sans ressources pour investir dans Android et programmeurs iOS (et Windows Phone). Espérons que les avantages l'emportent sur les coûts ci-dessus pour les adoptants.
En outre, écrire à MonoTouch a des avantages pour le développement inter-plate-forme avec Android?
Je suppose que ce serait. En effet, le est un avantage principal d'utiliser le cadre. Je ne suis pas sûr des cours de visualisation / contrôleur, car ceux-ci semblent être liés à uikit , mais la logique encapsulée dans vos modèles doit être assez facile à porter.
Longue histoire courte, je pense que vous et votre équipe devriez rester avec Objective-C pour le développement IOS.
Convenu que, généralement le meilleur pari, est objc (et vos raisons sont excellentes). J'ai un réel espoir pour Rubymotion compte tenu de mes enquêtes avec MacRuby (qui est en fait assez bonne OMI). Je n'ai pas encore vu de très bonnes expériences hors des réponses JavaScript, en particulier du titane. Utilisation de JavaScript signifie que vous êtes soumis à tous les maux de tête de UiWebView, et il y en a beaucoup. Et le titane que j'ai personnellement trouvé comme un maux de tête royal. Je recommanderais toujours objc sur JavaScript pour iOS; Il est plus rapide de se développer à Objc. Mais je porte un jugement sur Rubymotion; Cela pourrait être assez bon.
MacRuby est génial (dans le même temps que je déplore le triste état de Pyobjc) et Rubymotion semble très prometteuse. Il possède apparemment un support CTAGS, qui devrait aider à l'autocomplétion des méthodes API, et la possibilité de voir les mises à jour de l'interface utilisateur en temps réel pourrait rendre les composants de l'interface utilisateur plus rapidement que l'OBJC dans certains cas. Je prévois de lui donner une rotation bientôt. Le titane perd certainement dans l'arène de la performance (bien que cela puisse parfois être médié avec des astuces / astuces spécifiques), mais JS-To-iOS et JS-TO-Android est très attrayant.
Pourquoi ne pas énumérer des inconvénients bien connus aussi? 1) Vous devez gérer la mémoire par vous-même (MonoTouch a GC); 2) Une nouvelle libération iOS annule également des applications basées sur des objectifs (autant d'applications se sont écrasées après la mise à niveau de mon iPad sur iOS 4 et 5); 3) L'objectif C est toujours un dialecte étrange de la famille C / C ++ (peu importe le nombre de ressources, vous devez toujours vous battre pour l'apprendre); 4) Si vous devez communiquer avec des services Web externes (sauf iCLoud), vous devrez peut-être compter sur une bibliothèque de pommes non-Apple (MonoTouch prend bien soin de cela et de nombreux autres, car c'est un avantage de .NET / Mono) .
1) Il y a des arcs maintenant, mais cela semble être une caractéristique assez puissante, donc +1 pour les bibliothèques avec une mise en œuvre réussie de GC. 2) voir la réponse originale. 3) OP a dit qu'il avait appris quelque chose de toute façon. Pourquoi prendre la route du rond-point et apprendre une langue autre que l'Objc? 4) Comme dans le repos Api et similaires? Vous n'avez pas besoin bibliothèques externes pour cela, mais il y a beaucoup de choix à choisir ( Afnetworking , Restkit , etc.). Désolé si je suis mal compris votre point, mais cela ne semble guère comme un inconvénient.
1) Arc Kicks GC Butt. Désolé, mais pour Objc GC est mort. C'est une bonne chose 2) Beaucoup de gens font mal. IOS 4 à iOS 5 Apple a fixé beaucoup de trous pour empêcher cela. Ne comptez pas sur Stackoverflow autant. Parfois, ils répètent les mêmes mauvaises informations. 3) L'OBJC existe depuis plus de deux décennies. Ce n'est pas difficile d'apprendre. Mais comme toute autre langue qu'il faut du temps pour aller bien 4) Il y a beaucoup de bibliothèques externes. Apple a beaucoup de code source qu'ils fournissent gratuitement.
Si vous construisez simplement une application iPhone , alors par tous les moyens choisissez un objectif C. mais si vous souhaitez une application
Pour la performance, la réponse est Objective-C, tout le chemin.
Cela dit, regardez cela avec HTML5. Si vous vous tenez à des transformations accélérées, les performances HTML5 pour une application d'application sont étonnamment bonnes. Il est également assez facile de déplacer votre application HTML5 sur Android.
La réponse simple est l'objectif-c. Ce n'est pas trop difficile d'apprendre. Si vous êtes solide sur C et solide sur OOP, tout ira bien.
Je ne suis pas un fan de déclarations absolues sans références. Vous dites cela "pour la performance, l'objectif-C tout le chemin". Qui sait, vous avez peut-être raison, mais vous dirigerait vers une ressource de mesures réelles emmènerait votre déclaration de la zone d'opinion arbitraire que j'aime downvote.
@ctacke Il est basé sur 1) expérience et 2) la compréhension intuitive que le chemin le plus mince est généralement le plus rapide. Il y a quelque chose de tromperie à avoir des choses de rester rapides (par exemple, utilisez des vues avec traduction et transparence), mais Apple a fortement optimisé ce qu'ils considèrent comme le chemin cible. Ça montre. Vous voudrez peut-être savoir (et vous sentir libre), mais je ne vais pas fournir aux citations d'une réponse clairement évidente (écho par d'autres). La viande de ma réponse est que HTML5 devrait figurer sur sa liste, mais entre Mono Touch et Objective-C, je ne vois pas beaucoup de cause à s'écarter à l'extérieur du jardin.
@chaboud - que monoTouch devrait être derrière HTML5 en termes de performance est risible. Vous devez fournir des citations si vous voulez faire des déclarations comme ça. Safari JS est beaucoup plus lent, en particulier pour l'animation avec jQuery. Peut-être que CSS3 est beaucoup mieux, mais ne sonne pas une excellente solution.
@AngelofCode - Je n'ai jamais suggéré que MonoTouch soit derrière HTML5 en termes de performance. Il y avait plusieurs critères, comme la facilité d'utilisation, la facilité d'apprentissage, la fiabilité et la portabilité. Je Comme MonoTouch, mais HTML5 devrait être en cours d'exécution pour que quelqu'un envisageait une nouvelle application, au moins si l'application est basique.
Overflow de pile n'est pas un moteur de recommandation.
Il demande des comparaisons (performance, facilité d'utilisation..etc) ne demandant pas de recommander ...
Afin de comprendre les documents de la langue et des cadres et la plupart des échantillons de code, vous devrez apprendre l'objectif-C, de toute façon.