Каково состояние программирования без Objective-C для iPhone?

Ответ 1

Я бы скептически относился к не-ObjC-языкам на iPhone. Не обязательно потому, что можно преодолеть какое-то огромное техническое препятствие (вы можете скомпилировать все, что угодно, на iPhone, и даже заставить его работать с некоторой настройкой), но по двум другим важным причинам:

• Каркасы. В то время как перечисленные вами вещи имеют привязку к сенсорному экрану и акселерометру, вы, скорее всего, будете пропускать такие вещи, как Bluetooth-соединение и набор игр, аудиокарты, In-App Purchase и т.п. Было бы довольно сложно воспроизвести все, что предлагает Apple на другом языке, и если вы выберете другой способ, а затем выйдете из одной из этих фреймворков, вы можете застрять.
• Подача заявки. Если вы хотите получать приложения в App Store, вы, вероятно, должны придерживаться ObjC. Apple, как известно, придирчивы к тому, что они допускают, и использование другого языка может нанести вред определенному рецензентам.

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

В общем, я бы придерживался ObjC, если можно. Обычно это проще для всех заинтересованных сторон.

Обновление: сентябрь 2010 Новые условия использования iOS охватывают сторонние разработки, рекламные платформы

Ответ 2

MonoTouch выглядит неплохо, но он мучительно медленный. Я играл с XCode на своем MacBook последнего поколения некоторое время (около 2007 года), и он был быстрым и отзывчивым. На прошлой неделе я загрузил MonoTouch, так как хотел бы преобразовать существующую большую кодовую базу Mono для работы на iPhone, и пока она устанавливается и работает нормально, использование в ней крайне болезненно, так как все в IDE неактивно и не реагирует.

YMMV, если у вас более новый и более мощный набор, но он не сулит ничего хорошего.

Ответ 3

Как насчет другого встроенного языка, Javascript?

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

Преимущество над сторонними языками и фреймворками заключается в том, что лицензия Apple dev явно позволяет загружать и запускать javascript-программы (поскольку вы используете их официальный API для этого).

Только что нашел этот подключаемый модуль Xcode, который предлагает разработку HTML и Javascript для приложений, ориентированных на родной язык: Nimble Kit. Возможно, стоит посмотреть...

Ответ 4

Unity для iPhone - хорошая платформа для разработки, отличной от ObjectiveC.

http://unity3d.com/unity/features/iphone-publishing

Это больше, чем просто игры, и если вам нужна .NET или другая поддержка языка script, это может быть хорошим способом.

IMHO: MonoTouch больше работает, чем хороший стек IB + ObjectiveC, даже с некоторыми из служебных накладных расходов ObjectiveC.

Ответ 5

Вы проиграете несколькими способами, не выбрав Objective-C, видя, как это единственная поддерживаемая Apple среда.

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

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

Ответ 6

Что касается flash-компилятора, там может быть пара проблем:

• Скомпилированный двоичный файл объединяет все свои ресурсы в скомпилированное приложение, тогда как с XCode скомпилированные двоичные пакеты объединяют все как отдельные файлы. Это может стоить вам пространственно, так как есть методы сжатия, которые Apple использует на некоторых ресурсах (PNG и т.д.), Чтобы получить меньшие двоичные файлы с другой стороны. Более того, любая оптимизация обработки ресурсов, используемая операционной системой, не будет доступна для ресурсов во двоичном файле flash.
• Было высказано некоторое мнение относительно приемлемости флеш-компилированных бинарных файлов iPhone. Adobe - это то, что они являются законными двоичными файлами и не нарушают бинарные правила приложений iPhone, условия обслуживания и т.д. Apple не очень хорошо известна тем, что играет в доброжелательный диктатор в App Store, когда дело касается приложений, которые заставляют их нервничать. До тех пор пока он не станет приемлемым для Apple, разработчик caveat.

Ответ 7

Вот мой ответ как кто-то, кто купил MonoTouch и использует его в качестве основы для всех моих iPhone-приложений.

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

MonoTouch достаточно легко продлить/изменить по мере необходимости, если вы уже достаточно хорошо знаете CocoaTouch и ObjC. Таким образом, идея о том, что родные каркасы могут измениться, оставляя вас в пыли, не так важна.

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

MonoTouch принес мне некоторую серьезную прибыль от повышения производительности, от возможности использовать гораздо менее тонкий и болтливый язык для возможности использовать библиотеки, такие как Rhino Mocks и NUnit, из коробки.

MonoDevelop - отличная среда разработки в теории. Теоретически он также превосходит xcode. Он легкий, простой, очень простой в использовании, превосходный intellisense и макросы, и делает управление проектом iPhone намного проще, чем xcode. Но... это действительно багги. Это настоящий спад прямо сейчас.

Ответ 8

В App Store есть четыре приложения, которые полностью написаны в Squeak Smalltalk (и Seaside над ним), используя виртуальную машину, созданную Джоном Макинтошем (имя полностью совпадение).

Ответ 9

Я также искал альтернативы Objective-C, потому что писать это для меня просто неэффективно. В настоящее время я просматриваю XMLVM (http://xmlvm.org/overview/) как способ записи Java, который затем становится Objective-C исходным кодом. Есть много приятных вещей об этом решении, но самым большим, на мой взгляд, является то, что он создает исходный код Objective-C, поэтому вам не помешают привязать ваше основное приложение к API, которые еще не были сопоставлены с использованием XMLVM. Мое намерение состоит в том, чтобы написать ядро ​​моих приложений на Java, которое затем переносится на IPhone и Android, а затем добавить функциональность, специфичную для платформы, в дополнение к ней в Objective-C или Android-Java.

Ответ 10

Я бы предложил посмотреть на использование гибридного решения.

Из-за гибкости Objective-c вы можете реализовать свой интерфейс в Objective-c и вашей модели данных почти во всем остальном. Вы можете практически нарисовать интерфейс с помощью Interface Builder, поэтому ваше фактическое кодирование в Objective-c минимально. Реальные сложные части наиболее серьезных приложений находятся в модели данных, и именно там вы, скорее всего, имеете устаревший код или код из других проектов.

Как отмечено здесь другими, существует множество библиотек, которые позволяют склеить практически любой основной язык /API в Objective-c.

Ответ 11

Хотя использование С# и Java в Iphone заставит кого-то, у кого фон на этих языках будет более комфортным, я все равно буду придерживаться ObjectiveC.
Вначале будет проще использовать С# или Java, но позже может быть сложнее. Например, что, если Apple решит изменить структуру cocoatouch в будущем? Вы должны будете зависеть от monotouch, реализующего все эти изменения, и на самом деле будет отставать от тех парней, которые используют ObjectiveC.
Даже когда Apple все-таки сохраняет вещи, все равно будет возможно, что вы столкнетесь с причудами стека Mono и вам придется перепрыгнуть через обручи, чтобы все было сделано.

Ответ 12

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

Ответ 13

Как тот, кому был предоставлен ранний доступ к внешнему экспорту iPhone в Flash CS5, я надеюсь, что могу предоставить немного информации об этом. Для записи одна из моих игр, созданных с помощью этой технологии, была представлена ​​на конференции Adobe MAX 2009, поэтому общеизвестно, что я работал с ней, и я не нарушаю NDA, рассказывая о своем опыте, пока я придерживайтесь того, что Adobe уже раскрыла.

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

Как и следовало ожидать, существует большая разница в возможностях процессора между настольными и мобильными устройствами. К счастью, в процессе преобразования ActionScript 3 проходит через компилятор LLVM, который должен быть оптимизирован раньше, чем сборка ARM для iPhone. В результате производительность кода не страдает слишком сильно, если вообще. Большая часть моего кода из существующих проектов, которые я переношу на мобильный, остается неизменной. В основном, я должен переконфигурировать визуальный контент для установки на устройство и сосредоточиться на узких местах в программном обеспечении Flash. Даже на рабочем столе рендеринга, вероятно, являются главными разработчиками стен, на которых нажимают возможности Flash Player.

К счастью, одна вещь, которую инженеры Adobe, наконец, изучают, - это аппаратное ускорение (на самом деле, видео ускоряется в плагине рабочего стола, но только в определенных конкретных ситуациях). Например, пока объект отображения остается статичным, он может быть помечен как кешированный как поверхность и очень быстро нарисован на экране, поскольку он хранится в графической памяти. Другие интересные оптимизации могут быть сделаны для ускорения визуального контента, например, с использованием растровых изображений для замены экранных объектов с фильтрами (тени, свечения и т.д.). Такие вещи могут повысить производительность на рабочем столе, но ленивые разработчики не всегда делают то, что лучше, когда они выглядят "достаточно хорошо" на своих машинах. Некоторые из моих коллег считают, что такое изменение рабочего процесса неприемлемо, но я считаю, что это как вызов пробуждения о том, как ленивы некоторые из нас стали, так и очевидное требование перехода на более ограниченную платформу.

Ответ 14

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

Ответ 15

Есть попытка получить функциональный язык Haskell (скомпилированный или интерпретированный) на iPhone, но он, похоже, не очень быстро перемещается...

http://www.haskell.org/haskellwiki/IPhone

Ответ 16

Существует также Rhodes framework, который является интерпретатором ruby, позволяющим писать приложения стиля Rails с представлениями HTML.

Ответ 17

Недавно я написал сообщение в блоге с компиляцией фреймворков, используемых для создания приложений iPhone на других языках, которые могут оказаться полезными:

http://akosma.com/2009/10/29/iphone-apps-without-objective-c/

Ответ 18

Веб-приложение также является очень хорошей альтернативой, если вы хотите сделать приложение для своего веб-сайта. Многие аппаратные средства отображаются через некоторые из современных HTML5-API, а PhoneGap предоставляет вам еще несколько вариантов.

Вы можете избежать процесса утверждения Apple, если хотите, только разместив его в Интернете, или можете добавить его в App Store с помощью UIWebView для загрузки своего веб-приложения. PhoneGap также поможет вам в этом.

Есть еще один вопрос, который специально задает вопрос о инфраструктурах веб-приложений для iPhone, в котором перечислены много хороших альтернативных фреймворков: Доступная библиотека iPhone/веб-приложение JavaScript для веб-приложений iPhone

Поскольку JavaScript интерпретируется WebKit изначально на iPhone, Apple также одобряет эти приложения (в зависимости от качества). Браузер на iPhone является одним из лучших браузеров на мобильном телефоне прямо сейчас, но они не единственные. С небольшой дополнительной работой вы можете заставить ваше веб-приложение также работать с несколькими форматами. Питер-Пол Кох много исследовал состояние браузеров, а также регулярно блоги о веб-разработке для мобильных устройств. Просмотрите его научные результаты в мобильных браузерах или прочитайте некоторые из его нарезок (смешные и информативные): http://www.quirksmode.org/mobile/

Мне также нравится книга Джонатана Старка Создание приложений iPhone с помощью HTML, CSS и JavaScript

Вы даже можете сделать приложение доступным в автономном режиме с помощью файла манифеста: Ссылка Safari - HTML 5 автономный кэш приложений. Это также описано в книге Джонатана Старка, поэтому вы автоматически изменяете манифест при изменении ресурса. Поскольку браузер загружает все ресурсы, указанные в файле манифеста, его можно сравнить с обновлением приложения в App Store. За исключением этого момента и отсутствия одобрения;)