Как выбрать между MonoTouch и Objective-C? [закрыто]

После сегодняшнего заседания в Mono на местном мероприятии .Net использование MonoTouch было «затронуто» в качестве альтернативы для разработки iPhone. Будучи очень комфортным в C # и .Net, это кажется привлекательным вариантом, несмотря на некоторые извороты стека Mono. Тем не менее, поскольку MonoTouch стоит 400 долларов, я несколько разозлился, если это путь для разработки iPhone.

У кого-нибудь есть опыт разработки с MonoTouch и Objective-C, и если это так, то разработка с MonoTouch намного проще и быстрее, чем изучение Objective-C, и, в свою очередь, стоит 400 долларов?

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

У меня есть свои предпочтения (мне нравятся оба стека), но именно здесь большинство «ответов» начинают ошибаться. Это не должно быть о том, что я хочу (или что хочет кто-то еще).

Вот как я могу определить ценность MonoTouch - очевидно, я не могу быть объективным, но я думаю, что это довольно без фанатизма:

• Это для развлечения или бизнеса? Если вы хотите получить консультацию в этой области, вы можете вернуть свои $ 399 очень быстро.

• Вы хотите изучать платформу наизнанку, или вы просто хотите написать приложения для нее?

• Вам нравится .Net настолько, что использование другого стека разработчиков доставит вам удовольствие? Опять же, мне нравятся оба стека (Apple и Mono), но для меня MonoTouch делает этот опыт намного веселее. Я не перестал использовать инструменты Apple, но это в основном потому, что мне действительно нравятся оба стека . Я люблю iPhone, и я люблю .Net. В этом случае для меня MonoTouch был легким делом.

• Вам комфортно работать с C? Я не имею в виду Objective-C, но C - это важно, потому что Objective-C - это C. Это хорошая, причудливая, дружелюбная ОО-версия, но если указатели дают вам хиби-джиби, MonoTouch - ваш друг. И не слушайте скептиков, которые думают, что вы изобретатель, если случится так, что вам не нравятся указатели (или C и т. Д.). Раньше я ходил с копией IBM ROM BIOS Pocket Reference, и когда я писал ассемблер и заставлял свой компьютер переходить в смешные режимы видео и писать свои собственные биты рендеринга шрифтов для них и (по общему мнению, дрянных) оконных систем, я этого не делал. Я думаю, что разработчики QuickBasic были хитрыми. Я былQuickBasic Dev (в дополнение к остальным). Никогда не поддавайся ботанику. Если вам не нравится C, и вам не нравятся указатели, и если вы хотите держаться как можно дальше от ручного управления памятью (и, честно говоря, это совсем не плохо в ObjC), тогда. .. MonoTouch. И не берись за это.

