Як вирішити між MonoTouch та Objective-C? [зачинено]

Після засідання сьогодні на сесії Mono на локальному заході .Net, використання MonoTouch було "зачеплено" як альтернативу для розробки iPhone. Будучи дуже комфортним у C # та .Net, це здається привабливим варіантом, незважаючи на певну вигадливість стека Mono. Однак, оскільки MonoTouch коштує 400 доларів, я дещо розірваний, якщо це шлях для розробки iPhone.

Хтось має досвід розробки MonoTouch і Objective-C, і якщо так розвивається з MonoTouch, це набагато простіше і швидше, ніж навчання Objective-C, а в свою чергу коштує 400 доларів?

Останнім часом я дуже часто бачив це питання (і його варіанти). Мене дивує те, як часто люди відповідають, але як мало хто відповідає .

У мене є свої уподобання (мені подобаються обидва стеки), але саме тут більшість "відповідей" починають іти не так. Це не повинно бути про те, що я хочу (або що хоче хто-небудь інший).

Ось як я б пішов щодо визначення вартості MonoTouch - я, очевидно, не можу бути об'єктивним, але я думаю, що це досить безтурботно:

• Це для розваги чи для бізнесу? Якщо ви хочете отримати консультацію в цій галузі, ви можете отримати свої 399 доларів назад дуже швидко.

• Ви хочете навчитися платформі зсередини, чи ви просто "хочете" написати додатки для неї?

• Вам подобається. Досить, що використання іншого стека розробників дозволить вам отримати задоволення? Знову ж, мені подобаються обидві стеки (Apple і Mono), але для мене MonoTouch робить цей досвід набагато веселішим. Я не переставав користуватися інструментами Apple, але це головним чином тому, що мені дуже подобаються обидві версії . Я люблю iPhone, і я люблю .Net У такому випадку для мене MonoTouch був нерезультативним.

• Чи почуваєтесь ви комфортно працювати з C? Я не маю на увазі «Objective-C», але «C» - це важливо, тому що «Objective-C» є C. Це приємна, вигадлива, доброзичлива версія OO, але якщо покажчики дають вам heebie-jeebies, MonoTouch - ваш друг. І не слухайте найсайєрів, які думають, що ви чорт, якщо трапляється, що вам не подобаються покажчики (або С тощо). Я коли-небудь ходив із копією кишенькової довідки IBM ROM BIOS, і коли я писав збірку і змушував комп’ютер у кумедних режимах відео та писав власні шрифти візуалізації шрифту для них та (правда, смішні) системи вікон, я цього не робив ' Не думаю, що динаміки QuickBasic були розпусниками. Я бувQuickBasic Dev (крім решти). Ніколи не поступайтеся дурному махізму. Якщо вам не подобається C, і якщо вам не подобаються покажчики, і якщо ви хочете триматися якнайдалі від ручного управління пам’яттю (і, якщо чесно, то в ObjC це зовсім не погано). .. MonoTouch. І не приймайте за це жодних зубців.

