VISTE

9 тайни на прогресивните уеб приложения (PWA)

Време за четене 8 минути

Прогресивните уеб приложения (PWAs) са сравнително нов елемент в уеба и стават все по-популярни. Поддръжката им започна с 

Chrome за Android и вече е достъпна и за други Android браузъри като Samsung Internet, Opera, Firefox, също и за Iphone и Ipad от iOS 11.3,

както и Edge за Windows и Chrome за настолни операционни системи.

01. WebAPK vs Android shortcut

През 2017г. Chrome пуснаха ново свойство за Android потребителите: WebAPK. Оттук нататък, когато потребителите инсталират дадено Прогресивно Уеб Приложение (PWA), сървър на Google Play ще създаде APK (Android Package) на момента и ще го инсталира в устройството, сякаш идва от Play Store.

Когато приложението е инсталирано, то ще се появи в началния екран, в мениджъра за приложения, в настройките и като всяко друго приложение ще показва информация за консумацията на батерия и за мястото, което заема в системата.

Ако уеб приложението не покрива изискванията, сървърът на Play Store е паднал, има проблем в осъществяването на връзка или се използва друг Android браузър като Firefox, ще бъде създадена стандартна икона за пряк път

WebAPK включва и приятна, но опасна функция, за която трябва да сте наясно: уеб приложението ще притежава домейна и пътя в рамките на Android OS. Въз основа на вашия Web App Manifest, всяка връзка, която потребителят получава чрез този обхват, ще бъде препратена към приложението ви на цял екран, а не в браузъра, което означава, че трябва да обърнете внимание на използваните от вас URL адреси.

Да речем, че имате прогресивно уеб приложение, което обслужва мобилните потребители и е в главната папка на вашия домейн. Когато приложението се инсталира чрез WebAPK, целият домейн ще бъде собственост на даденото приложение. Ако имате проучване в /survey, което споделяте чрез Facebook, или PDF с условия, които изпращате на потребителите си на адрес /terms.pdf, операционната система ще отвори даденото приложение, а не браузъра, когато кликнат върху тези връзки. Важно е да проверите дали вашата PWA маршрутизираща система знае за тези URL адреси и как да ги обслужва и ако не, да ги отворите в браузър с различен обхват.

02. Създаване на персонализиран банер за инсталиране на уеб приложения

Няколко браузъри канят потребителя да инсталира уеб приложението, ако са изпълнени определени условия, включително периодични посещения от този потребител за вашето приложение. В момента банерът не съдържа достатъчно информация за това защо потребителят трябва да приеме. Въпреки това, можем да използваме събития, за да избегнем банера и, което е по-важно, да го отложим за нещо по-вероятно да генерира приемане, като например икона за инсталиране.

Първата стъпка е да скрием външния вид на банера и да запишем обекта на събитието за по-късно използване:

Copy to Clipboard

Следващата стъпка е да предоставим потребителски интерфейс, който да обясни предимствата на инсталирането, или бутон за инсталиране. Този потребителски интерфейс ще се осигури чрез следващата функция:

Copy to Clipboard

03. Споделяне на съдържание от прогресивното уеб приложение

Когато уеб приложението е в режим на цял екран, няма URL лента или Share бутон от браузъра, за да може потребителят да споделя съдържание в социални мрежи. Можем да се възползваме от API на Web Share и да имаме резервно копие за отваряне на собствени социални приложения.

