Компания
68,16
рейтинг
4 июня 2013 в 18:31

Разработка → PhoneJS — Новый HTML5-фреймворк для мобильных приложений

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

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



В настоящее время веб-технологии и JavaScript, в частности — это очень либеральная среда, не привязанная к конкретным средствам и методологиям разработки. Как в любой подобной ситуации, с одной стороны это дает свободу, с другой стороны вносит долю хаоса.

Мы в DevExpress организовали небольшую команду, которая на протяжении нескольких месяцев анализировала и пробовала различные существующие средства и подходы. Результат полученного опыта — PhoneJS — наше комплексное решение для создания кросс-платформенных мобильных приложений на HTML5.

Мы не стали писать PhoneJS с нуля. Взяли jQuery, потому что сегодня для многих это синоним слова JavaScript. Затем добавили упоминавшуюся несколько раз на Хабре библиотеку Knockout, реализующую паттерн Model-View-ViewModel (MVVM) для JavaScript, и выбрали MVVM рекомендованным подходом к структурированию приложения. Использование Apache Cordova (aka PhoneGap) позволило выйти из изоляции внутри WebView браузера и получить доступ к камере, файловой системе, акселерометру и другим функциям устройства. Сочетание этих компонентов помогло создать отличный фундамент для фреймворка.

На этом фундаменте мы построили layout-движок и UI-компоненты, адаптирующие свой внешний вид под три самых популярных платформы — iOS, Android и Windows Phone 8.

Стоит упомянуть, что всё большее количество сотрудников компаний пользуются на рабочем месте своими собственными мобильными устройствами. Идея создания кросс-платформенных приложений хорошо согласуется с этим трендом (известным под названием Bring Your Own Device, BYOD) и позволит сотрудникам устанавливать необходимое для работы корпоративное ПО на свои смартфоны и планшеты.



Сейчас на примере очень простой демки TipCalculator давайте посмотрим, как выглядит приложение на фреймворке PhoneJS. Несмотря на то, что TipCalculator состоит из одного экрана, его будет достаточно для понимания подхода и базовых принципов работы.

Приложение реализует алгоритм расчета чаевых. Исходный код доступен на GitHub, а посмотреть его в действии можно в онлайн-симуляторе.

В сущности, это Single Page Application на HTML5. Точка входа — файл index.html, в котором вы увидите только необходимые META-теги и подключение всех остальных ресурсов. Обратите внимание, как подключаются view-файлы

<link rel="dx-template" type="text/html" href="views/home.html" />

Такой подход позволяет избежать распространенной проблемы Single Page приложений, когда всю HTML разметку приходится держать в одном длинном index.html. Мы соблюдаем принципы декомпозиции приложения и облегчаем последующие этапы разработки и отладки.

В файле index.js объявляется пространство имен TipCalculator и создается объект-приложение:

TipCalculator.app = new DevExpress.framework.html.HtmlApplication(...)

Приложению мы сообщаем тип layout-а, используемый по умолчанию. В данном случае это самый простой из возможных — empty layout, однако есть и более функциональные варианты с навигационной панелью и так популярной сегодня боковой навигацией.



Здесь необходимо сделать отступление о том, что же такое layout вообще. В PhoneJS мы применили знакомую, проверенную и, давно известную вам идею декорации страниц (представлений, экранов) с помощью layout. Так делается в многочисленных серверных web-фреймворках (Ruby on Rails, ASP.NET MVC и многих PHP-библиотеках).

Подробнее про Views и Layouts можно почитать в нашей документации.

Есть и маршрутизация (routing):

TipCalculator.app.router.register(":view", { view: "home" });

Таким образом мы зарегистрировали простой маршрут, который из адресной строки (а если точнее, то из hash-сегмента) получает имя текущего экрана (view), причем экран «home» будет использоваться по умолчанию. Его и рассмотрим.

View Model

В файле views/home.js в пространство имен TipCalculator добавляется функция home, которая создает view-model (модель представления) для экрана home

TipCalculator.home = function(params) {
    . . .
};

