Как выбрать MonoTouch и Objective-C?

Ответ 1

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

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

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

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

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

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

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

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

• Выполнение любой работы XML? MonoTouch. Период.

• Обработка строк? Дата манипуляции? Миллион других мелочей, с которыми мы привыкли использовать .Net все-и-кухонные раковины? MonoTouch.

• Веб-службы? MonoTouch.

• Синтаксически они оба имеют свои преимущества. Objective-C имеет тенденцию быть более подробным, когда вы должны его написать. Вы обнаружите, что пишете код с С#, который вам не нужно писать с помощью ObjC, но он идет в обоих направлениях. Эта конкретная тема могла бы заполнить книгу. Я предпочитаю синтаксис С#, но, пройдя свою первоначальную, это - потусторонняя реакция на Objective-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 (он бесплатный) и возьмите стек eval MonoTouch (он бесплатный). Пока вы не присоединитесь к программе Apple dev, оба будут работать только с симулятором, но это достаточно, чтобы помочь вам разобраться, если вы предпочитаете друг друга, и возможно ли, что MonoTouch для вас стоит 399 долларов.

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

Ответ 2

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

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

http://xamarin.com

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

Ответ 3

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

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

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

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

Теперь Monotouch вам легче. Но тяжелее позже.

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Мало набирает текст.

Только мой опыт.

Ответ 6

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

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

Ответ 7

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

Короче говоря:

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

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

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

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

Ответ 8

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

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

Но для тех, кто начинает с нуля, я действительно не вижу в этом смысла или мудрости.

Ответ 9

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

Да, это стоит $.

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

Вот мой опыт:

Плохие биты:

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

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

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

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

• Большие двоичные файлы. Меня это не беспокоит, но я думал об этом. IMO еще несколько лишних Мбайт в наши дни.

Хорошие бит:

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

• .Net. Работа в С#.Net намного лучше, чем Objective C IMO.

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

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

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

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

Ответ 13

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

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

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

• С# имеет generics, что уменьшит ошибки по сравнению с эквивалентным кодом 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 имеет некоторые преимущества перед С#, но в большинстве случаев пишущие приложения на С# обычно приводят к меньшему времени разработки и более чистого кода, а также меньше работы для переноса того же приложения на другие платформы. Одним из примечательных исключений могут быть высокопроизводительные игры, которые полагаются на OpenGL.

Ответ 14

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

Редактировать: 4/14/2010 Приложения, написанные с помощью MonoTouch, не имеют права на iTunes Store. Это так и должно быть. Apple увидела много мелких портов на Mac, используя кросс-платформенные инструментальные средства, такие как Qt, или собственную собственную частичную повторную реализацию инструментальной панели System 7, и длинный и короткий из них - они просто недостаточно хороши.