приложения для iPhone: Веб-приложения или собственный компонент?

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

Требование является на самом деле довольно основным. Приложения для iPhone должны отправить данные и получить данные из базы данных, которая также используется веб-приложениями. У пользователя был бы тот же доступ к веб-приложениям, только я хочу это характерное для iPhone, поскольку пользовательский опыт был бы другим использованием веб-приложения и приложения для iPhone. Мне также интересно продавать приложение на Apple Store.

На основе Вашего опыта, что было бы лучше для этого вида требования, iPhone собственные или веб-приложения? Что недостатки создают собственные приложения для iPhone и веб-приложения, который работает на браузере iPhone? Кроме того, я только ограничен Objective C для создания собственных приложений для iPhone? Или есть ли какая-либо другая платформа для этого?

Будьте нежны на мне, я не запускаю flamewar.

6
задан Joshua Partogi 16 May 2010 в 00:48
поделиться

3 ответа

Если вы хотите иметь приложение в 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, может компилироваться и непосредственно связываться с документированными APIs (например, Приложения, которые связываются с Документированные API через промежуточный перевод или уровень совместимости или инструмент запрещены).

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

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

1
ответ дан 16 December 2019 в 21:36
поделиться

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

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

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

1
ответ дан 16 December 2019 в 21:36
поделиться

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

6
ответ дан 16 December 2019 в 21:36
поделиться