• Хотите ли вы ориентироваться на пользователей или предприятия? Для меня это не имеет большого значения, но на Edge все еще есть люди, и дело в том, что вы можете создать гораздо меньший пакет загрузки, если используете стек Apple. Я играл с MonoTouch, и у меня есть приличное маленькое приложение, которое после сжатия сокращается до 2,7 МБ (когда вы отправляете свое приложение для распространения, вы архивируете его - когда приложения загружаются из магазина, они ' Застегните молнию - так что, выясняя, будет ли ваше приложение загружено в лимит OTA в 10 МБ, сначала застегните молнию на присоске - вы будете приятно удивлены MonoTouch). Но, если не считать счастья МТ, половина мег против почти трех (например) - это то, что может быть важно для вас, если вы ориентируетесь на конечных пользователей. Если вы думаете о работе предприятия, несколько МБ не будут иметь значения вообще. И, просто чтобы быть ясным - я собираюсь в ближайшее время представить приложение на базе MT в магазин, и у меня нет никаких проблем с размером. Меня совсем не беспокоит. Но если это то, что касаетсяВы , тогда стек Apple выигрывает этот.

• Делаете какие-нибудь работы с XML? MonoTouch. Период.

• Струнные манипуляции? Дата манипуляции? Миллион других мелочей, к которым мы привыкли, в .Net-инфраструктурах «все и кухня»? MonoTouch.

• Веб-сервисы? MonoTouch.

• Синтаксически они оба имеют свои преимущества. Objective-C имеет тенденцию быть более многословным, где вы должны написать это . Вы обнаружите, что пишете код на C #, вам не нужно писать на ObjC, но это происходит в обоих направлениях. Эта конкретная тема может заполнить книгу. Я предпочитаю синтаксис C #, но после преодоления моей первоначальной реакции "потусторонний мир" на Objective-C я научился получать от нее удовольствие. Я высмеивать него немного в переговорах (это является странным для разработчиков , которые вы использовать для C # / Java / и др.), Но правда в том , что у меня есть Objective-C форму пятна в моем сердце , что делает меня счастливым.

• Планируете ли вы использовать Interface Builder? Потому что даже в этой ранней версии я выполняю гораздо меньше работы по созданию своих пользовательских интерфейсов с помощью IB, а затем использую их в коде. Такое ощущение, что целые шаги отсутствуют в способе выполнения Objective-C / IB, и я почти уверен, что это происходит потому, что целые шаги отсутствуют в способе выполнения Objective-C / IB. До сих пор, и я не думаю, что я достаточно протестировал, но пока MonoTouch - победитель за то, сколько меньше работы вам нужно сделать.

• Как вы думаете, это интересно изучать новые языки и платформы? Если это так, у iPhone есть что предложить, и стек Apple, скорее всего, выведет вас из вашей комфортной зоны - что для некоторых разработчиков забавно (Привет - я один из тех разработчиков - я шучу об этом и даю Apple, это тяжелое время, но мне было очень весело изучать разработку iPhone с помощью инструментов Apple).

Есть так много вещей, чтобы рассмотреть. Ценность такая абстрактная. Если мы говорим о стоимости и о том, стоит ли она того, ответ сводится к моему первому пункту: если это для бизнеса, и если вы можете получить работу, вы вернете свои деньги обратно.

Так что ... это настолько объективно, насколько я могу быть. Это краткий список того, что вы можете задать себе, но это отправная точка.

Лично (давайте на минутку отбросим объективность), я люблю и использую оба. И я рад, что сначала изучил стек Apple. Мне было легче начать работать с MonoTouch, когда я уже знал свой путь в мире Apple. Как уже говорили другие, вы по-прежнему будете работать с CocoaTouch - он просто будет работать в среде .Net.

Но это еще не все. Люди, которые не использовали MonoTouch, как правило, останавливаются на достигнутом - «Это фантик бла-бла-бла» - это не MonoTouch.

MonoTouch дает вам доступ к тому, что может предложить CocoaTouch, а также дает доступ к тому, что может предложить (подмножество) .Net, IDE, с которой некоторые люди чувствуют себя более комфортно (я один из них), лучшая интеграция с Interface Builder и хотя вы не можете полностью забыть об управлении памятью, вы получаете хорошую степень свободы.

Если вы не уверены, возьмите стопку Apple (это бесплатно) и захватите стека MonoTouch eval (это бесплатно). Пока вы не присоединитесь к программе разработчиков Apple, оба будут работать только на симуляторе, но этого достаточно, чтобы помочь вам выяснить, предпочитаете ли вы одно другому, и возможно, стоит ли MonoTouch для вас $ 399.

И не слушайте фанатиков - они, как правило, те, кто не использовал технологию, против которой они ругаются :)

В этом посте много слухов от разработчиков, которые не пробовали MonoTouch и Objective-C. Похоже, что в основном это разработчики Objective-C, которые никогда не пробовали MonoTouch.

Я явно предвзят, но вы можете проверить, в чем состоит сообщество MonoTouch:

http://xamarin.com

Там вы найдете несколько статей от разработчиков, которые разработали как в Objective-C и C #.

Итак, мой ответ на предыдущий похожий вопрос - изучить Objective-C. (Также не забывайте о поддержке отладки)

Возможно, это кого-то обидит, но, честно говоря, если вы собираетесь заниматься серьезным развитием, вам следует изучить Objective-C. Незнание Objective-C в разработке для iPhone будет просто помехой. Вы не сможете понять много примеров; вам приходится иметь дело с особенностями Mono, тогда как, если вы обладаете практическими знаниями Objective-C, вы можете получить гораздо больше из документации по платформе.

