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

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

Я знаю о двух существующих альтернативах и одной будущей возможности.

C #

  • Xamarin (ранее MonoTouch) - это реализация C # .NET с привязками для определенных функций iPhone, таких как сенсорный экран и акселерометр. Он интегрируется с Xcode и Interface Builder, а также позволяет создавать пользовательские привязки Objective-C.

Java

  • alcheMo-для-iPhone генерирует код C ++ для компиляции для iPhone из источника J2ME. Он также обеспечивает привязку сенсорного экрана и акселерометра.

Flash / ActionScript 3

  • Adobe объявила, что Flash Professional CS5 позволит развертывать приложения Flash для iPhone. Подробности пока не предоставлены.

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

РЕДАКТИРОВАТЬ: Я знаю недостатки использования Objective-C и предоставленных структур. Я хотел бы получить информацию о возможных решениях от людей с опытом, делающими это, а не о причинах, почему Objective-C лучше.

Ответы [ 18 ]

1 голос
/ 26 ноября 2009

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

1 голос
/ 10 ноября 2009

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

1 голос
/ 09 ноября 2009

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

1 голос
/ 09 ноября 2009

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

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

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

1 голос
/ 09 ноября 2009

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

1 голос
/ 16 января 2010

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

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

1 голос
/ 20 июля 2010

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

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

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

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

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

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

1 голос
/ 26 ноября 2009

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...