[Перевод] Нативные приложения обречены (часть 1)24.11.2016 12:19

image

Отныне я не буду больше создавать нативные приложения. Все мои приложения в дальнейшем будут прогрессивными веб-приложениями (PWA, Progressive Web Apps). Это такие приложения, которые предназначены для еще более органичной работы на мобильных устройствах, чем нативные приложения.

Что я имею ввиду под «более органичной работой»? Большая часть веб-траффика исходит от мобильных устройств и пользователи устанавливают в среднем от 0 до 3 новых приложений в месяц. Это означает, что люди не тратят много времени на поиск новых приложений в App store, но они проводят много времени в сети, где могут найти и использовать ваше приложение.

Прогрессивные веб-приложения начинают свою работу как любое другое веб-приложение, но когда пользователь возвращается в приложение и показывает (фактом использования), что он заинтересован в более регулярном обращении к приложению, браузеры предложат пользователю установить приложение на свой домашний экран. PWA также могут использовать push-уведомления как и нативные приложения.

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

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

Немного истории


На заре iPhone не существовало app store. Стив Джобс хотел, чтобы разработчики создавали приложения для iPhone, используя стандартные веб-технологии.

Иногда мечтатели правы, но они на 10 лет опережают свое время. Оглядываясь назад на 2 года, рекомендация Стива Джобса о создании веб-приложений для iPhone была названа журналом Forbes его «крупнейшей ошибкой», поскольку нативные приложения приобрели сокрушительный успех.

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

Сейчас десятилетие спустя, мобильные веб-стандарты поддерживают многие функции, которые были нужны разработчикам нативных приложений и первоначальное видение мобильных веб-приложений Стива Джобса теперь воспринимается серьезно всем миром. Практически с самого начала Apple поддерживал «apple-mobile-web-capable» веб-приложения, которые вы можете добавить себе на домашний экран, используя мета тэги, которые помогают устройствам iOS находить такие вещи как подходящие иконки.

Другие производители последовали примеру, каждый создавал свою собственную коллекцию мета тэгов для объявления возможностей мобильных веб-приложений. Но недавно была введена кросс-платформеная спецификация и теперь кросс-платформенные мобильные веб-приложения наконец-то становятся реальностью.

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

Что такое прогрессивные веб-приложения


Прогрессивные веб-приложения являются веб-приложениями, разработанными и адаптированными под мобильные устройства. Если браузер отмечает, что пользователь хочет продолжить использование приложения, то он может предложить ему установить приложение на свой домашний экран. Но для того чтобы он это сделал, приложения должны удовлетворять специфическим критериям:
  • Должны быть HTTPS (смотри let’s encrypt)
  • Валидный манифест с обязательными свойствами (Web Manifest Validator)
  • Должны иметь service worker
  • start_url прописанный в манифесте, должен всегда загружаться даже в offline (используя service worker)
  • Должны предоставлятьсвою собственную навигацию
  • Должны быть отзывчивыми к разным размерам экрана и ориентациям

Конечно, использование HTTPS и service worker для оффлайн пользователей является сегодня рекомендуемой нормой для любого современного приложения.

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

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

Прогрессивные приложения — инструкция


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

Включить HTTPS


Чтобы включить HTTPS вам понадобится:
  • Веб-сервер (я рекомендую DigitalOcean)
  • SSL сертификат
  • Сильная группа Diffie-Hellman (sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048)
  • TLS/SSL конфигурация для вашего веб-сервера (инструкции для Nginx на Ubuntu)

Манифест


Файл манифеста называется manifest.json и он достаточно простой. Он состоит из имени (short_name для иконки домашнего экрана и опционального name для более полного названия), начального url, большого списка иконок чтобы вы могли поддерживать широкий спектр если для разных платформ нужны разные размеры иконки. Для Android и iOS вам понадобится:
  • 36×36
  • 48×48
  • 60×60 (значок Apple touch на iPhone)
  • 72×72
  • 76×76 (значок Apple touch на iPad)
  • 96×96
  • 120×120 (значок Apple touch на iPhone retina)
  • 152×152 (значок Apple touch на iPad retina)
  • 180×180 (значок Apple touch для iOS 8+)
  • 192×192
  • 512×512

Я выделил значки Apple touch потому что у них известные имена:

apple-touch-icon-180x180.png

Где 180×180 может быть заменено на любое нужное разрешение. Использование известных имен не обязательно, но если вы забудете включить тэги, iOS все-равно сможет найти иконки, ища их в корневой директории вашего веб-приложения, если вы будете использовать известные имена.

Иконки iOS не поддерживают прозрачность.

Простой manifest.json: 


