Тренды фронтэнда. Javascript APIs для мобильных устройств

Презентация: http://sergey.makoveev.info/2013/01/frontend.js-apis-mobile.presentation/.
Примеры: http://goo.gl/5jv4i.
Исходники: http://goo.gl/YYj0R.

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

Интересны разные пути развития приложений и сервисов. Яркими примерами являются Adobe с его Adobe Creative Cloud, Microsoft с его SkyDrive и Microsoft Office Web App — здесь популярные приложения мигрировали в веб. Другой путь развития — развитие сервисов, когда веб-сервисы, набирая популяность, «обрастают» приложениями — GMail, Youtube.

Таким образом, приложение (сервис), целью которого является «быть качественным, удобным и популярным», в настоящее время содержит в своей структуре:

  • клиентские приложения для популярных OS (iOS, Android, Windows, Linux, ...);
  • расширения для популярных браузеров;
  • букмарклеты для популярных браузеров;
  • веб-клиента;
  • общий бэкэнд, в котором, наряду с основным функционалом, реализованы собственное api и средства интеграции с внешними сервисами.

Совершенно очевидно что:

  • для развития и поддержки подобного приложения требуются усилия слаженной команды разработчиков, включающей в себя специалистов с опытом разработки приложений под соответствующие платформы, одновременно обладающих опытом и знаниями в смежных областях (это как минимум знание архитектуры веб-приложений и технологий, применяемых для их реализации);
  • возрастают «накладные расходы» на поддержание инфраструктуры самого процесса разработки (для каждого составляющего этой структуры требуется написание всего спектра тестов — юнит, функциональных, нагрузочных; ведение отдельного баг-трекера, и т.д. ...);
  • многократно усложняется введение нового функционала в сервис (поддержка которого должна быть одновременно и единообразно реализована во всех его структурных частях);
  • подобная структура изначально расположена к появлению ошибок в следствии рассогласования взаимодействия ее составляющих, вызванных в первую очередь разнообразием клиентских приложений и разнообразием их версий на устройствах пользователей.

Бесспорно что трудоемкость (и, как следствие, стоимость) поддержки и развития такого приложения будет несравнимо больше по-сравнению с «pure-web-application». Структура такого приложения выглядит гораздо лаконичней:

  • веб-итерфейс;
  • клиентские приложения для популярных OS, расширения и букмарклеты для популярных браузеров представляют собой тривиальную «оболочку», в которую «упакован» веб-интерфейс;
  • общий бэкэнд, +api, +средства интеграции с внешними сервисами.

При такой структуре сервиса исключаются практически все минусы, перечисленные выше, в силу того, что при реализации всех частей структуры используются мономорфные технологии (js, css, html), и, следовательно, мономорфная инфраструктура самого процесса разработки и команда разработчиков.

Здесь возникает естественный вопрос — почему подобная практика не используется повсеместно?
Ответ прост: до недавнего времени веб-интерфейсы не могли составить достойную конкуренцию интерфейсам, реализованным при помощи нативных средств каждой из платформ.

JavaScript APIs


Еще в июле 2009 года в рамках World Wide Web Consortium (W3C) была создана "Device APIs Working Group (GAP)", целью которой является создание client-side API для взаимодействия веб-приложений с сервисами устройств (камера, календарь, контакты, ...). Здесь можно увидеть текущие направления разработок группы. Некоторые из них уже реализованы в браузерах.

Внимание: тестовые примеры написаны для Firefox mobile beta.

Battery Status API


Служит для отображения информации о состоянии батарей клиентской машины.
Реализован с браузерным префиксом.

//объект, содержащий информацию о батареях
var battery = navigator.battery || navigator.webkitBattery || navigator.mozBattery;

//battery.level - уровень заряда батарей (значение в диапазоне 0...1)
var onlevelchange = function(e) {
    console.warn("Battery level change: ", battery.level);
};
//levelchange - событие изменения уровня заряда
battery.addEventListener("levelchange", onlevelchange);

//battery.charging - статус заряда (true - заряжается, false - не заряжается)
var onchargingchange = function() {
    console.warn("Battery charge change: ", battery.charging);
};
//chargingchange - событие изменения статуса заряда
battery.addEventListener("chargingchange", onchargingchange);

//battery.chargingTime - оставшееся время до полного заряда
var onchargingtimechange = function() {
    console.warn("Battery charge time change: ", battery.chargingTime);
};
//chargingchange - событие изменения времени до полного заряда
battery.addEventListener("chargingtimechange", onchargingtimechange);

