Un utilisateur de .Net a besoin d'informations sur Cocoa

Question

Je veux faire un peu de développement dans OSX et l'iPhone. Je suis un développeur .Net/C# depuis des années. Je me demandais si quelqu'un avait de l'expérience dans les deux plateformes et pouvait me dire comment elles se comparent et contrastent. J'aimerais avoir une idée de la courbe d'apprentissage qui m'attend.

Merci,

Geoff

Answer 1

D'abord le mauvais :
J'ai fait un peu de développement Cocoa dans XCode. La première chose que vous remarquerez est que l'IDE (XCode) n'est pas aussi intuitif, ou agréable en général, que Visual Studio. L'intellisense me manque vraiment lorsque je travaille dans XCode. Les développeurs d'Apple vont probablement voter contre moi pour cette déclaration. Mais venant d'un environnement .Net, c'est ce qui me manque vraiment. Ne placez donc pas vos attentes trop haut et vous ne serez pas trop déçu. Je n'essaie pas de rabaisser XCode, mais il n'est pas aussi agréable que Visual Studio.

Maintenant, le bon :
L'architecture générale d'un projet Cocoa est très bien . J'aurais aimé que .Net Winforms et WPF utilisent MVC dès le départ, comme le font les projets Cocoa. Tant que vous suivez le modèle MVC, vous devriez vous en sortir avec votre projet. Tout ce que j'ai fait est en Objective C. Vous pourriez prendre un livre à ce sujet. J'ai acheté Programmation Cocoa pour Mac OS X et j'ai pensé que c'était plutôt bien. Si vous avez du C dans votre bagage, cela vous semblera très familier. Du point de vue du C#, la notation par points des classes est remplacée par une notation d'envoi de messages similaire à celle de Tcl.

Chargez iTunes sur votre machine et téléchargez les vidéos de développement de l'iPhone sous iTunes U . Vous devrez également vous inscrire au programme de développement d'Apple et télécharger les bits supplémentaires de XCode pour l'iPhone.

J'espère que cela vous aidera. Je ne suis en aucun cas un développeur Cocoa professionnel.

Answer 2

Je développe professionnellement avec C# et .NET depuis la version bêta 1. L'IDE XCode est un animal complètement différent de Visual Studio. Au début, vous vous sentirez très confus et perdu. Je ne suis toujours pas totalement satisfait de l'interface utilisateur (mon Dieu, donnez-moi une fenêtre Solution Manager et arrêtez cette merde d'écran partagé), mais en un rien de temps vous serez aussi productif et rapide que dans Studio. La documentation est comparable, même si je préfère la mise en page de MSDN.

Quant à Cocoa, il est généralement plus facile de travailler avec une boîte à outils d'interface graphique que .NET. Comme indiqué ci-dessus, c'est un état d'esprit différent, mais une fois que vous l'aurez compris, vous l'apprécierez.

Bien que cela ne soit pas lié à l'iPhone, il existe de nombreuses similitudes entre le développement Mac et iPhone. Vous vous rendriez service en vous procurant la dernière version du livre OSX d'Aaron Hillegass. C'est à peu près le guide de facto pour l'écriture de tout logiciel Cocoa.

En résumé... vous allez être TRES perdu et confus au début, mais tenez bon, cela en vaut la peine.

Answer 3

Si vous avez des connaissances en Cocoa/Objective-C, vous pouvez vous lancer dans le développement de l'iPhone avec l'aide de "Beginning iPhone Development" de Dave Mark et Jeff LaMarche :

http://www.amazon.com/dp/1430216263/

Il est très facile à suivre, mais les auteurs supposent une certaine connaissance préalable d'Objective-C (comme indiqué sur la quatrième de couverture). Je recommande donc de commencer par les cinq ou six premiers chapitres de "Cocoa Programming for Mac OS X" d'Aaron Hillegass, comme d'autres l'ont déjà fait remarquer.

http://www.amazon.com/dp/0321503619/

Aaron utilise et enseigne Objective-C et les frameworks désormais associés à Cocoa depuis l'époque où il travaillait chez NeXT, et cela se voit. La matière est vraiment, vraiment bonne.

Si la plupart des techniques de développement s'appliquent aussi bien au Mac qu'à l'iPhone, certaines techniques ne s'appliquent qu'au Mac (par exemple, le garbage collection, les bindings, Core Data) et d'autres ne s'appliquent qu'à l'iPhone (par exemple, plusieurs cibles pour une même action).

