Перевод: Comparing Titanium and PhoneGap или Сравнивая Titanium и PhoneGap

Недавно чтобы выбрать систему разработки простого мобильного приложения, пришлось осознать разницу между Titanium от Appcelerator и PhoneGap от Adobe.

Осознавать помогал Kevin Whinnery

Именно его статью я решил перевести для себя.

Примечание переводчика: Если вы, как и я перед переводом этой статьи, расчитываете найти в ней примеры кода, то я вас огорчу. Примеров кода в статье нет и после прочтения, в принципе становится ясно почему — слишком разные подходы. Статья обширная и в некоторых местах наполнена водой, но я перевел ее всю, для целостности. Сам Кевин работает в Appcelerator, поэтому статья получилась с некоторым информационным перевесом — о Titanium он знает больше, чем о PhoneGap. Тем не менее кое что новое для себя я вынес, а после всего потраченного на перевод мне просто жалко было стереть это все.

На докладах меня часто спрашивают в чем разница между Titanium и PhoneGap. Я решил выделить немного времени чтобы объяснить как каждая из технологий работает на высоком уровне и оценить то, насколько технологии отличаются.

С 10 тысяч метров PhoneGap и Titanium кажутся одинаковыми. Они оба предоставляют средства для кроссплатформенной разработки мобильных приложений. Оба требуют использования javascript и веб-технологий в каком-то объеме. Они оба имеют открытый исходный код с либеральными лицензиями (Titanium Mobile SDK — Apache 2.0, PhoneGap — MIT). Но на этом схожесть кончается. В то время как обе технологии существуют для кроссплатформенной разработки под мобильные устройства, философии и подходы их имеют мало общего. Также бизнес-цели, движущие каждым проектом с точки зрения компаний-спонсоров (Adobe для PhoneGap и Appcelerator для Titanium), очень разные. Далее я постараюсь описать эти технические и философские различия, а также различия в бизнес-моделях.

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

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

Давайте начнем с разбора PhoneGap и того, как он работает.

Чего пытается добиться PhoneGap?
Цель PhoneGap в том, чтобы позволить основанным на HTML веб-приложениям быть собранными и установленными, как нативные приложения (прим. переводчика: здесь и дальше по тексту автор невероятно часто использует слово native в отношении платформ и кода, аналога лучше подобрать не смог). PhoneGap веб-приложения обернуты в нативную оболочку и могут быть установлены через магазины приложений для нескольких платформ. Вдобавок, PhoneGap стремится предоставить набор часто используемых API функций, которые обычно недоступны веб-приложениям: доступ к камере, контактам устройства и сенсорам. Все это еще не доступно в обычном браузере.

PhoneGap можно считать авангардистом новых стандартов W3C Device API, потому что они пытаются приблизить эту будущую инновацию разработчикам настоящего. Сегодня ни одна платформа не может выполнять веб-приложения как нативные, хотя обещанная Mozilla платформа Boot To Gecko имеет все шансы изменить это. Micsrosoft тоже делает определенные успехи с Windows 8 в отношении первоклассного API доступа для веб-приложений. Но преимуществом PhoneGap является возможность предоставить все возможности веб-приложениям уже сегодня.

Процесс работы, инструментарий и интерфейс в PhoneGap для конечного пользователя
Для того, чтобы разрабатывать PhoneGap приложения, разработчики будут создавать HTML, CSS и JavaScript файлы в локальной директории, почти так же, как если бы они делали статический веб-сайт. На самом деле, некоторые PhoneGap разработчики выделяют как фичу то, что они могут вести разработку на десктопном браузере большую часть времени без необходимости в родном наборе инструментов.

Чтобы запустить PhoneGap приложение на нативном эмуляторе/симуляторе, разработчики будут собирать проект для каждой из платформ, которую они хотят поддерживать, настраивать корневую директорию проекта в Xcode, Eclipse и других нативных инструментах при необходимости, и потом запускать проект используя эти самые инструменты для нативной разработки. Более точные шаги выделены в руководстве для начинающих для каждой платформы в частности. Часто используются символические ссылки для «www» директории между нативными проектами, чтобы иметь единственную директорию проекта.

Для установки PhoneGap приложение на устройство придется выполнить те же действия. Тем не менее, чтобы облегчить этот процесс и снизить потребность в родной SDK, Nitobi (недавно приобретенная Adobe) создала сервис называемый PhoneGap Build, который будет собирать приложения в облаке. Функциональность для поддержки PhoneGap Build деплоймента была недавно включена в Adobe’s Dreamweaver. (прим. переводчика: PhoneGap Build может собирать приложения в облаке, но не думайте, что в этом случае вы сможете обойтись без MacOS, вам как минимум понадобится provision profile key)