//battery.dischargingTime - оставшееся время до полного разряда
var ondischargingtimechange = function() {
    console.warn("Battery discharging time change: ", battery.dischargingTime);
};
//dischargingtimechange - событие изменения времени до полного разряда
battery.addEventListener("dischargingtimechange", ondischargingtimechange);

Пример:
David Walsh/Battery Status API/Example.

Источники:
W3C Battery Status API,
MDN/window.navigator.battery,
David Walsh/Battery Status API.

Vibration API


Предназначен для управления вибросигналом устройства.

//вибросигнал длительностью 1 сек
navigator.vibrate(1000);

//последовательность: вибросигнал 0.5 сек, пауза 1 сек, вибросигнал 0.3 сек
navigator.vibrate([500, 1000, 300]);

//последовательность множества сигналов
navigator.vibrate( ('111111111111111111'+
                    '111111111111111111').split('')
                                         .map(function(){ return 300; }) );

//остановить вибросигнал
navigator.vibrate(0);

//вибросигнал длительностью 10 сек
navigator.vibrate(10000);

//остановить вибросигнал
navigator.vibrate([]);

Примеры:
Vibration API example,
David Walsh/Vibration API/Example.

Источники:
W3C Vibration API,
MDN/window.navigator.vibrate,
David Walsh/Vibration API

Screen Orientation API


Предназначен для получения событий изменения ориентации экрана устройства, информации о текущем состоянии ориентации экрана.
Реализован с браузерным префиксом.

// screen.orientation - текущее значение ориентации экрана

console.log("orientation: " + screen.mozOrientation);

// screen.onorientationchange - событие изменения ориентации экрана устройства

screen.addEventListener(
    "mozorientationchange",
    function() {
        console.log("orientation: " + screen.mozOrientation);
    }
);

Пример:
Screen Orientation API example.

Источники:
W3C/Screen Orientation API,
MDN/orientationchange event.

Device Orientation API


Предназначен для получения событий изменения ориентации устройства.

// window.ondeviceorientation - событие изменения ориентации устройства
// e.alpha, e.beta, e.gamma - текущее значение ориентации экрана
//                            по осям x, y, z соответственно
window.addEventListener(
    "deviceorientation",
    function(e){
        console.log(e.alpha, e.beta, e.gamma);
    }
);

Примеры:
Device Orientation API example,
Opera/compass.

Источники:
W3C/deviceorientation,
MDN/Orientation and motion data explained,
Opera/Orientation API.

Device Motion API


Предназначен для получения событий датчика-акселерометра о перемещении устройства.

// window.ondevicemotion - событие перемещения устройства
// ускорение по осям x, y, z соответственно:
// e.acceleration.x, e.acceleration.y, e.acceleration.z
// значение ускорения по осям x, y, z (с учетом гравитации) соответственно:
// e.accelerationIncludingGravity.x, e.accelerationIncludingGravity.y, e.accelerationIncludingGravity.z
// значение угловой скорости вращения по осям z, x, y (в градусах) соответственно:
// e.rotationRate.alpha, e.rotationRate.beta, e.rotationRate.gamma
window.addEventListener( "devicemotion",
                         function(e){ console.dir(e.acceleration);
                                      console.dir(e.accelerationIncludingGravity);
                                      console.dir(e.rotationRate); }; );

Пример:
Device Motion API example.

Источники:
W3C/devicemotion,
MDN/Orientation and motion data explained,
MDN/devicemotion,
Opera/Orientation API.

Ambient Light Events


Предназначены для получения событий датчика освещенности устройства.

window.addEventListener(
    "devicelight",
    //e.value - значение освещенности в люксах
    function(e){ console.log(e.value); }
);
window.addEventListener(
    'lightlevel',
    // e.value = ("normal"|"dim"|"bright")
    function(e) { console.log('lightlevel: ' + e.value); }
);

Примеры:
Ambient Light API example,
Doug Turner/Ambient Light Events/Example.

Источники:
W3C Ambient Light Events,
MDN/DeviceLightEvent,
Doug Turner/Ambient Light Events.

Proximity Events


События датчика приближения устройства.

window.addEventListener(
    "deviceproximity",
    function(e){console.log(
        e.value, // текущая дистанция до датчика в сантиметрах (!)
        e.min,   // минимальное значение, которое может определить датчик (==0)
        e.max    // максимальное значение, которое может определить датчик
    )}
);
window.addEventListener(
    "userproximity",
    function(e){console.log(
        e.near //true - близко, false - далеко
    )}
);

Примеры:
Proximity Events example,
Doug Turner/Device Proximity/Exapmle.

