Парню .Net нужна информация о Какао - PullRequest
28 голосов
/ 16 ноября 2008

Я хочу немного развить OSX и iPhone. Я был разработчиком .Net / C # в течение многих лет. Мне было интересно, есть ли кто-нибудь, имеющий опыт работы с обеими платформами, который мог бы сказать мне, как они сравниваются и сравниваются. Я хотел бы получить представление о том, какую кривую обучения я опередил.

Спасибо

Geoff

Ответы [ 6 ]

22 голосов
/ 16 ноября 2008

Сначала плохо:
Я сделал некоторые разработки Какао в XCode. Первое, что вы заметите, это то, что IDE (XCode) не так интуитивно понятен или вообще хорош, как Visual Studio. Я очень скучаю по intellisense при работе в XCode. Разработчики Apple, вероятно, проголосуют за это утверждение. Но из среды .Net я очень скучаю. Так что не устанавливайте свои ожидания слишком высокими, и вы не будете слишком разочарованы. Я не пытаюсь запустить XCode, он не так хорош, как Visual Studio.

Теперь хорошо:
Общая архитектура проекта Какао очень хорошая . Я хочу, чтобы .Net Winforms и WPF использовали MVC из коробки, как это делают проекты Cocoa. Пока вы следуете шаблону MVC, вы должны делать все правильно с вашим проектом. Все, что я сделал, находится в Задаче C. Вы можете взять книгу об этом. Я купил Cocoa Programming для Mac OS X и подумал, что это довольно хорошо. Если у вас есть C на заднем плане, это будет выглядеть очень знакомо. С точки зрения C # точечная нотация для классов заменяется нотацией отправки сообщения, аналогичной Tcl.

Загрузите iTunes на свой компьютер и загрузите видео с iPhone для разработчиков под iTunes U . Вам также необходимо зарегистрироваться в программе разработчика в Apple и загрузить дополнительные биты для XCode для iPhone.

Надеюсь, это поможет. Я ни в коем случае не профессиональный разработчик Какао.

14 голосов
/ 16 ноября 2008

Я профессионально занимаюсь разработкой на C # и .NET начиная с бета-версии 1. XCode IDE - это нечто совершенно иное, чем Visual Studio. Первоначально вы будете чувствовать себя очень смущенным и потерянным. Я до сих пор не совсем удовлетворен пользовательским интерфейсом (дорогой бог, дай мне окно диспетчера решений и убей эту чушь с разделенным экраном), однако через мгновение ты будешь столь же продуктивным и быстрым, как в Studio. Документация сопоставима, хотя я предпочитаю макет в MSDN.

Что касается Какао, то его, как правило, легче использовать в качестве инструментария с графическим интерфейсом, чем .NET. Как было сказано выше, это другое мышление, однако, как только вы обернетесь вокруг него, вы поймете это.

Хотя это не связано с iPhone, между разработкой Mac и iPhone существует МНОЖЕСТВО. Вы сделаете себе одолжение, чтобы получить последнюю версию книги Aaron Hillegass OSX. Это в значительной степени фактическое руководство по написанию любого программного обеспечения Какао.

Подводя итог: вы будете ОЧЕНЬ потеряны и растерянны на начальном этапе, но это стоит того.

10 голосов
/ 28 декабря 2008

Если у вас есть фон Какао / Objective-C, то вы можете перейти к разработке для iPhone с помощью «Начала разработки для iPhone» Дэйва Марка и Джеффа Ламарша:

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

За ним очень легко следовать, но авторы предполагают некоторые предварительные знания Objective-C (как указано на задней обложке), поэтому я бы рекомендовал начать с первых пяти или шести глав «Программирование какао для Mac OS X» Аароном Хиллегасом, как уже отмечалось другими.

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

Аарон использует и преподает Objective-C и фреймворки, теперь связанные с Какао, с тех пор, как он работал в NeXT, и это видно. Материал действительно очень хороший.

Хотя основная часть методов разработки в равной степени относится к Mac и iPhone, некоторые методы применяются только к Mac (например, сборка мусора, привязки, базовые данные), а некоторые применяются только к iPhone (например, несколько целей). за одно действие).

Если вы хотите быстро освоить разработку для iPhone и готовы инвестировать немного денег, команда Аарона также может научить вас всему, что вам нужно знать, за неделю, на уроках на Ранчо Большого ботаника. (Класс iPhone всегда заполняется быстро, но если вы оказались в Силиконовой долине, в январе в «iPhone для пассажиров» еще есть место.)

http://www.bignerdranch.com/

(Перейдите на вкладку классы , чтобы узнать, что и когда, включая Ruby, Android и т. Д.)

Хотя я лично предпочитаю варианты выше, конечно, есть и бесплатные онлайн-опции. Скотт Стивенсон приложил огромные усилия к урокам Cocoa / Objective-C:

http://www.cocoadevcentral.com/

А Стэнфорд предложил классы как для разработки на Mac, так и для разработки под iPhone для преподавателей Apple, и разместил материалы для занятий в Интернете:

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

Наконец, кажется, что разработчики, которые приходят к разработке для Mac / iPhone с фоном Windows, стараются избегать Interface Builder (IB) и вместо этого создают пользовательский интерфейс в коде. Я понимаю, почему - IB не выкладывает все, что происходит, в хороший список кода - но я настоятельно рекомендую против этой стратегии.