Инструменты используемые с PhoneGap — это стандартные инструменты веб-разработки, такие как Firebug, Web Inspector, и любой редактор кода. Также существует новый инструмент для удаленного тестирования, известный как Weinre, который набирает популярность. В целом тот факт, что вы разрабатываете нативное приложение, остается для вас почти всегда абстрактным в процессе разработки.

Как работает PhoneGap
Как я упоминал ранее, PhoneGap это «нативно-обернутое» веб-приложение. Давайте рассматрим, как именно оно обернуто. Множество нативных SDK для мобильной разработки предоставляют виджет веб-браузера (так называемый «web view») как часть их UI фреймворка (iOS и Android например). В нативных приложениях элементы управления web view используются для отображения HTML, как с удаленного сервера, так и локальных файлов, встроенных в приложение. Нативная обертка приложения генерируемая PhoneGap загружает HTML страницы разработчика в одно из этих web view и отображает результирующий HTML как UI при запуске приложения.

Если в загружаемую страницу были включены js-файлы, этот код будет выполнен на странице как обычно. В любом случае нативное приложение, которое создает web view способно (различными способами, в зависимости от платформы) асинхронно взаимодействовать с js кодом, выполняемым внутри web view. Эту технологию обычно называют «мостом» в контексте архитектуры PhoneGap, в Titanium «мост» имеет немного другое значение, как мы увидим позже.