Источники:
W3C Proximity Events,
MDN/DeviceProximityEvent,
MDN/UserProximityEvent,
Doug Turner/Device Proximity,
Doug Turner/User Proximity.

Page Visibility API


Позволяет определить отображается ли страница на экране устройства.
Реализован с браузерным префиксом.

// Поля, содержащие состояние отображаемости страницы:
// document.hidden = (true|false)
// document.visibilityState = ("hidden"|"visible"|"prerender"|"unloaded")

console.log( document.mozHidden, document.mozVisibilityState );

// Событие смены состояния отображаемости страницы:
// document.onvisibilitychange = function(e){ ... }

document.addEventListener( 'mozvisibilitychange',
                           function(){console.log( document.mozHidden,
                                                   document.mozVisibilityState );} );

Примеры:
Page Visibility API example,
David Walsh/Page Visibility API/Example,
Mozilla/Page Visibility API/Example.

Источники:
W3C Page Visibility,
David Walsh/Page Visibility API,
Chrome/Page Visibility API,
MDN/Page Visibility API.

Fullscreen API


Предоставляет возможности работы с полноэкранным режимом.
Реализован с браузерным префиксом.

// доступность полноэкранного режима:
// document.fullScreenEnabled = (true|false)

console.log('fullScreenEnabled :', document.mozFullScreenEnabled );

// вывод DOM-ноды в полноэкранном режиме:
// el.requestFullScreen();

document.mozRequestFullScreen();

// элемент, выведенный в полноэкранном режиме:
// document.fullscreenElement

console.log('fullscreenElement:', document.mozFullscreenElement);

// выход из полноэкранного режима:
// document.cancelFullScreen();

document.mozCancelFullScreen();

Примеры:
Fullscreen API/Example,
MDN/Fullscreen API/Example,
David Walsh/Fullscreen API/Example.

Источники:
W3C Fullscreen,
MDN/Using fullscreen mode,
David Walsh/Fullscreen API.

Итог


Обобщая развитие веб-стандартов в сфере фронтенд-технологий (css, js, html), можно увидеть общую тенденцию инновационных разработок, конечной целью которых является становление веб-интерфейсов как стандарта де-факто в качестве интерфейсов приложений.
Уже сейчас можно воспользоваться новыми API при помощи Modernizr.

Источники




Презентация: http://goo.gl/2CkWb.
Примеры: http://goo.gl/5jv4i.
Исходники: http://goo.gl/YYj0R.
  • +26
  • 16.7k
  • 8
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 8

    0
    Прекрасно. Предположим, сейчас я пишу приложение, которое использует камеру, которое проводит некую обработку, полученного с камеры изображения и вновь выводит его на экран. Даже java код иногда тормозит при этом и приходится тратить много усилий для его оптимизации. Сейчас я вообще прихожу к тому, что бы вынести этот код в NDK. Как дела обстоят с этим в JavaScript API? Этот вопрос абсолютно актуален для большинства приложений дополненной реальности и игр. Или же использование JavaScript сразу ограничивает сферу применения приложений?
      0
      Совершенно согласен, что js api не позволят ( да и не должны по-сути ) сделать подобное. Но, согласитесь, было бы неплохо написать сам интерфейс программы на html/css/js, предоставив ядру (java) делать преобразования видео.
      Хотя относительно работы с медиа в браузерах тоже есть прогресс. Кто знает, может быть далее разработают и для медиа-потоков фильтры, подобные уже реализованным фильтрам для изображений:

      Но уже сейчас видны предпосылки для использования css/html/js в мобильных интерфейсах:

      Игры уже пришли в веб (сначала на flash, потом на html5/css3/svg), хотя совсем недавно такие возможности казались весьма призрачными.
      Но, повторяюсь, безусловно, это нисколько не уменьшает преимуществ нативных приложений в отношении скорости. Интерфейс на css/html/js — да, удобно, тяжелые вычисления — безусловно нативное ядро или java.
      Хотя многие клиенты сервисов (facebook, twitter,… ) наверняка могут быть полностью реализованы в качестве приложений на css/html/js.
        0
        Я, возможно, ошибаюсь, но развитие в этой сфере вижу так: Действительно HTML/css идеально подходит для описания интерфейса. Поэтому было бы неплохо, если бы в будущем появилась технология, которая забрала бы самое лучшее из мультиплатформенности HTML/JavaScript и скорости нативного кода, так как браузер, на мой взгляд не дает полной гибкости работы, я не говорю уже про производительность (речь пока только про мобильный сегмент).
        0
        К JavaScript'у легко приделывается Java bridge с вызовами желанной библиотеки на c/c++. Конечно, для реал-тайм процессинга audio/video не подходит, а вот для других задач может быть в самый раз.
        +1
        В черновиках статья — «Почему именно сейчас стоит начать заниматься frontend-разработкой».

        В последнее время все чаще статьи на Хабре подробно описывают некоторые из пунктов этой статьи. Теперь вот думаю что делать :)

        По существу: я считаю, что html+css+javascript в ближайшие два-три года очень плотно придут на мобильные платформы. WebGL, canvas, Javascript Mobile API, Firefox OS. Это очень радует )
          0
          Javascript+HTML5 и PhoneGAP давно уже не новость, как и всевозможные упаковщики сайтов в мобильные приложения. Но технология большого распространения все равно пока еще не получила.
          У facebook было изначально приложение на html5, которое Цукерберг закрыл и назвал наибольшей ошибкой.
          www.businessinsider.com/mark-zuckerberg-html5-mobile-2012-9
          Сейчас конечно спорят с его словами
          www.theregister.co.uk/2012/09/14/facebook_html_5_vs_native_apps/
          но суть остается в том, что не все так просто.

          Например, phonegap не дает никакого графического интерфейса (все нужно делать на html5 и css3), с одной стороны это как бы преимущество с другой стороны имеем проблемы.

          1. Пользователь хочет и ожидает увидtть стандартный интерфейс ios или android (а они отличаются и довольно сильно), а получает, что-то другое и это что-то зачастую ему не нравится (да просто потому что другое).
          2. Пытаемся имитировать стандартный интерфейс. Теряем в «кроссплатформености» интерфейса (у нас на адроиде будет айфоновсrий интерфейс или наоборот). Зачастую получаем тормозное приложение, которое все называют жалким подобием нативного.
          3. Быстрее таки делать интерфейс стандартными контролами, да и проектировать его тоже.

          Еще забыли про Sencha Touch 2 упомянуть. Хотя может не совсем в тему, т.к. этот фреймворк не дает api к девайсу, но дает стандартные контролы (как в ext js) для разработки мобильных приложений на javascript и кстати все это очень неплохо работает. Зачастую скрешивают Sencha Touch c phonegap
            +1
            Да, действительно, не все так просто. Но соблазн писать интерфейсы приложений на единых технологиях под всеми платформами достаточно велик.
            Относительно ожидания пользователем стандартного интерфейса — тут как раз не должно быть проблем. Можно достаточно несложно определить какая OS работает на стороне клиента и подгрузить соответствующий layout с ui-компонентами, выполненными в стиле этой платформы, благо bootstrap-ов под все стили GUI уже сейчас хватает (вот, на «вскидку»: iOS, Metro#1, Metro#2, Metro#3, facebook, google и, собственно сам twitter ).

            Здесь надо отметить, что пользователь не всегда ждет «нативных» gui-элементов. Например, в случае приложения под какой-то сетевой сервис (например facebook) пользователь ждет ui от фейсбука, а не андройда или iOS.
            Кроме bootstrap возможно использовать web-ui-компоненты, которые поддерживают сами разработчики сервисов ( facebook, google, yahoo ).

            Хотя соглашусь, что для всех этих сервисов ( почти для всех ) есть SDK под популярные OS. Насколько полные и удобные эти SDK, входит ли в них полный комплект необходимых UI-элементов судить не вправе, т.к. не считаю себя специалистом в этой области.

            Однако с уверенностью могу сказать, что уже сейчас в html/css/js существуют гибкие и эффективные механизмы (например Media Queries (w3c), flexbox (w3c),… ), которыми можно и нужно пользоваться для создания адаптивных интерфейсов под разные типы устройств.

            Насколько станет популярным использование веб-технологий в разработке интерфейсов именно мобильных приложений — покажет время. Но такой тренд есть и есть все условия для его продвижения.
            Большое влияние на него будет оказывать W3C (со своей «неповоротливостью» во внедрении новых версий стандартов), разработчики браузеров (насколько точно они будут следовать рекомендациям W3C), действия основных игроков на рынке веб-сервисов (facebook, google, twitter,… ) — будут ли они расширять свои html/css/js-SDK.

            Тут надо отметить, что позиция twitter по этому поводу предельно ясна — его bootstrap в течении этого года произвел впечатление на многих разработчиков, и bootstrap-way уже по-праву может считаться отдним из самых популярных IT-трендов ушедшего года.
              0
              По прошествии 1.5 лет могу сказать, что PhoneGap по прежнему не впечатляет. Но..Titanium оказался вполне годным для коммерческой разработки.

          Only users with full accounts can post comments. Log in, please.