Лично я не понимаю позицию, которая говорит об увеличении объема необходимой вам информации в пользу использования Mono над родным языком платформы. Это кажется несколько контрпродуктивным для меня. Я думаю, что если это очень дорогое предложение (изучение нового языка), то, возможно, стоит потратить некоторое время на фундаментальные концепции программирования, чтобы изучение новых языков было довольно дешевым предложением.

Другой пользователь также написал это:

Monotouch теперь проще для вас. Но сложнее позже.

Например, что происходит, когда появляются новые семена, с которыми вам нужно протестировать, но по какой-то причине сломать MonoTouch?

Придерживаясь Mono, каждый раз, когда вы ищете ресурсы для фреймворков, вы должны мысленно перевести на то, как вы собираетесь использовать их с Mono. Двоичные файлы вашего приложения будут больше, время разработки не станет намного быстрее после нескольких месяцев использования Objective-C, и у других разработчиков приложений будет гораздо больше преимуществ перед вами, потому что они используют собственную платформу.

Другое соображение заключается в том, что вы хотите использовать C #, потому что вы более знакомы с языком, чем Objective-C. Но подавляющее большинство кривой обучения для iPhone - это не Objective-C, а фреймворки, которые вам также придется использовать в C #.

Для любой платформы вы должны использовать платформу, которая непосредственно выражает философию дизайна этой платформы - на iPhone, то есть Objective-C. Подумайте об этом с другой стороны: если бы разработчик Linux, привыкший к программированию на GTK, хотел писать приложения для Windows, вы бы серьезно рекомендовали им не использовать C # и придерживаться GTK, потому что им было «легче» это делать?

Использование Mono не опора. Есть много вещей, которые он добавляет в iPhone OS. LINQ, WCF, разделяемый код между приложением Silverlight, страницей ASP.NET, приложением WPF, приложением Windows Form, а также моно для Android, и оно будет работать и для Windows Mobile.

