На сайте Developer Apple была опубликована статья про использование одноразовых SMS-кодов, привязанных к домену, — "Enhance SMS-delivered code security with domain-bound codes".

Современные смартфоны предоставляют средства для автозаполнения поля с SMS-кодом, который отправляется пользователю при включённой двухфакторной аутентификации или подтверждения каких-либо операций. Сейчас автодополнение кодов работает на любых страницах, которые используют поле ввода с атрибутом autocomplete=one-time-code. Проблема в том, что этим могут пользоваться фишинговые сайты.

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

123456 is your Example code.

@example.com #123456

Привязанные к домену коды можно использовать в iOS 14 и macOS Big Sur. На Android эта фича скорее всего появится в одном из следующих релизов.

#security #mobile

https://developer.apple.com/news/?id=z0i801mg
https://github.com/WICG/sms-one-time-codes

Недавно Adobe объявила о прекращении поддержки PhoneGap — инструмента для разработки кроссплатформенных мобильных приложений на базе web-технологий. В официальном анонсе компания пишет о том, что PhoneGap больше неактуален, так как он может быть заменен PWA. Пользователям PhoneGap предлагается мигрировать на форк PhoneGap — Apache Cordova.

Максимилиано Фиртман провёл анализ возможностей PWA и сравнил их с текущей версией PhoneGap — "Is the Phone Gap closed in 2020?"