Есть три входных параметра: сумма чека (billTotal), количество участников (splitNum) и размер вознаграждения (tipPercent). Они объявлены как observable, чтобы их можно было привязывать к UI-компонентам и отслеживать изменения значений

var billTotal = ko.observable(),
    tipPercent = ko.observable(DEFAULT_TIP_PERCENT),
    splitNum = ko.observable(1);

На основании пользовательского ввода вычисляются 4 результата: totalToPay, totalPerPerson, totalTip и tipPerPerson. Все четыре являются dependent observable (или computed) — то есть обновляются автоматически при изменении хотя бы одного observable, задействованного в вычислении результата.

var totalTip = ko.computed(...);

var tipPerPerson = ko.computed(...);

var totalPerPerson = ko.computed(...);

var totalToPay = ko.computed(...);

Финальную сумму, как правило, округляют, для чего есть две функции roundUp и roundDown, изменяющие значение roundMode. Его изменение влечет пересчет зависящего от него totalToPay:

var totalToPay = ko.computed(function() {
    var value = totalTip() + billTotalAsNumber();

    switch(roundMode()) {
        case ROUND_DOWN:
            if(Math.floor(value) >= billTotalAsNumber())
                return Math.floor(value);
            return value;

        case ROUND_UP:
            return Math.ceil(value);

        default:
            return value;
    }
});

Однако при изменении каждого из входных параметров необходимо сбросить округление, чтобы пользователь видел точные цифры, для этого с помощью метода subscribe мы подписываемся на их изменение:

billTotal.subscribe(function() {
    roundMode(ROUND_NONE);
});

tipPercent.subscribe(function() {
    roundMode(ROUND_NONE);
});

splitNum.subscribe(function() {
    roundMode(ROUND_NONE);
});

View model очень проста, особенно для тех читателей, кто уже знаком с Knockout. А для тех, кто не знаком, это хорошая демонстрация его возможностей.

View

Перейдем к HTML-разметке, а именно к файлу views/home.html. На верхнем уровне расположены два специальных div-элемента: для view с именем “home” задается разметка для области с именем “content”.

<div data-options="dxView : { name: 'home' }">
    <div data-options="dxContent : { targetPlaceholder: 'content' }">
        . . .
    </div>
</div>

Внутри расположен тулбар:

<div data-bind="dxToolbar: { items: [ { align: 'center', text: 'Tip Calculator' } ] }"></div>

dxToolbar — это виджет из состава PhoneJS. Его описание в разметке реализовано в виде Knockout-привязки (binding).

Ниже идут филдсеты. Для их создания применяются предопределенные во фреймворке CSS классы dx-fieldset и dx-field. Внутри поле для ввода суммы и два слайдера для процентов и количества человек:

<div data-bind="dxNumberBox: { value: billTotal, placeholder: 'Type here...', valueUpdateEvent: 'keyup', min: 0 }">
</div>

<div data-bind="dxSlider: { min: 0, max: 25, step: 1, activeStateEnabled: true, value: tipPercent }"></div>

<div data-bind="dxSlider: { min: 1, step: 1, max: 10, activeStateEnabled: true, value: splitNum }"></div>

Далее — две кнопки (dxButton) для округления итоговой суммы и вывод результатов.

<div class="round-buttons">
    <div data-bind="dxButton: { text: 'Round Down', clickAction: roundDown }"></div>
    <div data-bind="dxButton: { text: 'Round Up', clickAction: roundUp }"></div>
</div>

<div id="results" class="dx-fieldset">
    <div class="dx-field">
        <span class="dx-field-label">Total to pay</span>
        <span class="dx-field-value" style="font-weight: bold" data-bind="text: Globalize.format(totalToPay(), 'c')"></span>
    </div>
    <div class="dx-field">
        <span class="dx-field-label">Total per person</span>
        <span class="dx-field-value" data-bind="text: Globalize.format(totalPerPerson(), 'c')"></span>
    </div>
    <div class="dx-field">
        <span class="dx-field-label">Total tip</span>
        <span class="dx-field-value" data-bind="text: Globalize.format(totalTip(), 'c')"></span>
    </div>
    <div class="dx-field">
        <span class="dx-field-label">Tip per person</span>
        <span class="dx-field-value" data-bind="text: Globalize.format(tipPerPerson(), 'c')"></span>
    </div>