{
  "name": "My Progressive Web Application",
  "short_name": "Progressive",
  "start_url": "/?home=true",
  "icons": [
    {
      "src": "/icons/icon36.png",
      "sizes": "36x36",
      "type": "image/png"
    },
    {
      "src": "/icons/icon48.png",
      "sizes": "48x48",
      "type": "image/png"
    },
    {
      "src": "/icons/icon60.png",
      "sizes": "60x60",
      "type": "image/png"
    },
    {
      "src": "/icons/icon72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "/icons/icon76.png",
      "sizes": "76x76",
      "type": "image/png"
    },
    {
      "src": "/icons/icon96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "/icons/icon120.png",
      "sizes": "120x120",
      "type": "image/png"
    },
    {
      "src": "/icons/icon152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "/icons/icon180.png",
      "sizes": "180x180",
      "type": "image/png"
    },
    {
      "src": "/icons/icon192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "theme_color": "#000000",
  "background_color": "#FFFFFF",
  "display": "fullscreen",
  "orientation": "portrait"
}

Существуют некоторые функции, о которых вам следует знать. theme_color устанавливает цвет статусной строки, а заголовок окна используется при переключении между приложениями на Android.

background_color устанавливает цвет заставки. На Android заставка будет состоять из свойства name (длинное имя) и большой иконки поверх background_color.

Манифест есть не везде


Когда с создал первое прогрессивное веб-приложение, я был потрясен тем, что оно работало как и предполагалось в Chrome на Android, но не в Safari /iOS. Причина в том, что мобильный Safari, несмотря на десятилетнюю поддержку этих функций, используя свои специфичные тэги не поддерживает до сих пор спецификацию веб-манифеста.

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

cf3a769c6504427ca740986c0ae28561.jpg

Существует множество тэгов, о которых надо помнить, хотя есть и другой способ. Есть web manifest polyfill, который прочтет ваш manifest.json файл и добавит тэги производителей для более старых мобильных браузеров, iOS и даже для Windows phone и Firefox OS.

Перевод: Ольга Чернопицкая

Продолжение следует

Поддержка публикации — компания Edison, которая разрабатывает автоматическую систему сборки прошивки для сетевой техники, а так же делает перевод ПО на русский для транснациональной промышленной корпорации.

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

  • 24 ноября 2016 в 01:26

    +7

    ↑

    ↓

    (Про заголовок и первый абзац первоисточника)
    Только ситхи все возводят в абсолют.

    • 24 ноября 2016 в 03:44 (комментарий был изменён)

      –5

      ↑

      ↓

      Моя жена ситха… ситоха… ситиха… тьфу… ситх!

  • 24 ноября 2016 в 01:59

    +4

    ↑

    ↓

    Ух ты, здорово) Впервые слышу про PWA, огромное спасибо за статью!

  • 24 ноября 2016 в 01:59

    +2

    ↑

    ↓

    Русское «обречены» оптимистично, оно ещё не произошло, просто предсказание.
    А вот «native apps are doomed» из источника для меня звучит, как будто уже произошедшее и скоро похороны.

    Родные приложения никогда не умрут, скорее сотрется грань между нативными и ПВА.

  • 24 ноября 2016 в 02:33 (комментарий был изменён)

    +10

    ↑

    ↓

    Нативные приложения обречены. Отныне я не буду больше создавать нативные приложения

    Ну да, теперь точно обречены. Куди им без автора?

  • 24 ноября 2016 в 04:01

    +6

    ↑

    ↓

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

    Я даже почтовый клиент предпочитаю традиционный, потому что тонны писем намного проще хранить и обрабатывать у себя, ровно как частенько бывает полезно видеть все заголовки целиком чего во всяких вебмордах если и есть то совсем не удобно. И такие вещи как PGP имеют смысл только локально, а не на каком то там сервере.

    • 24 ноября 2016 в 08:05

      0

      ↑

      ↓

      У Вас адъ в голове творится.

  • 24 ноября 2016 в 06:33

    +2

    ↑

    ↓

    Про полную победу кросс платформенных приложений начали говорить и писать, как только они появились. Я лично помню это еще с момента приобретения популярности Явой. Помню как мне с восхищением и предвкушением рассказывали как приложения смогут работать везде, от разных ОС до бытовой техники и телефонов. С тех пор каждый новый виток кроссплатформености приводил к подобным предсказаниям и подготовкам похорон нативных приложений. Правда еще ни одна платформа не лишилась своих нативных приложений. А все потому, что универсальность требует общий знаменатель, а значит часть возможностей железа остается незадействованными, и это серьезный минус. Конкретно у ПВА есть еще один минус — привязка к онлайну. Не знаю как кого, а меня с течением времени все больше раздражают приложения которые не могут работать офлайн или на плохом канале. Т.к. именно в такие моменты мне обычно скучно и я думаю как его убить, а оказывается что телефон практически кирпич без интернета. В итоге я удаляю после первого запуска все, что требует интернет, но не является средством потребления интернета (браузер, месенджер, новости…).
    Возможно это ДМА обречены?

  • 24 ноября 2016 в 07:57

    +3

    ↑

    ↓

    Не нативное приложение это огромное ограничение по функционалу и производительности. Если вы нищеброд, делайте ПВА, нормальная организация не позволит себе, чтобы опыт их пользователей был ужасным (а он будет, особенно медленным)

  • 24 ноября 2016 в 08:18

    +6

    ↑

    ↓

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

  • 24 ноября 2016 в 08:23

    0

    ↑

    ↓

    Сейчас об этом спорить бессмысленно, так как идея подсаживать юзера на абонентскую плату настолько привлекательна, что работодатели ничего нигде никак обсуждать не будут, всё будут перекидывать в веб.
    С рекламой юзеры уже проголосовали, многие устанавливают блокировщики рекламы.
    Ждём массовых реакций от юзеров на удаления аккаунтов и возмущения от постоянно требуемых абоненток.

  • 24 ноября 2016 в 09:09

    +1

    ↑

    ↓

    3636
    48    48
    6060 (значок Apple touch на iPhone)
    72    72
    7676 (значок Apple touch на iPad)
    96    96
    120120 (значок Apple touch на iPhone retina)
    152    152 (значок Apple touch на iPad retina)
    180180 (значок Apple touch для iOS 8+)
    192    192
    512×512

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

  • 24 ноября 2016 в 09:36

    +1

    ↑

    ↓

    Нативные не умрут т.к. для них есть фичи, которые только там и есть, а уж pwa они и не снились.
    Есть для каждой из ос стайл-гайды к которым пользователи привыкли.

    Нативные будут явно быстрее, меньше проблем с тем, что для pwa надо будет на 25 браузерах все отлаживать или же прийдется писать «ой, сарян бро, но мы только под хром сделали»

    Или же, «ну мы типа не следовали стайлгайдам дройда, эпла, майкрософта», поэтому запилил вам свой собственный, хоть он и гавно по вашему мнению, но по нашему он огонь и нам не надо делать Х разных скинов, под разные платформы, а если делать, это ж сколько надо писать дополнительного кода.

    «А че оно так лагает?» — ну понимает, это кросс-платформенное, поэтому мы его сделали 1 раз и везде показывается, но за это приходиться поплатиться скоростью.

    «А че оно вылетает?» — ну мы где-то накосячили и браузер крашится, но мы поправим.
    «Да, но на дройдет не вылетает!» — ну там типа хром лучше отработал.

    Ну и так далее.

    • 24 ноября 2016 в 10:59

      0

      ↑

      ↓

      В наше время в браузерех куда как проще писать «кроссплатформенный» код (кроссбраузерный по сути).

      Однако есть очень популярные ниши, где PWA вряд ли в ближайшее время будут:
      1. 3D и прочие очень анимированные игры,
      2. Напоминалки и другие приложения, которые гоняют бэкграунд-сервисы на девайсах. Пуши же ведь только при подключении к интернету работают :)
      3. САМОЕ имхо ВАЖНОЕ — приложения, которым не нужны сайты! Да-да. Таких полмаркета.

      • 24 ноября 2016 в 11:03

        +1

        ↑

        ↓

        Сколько живу, столько слышу о том, что «мы изобрели то, на чем можно 1 раз написать и везде будет работать», а когда все это сталкивается с реальными нуждами приложений, то все уходят в нативку :)

  • 24 ноября 2016 в 11:16 (комментарий был изменён)

    +1

    ↑

    ↓

    Кажется, эта идея с манифестом так же мёртворожённа как и объявление @viewport в стилях. Потому что когда стоят мета-теги в документе, браузер знает о всех свойствах сразу как загрузилась страница. А так ему надо загрузить ещё внешний файл, распарсить его и только после этого предпринять какие-то существенные действия, возможно, выбрасывая часть ранее сделанной работы. Это увеличивает зависимость от внешних файлов и замедляет рендеринг, особенно в зоне неуверенного приёма сети.

    Ну, и Эппл справедливо критикует Service Workers как переусложнённую спецификацию, где для самых простых кейсов нужно много лишних действий. Не секрет, что Гугл разрабатывает её в одиночку под себя. Никаким «стандартом», о котором договорились все разработчики браузеров здесь и не пахнет. Это такой же костыль, как и другие проприетарные вещи (вспомните ActiveX).

© Habrahabr.ru