Приложения для iPhone: веб-приложения или нативные?

Если вы хотите иметь приложение в iTunes App Store, вы должны написать приложение на Objective-C. Вот цитата из соглашения с разработчиком iPhone OS 4.0, взятого из Daring Fireball. Я выделил наиболее актуальный раздел.

3.3.1 - Приложения могут использовать только Документированные API в порядке, предписанном Apple, и не должны использовать или вызывать какие-либо частные API. Приложения должны быть изначально написаны на Objective-C, C, C ++ или JavaScript в том виде, в каком они выполняются движком iPhone OS WebKit, и только код, написанный на C, C ++ и Objective-C, может компилироваться и напрямую связываться с Документированными API (например, Приложения, которые ссылаются на Документированные API через промежуточный уровень или инструмент перевода или совместимости, запрещены).

Это, конечно, не относится к OS 3.1 или 3.2, и в настоящее время неизвестно, удалит ли Apple после выхода OS 4.0 задним числом все существующие приложения, которые использовали такие инструменты. Теоретически, если вам удастся выпустить приложение до того, как выйдет 4.0, и вам повезет, то, возможно, вы могли бы использовать что-то вроде PhoneGap, но на данный момент кажется действительно большой авантюрой потратить время на такие инструменты. .

Тем не менее, Objective-C на самом деле не так уж и сложно изучить, его основной синтаксис - [someObject doSomething]; или [someObject doSomethingWith:thisObject];. У меня очень мало знаний о веб-разработке, поэтому я не могу говорить о его достоинствах или недостатках, но если у вас все настроено в веб-приложение, возможно, вы захотите склониться либо к гибридному варианту, упомянутому выше, либо к использованию исключительно веб-интерфейса.

Вы можете съесть торт и съесть его.

Вы можете легко смешивать веб-приложение и собственное приложение, используя экземпляры UIWebView, например реализовать чувствительные к производительности части в коде Какао / Objective-C и вставлять представления WebKit частями, которые потребовали бы слишком много времени, чтобы переписать их как родные.

Вы даже можете обернуть все веб-приложение в нативный пакет, если хотите распространение в App Store - см. PhoneGap.

Вы также можете разработать чистое веб-приложение, которое не будет выглядеть так, как будто оно запущено через Safari, если пользователь добавит вашу страницу на свой домашний экран - см. jQTouch.

Недостатки:

Веб-приложения могут быть не такими быстрыми, как собственные приложения, хотя с автономной поддержкой HTML5 и расширениями, специфичными для WebKit, такими как переходы и анимация, вы можете уйти довольно далеко. Убедитесь, что вы используете события касания - Safari с задержками onclick.

Трудно сделать так, чтобы чистое веб-приложение выглядело как полноценное нативное приложение. Например, мобильный WebKit не поддерживает position:fixed, необходимый для репликации верхней панели навигации, а веб-представления имеют скорость прокрутки, отличную от представлений таблиц. Это поправимо, но для этого требуется тонна JavaScript.

Преимущества:

Быстрое развитие. Я действительно оценил, насколько полезен CSS / HTML для сложных макетов, когда мне приходилось реплицировать приложения в UIViews (InterfaceBuilder подходит только для полуфиксированного макета).

Вы застрахованы от того, что Apple внезапно возненавидит и запретит что-то еще. Если они удалят ваше приложение из AppStore, вы можете предоставить пользователям доступ к нему через Интернет (Google сделал это с приложениями Voice и Latitude).

Легче переносить веб-приложения на Android и другие (WinMo, HP Pre, последние BlackBerries и т. Д.). Apple занимает первое место в мире, но доля ее умов не пропорциональна доле на рынке. Другие догоняют.

Если вы выберете родной

Вы должны делать это так, как Apple: Objective-C и Какао (вы можете делать части приложения на простом C или C ++). По этой теме есть множество руководств и книг, поэтому я не буду их здесь повторять. Просто несколько случайных советов:

• Несмотря на то, что файлы plists являются родным для iPhone форматом, они не подходят для взаимодействия клиент-сервер. XML-списки связаны с большими накладными расходами даже по стандартам XML, а создание и отладка двоичных списков может оказаться сложной задачей. JSON на самом деле быстрее и обычно с ним проще работать.

• Если вы извлекаете только небольшие кусочки информации, NSConnection только усложняет ситуацию. Вы можете просто использовать [NSData dataWithContentsOfURL:] в методе, запущенном через performSelectorInBackground:.

• Уведомления не доставляются, пока UITableView прокручивается. Если вы хотите, чтобы изображения в таблице загружались лениво, загрузите и установите их с помощью обратных вызовов.

PhoneGap, о котором упоминает Ной, определенно является маршрутом, которым вы можете воспользоваться, чтобы разработать HTML + javascript и при этом упаковать это для распространения, а также для использования преимуществ ряда отличных встроенных функций iPhone.

Все остальное зависит от некоторых элементов, которыми вы не поделились. Насколько быстрым и плавным должен быть ответ от пользовательского интерфейса / поиска? Это место, где задержка веб-приложения, даже в сети 3G, может побудить вас искать альтернативу для более быстрого локального представления (с использованием всего локального или даже Objective-C).

Другие места, которые не звучат так, как будто они находятся на вашем пути, чтобы искать, где вы могли бы захотеть сделать Objective-C напрямую, - это более тяжелая графика и манипуляции с анимацией (хотя javascript + Canvas и HTML5 делают меня лжецом там), используя камеру и / или микрофон для записи мультимедиа, или что-то, что требует достаточно большого объема интенсивной обработки. И последнее - это действительно вопрос о том, где вы можете и хотите ли вы, чтобы эта работа была проделана? На серверах (типичный выбор в стиле Google) или на устройстве?