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 бесплатен для некоммерческого использования. А наша служба поддержки готова ответить на ваши вопросы и помочь преодолеть возникшие трудности.
    Метки:
    DevExpress 104,81
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 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) и оценить реальную производительность. Ну и как уже было неоднократно сказано, мы уже знаем некоторые наши узкие места и сейчас работаем над их устранением, и некоторые из них постараемся включить в ближайшие миноры. В любом случае, спасибо за отзыв.

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

                                                                    Самое читаемое