Разработка Mac / iPhone - это минимизация кода. Чем меньше кода вы должны написать, тем меньше вам нужно поддерживать и тем меньше шансов на ошибку. IB отлично подходит для минимизации кода, необходимого для пользовательского интерфейса.

Ваш C / C # фон послужит вам хорошо. Сначала вы обнаружите, что Objective-C кажется довольно странным, но я подозреваю, что вы оцените его сильные стороны и очень быстро его поднимете. В отличие от C ++, это на самом деле довольно просто.

7 голосов
/ 18 ноября 2008

Я только что отметил это как фаворит, поскольку я надеюсь, что больше парней .NET + Какао вмешиваются. Я только начинаю (снова) с Какао, и до сих пор люблю это. (Помогает, что я работаю над 10.5, который позволяет сборку мусора в качестве опции.)

Некоторые из самых больших различий, которые я заметил до сих пор:

  1. Да, XCode сильно отличается от Visual Studio. Другие могут высмеивать природу «разделенного экрана», но я нахожу это довольно интуитивным, как только обернул его вокруг себя. Возможно, самый большой совет, который я могу дать здесь, это настроить панель инструментов, добавить кнопку «Редактор» и использовать эту кнопку неукоснительно для редактирования кода.
  2. Синтаксис сообщений кажется незнакомым, но я подозреваю, что это потому, что я не из среды Smalltalk. (Я слышал - хотя я не проверял это - что концепции очень похожи.) По-видимому, по состоянию на 10.5 добавлены точечные обозначения и понятие свойств, но Hillegass рекомендует против них. Я говорю, делай то, что тебе кажется правильным. (Я сам пока не зашел так далеко в книге ...)
  3. Язык, по сути, нетипизирован. Плюсы в том, что вы можете изменять классы фреймворка в соответствии с вашими потребностями, и сообщения будут обрабатываться во время выполнения, предоставляя вам гораздо больше свободы. Недостатки в том, что вы можете не находить ошибки до времени выполнения, и многие из этих ошибок не ведут себя так, как это делают исключения .NET, то есть многие из них не вызывают полной остановки приложения, когда вы не можете их перехватить. (Следует признать, что есть ключевое слово @throw; я еще не получил его там. :)) Другой недостаток заключается в том, что концепция Obj-C null (nil) может принимать сообщения - нет понятия NullReferenceException, или. Оба из них могут вызвать головную боль отладки.
  4. Интерфейсный конструктор - совершенно новый зверь по сравнению с дизайнерами WinForms / WPF / ASP.NET. Концепция архивирования всего пользовательского интерфейса, а также отсутствие кода, является одной из самых сложных концепций для многих из нас, ребят .NET. В этом нет ничего плохого, но нам нужно обдумать это.
  5. Сборка мусора. Начиная с 10.5, Cocoa и Objective-C поддерживают управление подсчетом ссылок (retain / release / autorelease) и автоматическую сборку мусора. Начав работать, я не могу описать слишком много из них, но, несмотря на то, что GC проще в использовании, вам придется вручную указать его в параметрах цели - и вашему приложению теперь потребуется 10,5 или выше, чтобы запустить. Кроме того, даже с помощью GC рекомендуется вручную устанавливать указатели на nil, когда вы закончите с ними, чтобы намекнуть GC, что они могут быть готовы к сбору. Не так прозрачно, как .NET. (Опять же, неплохо, просто другое. Что нужно знать!)

Я отнюдь не эксперт. Я буквально только начал этот путь сам (еще раз). Однако мне это нравится, и я подозреваю, что если такой заядлый разработчик Microsoft, как я, сможет его откопать, то и другие тоже смогут.

Наконец, несколько месяцев назад я обнаружил блог .NET Addict . Автор делает и .NET и Какао, и имеет несколько постов, обсуждающих различия. Настоятельно рекомендуется.

4 голосов
/ 18 ноября 2008

Я довольно опытный в обоих случаях, хотя я не делал много кода на C # в течение года или около того. Я перешел с Obj-C на C #, и у меня не было особых проблем. Мне кажется, что код Obj-C немного более неформален и менее жесток, чем C #; например, нет типизированных массивов, и вам не нужно беспокоиться о явной проверке, является ли объект nil / null, прежде чем вызывать метод для него. В целом это хорошо, так как вы можете написать более компактный и элегантный код (IMO). В то же время, в отличие от C #, вам нужно знать основные концепции программирования на C, чтобы работать с Obj-C, поэтому, возможно, вы захотите освежить в памяти такие вещи, как указатели, если вы ржавые.

Я думаю, что для API вы обнаружите, что Cocoa больше подходит для настольных приложений, чем для предприятия, как .NET. Например, где .NET имеет ADO.NET, элемент управления ReportViewer, а у Cocoa есть Core Data, PDFKit и SearchKit.

3 голосов
/ 16 ноября 2008

Главное, что вы всегда должны напоминать себе, это то, что Cocoa просто не работает так же, как WinForms . Вы нигде не найдете «Обработчик событий», даже если будете искать его! Не то, чтобы WinForms - это плохо, но Какао - это просто другая парадигма.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...