</div>

Даже на таком простом примере мы чётко видим, как быстро с помощью PhoneJS создать мобильное приложение, обладая навыками веб программирования. Минимум кода, структурированность и простота освоения.

Запуск, отладка и упаковка для маркетов

Приложения на HTML5 очень легко отлаживать. Достаточно настроить ваш локальный веб-сервер (Apache, IIS, nginx или любой другой) на папку с исходными кодами и открыть URL на устройстве, в эмуляторе устройства или в браузере. Правда в браузере будет необходимо подменить строку UserAgent, чтобы он представлялся смартфоном или планшетом. К счастью, developer tools современных браузеров это легко позволяют.



Другой удобный вариант — это Ripple Emulator, работающий в браузере.



Но нам хочется получить настоящее мобильное приложение, с возможностью публикации в маркеты (AppStore, Google Play и Windows Store).

Конечно же, придется зарегистрироваться как разработчик на сайтах Apple, Google и Microsoft, но этот процесс хорошо описан для каждого из магазинов, так что отдельно заострять внимание на этом не будем.

PhoneGap содержит нужные инструменты и шаблоны проектов. Основной сценарий работы с PhoneGap привязан к SDK мобильной платформы. Например, чтобы собрать APK для Android нужно будет установить Android SDK и создать в Eclipse PhoneGap-проект, а для разработки под iOS понадобится Mac.

Более простой путь, избавляющий нас от установки платформенных SDK — использовать онлайн-сервис PhoneGap Build, который позволяет бесплатно собирать одно приложение (для большего количества необходимо приобрести платный аккаунт). Имея необходимые сертификаты, с помощью PhoneGap Build, буквально через пару кликов можем получить мобильное приложение для разных платформ. Останется только подготовить описания, промо-материалы, картинки, иконки и приступать к публикации вашего приложения.

Небольшая ложка дегтя: на сегодняшний день PhoneGap Build не поддерживает упаковку для Windows Phone 8 (планируют добавить позже в этом году), и для сборки пакетов понадобится Windows Phone SDK и шаблон CordovaWP8App, включенный в дистрибутив PhoneGap.

Для пользователей Visual Stuido у нас есть отдельный продукт DXTREME Mobile (включающий PhoneJS в качестве одного из компонентов), позволяющий собирать приложения для iOS, Android и Windows Phone 8 непосредственно из среды разработки.



Итак PhoneGap + PhoneJS — все что нужно для разработки мобильных приложений

PhoneGap реализует доступ к аппаратным возможностям и решает задачу упаковки в нативные пакеты.

PhoneJS предоставляет инфраструктуру для Single Page приложений и набор оптимизированных под touch-устройства элементов для построения кроссплатформенного UI.

Списки с эластичной прокруткой, «бесконечной подгрузкой» и поддержкой жеста «pull down to refresh», переключатели ON/OFF, различные кнопки и поля ввода, галерея, карты и навигационные элементы — всё это есть в PhoneJS. Посмотреть примеры можно в демо-приложении Kitchen Sink.

Все виджеты можно использовать в двух режимах — как Knockout binding:

<div data-bind="dxCheckbox: {checked: checked} "></div>
<script>
    var myViewModel= {
            checked: true
    };
    ko.applyBindings(myViewModel);
</script>

и как jQuery-плагин:

<div id="checkboxContainer" ></div>
<script>
    $(function() {
        $("#checkboxContainer").dxCheckbox({
            checked: true
        });
    });
</script>

Предвосхищая естественный вопрос читателя, чем PhoneJS лучше / хуже / выделяется на фоне существующих известных решений, мы подготовили нашу реализацию для PropertyCross. Это интересный проект, цель которого сравнить разные существующие подходы к мобильной разработке.