• Хочете націлити користувачів або підприємства? Для мене це не має великого значення, але на Edge все ще є люди, і факт полягає в тому, що ви можете створити набагато менший пакет завантажень, якщо використовувати стек Apple. Я граю з MonoTouch, і у мене є пристойний маленький додаток, який, стиснувшись, зменшиться до приблизно 2,7 Мб (коли ви подаєте свою програму для розповсюдження, ви поштовуєте її - коли програми завантажуються з магазину, вони ' знову застебнутий - тож, коли з’ясуєте, чи буде ваш додаток за межею OTA в межах 10 МБ, спочатку застебніть присоску - ви будете приємно здивовані MonoTouch). Але, окрім щастя MT, півмісяця проти майже трьох (наприклад) - це те, що може бути важливим для вас, якщо ви орієнтуєтесь на кінцевих користувачів. Якщо ви думаєте про роботу на підприємстві, кілька МБ взагалі не матимуть значення. І, просто, щоб було зрозуміло - я незабаром буду надсилати додаток на основі МТ в магазин, і в мене немає жодних проблем із розміром. Це мене зовсім не турбує. Але якщо це щось, що стосувалося бви , тоді стек Apple виграє цей.

• Робите якісь XML роботи? MonoTouch. Період.

• Струнна маніпуляція? Дата маніпуляції? Мільйон інших дрібниць, до яких ми звикли, з раковинами. MonoTouch.

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

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

• Ви плануєте використовувати Interface Builder? Тому що навіть у цій ранній версії я вважаю, що роблю набагато менше роботи, щоб створити свої інтерфейси з ІБ та потім використовувати їх у коді. Складається враження, що цілі кроки відсутні у способі здійснення об'єктивної C / IB, і я впевнений, що це так, оскільки цілі кроки відсутні у способі здійснення об'єктивної 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 чомусь зламати?

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

Інша думка полягає в тому, що ви хочете використовувати C #, оскільки ви більше знайомі з мовою, ніж з Objective-C. Але переважна більшість кривих навчання для iPhone не це Objective-C, це рамки - до яких вам доведеться також залучати і C #.

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

Використання Mono не є милицею. Є багато речей, які він додає до ОС iPhone. LINQ, WCF, код, який можна поділити між додатком Silverlight, сторінкою ASP.NET, додатком WPF, додатком для форм Windows, також є моно для Android, і він також буде працювати для Windows Mobile.

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

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

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

Я перейшов. Monotouch давайте мені писати програми принаймні в 3-4 рази швидше (4 програми на місяць порівняно з моїми старими 1 на місяць в Obj C)

Багато менше друкувати.

Просто мій досвід.

Якщо це єдине додаток для iPhone, яке ви коли-небудь розробляєте, і у вас також є нульовий інтерес до розробки додатків для Mac, то MonoTouch, мабуть, вартує витрат.

Якщо ви думаєте, що коли-небудь будете розробляти більше додатків для iPhone або коли-небудь захочете зробити якусь основну розробку для Mac, напевно, варто цього вивчити Objective-C та пов'язані з ним рамки. Плюс, якщо ти тип програміста, який любить вивчати нові речі, вивчати нову цікаву парадигму.

Особисто я думаю, що вам буде краще провести час, просто навчившись Objective-C.

Коротко:

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

Я виявив, що такі проекти, як Unity та MonoTouch, повинні "заощадити ваш час", але в кінцевому підсумку вам доведеться в будь-якому разі вивчати мову, що відповідає їхньому домену, і доведеться часом ухилятися від речей. Все, що, ймовірно, займе у вас стільки ж, скільки часу, щоб вивчити мову, якої ви намагалися уникати вивчення (у календарний час). Зрештою, ви не заощадили жодного часу, і ви міцно прив'язані до якогось продукту.

EDIT: Я ніколи не мав на увазі нічого негативного щодо .NET, я, мабуть, є великим шанувальником цього. Моя думка полягає в тому, що додавання більшої кількості складних шарів тільки тому, що вам поки що не зручно з вигадливою нотацією дужок об'єкта, для мене насправді не має великого сенсу.

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

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

Тільки переконливі аргументи я можу бачити , для MonoTouch це організації , які мають багато і багато C # програмістів і C # код , що лежать навколо , що вони повинні використовувати на iPhone. (Такий магазин, який навіть не блимає на $ 3500.)

Але для тих, хто починає з нуля, я справді не можу вважати це гідним або мудрим.

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

Так, це добре коштує $.

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

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

Інша справа, що ваш код (мова вибору) буде підтримуватися яблуком. Наприклад, що iOS 5.x видаляє підтримку сторонніх рішень, таких як MonoTouch? Що ви тоді скажете своїм клієнтам?

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

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

Ось мій досвід:

Погані біти:

• Студія Xamarin Інді-розробники, такі як я, змушені використовувати Xamarin Studio. З кожним тижнем стає все краще, розробники дуже активно працюють на форумах ідентифікують і виправляють помилки, але це все ще дуже повільно, часто зависає, має багато помилок і налагодження також досить повільне.

• Часи побудови. Побудова мого великого (пов'язаного) додатка для налагодження на пристрої може зайняти кілька хвилин, це порівнюється з XCode, який розгортається практично відразу. Будівництво для тренажера (без зв’язку) трохи швидше.

• Випуски MonoTouch. У мене виникли проблеми з витоком пам’яті, спричиненими обробкою подій, і мені довелося ввести деякі досить потворні способи запобігання протікання, як-от прикріплення та від'єднання подій під час входу та виходу з подання. Розробники Xamarin активно розглядають подібні проблеми.

• Бібліотеки сторонніх партій. Я витратив досить багато часу на перетворення / прив'язування бібліотек ObjectiveC для використання в моєму додатку, хоча це покращується за допомогою автоматизованого програмного забезпечення, такого як Objective Sharpie.

• Більші двійкові файли. Це насправді не турбує мене, але думав, що я це зазначу. IMO пара зайвих Мб - це нічого.

Хороші шматочки:

• Багатоплатформа. Мій друг із задоволенням створює Android-версію мого додатка з моєї основної кодової бази, ми розвиваємось паралельно і беремо на себе віддалене сховище Git на Dropbox, це йде добре.

• .Нет. Робота в C # .Net набагато приємніша, ніж об'єктивна C IMO.

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

• Ксамарін. Ви можете бачити, що ці хлопці справді працюють над тим, щоб покращити все, роблячи розвиток більш плавним та легким.

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

Якщо ви створюєте виключно додаток для iPhone, який ніколи не знадобиться на іншій платформі, і ви розробник Indie, я б зараз дотримувався XCode та Objective C.

Як хтось із досвідом роботи як з C #, так і з Objective-C, я б сказав, що для більшості людей Xamarin добре коштує грошей.

C # - це дійсно добре розроблена мова, і API C # також добре розроблений. Звичайно, API Cocoa Touch (включаючи 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, або власне часткове повторне впровадження панелі інструментів System 7, а довге і коротке - вони просто недостатньо хороші.