PhoneGap использует преимущества данного метода, чтобы создать Javascript API внутри web view, которое будет способно посылать и получать сообщения от машинного кода внутри приложения-обертки асинхронно. Способ реализации этой прослойки различается в зависимости от платформы. В iOS например, когда вы запрашиваете список контактов, ваш запрос к нативным методам становится в очередь запросов, которые будут посланы через мост. Затем PhoneGap создаст iframe, который загрузит адрес в протоколе («gap://»). Адрес будет обработан нативным приложением, под это настроенным. В этот момент все поставленные в очередь команды будут выполнены. Обратная связь с web view осуществляется путем выполнения js-кода в контексте этого самого web view машинным кодом.

Вообще-то PhoneGap — это намного большее, чем просто обмен сообщениями между APi, но сам обмен сообщения через «мост» — это ключевой момент технологии, которая позволяет внутренним веб-приложениям вызывать машинный код.

Расширяя PhoneGap
Чтобы писать расширения для PhoneGap, вам необходимо:

  • Написать js интерфейс для вашего расширения, которое будет использовать PhoneGap API для добавления сигналов в очередь для передачи на нижний уровень.
  • Зарегистрировать ваше расширение в родном проекте каким-либо способом — на iOS это делается с помощью Cordova.plist файла.
  • Написать нативный код, которому PhoneGap будет передавать сигналы из web view, и внутренних методов, если нужно
  • По сути, разработчики могут участвовать в том самом асинхронном обмене сообщениям, которое происходит с ядром PhoneGap API

Преимущества PhoneGap
В моих расчетах главная архитектурная сила PhoneGap в том, что он небольшой и простой. Он делает, то что должен, и делает это хорошо. Команда PhoneGap намеренно реализовала только самую базовую часть взаимодействия родных API с веб-приложением. Из-за того, что надстройка над родным API настолько мала, то становится относительно легко портировать PhoneGap во множество различных окружений. По сути, любая платформа, которая поддерживает web view или web runtime, может стать PhoneGap платформой.

Невизуальные родные расширения в PhoneGap тоже очень простые. Требования для регистрации нативного кода для получения сообщений от web view очень скромные. Простые родные расширения могут быть разработаны быстро. И я считаю, что эта архитектура хорошо используется.

Также существует преимущество в том, что родное API и разработка нативных приложений остаются почти полностью абстрактными для разработчика. Любой, кто может писать HTML, CSS, и немного Javascript, может обернуть веб-страницу в нативное приложение и поставлять ее на рынок таким образом. Порог вхождения в разработку под PhoneGap очень низок.

Слабые стороны PhoneGap
Качество пользовательского интерфейса в PhoneGap приложениях будет в основном зависеть от качества web view и движка рендеринга на платформе. Webkit силен и предоставляет лучшую производительность. Web view на Anrdoid функционален, но имеет определенные ограничения. На других платформах  производительность web view будет зависеть от версии операционной системы.

Остаются также стандартные кросс-браузерные проблемы, с которыми обычно приходится сталкиваться веб-разработчикам. В UI придется использовать разные технологии, media queries, хаки и прочие костыли, чтобы сохранить юзабельность на различных платформах. Очень кстати конечно, что множество платформ используют webkit, но все еще остаются существуенные различия даже в них.

Мобильные браузеры все время совершенствуются, и это поможет преодолеть многие проблемы. Но приближение браузерного отображения к нативному — это не тривиальная задача — Sencha например держит на полной ставке огромную команду экспертов в веб-программировании чтобы решить эту проблему. Но даже при этом, на большинстве платформ, на большинстве браузеров сегодня, достижение UI «идентичного натуральному», просто невозможно, даже с таким фреймворком, как Sencha Touch. Достаточно ли хорош браузер для этого сейчас? Это зависит от ваших требований, но браузер безусловно хуже, чем нативный UI. Иногда намного хуже, в зависимости от браузера.

PhoneGap также не может быть дополнен нативным UI. Готовое приложение само по себе живет внутри web view, и пользовательский интерфейс отрисовывается в HTML. При этом возможно общаться с нативной частью, создавать UI интерфейс, который будет работать отдельно по отношению к web view, но очень трудно или даже невозможно интегрировать динамический, DOM HTML UI с нативными компонентами. В Appcelerator пробовали это — мы пытались ассоциировать нативный UI с DOM элементами на ранней стадии, и вынуждены были отказаться от этой затеи, потому что результаты были непредсказуемыми и некачественными.

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

Мы вернемся к философским аспектам PhoneGap скоро, но сначала посмотрим на технические детали Titanium.

К чему стремится Titanium?
Цель Titanium Mobile в том, чтобы предоставить высокий уровень, кросс-платформенное выполнение Javascript, и API для мобильной разработки (сегодня мы поддерживаем iOS, Android и браузер. Поддержка BlackBerry 10 и Windows Phone ожидается в скором времени). Titanium на самом деле имеет больше общем с MacRuby/Hot Cocoa, PHP или Node.js, чем с PhoneGap, Adobe AIR, Corona или Rhomobile.

Существует основное API мобильной разработки, которое может быть нормализировано между платформами. Эти области должны быть направлены на повторное использование кода.

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

Исходя из этого, Titanium не пытается претендовать на принцип «пиши однажды, используй повсюду». Мы считаем существуют большой пользовательский опыт для платформ, который разработчики должны использовать. Мы считаем, что нативные приложения должны, где это применимо, использовать преимущества известных и высокопроизводительных нативных UI виджетов. В любом случае, мы считаем излишним, чтобы разработчики учили платформозависимые API, чтобы нарисовать квадрат или отправить HTTP запрос.

Titanium пытается добиться повторного использования кода с помощью унифицированного Javascript API, с платформозависимыми фичами и нативной производительностью, чтобы соответствовать ожиданиям пользователя. Когда вы пишите Titanium приложение, вы пишите нативное приложение на Javascript. Titanium должен считаться фреймворком для написания нативных приложений, вместо абстрагирования от платформы, под которую вы пишите.

Процесс работы, инструментарий и интерфейс в PhoneGap для конечного пользователя
Для разработки нативных приложений на Titanium, разработчики должны установить нативные наборы инструментов для iOS и Android. После этого разработчик как правило взаимодействует только с Titanium SDK (в данный момент основанном на python). Это взаимодействие можно также производить через командную строку или (чаще) через Titanium Studio, нашу IDE, основанную на Eclipse.

Используя набор инструментов Titanium, вы создаете директорию проекта приложения, которая содержит конфигурационный файл, файлы локализации и директории, содержащие изображения, ресурсы и js исходники, которые вы будете писать, для того, чтобы оживить ваше приложение. По умолчанию вы не будете писать HTML и CSS код, пока вам не понадобится гибридное приложение, которое должно будет содержать и нативный, и HTML UI. Приложения на Titanium могут и часто применяют гибридные UI, такие как приложение Facebook. Такое приложение может одновременной использовать PhoneGap и Titanium, но к сожалению это за пределами данной темы.

Используя этот набор инструментов, ваше приложение будет запускаться, используя настоящий эмулятор/симулятор для целевой платформы. Titanium Studio также предоставляет пошаговую отладку, дополнение кода и другие вкусности уровня IDE.

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

Когда наступит время опубликовать ваше приложение в appstore’ах, наша система позаботится о создании конечного билда для вас. Это делается локально на машине разработчика используя нативные инструменты. Процесс загрузки будет тот же, что и для разработчиков, пишущих нативные приложения.

Во время разработки приложения на Titanium, основные инструменты абстрактны. Они должны присутствовать в разработке, но конечный разработчик редко вынужден использовать их. Тот факт, что создаются нативные приложения при этом не абстрактен. UI создается с кроссплатформенными и платформо-специфичными компонентами и ваше приложение будет работать с фоновыми сервисами, локальными уведомлениями, значками изображений, конфигурациями, активити (для Android)… всеми штуковинами, которые доступны через Titanium Javascript API.

Как работает Titanium
Совсем немного происходит за сценой внутри Titanium приложения. Но в принципе во время выполнения, ваше приложение состоит из трех основных компонентов — вашего js-кода (вписанного в Java или Objective-C файл и скомпилированного, как кодированная строка), платформо-специфичных реализаций Titanium API и нативных программных языков, а также js интерпретатора, который будет использован, чтобы выполнять ваш код на лету (V8 по умолчанию от Rhino для Android, или JavaScriptCore для iOS). Исключение составляет браузер, где будет использован встроенный js движок.

Когда ваше приложение запустится, исполняемое js окружение будет создано в нативном коде и исходный код вашего приложения будет выполнен. Внедрение в исполняемое js окружение вашего приложения — это то, что мы называем «прокси» объектами, которые по сути являются js-объектами, имеющими парные объекты в нативном коде. В разговоре мы будем часто употреблять «Javascript сторону» и «нативную сторону», когда будем говорить о приложениях на Titanium, потому что эти две сущности можно сравнить с параллельными вселенными. Прокси объекты существуют и на js-стороне и на нативной стороне, и выступают в качестве «моста» от одной стороны на другую.

В вашем js-коде, когда вы вызываете метод глобального Titanium или Ti объекта, например так
var b = Ti.UI.createButton({title:’Poke Me’});
то это вызывает нативный метод, который создаст нативный UI объект, и создаст прокси объект (b), который предоставляет свойства и методы нативного интерфейса UI объекта в javascript.

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

Надеюсь это поможет исправить два распрастраненных заблуждения о Titanium.

  1. Titanium не требует web view. Разработчик может создавать web view как нативный виджет, но web view не используется для выполнения исходного кода Titanium.
  2. Javascript код не прекомпилируется в Objective-C или Java. Ваш javascript будет выполнятся на лету.

Расширение Titanium
Titanium может быть расширен с помощью визуальных и невизуальных средств. Создавая Прокси и/или View-Прокси интерфейс в нативном коде, разработчик может создать новую нативную функциональность для Titanium приложений. Мы предоставляем разработчикам iOS и Android тот же интерфейс, который сами используем для создания внутренних интерфейсов Titanium.

Сильные стороны Titanium
Так как цель Titanium в том, чтобы предоставить высокий уровень API для нативной mobile-разработки между платформами, то вы получите доступ к широкому массиву нативных фич и функций «из коробки», от компонентов UI до интерфейсов сокетов для интеграции системы уведомления. Цель Titanium в том, чтобы убрать пропасть в функциональности между Titanium и чистыми нативными приложениями. Похоже мы никогда не сможем поддерживать весь API платформ прямо из коробки, но мы хотим охватить 90% всех типичных случаев и предоставить платформу, где оставшиеся 10% смогут быть легко добавлены людьми, которым это понадобиться

Так как Titanium можут быть расширен визуальными компонентами, которые подключаются в ту же view-иерархию, как и остальная часть приложения, то вы способны разработать любой пользовательский интерфейс, который возможно реализовать на соответствующей нативной платформе. Вам нужна таблица чтобы скролилась на 60fps с помощью специального нативного кода? Вы можете сделать это. Хотите легко интегрировать OpenGL для отрисовки поверхности в игре и сохранить логику в js-цикле? Вы можете это сделать. Вы можете интегрировать расширения UI прямо в основное ваше приложение вместе с ядром Titanium.

Внешний вид Titanium приложений, использующий стандартные UI виджеты — это тоже одна из сильных сторон платформы. Не требуется визуальной эмуляции (ни через CSS, ни через рендеринг UI виджетов на OpenGL или Flash). Когда вы создаете NavigationGroup, она будет использовать UINavigationController в iOS. Анимации и поведения соответсвуют нативным, потому что вы используете те самые элементы интерфейса.

Так как Titanium предоставляет высокоуровневый доступ к нативному API в javascript, порог входа для программирования на нативной платформе ощутимо низок для всех, кто использовал язык семейства ECMASctipt.

Недостатки Titanium
Рамки Titanium API делают добавление новых платформ сложным. Разработка Titanium API на новой нативной платформе — это сложное мероприятие. Поэтому платформа Titanium поддерживает только самые основные современные платформы: iOS, Android и Web.

Наш мобильный веб-браузер еще далек от совершенства — мы продолжаем работать над производительностью и рендерингом набора UI виджетов, также как и над усовершенствованием ядра Titanium API.

Из-за слоя абстракции, предоставляемого Titanium, остаются большие, неоптимальные реализации API внутри нашего фреймворка. Некоторые компоненты интерфейса не работают так, как работают нативные аналоги, например большие таблицы с очень кастомизированными шаблонами. Оптимизация ядра нашего пользовательского интерфейса остается первоочередной технической целью нашей команды. По мере того, как мы исправляем баги и по мере того, как совершенствуется аппаратная часть, проблемы уходят. Мы также считаем, что информационная архитектура, особенно для больших наборов данных, должна быть применена во многих случаях.

Также в связи с амбициозностью Titanium платформы, расширение Titanium является не тривиальным. Хорошее ззнание архитектуры Titanium и окружения важно для эффиктивной интеграции нового элемента нативного API. Опыт разработчиков, документация по API и хорошие инструкции для разработчиков модулей были значительно усовершенствованы с релиза 2.0, но мы все еще работаем над ними.

Различия в философии
Теперь надеюсь технические различия между PhoneGap и Titanium достаточно ясны. Но помимо этих различий, цели и направления каждого проекта также различаются. Заявленная цель проекта PhoneGap в конце концов рано или поздно перестанет существовать. Как и было заявлено, PhoneGap предназначен быть передовой разработкой внедрения Device API в браузеры. В теории, в случае если производители браузеров разработают такие функции сами, то платформа PhoneGap больше не будет нужна. Сама по себе PhoneGap платформа не предназначена быть платформой — это прослойка для добавления нативной функциональности в веб-приложения. Сам веб является платформой.

Новый спонсор PhoneGap, Adobe, также очень заинтересован в усовершенствовании веба, как платформы. В последние месяцы, Adobe агрессивно выпускает инструменты, которые позволят разработку HTML5/CSS3 веб-приложений. Мне кажется очевидным (и не только мне), что Adobe видит уменьшение роли Flash по мере того, как совершенствуются веб технологии.

В своей основе, Adobe — это бизнес по производству инструментов. Платформы — это каналы, через которые Adobe может продавать инструменты. Когда-то такой платформой был Flash. Теперь эта платформа — веб браузер (вдобавок к Flash). Я не знаю точно, как PhoneGap влияет на план выпуска продуктов Adobe, но по многим параметрам он служит той же цели, что и Flash. PhoneGap пытается создать абстрактное окружение для кроссплатформенной разработки.

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

Стоит отметить, однако, что Adobe не руководящий орган проекта Cordove, на котором сейчас базируется PhoneGap. Проектом Cordove владеет и управляет Apache Software Foundation. Пока неясно, как будут отличаться оба проекта, но причуствие подсказывает, что отличаться они будут солидно. Я думаю их цели будут связаны в философском смысле.

Appcelerator тоже заинтересован в поддержке расширения веб платформы. Все выигрывают, когда веб становится сильнее, как платформа для приложений. Разница в том, что мы смотрим на веб, как на самую великую платформу среди других, с уникальным характером и набором сильных и слабых сторон. Мы не ждем, что веб станет единственной платформой для мобильных приложений. Мы думаем, что платформы, такие как iOS, Android, BlackBerry, Windows Phone будут оставаться влиятельными и предоставят много полезного пользователям. Это соревнование будет полезным для потребителей, но останется проблемой для разработчиков.

Через Titanium мы хотим предоставить разработчикам путь для охвата веб и нативных платформ на одной кодовой основе, сохраняя при этом фичи, производительность и тесную интеграцию с платформой, которую ожидает пользователь. Мы хотим построить прочную платформу для разработки мобильных приложений, с сервисами и инструментами для ускорения самого процесса. Мы не производим инструменты, мы производим платформу и наш успех — это успех разработчиков, пишущих на нашей платформе. Со временем мы планируем построить open source платформу в духе Red Hat или других гигантов в этой сфере.

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

Источник: http://kevinwhinnery.com/post/22764624253/comparing-titanium-and-phonegap

Надеюсь кому-то будет полезно.

Полезно(5)Бесполезно(0)

Добавить комментарий