PhoneGap был популярен 10 лет назад, когда на рынке существовало много платформ: iOS, Android, WebOS, Bada, Ubuntu Touch, Symbian, Windows Phone и т.п. К 2020 году остались только две популярные платформы: iOS и Android. Но несмотря на то что многие возможности PhoneGap могут быть покрыты PWA (работа оффлайн, доступ к приложению с домашнего экрана), всё ещё есть API, которые недоступны для web-приложений (информация о устройстве, доступ к контактам (iOS). Ситуация усугубляется ещё тем, что разные платформы поддерживают разный набор API. Лучше всего дела обстоят у Android, у iOS поддержка PWA слабее.

#mobile #pwa

https://firt.dev/phonegap-end/

Эдди Османи написал статью про использование паттерна PRPL — "Faster Web App Delivery with PRPL".

PRPL — это паттерн для структурирования и улучшения производительности web-приложений (SPA и PWA).

PRPL описывает четыре этапа жизненного цикла приложения от этапа доставки кода в браузер до его отрисовки:
— Push — при первом открытии приложения, самые необходимые ресурсы доставляются как можно быстрее с помощью server push или preload;
— Render — затем отрисовывается экран приложения с использованием минимального количества необходимых ему ресурсов;
— Pre-cache — после того как приложение было отрисовано, оно может подгрузить ресурсы тех страниц приложения, которые с большой вероятностью будут открыты пользователем;
— Lazy-load — при работе с приложением его куски доставляются в браузер по мере необходимости, это обычно реализуется с помощью code splitting и динамических импортов.

Хорошая статья. Обязательно загляните, если занимаетесь разработкой web-приложений.

#performance #mobile #js

https://addyosmani.com/blog/the-prpl-pattern/

Стэфан Гису и Мартин Ширли в блоге web.dev рассказали о том, как собирать аналитику, когда устройство находится в оффлайне — "Measuring offline usage".

Собирать аналитику в оффлайне можно с помощью сервис воркеров. В статье для этого используется библиотека workbox, которая использует сервис воркеры под капотом. В workbox в свою очередь есть расширение, с помощью которого можно собирать оффлайн-аналитику и отправлять её в Google Analytics после перехода устройства в онлайн. Это расширение использует Background Sync API (поддерживается только в Chrome).

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

Рекомендую почитать статью всем, кто думал над тем, чтобы добавить оффлайн-режим в свой проект.

#serviceworker #mobile

https://web.dev/measuring-offline-usage/

Патрик Лаук опубликовал статью про использование медиафич для определения устройств ввода — "Interaction Media Features and Their Potential (for Incorrect Assumptions)".

В разделе Interaction Media Features CSS-спеки Media Queries Level 4 определяются несколько медиафич, с помощью которых можно проверить поддержку hover, тача, стилуса и соответствующим образом адаптировать интерфейс.

Медифичи pointer и hover предоставляют информацию о возможностях ввода того устройства, которое браузер считает основным. Медиафичи any-pointer и any-hover представляют обобщённую информацию о всех подключенных устройств ввода. Последние две медиафичи наиболее полезны, так как к девайсу, на котором отображается сайт, может быть подключено несколько устройств ввода. Например, к iPad могут быть одновременно подключены Apple Pencil, bluetooth-клавиатура и мышь.

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

Статья большая и полезная. Рекомендую почитать.

#css #mobile

https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/

Алекс Рассел из Google рассказывает о том, как современный фронтенд влияет на веб в целом, и что можно с этим сделать — "The Mobile Performance Inequality Gap, 2021".

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

Одна из главных причин медленного веба — выбор неподходящих инструментов и неконтролируемый рост JS-бандлов. В 2017 году Алекс призывал ограничивать размер JS до 130-170KiB. Сейчас он предлагает поднять эту границу до 350KiB для JS и 100KiB для HTML/CSS/шрифтов. Это связано с тем, что в последние годы операторы сотовых сетей активно внедряли 4G. При этом вычислительная мощность среднестатистического смартфона, наоборот, не выросла. Сейчас до сих пор в бюджетных смартфонах часто используются устаревшие процессоры, построенные на базе 28нм технологического процесса. Эта ситуация в ближайшие годы изменится, так как пользователи неизбежно будут обновлять свои устройства и границу в 350KiB можно будет подвинуть ещё дальше.

Алекс призывает при выборе инструментов и принятии технических решений в первую очередь думать о пользователях, которые в подавляющем большинстве используют обычные дешёвые смартфоны, а не последний iPhone или флагманский Samsung.

#performance #mobile

https://infrequently.org/2021/03/the-performance-inequality-gap/

Девид Соммерс рассказал о том, почему при разработке сайтов не нужно фокусироваться на айфонах, даже если они преобладают в аналитике — "Stop building websites for iPhones".

Девид разрабатывает сервисы для аренды жилья в Соединённых Штатах. В аналитике одного из его проектов видно значительное преобладание айфонов. Это результат того, что строка User-Agent Safari не меняется для разных устройств (iPhone 5, SE, 6, 7, 8, X, 11), тем самым создавая иллюзию того, что у пользователей производительные устройства. Проанализировав данные по айфонам с учётом разрешения экрана (благодаря разрешению можно примерно предсказать конкретную модель iPhone) и других моделей смартфонов оказалось, что примерно 38%-45% посетителей сайта используют медленные устройства.

Хорошая статья. Рекомендую почитать всем, кто интересуется производительностью.

#performance #mobile

https://blog.rentpathcode.com/analyzing-performance-e7aed196df64

VirtualKeyboard API — управление поведением виртуальной клавиатуры

Томас Штайнер написал статью про VirtualKeyboard API — "Full control with the VirtualKeyboard API".

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

VirtualKeyboard API решает подобные проблемы. С его помощью можно отслеживать открытие и закрытие клавиатуры, получать её размеры и адаптировать необходимым образом страницу. Для этого используется объект navigator.virtualKeyboard. В рамках этого API также появилась возможность настройки поведения виртуальной клавиатуры для полей ввода с помощью атрибута virtualkeyboardpolicy.

В данный момент поддержка VirtualKeyboard API есть только в бете Chrome 94.

#api #mobile

https://web.dev/virtualkeyboard/

VirtualKeyboard API на практике

Брамус Ван Дамм написал статью про практическое применение VirtualKeyboard API — "Prevent content from being hidden underneath the Virtual Keyboard by means of the VirtualKeyboard API".

В статье рассказывается о том, как реализовать раскладку элементов страницы с адаптацией под открытие виртуальной клавиатуры. Для решения подобных задач можно использовать переменные окружения CSS, которые были добавлены в рамках VirtualKeyboard API: keyboard-inset-top, keyboard-inset-right, keyboard-inset-bottom и т.п. Например, адаптация нижнего блока под открытие клавиатуры на CSS может выглядеть так:

.bottom-box {
  position: fixed;
  bottom: 0;
  margin-bottom: calc(20px + env(keyboard-inset-height));
}

Есть небольшой нюанс. Чтобы воспользоваться VirtualKeyboard API, браузеру необходимо сообщить о своём намерении управлять перекрытием с помощью вызова кода
navigator.virtualKeyboard.overlaysContent = true. Это не очень удобно, поэтому Брамус завёл ишью с обсуждением альтернативных механизмов включения VirtualKeyboard API.

Хорошая статья. Рекомендую почитать всем, кто разрабатывает сайты и web-приложения под мобилки.

#css #api #mobile

https://www.bram.us/2021/09/13/prevent-items-from-being-hidden-underneath-the-virtual-keyboard-by-means-of-the-virtualkeyboard-api/

Новые единицы измерения CSS, зависящие от области просмотра

Брамус Ван Дамм рассказал про новые единицы измерения, которые недавно были добавлены в спецификацию CSS Values and Units Level 4 — "The Large, Small, and Dynamic Viewports".

Довольно давно в браузерах появилась поддержка единиц измерений vw, vh, vmax, vmin. Их используют для ограничения размера элемента размером доступной области просмотра и для заполнения вьюпорта содержимым на мобилках. Когда создавалась спецификация, всё было логично. Однако ситуация изменилась, когда Safari стал скрывать части интерфейса во время прокрутки. Размер вьюпорта стал меняться динамически, и страницы, использующие vh, стали перекрываться интерфейсом браузера.

Для решения этой проблемы были придуманы разные хаки, а CSSWG разработала новые единицы измерения, более тонко учитывающие поведение вьюпорта:

— lvw, lvh, lvmax, lvmin — единицы относительно вьюпорта браузера со скрытыми элементами интерфейса (префикс "l" — large viewport)
— svw, svh, svmax, svmin — единицы относительно вьюпорта браузера без скрытых элементов интерфейса (префикс "s" — small viewport)
— dvw, dvh, dvmax, dvmin — единицы относительно вьюпорта, учитывающие динамическое изменение интерфейса (префикс "d" — dynamic viewport)

На данный момент новые единицы измерения не поддерживаются ни в одном браузере, но первые коммиты для их поддержки уже были добавлены в WebKit.

#css #spec #mobile

https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/

Важность тестирования сайтов на слабых устройствах

Эрик Бейли призывает тестировать сайты на слабых устройствах — "Test Your Product on a Crappy Laptop".

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

Чтобы контролировать доступность сайта для всех категорий устройств, Эрик предлагает проводить регулярные юзабилити-тесты на слабых устройствах. Также он предлагает купить дешёвый ноутбук (crapbook) и периодически вести на нём разработку.

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

#performance #mobile

https://css-tricks.com/test-your-product-on-a-crappy-laptop/

Встроенный браузер Facebook

Томас Штайнер проанализировал работу встроенного браузера Facebook (In-App Browser — IAB), чтобы разобраться, чем он отличается от обычных браузеров — "Inspecting Facebook's WebView".

Некоторые приложения открывают ссылки во встроенном браузере на базе WebView, потому что это даёт им больше возможностей для работы со страницей. На сайтах, открытых с помощью IAB Facebook, встраивается код сбора метрик производительности и информации о доступных возможностях WebView, в window добавляются свойства TEMPORARY и PERSISTENT, модифицируется отправляемый HTTP-заголовок User-Agent.

WebView не поддерживает все возможности браузеров, поэтому некоторые страницы в нём могут быть сломаны или отображаться неправильно. Так как пользователей Facebook несколько миллиардов, вероятность встречи с подобными ошибками довольно высока. Для упрощения решения проблем в IAB включён режим отладки, чтобы разработчики могли подключиться к WebView удалённо с помощью DevTools браузера.

#facebook #debug #mobile

https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/