Отметим важную деталь: PhoneJS не похож на большинство наших продуктов — он не привязан к определенному средству разработки. Дистрибутив — это zip-архив, а в качестве инструментов разработки и отладки можно использовать ваш любимый текстовый редактор, ваш любимый веб-сервер и developer tools вашего любимого браузера. Скачать PhoneJS можно по этой ссылке.

P.S. PhoneJS бесплатен для некоммерческого использования. А наша служба поддержки готова ответить на ваши вопросы и помочь преодолеть возникшие трудности.
Автор: @AlexAkimov

Комментарии (71)

  • +4
    У меня наверно глупый вопрос. Я смотрел на вашу демку tip calculator, там есть qr код для девайса. Я отсканил его и на wp8 девайсе, она открыласб в браузере устройства — выглядит оно далеко не так как на экране.
    А есть какая нибудь более существенная демка, мне любопытно насколько это шустро работает.
    • +1
      phonejs.devexpress.com/Demo — там три демки. Kitchen Sink например показывает все виджеты которые у нас есть.
      Насчет того что выглядит не так как на экране — не очень понятно. Если не так как на скриншоте — это потому что по-умолчанию для iOS, Андроид и WP8 применяются разные темы — приложение будет выглядеть так, как «принято» на данном устройстве.
  • +1
    А как же qooxdoo mobile (http://demo.qooxdoo.org/current/mobileshowcase/index.html)?
    На мой взгляд, неплохой продукт получился.
    Конечно, у них пока нет поддержки WinPhone, да и реализация под Android не столь красива, но работает она вполне стабильно.
  • +8
    Хмм. Честно говоря совсем не нативные ощущения на iOS.
    А это первое, что ожидается от такого фреймворка.
    • +15
      А разве на JS+HTML5 можно написать что-то, что будет настолько же отзывчивым как и native?
      • 0
        Посмотрите на документацию к iPhone
      • –4
        Наверное, если сделать из JS -> objective C по типу GWT, то получится.
      • +1
        >А разве на JS+HTML5 можно написать что-то, что будет настолько же отзывчивым как и native?

        Как это нынче модно говорить, «я просто оставлю это здесь»:

        • +1
          Это все круто, но их демо Kitchen Sink на iPhone 4 ворочается как беременная, еще и куча визуальных багов. Когда нужно написать простой прототип — веб-приложение — лучший выбор. Если нужно вылизать до юзабельного состояния, то тут лучше нативное.
  • +4
    Попробовал демки — на iOS работает очень шустро, субъективно — шустрее чем sencha.
    • +2
      Скажите, а на демке с кухней (раздел Формы), у вас кнопки не подтормаживают, при нажатии?
      У меня в Файерфоксе на ноуте подтормаживает на 1-2 секунды.

      На айфоне немного пошустрее, конечно, но совсем немного.
      • +3
        Switch работает с совсем небольшой задержкой относительно родного. Checkbox хуже, включается не всегда с первого нажатия.
        А насчёт кнопок — при нажатии остаются в нажатом состоянии на пару секунд.
  • +7
    На lumia 520 жуткие тормоза. я бы не пользовался прилложением, которое так работает
  • +14
    Да уж очень сыро. С начала всё вроде хорошо, и походу на встроенное приложение, но когда доходит дело до контров, понятно, что это не то. Ну и…
    > Взяли jQuery, потому что сегодня для многих это синоним слова JavaScript.
    Ещё не понял, кого мне больше жаль, вас или их.
  • –15
    Дизлайк.
    Ваши амбиции не совместимы с jQuery программированием.
    • –3
      У кого баттхерт? У разработчиков либы?
    • –2
      Или фанатов jQuery?

      Использовать заведомо медленные подходы в разработке мобильных приложений на HTML это фейл и мне больно видеть, как благодаря таким проектам жизнеспособная парадигма хоронится живьем. Это антиреклама платформы.
      • +3
        Ну, мы ускорим где надо. Если где тормозит, то это не факт что jQuery виновато, мы и сами с усами :-). Не все сразу дается, особенно на разных платформах. Мы не обязаны везде jQuery использовать, мы взяли его за некую основу/базу чтобы людям позволить оставаться в знакомых парадигмах, а не так как у Sencha Mobile.
        • +2
          если не секрет, почему не взяли Zepto.js вместо jQuery?
          • 0
            Например, у Zepto ситуация с поддержкой существующих браузеров сложнее, нежели у jQuery.
            If you need to support Internet Explorer, you can fall back on jQuery.
            • 0
              Зачем в мобильном webview поддержка восьмого интернет эксплорера?
        • +2
          Знакомые парадигмы это хорошо.

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

          IMHO — вам стоит избавиться от jQ и это будет лучшей рекламой чем ее присутствие. На jQuery достаточно jQM который по факту нигде не используется из за низкой скорости работы и излишней универсальности, которая тоже давит на производительность.

          А jquery.js при необходимости любой подключить может…
        • –1
          Ну, кто знаком с ExtJS, тому вполне удобно с Sencha Touch, вроде бы. И подход jQuery им вообще непривычен и неудобен :)
    • 0
      habrahabr.ru/company/mailru/blog/188254/ вы бы тесты производительности посмотрели прежде чем на jq что то делать для мобильных
  • 0
    Как раз вчера натыкался на ваш сайт в поисках подобного решения, но хочу сказать, что для юзера, который не первый день знаком с платформой сразу видна разница: контролы, навигейшн.
  • +21
    Основная проблема таких фреймворков в том, что простые ситуации можно решать и без них, а сложные с ними становятся еще сложнее:

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

    Во-вторых, решение задач вида: работа в фоне, нотификации, разрешения, адаптация под версию Ос, интеграция с какими-то другими приложениями, работа с системными вызовами и т.д. вызывают множество проблем, очень часто сводящихся к «дописать какой-то код на нативном API целевой платформы». Т.е. нам все равно прийдется лезть в дебри каждой из платформ и иметь в штате людей, которые умеют и Java и C#, и Obj-C. Т.е. забыть про красивую сказку «write once, run anywhere» и быть готовым к изучению минимум трех SDK, покупке Мака, Виндоус; вам прийдется осилить вим или быть готовым к паре-тройке разных IDE и т.д. А еще спецов, готовых писать на js и при этом хорошо знающих целевые платформы можно пересчитать по пальцам.

    При этом постоянные тормоза и лаги на сложных UI не покрываются увеличивающейся производительностью системы, а на некоторых платформах, ваше HTML приложение будет работать в заведомо худших условиях, чем аналогичный код, запущенный в дефолтном браузере (привет, Сафари). Будут ли окупаться все эти нехилые затраты — решать вам.

    Пишу на основании длительного опыта общения с такими фреймворками, из всего многообразия, меня порадовал только impact.js с его попыткой приблизится к нативным играм по производительности, но политика автора «сначала купи лицензию, потом смотри исходники» не всех устраивает.
    • +6
      Естественно, у данного продукта есть очень четкая ниша применимости, о которой мы подробно порассуждаем в последующих постах. Эта ниша не пуста, наоборот, бурно растет и мы сделали этот продукт не для того чтобы рискнуть, а для того чтобы удовлетворить потребност вот таких людей: www.grobmeier.de/would-you-use-phonegap-again-18052013.html#.Ua4SApVZjlI
    • +1
      Очень правильный комментарий, особенно первое предложение. Две мои руки вверх.
  • +1
    Версия для Android выглядит ну совсем не нативно.
    • +2
      Да фиг с ней, как она выглядит. Лично меня останавливает, что скорость работы черезчур далека от нативной
      • 0
        А ещё нет плюшек наподобие виртуализации списков (когда элемент списка создаётся только тогда, когда он попадает в видимую часть прокрутки).
        • 0
          На HTML5 это было бы ужасно медленно, к сожалению. Считать смещения в DOM так затратно…
          • 0
            Таки в Sencha Touch сделали в версии 2.1. Пруф
            • 0
              Здорово. Разве оно у вас быстро работает с большими списками (больше 100 пунктов) на мобильных устройствах?
              • 0
                То-то и оно, что работает практически одинаково как на 10 элементах, так и на 100 элементах, так и на 1000. Но у нас в приложении, когда пробовали на 2.1 переехать, то работать все стало гораздо хуже, но памяти стало жрать заметно меньше. Но списки скроллились с дерганием при показе нового элемента, и рендерились они очень странно (и анимация в целом везде странно стала работать), поэтому откатились обратно на 2.0.
    • +1
      Вы версию для Windows Phone не видели :)
  • +4
        <script type="text/javascript" src="js/jquery-1.9.1.min.js"></script>
        <script type="text/javascript" src="js/knockout-2.2.1.js"></script>
        <script type="text/javascript" src="js/globalize.min.js"></script>
        <script type="text/javascript" src="js/dx.phonejs.js"></script>
    

    Вот это паровозик у вас получился… А почему jquery 1.9? Ведь на дворе уже 2.0.2 и 1.10 с поддержкой старых IE, которая вроде как ни к чему в вашем случае…
    Ваша библиотека весит почти в два раза больше своих зависимостей.
    Чем всё это лучше той же jquerymobile, кроме маскировки интерфейса под платформу мобильной ОС?
    • +1
      Продукт будет развиваться, и с выходом новых версий будет обновляться идущий в комплекте jQuery. В своем проекте разработчик может подложить версию поновее самостоятельно, главное не напороться на несовместимости (например, мы знаем что не всякая версия Knockout совместима с jQuery)
  • +1
    А что в Kitchen Sink такие списки маленькие? Как работает с 100 элементами в списке? На IPad 2, правда, заметно подтормаживают в Хроме и с таким количеством элементов
    • +4
      Цель демки Kitchen Sink — показать доступный арсенал UI-элементов, а не производительность. В плане производительности же, скажем прямо, есть куда копать.
  • +4
    Мое мнение что универсальные решения никогда не будут приемлемыми для всех абсолютно платформ.
    Я, как пользователь WP8, очень раздосадован тем фактом, что вся оптимизация под платформу свелась только к изменению стилей контролов.
    Хочу акцентировать внимание что каждая платформа имеет свою специфику в построении архитектуры интерфейса, а Вы пытаетесь пересадить всех на идеологию iPhone UI, которая, в свою очередь, очень сильно отличается от подхода WP8.
    Тут есть два варианта:
    — либо нужно копать намного глубже, например контрол навигации для айфона лучше сделать пивотом или панорамой для винфона
    — либо не заниматься ерундой и интерфейс затачивать под каждую платформу отдельно

    Кстати, Вы пробовали открыть свои примеры на восьмом винфоне? Увиденное очень Вас огорчит.
    • +2
      Все мы пробовали, конечно. WP8 SDK появился поздновато для нашего цикла выпуска, да и, положа руку на сердце, сейчас им в мире пользуются меньше людей чем, скажем, Blackberry, под который мы темы вообще не делали. Допилим в этом году до нужного состояния. Вроде даже некое подобие пивота и панорамы получается сделать.
  • 0
    это реально лучше, чем Adobe Air? (кроме поддержки вин8)
    • +2
      Основная цель альтернативных подходов — позволить разработчику пользоваться знакомыми инструментами. Если вы хорошо владеете технологиями Adobe (Flash), то для вас Air, наверно, будет лучше и проще (но есть минус: упакованное Air-приложение включает runtime, размер которого десятки мегабайт). Если вы веб-разработчик, владеющий HTML/CSS/JS, то Air для вас будет чужим и не даст преимуществ.
    • 0
      Я думаю, что основная проблема с Air — неуверенность разработчиков что с ним все будет хорошо. Apple не любит Adobe и успешно портит им бизнес. Самое главное что и Adobe не уверен в будущем и фактически оплачивает разработку свободного Apache Cordova aka PhoneGap — платформы для гибридных приложений типа показанного выше.
  • 0
    Мы не стали писать PhoneJS с нуля. Взяли jQuery, потому что сегодня для многих это синоним слова JavaScript

    Мы не стали писать UI с нуля. Взяли iOS, потому что сегодня для многих это синоним слова UI.
    • +1
      Все правильно, но тут ключевое слово кросс-платформенный фреймворк. Ну вот у вас, не знаю, служба такси, например — вы же не напишете приложение только под iOS. Придется писать на все смартфоны что у ваших потенциальных клиентов на руках. Стало быть, для России это iOS, Android, Windows Phone и если захочется BlackBerry.
      • 0
        Сегодня наша основная задача на основной работе — проработка кроссплатформенного юзабилити на HTML5. Поэтому я Вас понимаю.

        Но одно дело таксопарк, который хочет взять максимально готовое. А другое дело — серьёзные ребята берутся за дело и называют это «кроссплатформенный фреймворк». Соответственно, тут другие ожидания.

        А в том, что DevExpress — серьёзные ребята, я не сомневаюсь, я юзал их продукцию ещё в 90-х.
        • 0
          Ну наши цели — упереться в пределы производительности WebView (мы еще до этого не дошли), максимально скрыть проблемы юзабилити чтобы UI отзывался всегда и было понятно что происходит.

          Ну а еще мы каждое утро молимся что железо и браузеры подтянутся.
          • +2
            Что ж, успехов вам, не завязнуть в перечисленных целях, а быстро их пройти и двигаться дальше, чтобы в итоге получился действительно кроссплатформенный фреймфорк, включая UI kit (первый в мире, если я правильно нагуглил). Ну, вы поняли, чтобы один и тот же HTML отображался на iOS как стандартный список с группами, а на WP в виде панорамы и т.д.
  • +1
    Так, а в чем ваши конкурентные преимущества перед Sencha Touch?
    • +1
      Я напишу чем мы отличаемся.

      У нас более привычный для веб-разработчика подход — HTML+JavaScript, не все в коде, при этом PhoneJS заставляет использовать MVVM, позволяющий получить хороший тестируемый код.

      С точки зрения UI мы стараемся адаптировать стиль и даже структуру UI под стандарты платформы, тогда как приложение на Sencha Mobile выглядит везде одинаково. Хорошо это или нет — уже решать программисту, но мы, по крайней мере даем больше гибкости в этом вопросе.

      Есть еще десятки нюансов, но для понимания их лучше, все-таки поисследовать propertycross.com.
  • +1
    С Айфоном совсем не вышло. Киллер-фича Айос — это гладкость и отзывчивость. В мире Айос, когда пользователь касается экрана всё замирает. Сначала на всё реагирует интерфейс, а потом уже делаются какие-то действия.

    В это потеряли, сделав ровно наоборот. В результате на Айфоне получился Андроид. Всё тормозит и постоянно есть желание нажать на кнопку 2-3 раза.

    Планируете над этим поработать?
    • 0
      Ну, это не мы сделали наоборот, это так сейчас браузеры работают. Мы какие только ухищрения не делаем чтобы обойти особенности работы браузеров, обработки событий и т.п. Свои косяки мы выловим конечно.
      Есть надежда что ситуация не будет ухудшаться, а наоборот на запросы мобильного сообщества разработчики браузеров будут реагировать.
      На последних моделях телефонов/планшетов все не так плохо — приемлемо для бизнес приложений вида списки-формы.
  • 0
    А почему выбрали knockout, а не angular? Последний для одностраничых приложений больше подходит, и роутинг там есть и вьюшки с лэйаутами и урезанный jquery.
    • +1
      На момент принятия решения knockout больше всех нравился. Внутри там, на самом деле, все абстрагировано, поддержать angular технически не сложно, если этого все захотят.
  • +3
    В HTML based кроссплатформенных фреймворках все еще стоит указывать жирным шрифтом в мануале, что их есть смысл использовать только для простых, незамысловатых приложений, иначе вы рискуете потерять уйму времени и денег, разбираясь с проблемами производительности. Мы с командой не так давно прошли путь PhoneGap + Backbone.js. Это была авантюра.
    • +2
      Наверное так. У нашей компании основная аудитория — разработчики бизнес-приложений, и PhoneJS под это затачивался. Поэтому, наверное глаза замыливаются и мы забываем что есть и другие ниши.
      Я бы не стал писать на PhoneJS игру или, скажем социальное приложение типа foursquare. А, например, приложение для авиакомпании (посмотреть расписание, зарегистрироваться на рейс) — почему нет? Да, его можно и просто руками на HTML написать, но граблей много собрать придется, поэтому PhoneJS тут вполне себе сэкономит время.
      В ближайших планах есть статья о позиционировании, напишем.
  • 0
    Я правильно понимаю, что WinPhone 7 не поддерживается?
    habrastorage.org/storage2/d9a/370/d52/d9a370d522bdfcd58e4a963b65418470.jpg
    • 0
      В Windows Phone 7 IE 9 — пока будем его глюки обходить, последние девайсы сдохнут. Мой сын Lumia на WP7 уже убил.
      • 0
        А как насчёт BlackBerry 10?
        • 0
          Там технических проблем нет — стили сделать только. В планах есть, но не в первую очередь.
  • 0
    Имел дело с ASP.NET html контролами от DevExpress, так там в разметке был ужасный бардак (использовались таблицы для всего чего можно и нельзя). Разметка была очень тяжелой. Интересно, в этой библиотеке они не тем же путем пошли!?
    • –1
      Тех людей уже уволили :-) (На самом деле не всех, самые умные учавствовали в PhoneJS).
      Ну и надо понимать, что ASP контролы писались еще под какой-нибудь IE5, и люди требовали чтобы работало и все тут.
      А потом через тройку лет и переписать уже можно было бы, да нельзя — обратная совместимость и все такое.

      Здесь HTML5, CSS3, webkit. Люди опытные пишут. Ну и DOM для виджетов динамически создается. Если там что и не оптимально — говорите, с радостью поправим.
      • 0
        Хорошо, как PhoneJS стабилизируется, обязательно попробую. Может и правда у вас плохих уволили, а остались только такие, как те, кто библиотеку для WinForms делал, хорошая штука.
  • 0
    Фреймворк довольно молодой, есть ли примеры успешных проектов на нем? Как обстоят дела с исправлением ошибок, релизами?
    • 0
      Ошибки исправляем, минорные релизы выпускаются примерно раз в месяц. Мажоры два раза в год. Команда опытная, достаточно большая чтобы оперативно реагировать, инженеры поддержки работают, отвечают на вопросы. Компании DevExpress 15 лет почти, это не стартап какой.

      Примеры приложений которые вот можно поставить и посмотреть мне пока неизвестны (они может быть и есть, но нам не всегда говорят). Люди в основном внутренние бизнес-приложения пишут. Но люди пишут что-то — вопросы задают, баги репортят.
  • 0
    Сравнивали PhoneJS и Kendo UI на андроид версии. Смотрели официальные демки.
    Скролинг\переключалки и т.п в PhoneJS пока отстают по производительности, прокрутка заметно дергается.
    Хотя конечно у вас более интересная ценовая политика и проект моложе.
  • 0
    Жалко Вы не упомянули конкретные демки, т.к. в идеале, конечно, сравнивать лучше на одном и том же приложении, которое написано на различных фреймворках. В этом плане официальные демки KendoUI минималистичны и заточены именно под перформанс, что с точки зрения продаж, более правильно. Люди обычно выбирают такого рода продукты именно исходя из производительности. Но это чревато разочарованием на последующих стадиях разработки, когда скоро выпускать продукт, а оказывается, что все тормозит. Мы же попытались сделать наши демки реальными приложениями, которые будут писать люди и которыми уже можно пользоваться (за исключением Kitchen Sink) и оценить реальную производительность. Ну и как уже было неоднократно сказано, мы уже знаем некоторые наши узкие места и сейчас работаем над их устранением, и некоторые из них постараемся включить в ближайшие миноры. В любом случае, спасибо за отзыв.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка