Что состояние неObjective C программирует для iPhone?

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

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

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

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

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

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

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

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

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

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

Unity для iPhone - хорошая платформа для разработки без использования ObjectiveC.

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

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

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

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

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

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

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

http: // www. haskell.org/haskellwiki/IPhone[1223 impression

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я хочу перейти на чистый C даже в родном приложении.

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

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

Я хочу перейти на чистый C даже в собственном приложении.

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

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

Это легкий, простой, очень простой в использовании, отличный intellisense и макросы, и он делает управление проектом iPhone намного проще, чем xcode. Но ... это действительно глючит. Это настоящее крушение.

Это легкий, простой, очень простой в использовании, отличный intellisense и макросы, и он делает управление проектом iPhone намного проще, чем xcode. Но ... это действительно глючит. Это настоящее крушение.

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

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

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

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

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

Есть еще один вопрос, в котором конкретно спрашивается о фреймворках для веб-приложений для iPhone, в котором перечислено множество хороших альтернативных фреймворков: Available iPhone Web Application JavaScript UI Library/Frameworks

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

Мне также нравится книга Джонатана Старка Building iPhone Apps with HTML, CSS, and JavaScript

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