function share() {
    var text = ‘Add text to share with the URL’;
    if (‘share’ in navigator) {
        navigator.share({
            title: document.title,
            text: text,
            url: location.href,
        })
    } else {
        // Here we use the WhatsApp API as fallback; remember to encode your text for URI
        location.href = ‘https://api.whatsapp.com/send?text=’ + encodeURIComponent(text + ‘ – ‘) + location.href }}

04. Проследяване на Google Анализ

Когато имате прогресивно уеб приложение, ще искате да проследявате колкото се може повече събития, така че нека разгледаме всичко, което в момента можем да измерим. Можете да използвате приложния програмен интерфейс (API) на Google Анализ (Google Analytics) или други инструменти за анализ, за да следите тези събития по-късно.

window.addEventListener(‘appinstalled’, function(event) {
    // Track event: The app was installed (banner or manual installation)
});
window.addEventListener(‘beforeinstallprompt’, function(event) {
    // Track event: The web app banner has appeared
    event.userChoice.then(function(result) {
          if (result.outcome === ‘accepted’) {
                // Track event: The web app banner was accepted
          } else {
                // Track event: The web app banner was dismissed
          }
    });
});

Следващото важно събитие за проследяване е, когато потребителят отвори приложението от началния екран. Това означава, че потребителят е натиснал иконата на приложението или, чрез Android с поддръжката на WebAPK, също е кликнал върху връзка, която води към обхвата на приложението.

Най-лесният начин да направите това е чрез атрибута start_url на манифеста, като добавите проследяващо събитие в URL адреса, който може автоматично да се използва като произход от скрипт в Google Аnalytics, като например:

start_url: ‘/?utm_source=standalone&utm_medium=pwa’

Също така, следният скрипт ни оставя boolean заявка, ако потребителят понастоящем е в браузър (вярно) или самостоятелен режим на приложение (невярно):

var isPWAinBrowser = true;
// replace standalone with fullscreen or minimal-ui according to your manifest
if (matchMedia(‘(display-mode: standalone)’).matches) {
    // Android and iOS 11.3+
    isPWAinBrowser = false;
} else if (‘standalone’ in navigator) {
    // useful for iOS < 11.3
    isPWAinBrowser = !navigator.standalone;
}

След това, ако използвате push известия, можете да проследявате няколко събития в service worker, като:

self.addEventListener(‘push’, function(e) {
    // Track event: Push Message Received
});
self.addEventListener(‘notificationclick’, function(e) {
    // Track event: Push Message Clicked, you can read e.action.id to track actions
});
self.addEventListener(‘notificationclose’, function(e) {
    // Track event: Push Message Dismissed
});

05.Създаване на прогресивно уеб приложение, съвместимо с iOS

Докато мнозина смятат, че поддръжката на прогресивните уеб приложения (PWA)  ще се появи за първи път на iOS 11.3, истината е, че концепцията – макар и с различно име – беше представена от Стив Джобс преди повече от десет години в WWDC 07. Ето защо IOS поддържа началния екран и офлайн приложения за известно време.

Но от iOS 11.3 той ще започне да поддържа същите характеристики като Android.

Сега прогресивното уеб приложение ще може да се инсталира на iOS, дори ако не се запишете за iOS. Важно е да разберете някои различия, които могат да повлияят на потребителското изживяване на приложението в iOS:

  1. Иконите на iOS трябва да са квадратни и непрозрачни, за да се избегнат проблеми с потребителския интерфейс. Не използвайте същата икона, която имате в Android. Използвайте 120×120 и 180×180 за iPhone.
  2. Ако имате приложения с една страница (SPA) или линк към други страници в обхвата си, бъдете внимателни с навигацията, тъй като потребителите на iOS нямат начин да се върнат назад или напред, ако не предоставите връзки за навигация в потребителския си интерфейс. Плъзгащите жестове не работят при пълно екранни уеб приложения.
  3. От първите версии на iOS 11.3 операционната система презарежда прогресивните уеб приложения на всеки достъп до приложението, така че ако потребителят трябва да излезе от приложението, за да се върне по-късно (например за двустранен процес на удостоверяване), запомнете приложението ще започне от нулата по подразбиране.

06.Синхронизиране на данни на заден план

Сервизните работници (service workers) имат отделен жизнен цикъл от прозореца на уеб приложението или от раздела на браузъра. Ето защо можете да правите мрежови операции във фонов режим, дори след като потребителят затвори приложението. Ако има изчакваща операция и няма наличен достъп до мрежата в този момент, двигателят ще ни позволи да обработваме във фонов режим (заден план), ако по-късно бъде открита връзка.

API-то за синхронизиране на заден план (фонов режим) понастоящем е налице само в някои браузъри, така че трябва да предоставите резервно копие. Идеята е, че уеб приложението ще постави флаг със string tag , заявявайки, че трябва да извърши операция за синхронизиране във фонов режим (на заден план).

navigator.serviceWorker.ready.then(function(reg) {
  reg.sync.register(‘myTag’)
});

След това в ServiceWorker преглеждаме събитието, и ако това е етикет (label), очакваме да върне обещание. Ако обещанието е изпълнено, операцията се маркира като завършена. Ако не, ще продължи да се опитва по-късно на заден план.

self.addEventListener(‘sync’, function(event) {
    if (event.tag === ‘myTag’) {
        event.waitUntil(doAsyncOperationForMyTag());
    }
});

07. Социалните мрежи и псевдо-браузърите

Ако вашите потребители споделят съдържание от уеб приложението в социални мрежи или ако използват псевдо браузъри (браузъри без собствен двигател, но използват уеб изгледи), трябва да сте наясно с някои проблеми.

Facebook например, използва WebView в приложенията за Android и iOS, за да предложи възможност за сърфиране в приложението, когато потребителите кликнат върху връзка. В Android повечето от WebViews не поддържат работниците за услуги и не могат да инсталират прогресивното уеб приложение, така че когато потребителят отвори съдържанието ви от Facebook, приложението ще действа така, сякаш е несъвместим браузър без кеширани файлове или подробности за сесията. 

От iOS 11.3, WebView ще поддържа сервизни работници (Service Workers), но това ще бъде клонинг на същото уеб приложение, което потребителят е използвал в Safari или дори в други псевдо браузъри, като Chrome или Firefox на iOS.

Ето защо, ако обработвате инсталационен банер или диалогов прозорец с намеци за инсталиране, обясняващи важността за инсталиране на приложението, проверете дали сте в рамките на WebView, защото потребителят няма да може да следва стъпките ви. Скрийте тази информация или поканете потребителя да отвори URL адреса в браузъра по подразбиране. Това се отнася за Facebook на Android, Facebook на iOS, Chrome на iOS и Firefox на iOS, наред с други приложения. Извършване на проверка на живо, ако сте в WebView или не, е трудно, но е налице този помощен инструмент.

08. Тествайте на Android устройства и емулатори

Тестването на сервизни работници (service workers) и Web App Manifest изисква https, с изключение на localhost. Докато локалното десктоп изпробване първоначално е наред, в един момент искаме да видим нашите прогресивни уеб приложения в действие на устройства с Android. Как можем да го направим? Достъпът до dev сървър от нашия телефон или емулатор на Android не работи, защото не е https и не е localhost от гледна точка на Android OS.

Намираме решение с инструментите за разработчици на Chrome (Chrome Development Tools). Ако отидем в chrome://inspect и отворим емулатор или реално устройство със свързано USB отстраняване на грешки, ще можем да разрешим пренасочването на портове. Тогава http://localhost на нашето устройство с Android ще бъде препратено към локалния хост на нашият хост компютър или друг хост. С този трик Android ще направи правилно прогресивно уеб приложение по незащитена връзка. Имайте предвид обаче, че докато WebAPK  създаде пакета и го инсталира, той може да не работи в самостоятелен режим.

09. Публикуване в магазините

PWA Builder е онлайн инструмент на Microsoft за създаване на съвместими с магазини PWA (прогресивни уеб приложения) пакети за Windows 10 и други операционни системи

Докато походът на прогресивните уеб приложения не започна с мисълта за магазините, някои предложения, включително Twitter Lite и Google Maps Go в Play Store, започнаха да обслужват приложенията в магазините. Ако това е нещо, което ви интересува, за да разпространите PWA, без да го опаковате с Cordova, наличните опции са:

  • Microsoft Store: Можете да създавате прогресивни уеб приложения за Windows 10 като използвате официалния инструмент pwabuilder.com
  • Google Play Store: По време на писането, надеждните уеб дейности, достъпни на Canary Channel, ви позволяват да създадете приложение за Android, което просто отваря прогресивните уеб приложения, които притежавате, и ги разпространява в магазина, като създава подобно решение за WebAPK.
  • Apple App Store: Понастоящем няма официални решения за разпространение на прогресивни уеб приложения, но WKWebView ще поддържа сервизни работници (service workers) от iOS 11.3, така че няма да е трудно да се създаде проста обвивка за приложенията. Въпросът е дали Apple ще го одобри в магазина? Apple не иска решения, които са само уеб сайтове с обвивка.