Таким образом, вы можете потратить кучу времени на написание Objective-C (из многих исследований вы увидите, что один и тот же пример кода на C # значительно меньше писать, чем на OC), а затем ДУБЛИРОВАТЬ все это для других платформ. Для меня я выбрал MonoTouch, потому что у облачного приложения, которое я пишу, будет много интерфейсов, и iPhone - только один из них. Потоковая передача данных WCF из облака в приложение MonoTouch безумно проста. У меня есть основные библиотеки, которые совместно используются различными платформами, и тогда мне нужно только написать простой уровень представления для развертываний iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Воссоздание всего этого в Objective-C было бы огромной тратой времени как для первоначальной разработки, так и для технического обслуживания, поскольку продукт продолжает двигаться вперед, поскольку все функции придется копировать, а не использовать повторно.

Людям, которые оскорбляют MonoTouch или намекают, что его пользователям нужен костыль, не хватает общей картины того, что значит иметь .NET Framework у вас под рукой, и, возможно, не понимают правильное разделение логики и представления таким образом, чтобы может быть повторно использован на разных платформах и устройствах.

Objective-C интересен и сильно отличается от многих распространенных языков. Мне нравится вызов и изучение различных подходов ... но не тогда, когда это мешает моему прогрессу или создает ненужное перекодирование. В структуре iPhone SDK есть несколько действительно замечательных вещей, но все это великолепие полностью поддерживается MonoTouch и исключает ручное управление памятью, уменьшает объем кода, требуемого для выполнения тех же задач, позволяет мне повторно использовать свои сборки и мои параметры остаются открытыми, чтобы можно было переходить на другие устройства и платформы.

Я перешел. Monotouch, давайте напишу приложения как минимум в 3-4 раза быстрее (4 приложения в месяц по сравнению с моим старым 1 в месяц в Obj C)

Намного меньше печатать.

Просто мой опыт.

Если это единственное приложение для iPhone, которое вы когда-либо разрабатывали, и у вас также нет никакого интереса к разработке приложений для Mac, то MonoTouch, вероятно, стоит своих затрат.

Если вы думаете, что когда-нибудь будете разрабатывать больше приложений для iPhone, или когда-нибудь захотите заняться какой-то нативной разработкой для Mac, вероятно, стоит изучить Objective-C и связанные с ним фреймворки. Плюс, если вы тот тип программиста, который любит изучать новые вещи, это новая забавная парадигма для изучения.

Лично я думаю, что вы лучше проведете время, изучая Objective-C.

Коротко:

• «Learning Objective-C» - это не так страшно, как вы думаете, вам это может понравиться даже после первых нескольких недель
• Вы уже знакомы с синтаксисом "стиль C" с большим количеством * & () {}; где угодно
• Apple сделала очень хорошую работу по документированию
• Вы будете взаимодействовать с iPhone так, как задумал Apple, а это значит, что вы будете получать преимущества напрямую от источника, а не через какой-то фильтр.

Я обнаружил, что такие проекты, как Unity и MonoTouch, должны «экономить ваше время», но в конечном итоге вам все равно придется изучать язык, специфичный для их предметной области, и время от времени придется обходить стороной. Все это, вероятно, займет у вас столько же времени, сколько и выучить язык, который вы пытались избежать (в календарном времени). В конце концов, вы не сэкономили время и тесно связаны с каким-либо продуктом.

РЕДАКТИРОВАТЬ: Я никогда не имел в виду ничего негативного о .NET, я оказался большим поклонником этого. Моя точка зрения состоит в том, что добавление большего количества уровней сложности только потому, что вы еще не знакомы с причудливыми обозначениями скобок objc, на самом деле не имеет большого смысла для меня.

Обновление 2019 года: 7 лет спустя. Я все еще чувствую то же самое, если не больше. Конечно, «специфичный для предметной области язык», возможно, был неправильным термином для использования, но я все же считаю, что гораздо лучше писать непосредственно для платформы, с которой вы работаете, и по возможности избегать слоев и абстракций совместимости. Если вы беспокоитесь о повторном использовании и переработке кода, то, вообще говоря, любые функциональные возможности, которые необходимы вашему кроссплатформенному приложению, могут быть реализованы с помощью современных веб-технологий.

В дополнение к тому, что уже сказали другие (хорошо!): У меня такое ощущение, что вы в основном удваиваете количество ошибок, о которых вам нужно беспокоиться, добавляя ошибки в MonoTouch к уже существующим в iPhone OS. Обновление для новых версий ОС будет еще более болезненным, чем обычно. Фу, все вокруг.

Единственный убедительный случай, который я вижу для MonoTouch, - это организации, в которых много и много программистов на C # и кода C #, которые они должны использовать на iPhone. (Магазин, который даже не будет мигать за 3500 долларов.)

Но для любого, начинающего с нуля, я действительно не вижу в этом смысла или мудрости.

Три слова: Linq to SQL

Да, оно того стоит.

Что-то, что я хотел бы добавить, несмотря на то, что есть общепринятый ответ - кто скажет, что Apple не просто отклонит приложения, которые имеют признаки того, что они созданы с Mono Touch?

Я бы потратил время на Objective-C главным образом из-за всей помощи, которую вы можете получить от таких сайтов, как этот. Одной из сильных сторон Objective-C является то, что вы можете использовать код на C и C ++, и есть много проектов, которые хорошо протестированы .

Другое дело, что ваш код (язык выбора) будет поддерживаться Apple. Что, например, iOS 5.x удаляет поддержку стороннего решения, такого как MonoTouch? Что вы скажете своим клиентам тогда?

Может быть, лучше использовать независимое от платформы решение, такое как HTML5, если вы не совсем готовы перейти на Objective-C?

Я использую MonoTouch уже несколько месяцев, я портировал свое наполовину законченное приложение из ObjectiveC, чтобы в будущем я мог поддерживать Android.

Вот мой опыт:

Плохие биты:

• Студия Хамарин. Независимые разработчики, такие как я, вынуждены использовать Xamarin Studio. С каждой неделей все лучше, разработчики очень активно выявляют и исправляют ошибки на форумах, но они все еще очень медленные, часто зависают, содержат много ошибок, а отладка также довольно медленная.

• Время сборки. Создание моего большого (связанного) приложения для отладки на устройстве может занять несколько минут, по сравнению с XCode, который развертывается практически сразу. Сборка для симулятора (без привязки) происходит немного быстрее.

• MonoTouch выдает. У меня возникли проблемы с утечкой памяти, вызванные обработкой событий, и мне пришлось применять довольно уродливые обходные пути, чтобы предотвратить утечки, такие как присоединение и отсоединение событий при входе и выходе из представлений. Разработчики Xamarin активно изучают подобные проблемы.

• Сторонние библиотеки. Я потратил довольно много времени на преобразование / связывание библиотек ObjectiveC для использования в моем приложении, хотя это становится лучше с помощью автоматизированного программного обеспечения, такого как Objective Sharpie.

• Большие двоичные файлы. Это на самом деле не беспокоит меня, но думал, что я упомяну это. ИМО пара лишних мб ничего не значит в наши дни.

Хорошие биты:

• Мультиплатформная. Мой друг с радостью создает версию моего приложения для Android из моей базовой базы кода, мы параллельно разрабатываем и подключаемся к удаленному Git-репозиторию на Dropbox, и все идет хорошо.

• .Сеть. Работать в C # .Net гораздо приятнее, чем в Objective C IMO.

• MonoTouch. Практически все в iOS отражается в .Net, и довольно просто заставить все работать.

• Xamarin. Вы можете видеть, что эти ребята действительно работают над тем, чтобы улучшить все, делая разработку более гладкой и легкой.

Я определенно рекомендую Xamarin для межплатформенной разработки, особенно если у вас есть деньги, чтобы использовать выпуски Business или Enterprise, которые работают с Visual Studio.

Если вы создаете исключительно приложение для iPhone, которое никогда не понадобится на другой платформе, и вы являетесь разработчиком для инди, я бы остановился на XCode и Objective C.

Как человек с опытом работы как с C #, так и с Objective-C, я бы сказал, что для большинства людей Xamarin будет хорошо стоить денег.

C # - действительно хорошо разработанный язык, и API C # также хорошо разработаны. Конечно, у Cocoa Touch API (включая UIKit) также отличный дизайн, но язык можно улучшить несколькими способами. При написании на C # вы, вероятно, будете более продуктивными по сравнению с написанием того же кода в Objective-C. Это связано с несколькими причинами, но некоторые причины могут быть:

• C # имеет вывод типа . Вывод типа делает написание кода быстрее, так как вам не нужно «знать» тип в левой части присваивания. Это также делает рефакторинг проще и безопаснее.

• В C # есть обобщения , которые уменьшат ошибки по сравнению с эквивалентным кодом Objective-C (хотя в Objective-C есть некоторые обходные пути, в большинстве случаев разработчики их избегают).

• Недавно Xamarin добавил поддержку Async / Await , что делает написание асинхронного кода очень простым.

• Вы сможете повторно использовать часть кода на iOS, Android и Windows Phone.

• MonoTouch в значительной степени реализует API-интерфейсы CocoaTouch очень простым способом. Например: если у вас есть опыт работы с CocoaTouch, вы будете знать, где найти классы для элементов управления в MonoTouch (MonoTouch.UIKit содержит классы для UIButton, UIView, UINavigationController и т. Д., Аналогично MonoTouch.Foundation получил классы для NSString, NSData и т.д ...).

• Xamarin предоставит пользователям нативный опыт, в отличие от таких решений, как PhoneGap или Titanium.

Теперь Objective-C имеет некоторые преимущества по сравнению с C #, но в большинстве ситуаций написание приложений на C # обычно приводит к меньшему времени разработки и более чистому коду и меньшему количеству работы по переносу того же приложения на другие платформы. Одним заметным исключением могут быть высокопроизводительные игры, использующие OpenGL.

Стоимость библиотеки MonoTouch совершенно не относится к делу. Причина, по которой вы не должны использовать Mono для своих приложений iPhone, заключается в том, что это опора. Если вы не можете потрудиться изучать нативные инструменты, то у меня нет причин полагать, что ваш продукт стоит скачать.

Изменить: 14.04.2010 Приложения, написанные с MonoTouch, не имеют права на iTunes Store. Это так и должно быть. Apple видела множество мелких портов на Mac, используя кроссплатформенные наборы инструментов, такие как Qt, или собственное частичное повторное внедрение Adobe Toolbox для System 7, и в общем и целом они просто недостаточно хороши.