Si vous voulez apprendre le développement de l'iPhone très rapidement et que vous êtes prêt à investir un peu d'argent, l'équipe d'Aaron peut également vous enseigner tout ce que vous devez savoir en une semaine, dans le cadre de cours au Big Nerd Ranch. (Le cours sur l'iPhone se remplit toujours rapidement, mais si vous vous trouvez dans la Silicon Valley, il y a encore de la place dans le cours "iPhone pour les banlieusards" en janvier).

http://www.bignerdranch.com/

(Cliquez sur l'icône classes pour un calendrier de ce qui est prévu et quand, y compris Ruby, Android, et plus).

Si je préfère personnellement les options ci-dessus, il existe bien sûr aussi des options gratuites en ligne. Scott Stevenson a consacré énormément d'efforts aux didacticiels Cocoa/Objective-C :

http://www.cocoadevcentral.com/

Stanford a proposé des cours de développement pour Mac et pour iPhone, dispensés par des ingénieurs d'Apple, et a mis en ligne les supports de cours :

Mac : http://www.stanford.edu/class/cs193e/
iPhone : http://www.stanford.edu/class/cs193p/

Enfin, il semble que les développeurs qui viennent au développement Mac/iPhone avec un passé Windows essaient d'éviter Interface Builder (IB) et de construire l'interface utilisateur en code. Je comprends pourquoi - IB n'expose pas tout ce qui se passe dans un beau listing de code - mais je déconseille fortement cette stratégie.

Le développement Mac/iPhone consiste à minimiser le code. Moins il y a de code à écrire, moins il y en a à maintenir et moins il y a de risques d'erreur. IB est idéal pour minimiser le code nécessaire à l'interface utilisateur.

Votre expérience en C/C# vous sera utile. L'Objective-C vous semblera assez étrange au début, mais je pense que vous finirez par apprécier ses points forts, et que vous l'assimilerez très rapidement. Contrairement au C++, il est en fait assez simple.

Answer 4

Je viens de marquer cet article comme favori, car j'espère que d'autres utilisateurs de .NET+Cocoa y participeront. Je commence (à nouveau) à utiliser Cocoa et j'adore ça jusqu'à présent. (Cela aide que je travaille sur 10.5, qui permet le garbage collection comme une option).

Les plus grandes différences que j'ai remarquées jusqu'à présent :

1. Oui, XCode est très différent de Visual Studio. D'autres peuvent se moquer de la nature de l'écran divisé, mais je l'ai trouvé assez intuitif une fois que j'y ai réfléchi. Peut-être que le plus grand conseil que je puisse donner ici est de personnaliser la barre d'outils, d'ajouter le bouton "Editor", et d'utiliser ce bouton religieusement pour l'édition du code.
2. La syntaxe de la messagerie ne m'est pas familière, mais je suppose que c'est parce que je ne viens pas d'un milieu Smalltalk. (J'entends dire -- bien que je ne l'aie pas validé -- que les concepts sont très similaires). Apparemment, à partir de la 10.5, la notation par points et la notion de propriétés ont été ajoutées, mais Hillegass les déconseille. Je dis : faites ce qui vous semble bon. (Je ne suis pas encore arrivé aussi loin dans le livre, moi-même ... )
3. Le langage est, à toutes fins utiles, non typé. Les avantages sont que vous pouvez réellement modifier les classes du framework pour répondre à vos besoins et que les messages seront résolus au moment de l'exécution, ce qui vous donne beaucoup plus de liberté. Les inconvénients sont que vous pouvez ne trouver les erreurs qu'au moment de l'exécution et que beaucoup de ces erreurs ne se comportent pas comme les exceptions .NET, c'est-à-dire que beaucoup d'entre elles ne provoquent pas l'arrêt complet de l'application si vous ne parvenez pas à les piéger. (Certes, il y a @throw mot-clé ; je n'y suis pas encore arrivé non plus. :)) Un autre inconvénient est que le concept d'Obj-C de null ( nil ) peut recevoir des messages -- aucun NullReferenceException non plus. Ces deux éléments peuvent causer des problèmes de débogage.
4. Interface Builder est une toute nouvelle bête, comparé aux concepteurs WinForms/WPF/ASP.NET. Le concept d'archivage de l'ensemble de l'interface utilisateur, sans qu'il s'agisse de code, est l'un des concepts les plus difficiles à appréhender pour nombre d'entre nous, les utilisateurs de .NET. Il n'y a rien de mal à cela, mais nous devons nous faire à l'idée.
5. Le ramassage des ordures. Depuis la version 10.5, Cocoa et Objective-C supportent tous deux le comptage de références ( retain / release / autorelease ) la gestion de la mémoire et la collecte automatique des déchets. Comme je viens juste de commencer à travailler, je ne peux pas trop détailler les rouages de l'une ou l'autre, mais bien que la GC soit plus facile à utiliser, vous devrez la spécifier manuellement dans vos options de cible - et votre application aura maintenant besoin de 10.5 ou plus pour fonctionner. De plus, même avec le GC, c'est une bonne pratique de mettre manuellement vos pointeurs à nil lorsque vous en avez fini avec eux, pour indiquer au CG qu'ils sont peut-être prêts à être collectés. Pas tout à fait aussi transparent que .NET. (Encore une fois, ce n'est pas mauvais, c'est juste différent. Choses à savoir !)

Je suis en aucun cas un expert. Je viens littéralement de m'engager dans cette voie (une fois de plus). Mais j'adore ça et je pense que si un spécialiste du développement Microsoft comme moi peut s'y mettre, d'autres le peuvent aussi.

Finalement, j'ai découvert le .NET Addict blog il y a quelques mois. L'auteur travaille à la fois sur .NET et sur Cocoa, et a rédigé plusieurs articles sur les différences. Hautement recommandé.

Answer 5

Je suis assez expérimenté dans les deux, bien que je n'aie pas fait beaucoup de code C# depuis un an environ. Je suis passé d'Obj-C à C#, et je n'ai pas eu trop de problèmes. Le code Obj-C me semble un peu plus informel et moins rigide que le C# ; par exemple, il n'y a pas de tableaux typés, et vous n'avez pas à vous soucier de vérifier explicitement si un objet est nil/null avant d'appeler une méthode sur lui. En général, c'est une bonne chose, puisque vous pouvez écrire un code plus compact et plus élégant (IMO). En même temps, à la différence de C#, vous devez connaître les concepts de base de la programmation C pour travailler avec Obj-C, donc vous pourriez vouloir réviser des choses comme les pointeurs si vous êtes rouillé.

Je pense que pour les API, vous trouverez que Cocoa est plus adapté aux applications de bureau, plutôt qu'aux entreprises comme .NET. Par exemple, alors que .NET a ADO.NET, le contrôle ReportViewer, Cocoa a Core Data, PDFKit et SearchKit.