Blok Bangunan Aplikasi Web Progresif

Aplikasi web dapat menggantikan semua fungsi aplikasi dan situs web asli sekaligus. Mereka semakin menonjol akhir-akhir ini, tetapi masih belum cukup banyak orang yang mengenal atau mengadopsinya.

Dalam artikel ini, Anda akan dapat menemukan beberapa hal yang boleh dan tidak boleh dilakukan tentang cara membuat aplikasi web progresif, serta sumber daya untuk penelitian lebih lanjut. Saya juga akan membahas berbagai komponen dan masalah dukungan seputar aplikasi web. Meskipun tidak semua browser ramah untuk mereka, masih ada beberapa alasan kuat untuk mempelajari lebih lanjut tentang teknologi ini.

Apa yang Membuat Aplikasi Web Progresif?

Aplikasi web progresif adalah istilah umum untuk teknologi tertentu yang berjalan bersama untuk menghasilkan pengalaman seperti aplikasi di web. Demi kesederhanaan, saya akan menyebutnya sebagai aplikasi web mulai sekarang.

Aplikasi web yang ideal adalah halaman web yang memiliki aspek terbaik dari web dan aplikasi asli. Itu harus cepat dan cepat untuk berinteraksi, sesuai dengan area pandang perangkat, tetap dapat digunakan secara offline dan dapat memiliki ikon di layar beranda.

Pada saat yang sama, itu tidak boleh mengorbankan hal-hal yang membuat web hebat, seperti kemampuan untuk menautkan jauh ke dalam aplikasi dan menggunakan URL untuk memungkinkan berbagi konten. Seperti web, itu harus bekerja dengan baik di seluruh platform dan tidak hanya fokus pada seluler. Ini harus berperilaku sama baiknya di komputer desktop seperti pada faktor bentuk lainnya, agar kita tidak berisiko mengalami era lain situs web m.example.com yang tidak responsif.

Aplikasi web progresif bukanlah hal baru. Peramban seluler memiliki kemampuan untuk menandai situs web ke layar beranda ponsel Anda sejak 2011 (2013 di Chrome Android), dengan tag meta di head yang menentukan tampilan laman web yang dipasang. Financial Times telah menggunakan aplikasi web untuk pengiriman konten digital di perangkat seluler sejak 2012.

Pindah ke aplikasi web memungkinkan Financial Times menggunakan aplikasi yang sama untuk dikirim ke seluruh platform dalam satu saluran distribusi. Kembali ketika saya bekerja untuk Financial Times, dengan satu build kami dapat mendukung hal berikut:

• iOS,
• Android (4.4+) Chrome,
• Android yang lebih lama (melalui pembungkus),
• Windows 8,
• BlackBerry,
• Firefox OS.

Itu benar-benar mencapai "bangun sekali, sebarkan di mana saja."

“Tapi Itu Tidak Ada Di App Store”

Ada beberapa alasan bagus mengapa melengkapi aplikasi asli dengan situs web masih merupakan praktik standar bagi sebagian besar perusahaan besar. Diantaranya adalah kekhawatiran tentang dukungan browser dan fakta bahwa sebagian besar pengguna terbiasa menggunakan aplikasi asli. Saya akan membahas masalah ini secara lebih rinci nanti. Tidak sedikit dari kekhawatiran ini adalah bagaimana aplikasi akan mendapatkan eksposur jika tidak ada di app store.

Saya berpendapat bahwa berada di toko aplikasi tidak memiliki keuntungan besar karena telah ditunjukkan bahwa jika Anda tidak berada di 0,1% teratas aplikasi di toko aplikasi, Anda tidak mendapatkan manfaat yang signifikan dari berada di sana.

Pengguna cenderung menemukan aplikasi Anda dengan terlebih dahulu menemukan situs web Anda. Jika situs web Anda adalah aplikasi web, maka mereka sudah sampai di tujuannya.

Salah satu kekuatan aplikasi web adalah memungkinkan Anda meningkatkan keterlibatan dengan mengurangi jumlah klik yang diperlukan untuk melibatkan kembali pengguna antara mendarat di situs web Anda dan terlibat dengan aplikasi Anda.

Dengan meminta pengguna “memasang” aplikasi web Anda dengan menambahkannya ke layar beranda, mereka dapat terus berinteraksi dengan situs web Anda. Ketika mereka menutup browser web, telepon akan menunjukkan kepada mereka di mana aplikasi web diinstal, membawa Anda kembali ke kesadaran mereka.

Latar Belakang Dan Iklim Saat Ini

Aplikasi web modern didasarkan pada teknologi baru yang disebut pekerja layanan. Pekerja layanan adalah proxy yang dapat diprogram yang berada di antara tab pengguna dan Internet yang lebih luas. Mereka mencegat dan menulis ulang atau membuat permintaan jaringan untuk memungkinkan caching yang sangat terperinci dan dukungan offline.

Sejak asal-usul aplikasi web pada tahun 2011, yang memungkinkan situs web di-bookmark ke layar beranda, sejumlah perkembangan telah terjadi untuk meletakkan lebih banyak dasar bagi pembuatan aplikasi web progresif.

Chrome 38 memperkenalkan manifes aplikasi web, yang merupakan file JSON yang menjelaskan konfigurasi aplikasi web Anda. Ini memungkinkan kami untuk menghapus konfigurasi dari head .

Di Chrome 40 (Desember 2014), service worker mulai diluncurkan di Firefox dan Chrome. Apple sejauh ini memilih untuk tidak mengimplementasikan fitur ini di Safari pada saat penulisan tetapi "sedang dipertimbangkan." Fungsi pekerja layanan adalah untuk menyederhanakan proses membawa aplikasi ke offline; itu juga meletakkan dasar untuk fitur seperti aplikasi di masa mendatang, seperti pemberitahuan push dan sinkronisasi latar belakang.

Aplikasi yang dibangun berdasarkan pekerja layanan baru dan manifes aplikasi web dikenal sebagai aplikasi web progresif.

Aplikasi web progresif tidak sama dengan spesifikasi. Faktanya, ini dimulai sebagai definisi tentang apa yang seharusnya menjadi aplikasi web di era pekerja layanan, mengingat teknologi baru yang dibangun ke dalam browser. Secara khusus, Chrome menggunakan definisi ini untuk memicu permintaan penginstalan di browser saat sejumlah kondisi terpenuhi. Syaratnya adalah aplikasi web:

• memiliki pekerja layanan (memerlukan HTTPS);
• memiliki file manifes aplikasi web (dengan setidaknya konfigurasi minimal dan dengan display: "standalone" );
• memiliki dua kunjungan yang berbeda.

Dalam hal ini, "progresif" berarti semakin banyak fitur yang didukung browser, semakin banyak pengalaman seperti aplikasi.

Permintaan untuk menginstal aplikasi web saat ini ditampilkan dalam berbagai kondisi di Opera, Chrome, dan browser Samsung.

Apple telah menunjukkan minat pada aplikasi web progresif untuk iOS, tetapi pada saat penulisan ini masih bergantung pada tag meta untuk konfigurasi aplikasi web dan cache aplikasi (AppCache) untuk penggunaan offline.

Pada Titik Apa Situs Web Menjadi Aplikasi Web?

Kita tahu seperti apa tampilan situs web dan seperti apa aplikasi, tetapi pada titik mana situs web menjadi aplikasi web? Tidak ada metrik pasti tentang apa yang membuat sesuatu menjadi aplikasi web daripada situs web.

Di sini kita akan membahas lebih detail tentang karakteristik aplikasi web.

Aplikasi Web Progresif Harus Menampilkan Properti Seperti Aplikasi Tertentu…

• Responsif
  Mengisi layar dengan sempurna, situs web ini terutama ditujukan untuk ponsel dan tablet dan harus merespons sejumlah besar ukuran layar. Mereka juga harus berfungsi sebagai situs web desktop. Desain responsif telah menjadi bagian utama dari pembuatan situs web selama bertahun-tahun sekarang. Majalah Smashing memiliki beberapa artikel bagus di dalamnya.
• Offline-pertama
  Aplikasi harus mampu memulai offline dan tetap menampilkan informasi yang berguna.
• Mampu menyentuh
  Antarmuka harus dirancang untuk sentuhan, dengan interaksi gerakan. Interaksi pengguna harus terasa responsif dan cepat, tanpa penundaan antara sentuhan dan respons.
• Data meta aplikasi
  Aplikasi harus menyediakan data meta untuk memberi tahu browser bagaimana tampilannya saat dipasang, sehingga Anda mendapatkan ikon resolusi tinggi yang bagus di layar beranda dan layar pembuka di beberapa platform.
• Pemberitahuan push
  Aplikasi dapat menerima pemberitahuan saat aplikasi tidak berjalan (jika ada).

… Tetapi Harus Mempertahankan Properti Seperti Web Tertentu

• Progresif
  Kemampuan aplikasi untuk diinstal adalah peningkatan progresif. Sangat penting bahwa aplikasi tetap berfungsi sebagai situs web normal, terutama pada platform yang belum mendukung instalasi atau pekerja layanan.
• HTTPS di web terbuka
  Aplikasi tidak boleh dikunci ke browser atau toko aplikasi mana pun. Itu harus dapat ditautkan dalam dan harus menyediakan metode untuk membagikan URL saat ini.

Membuat Situs Web Anda Offline

Membuat situs web Anda offline membawa beberapa keuntungan besar.

Pertama, ini akan tetap berfungsi saat pengguna menggunakan koneksi jaringan yang tidak stabil.

Selain itu, waktu dari membuka aplikasi hingga menggunakan aplikasi sangat berkurang jika aplikasi tidak bergantung pada jaringan. Ini memberi pengguna pengalaman hebat. Aplikasi web yang dioptimalkan dengan hati-hati dapat memulai lebih cepat daripada aplikasi asli jika browser telah digunakan baru-baru ini.

Ada dua metode untuk membuat situs web bekerja secara offline:

• Metode lama dan rusak
  Dukungan untuk memulai situs web Anda secara offline telah ada selama bertahun-tahun dalam bentuk AppCache. AppCache memiliki beberapa kelemahan serius, dan bahkan telah ditinggalkan dari spesifikasinya. Sulit untuk bekerja dengannya dan, jika salah konfigurasi, dapat merusak situs web Anda secara permanen. Namun, ini adalah satu-satunya cara untuk melakukan offline di iOS, setidaknya sampai Apple bergerak untuk mendukung pekerja layanan.
• Kehangatan baru
  Juga efektif adalah pekerja layanan, yang saat ini didukung di Chrome, Firefox dan Opera dan segera hadir di Edge. Tim WebKit Apple telah menandainya sebagai "sedang dipertimbangkan."

Pekerja layanan seperti pekerja web lainnya karena mereka berjalan di utas terpisah, tetapi mereka tidak terikat pada tab tertentu. Mereka diberi cakupan URL saat dibuat, dan mereka dapat mencegat dan menulis ulang permintaan apa pun dalam cakupan ini. Jika service worker Anda berada di https://example.com/my-site/sw.js , itu akan dapat mencegat permintaan apa pun yang dibuat ke /my-site/ atau lebih rendah tetapi tidak dapat dibuat untuk mencegat permintaan ke root https://example.com/ .

Karena mereka tidak terikat pada tab apa pun, mereka dapat dihidupkan di latar belakang untuk menangani pemberitahuan push atau sinkronisasi latar belakang. Paling tidak, tidak mungkin untuk memutuskan situs web Anda secara permanen dengan mereka karena mereka akan diperbarui secara otomatis ketika skrip pekerja layanan baru terdeteksi.

Pedoman yang baik adalah, jika Anda membangun situs web baru dari awal, mulailah dengan pekerja layanan. Namun, jika situs web Anda sudah bekerja offline dengan AppCache, maka Anda dapat menggunakan alat sw-appcache-behavior untuk menghasilkan pekerja layanan dari ini, karena kami mungkin akan segera mencapai titik ketika beberapa browser hanya akan menerima pekerja layanan dan beberapa hanya akan menerima Cache Aplikasi.

Karena AppCache sudah tidak digunakan lagi, saya tidak akan membahasnya lebih lanjut di artikel ini.

Menyiapkan Service Worker

(Juga, lihat “Menyiapkan Service Worker” untuk instruksi yang lebih detail.)

Karena pekerja layanan adalah tipe khusus pekerja web bersama, itu berjalan di utas terpisah ke halaman utama Anda. Ini berarti bahwa itu dibagikan oleh semua halaman web di jalur yang sama dengan pekerja layanan. Misalnya, service worker yang berada di /my-page/sw.js akan dapat memengaruhi /my-page/index.html dan my-page/images/header.jpg , tetapi tidak /index.html .

Pekerja layanan dapat mencegat dan menulis ulang atau menipu semua permintaan jaringan yang dibuat di halaman, termasuk yang dibuat ke data:// URL!

Kekuatan ini memungkinkannya memberikan respons yang di-cache agar halaman berfungsi saat tidak ada koneksi data. Namun, itu cukup fleksibel untuk memungkinkan banyak kemungkinan kasus penggunaan.

Ini hanya diperbolehkan dalam konteks aman (yaitu HTTPS) karena sangat kuat. Ini mencegah pihak ketiga untuk mengesampingkan situs web Anda secara permanen menggunakan pekerja layanan yang disuntikkan dari titik akses Wi-Fi yang terinfeksi atau berbahaya.

Menyiapkan HTTPS saat ini mungkin tampak menakutkan dan mahal, tetapi sebenarnya tidak pernah semudah atau semurah ini. Let's Encrypt menyediakan sertifikat dan skrip SSL gratis bagi Anda untuk mengonfigurasi server Anda secara otomatis. Jika Anda menghosting di GitHub, Halaman GitHub secara otomatis disajikan melalui HTTPS. Halaman Tumblr juga dapat dikonfigurasi untuk berjalan di HTTPS. CloudFlare dapat mem-proxy permintaan untuk meningkatkan ke HTTPS.

Offlining biasanya melibatkan pemilihan metode caching tertentu untuk berbagai bagian situs web Anda agar dapat dilayani lebih cepat atau ketika tidak ada koneksi internet. Berbagai metode caching akan saya bahas di bawah ini.

Saya menggunakan Service Worker Toolbox untuk mengabstraksi logika caching yang kompleks. Pustaka ini dapat diatur untuk menangani perutean dengan menyediakan empat rute yang telah dikonfigurasi sebelumnya, yang dapat dikonfigurasi dengan cara yang bersih. Itu dapat diimpor ke pekerja layanan Anda.

Kasus Penggunaan 1: Precaching

Precaching menarik permintaan sebelum situs web Anda berhasil bahwa mereka dibutuhkan. Ini dapat sangat mengurangi waktu pengecatan pertama karena situs web Anda tidak perlu menguraikan /site.css sebelum mulai mengunduh logo situs web Anda, /images/logo.png .

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

Kasus Penggunaan 2: Offline

Mengizinkan pengguna untuk mengunjungi kembali situs web Anda saat mereka offline dalam kasus yang paling sederhana berarti kembali ke cache jika perangkat sedang offline. Menetapkan batas waktu di sini penting karena jaringan yang tidak stabil, router yang salah konfigurasi, atau portal tawanan dapat membuat pengguna menunggu tanpa batas waktu.

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

Pada kenyataannya, kita sebenarnya bisa sedikit lebih pintar karena sebagian besar aset Anda tidak akan berubah seiring waktu. Kami mungkin hanya ingin mendapatkan konten sesegera mungkin, baik dari cache atau jaringan. Baris berikut memberi tahu Service Worker Toolbox bahwa semua permintaan ke jalur gambar harus berasal dari cache jika tersedia di sana.

 toolbox.router.all('/images/*', toolbox.fastest);

Dalam hal ini, saat pengguna mengautentikasi, penting agar kami tidak hanya mengembalikan respons yang di-cache; kita harus menyatakan bahwa permintaan yang dibuat ke /auth/ harus hanya untuk jaringan.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

Berikut adalah beberapa praktik yang baik untuk offline:

• Aset statis awal harus di-cache terlebih dahulu. Ini mengunduhnya dan menyimpannya dalam cache saat pekerja layanan diinstal. Ini berarti bahwa mereka tidak perlu dimuat dari server saat dibutuhkan.
• Secara default, permintaan idealnya harus baru bersumber dari jaringan tetapi kembali ke cache sehingga tersedia secara offline.
• Batas waktu jaringan yang relatif singkat berarti bahwa permintaan akan dapat mengembalikan data yang di-cache pada koneksi jaringan yang mengatakan bahwa ia memiliki koneksi data tetapi tidak ada tanggapan yang dikembalikan.
• Aset yang jarang diperbarui, seperti gambar, harus dikirim dari cache terlebih dahulu, kemudian browser juga akan mencoba memperbaruinya. Jika toolbox.cacheOnly digunakan, maka bisa juga menyimpan data pengguna.

Catatan: Cache browser dan Cache API adalah hewan yang berbeda. Cache API telah dilewati dalam kasus network-first atau network-only. Permintaan mungkin masih mengenai cache browser karena header caching dalam permintaan mengatakan itu masih valid. Hal ini dapat mengakibatkan masalah pengguna menerima campuran data yang di-cache dan baru. Jake Archibald memiliki beberapa saran bagus untuk menghindari masalah ini.

Men-debug Service Worker Anda

Jika Anda menggunakan Chrome atau Opera, buka chrome://serviceworker-internals . Ini akan memungkinkan Anda untuk memeriksa dan menjeda dan mencopot pemasangan skrip pekerja layanan Anda.

Di Chrome dan Opera versi terbaru, Anda bisa mendapatkan tampilan mendetail dan alat debugging melalui tab "Aplikasi" di inspektur.

Interaksi Dan Pertunjukan Animasi

Orang-orang berharap bahwa web tidak memiliki antarmuka animasi yang mulus seperti yang dilakukan oleh aplikasi asli. Namun, standar yang sama tidak dapat diterima untuk aplikasi web. Aplikasi web harus dianimasikan dengan lancar, agar pengguna kami tidak merasa bahwa kami memberikan pengalaman kelas dua yang terdegradasi. Kami memiliki tiga tujuan untuk membuatnya terasa cepat:

• Saat pengguna melakukan sesuatu, aplikasi juga harus melakukan sesuatu dalam waktu 100 milidetik; jika tidak, pengguna akan melihat jeda. Ini dihitung untuk ketukan, klik, seret, dan gulir.
• Setiap frame harus dirender pada 60 frame per detik yang konsisten (16 milidetik per frame). Bahkan beberapa frame lambat akan terlihat jelas.
• Itu harus cepat pada ponsel anggaran berusia tiga tahun yang berjalan di jaringan yang buruk, tidak hanya mesin pengembangan Anda yang mengkilap.
• Itu harus dimulai dengan cepat. Sudah lama kami berfokus untuk mempertahankan keterlibatan pengguna dengan membuat situs web kami terlihat dan dapat digunakan dalam waktu kurang dari 1 hingga 2 detik. Dalam hal aplikasi web, waktu memulai sama pentingnya dengan sebelumnya. Jika semua konten aplikasi di-cache dan browser masih ada di memori perangkat, aplikasi web dapat dimulai lebih cepat daripada aplikasi asli. Satu kesalahan yang dibuat oleh aplikasi asli dan pengembang situs web sama-sama membutuhkan konten jaringan agar produk berfungsi.
• Aplikasi web harus kecil untuk diunduh dan diperbarui: 10 MB dari toko aplikasi tidak terasa banyak, tetapi 10 MB yang tidak di-cache yang diunduh setiap kali sangat tidak mungkin dikelola untuk banyak pengguna seluler.

Langsung saja, item yang paling penting adalah ini, di bagian head dokumen:

 <meta name="viewport" content="width=device-width">

Baris ini memastikan bahwa tidak ada penundaan ketukan 300 milidetik pada browser ponsel yang berbasis Chromium atau Firefox, tetapi tetap memungkinkan pengguna untuk memperbesar dengan mencubit (bagus untuk aksesibilitas).

Sejak iOS 8 keluar, klik cepat secara default tetapi mungkin tampak lambat jika ketukannya cepat, menurut heuristik tertentu. Jika ini menjadi masalah bagi Anda, saya sarankan menggunakan FastClick untuk menghilangkan penundaan.

Ada juga masalah kinerja animasi. Anda mungkin menginginkan banyak elemen cantik yang masuk dan keluar, elemen yang dapat diseret oleh pengguna, dan interaksi indah lainnya.

Performa web dapat didiskusikan dengan sangat detail dan merupakan subjek yang dekat dengan hati saya, tetapi saya tidak akan membahasnya secara mendetail di sini. Saya akan menyentuh apa yang saya lakukan untuk memastikan bahwa interaksi dan animasi saya tajam dan halus.

Cari tahu atau tanyakan kepada teman atau keluarga Anda tentang smartphone lama. Saya biasanya meminjam Nexus 4 milik pasangan saya.

Colokkan ponsel ke komputer Anda, dan buka chrome://inspect/#devices . Ini akan membuka jendela inspeksi, yang dapat Anda gunakan untuk memeriksa halaman web yang berjalan di telepon. Anda dapat menggunakan pembuatan profil dan melihat garis waktu untuk menemukan sumber kinerja yang buruk dan kemudian mengoptimalkannya berdasarkan perangkat dasar yang sebenarnya.

Menganimasikan properti CSS tertentu adalah salah satu penyebab terbesar animasi gelisah, yang dikenal sebagai jank. Pemicu CSS adalah sumber yang bagus untuk menentukan properti mana yang dapat dianimasikan dengan aman tanpa menyebabkan browser mengecat ulang atau menata ulang seluruh halaman.

Jika menulis animasi performant adalah tugas yang menakutkan bagi Anda, banyak perpustakaan di luar sana akan menangani pekerjaan itu. Favorit saya adalah GreenSock, yang dapat menangani interaksi sentuh dengan sangat baik, seperti menyeret item, dan yang dapat melakukan animasi dan tweening yang sangat mewah.

Pemberitahuan Dorong

Pemberitahuan push adalah cara yang bagus untuk terlibat kembali dengan pengguna. Dengan meminta pengguna, Anda membawa aplikasi Anda ke depan pikiran mereka. Mereka dapat menyelesaikan transaksi yang belum selesai atau menerima peringatan tentang konten baru yang relevan.

Pastikan pemberitahuan push Anda relevan dengan pengguna untuk peristiwa yang terjadi pada saat itu. Jangan buang waktu mereka untuk hal-hal yang bisa dilakukan nanti. Apa yang Anda beri tahu mereka harus memerlukan tindakan mereka (membalas seseorang atau pergi ke suatu acara). Juga, jangan mendorong pemberitahuan jika aplikasi web Anda terlihat atau dalam fokus.

Saat berinteraksi dengan, pemberitahuan harus membawa pengguna ke halaman yang berfungsi offline. Pemberitahuan dapat berkeliaran belum dibaca; mereka mungkin berinteraksi dengan ketika pengguna tidak memiliki koneksi jaringan. Pengguna akan frustrasi jika pemberitahuan push Anda menolak bekerja setelah mereka mencoba berinteraksi dengannya.

Pengalaman terbaik untuk pemberitahuan push membebaskan pengguna dari keharusan membuka aplikasi web Anda sama sekali ! "Anda memiliki pesan baru" tidak berguna dan sama menjengkelkannya dengan judul clickbait. Menampilkan pesan dan pengirim.

Tombol tindakan dalam notifikasi dapat memberikan perintah interaksi yang tidak perlu membuka browser (“Suka postingan ini”, “Balas dengan ya”, “Balas dengan tidak”, “Ingatkan saya nanti”). Ini melayani pengguna dengan persyaratan mereka, membuat mereka tetap terlibat dan meminimalkan investasi waktu mereka.

Jika Anda mengirim spam kepada pengguna dengan notifikasi biasa atau tidak relevan, mereka mungkin menonaktifkan notifikasi untuk aplikasi Anda di browser. Setelah itu, hampir tidak mungkin untuk melibatkan kembali mereka, dan Anda tidak akan dapat dengan mudah meminta izin lagi kepada mereka!

Untuk menghindarinya, buat rute ke tombol "nonaktifkan notifikasi" aplikasi Anda jelas dan mudah. Setelah Anda mengatasi masalah yang membuat pengguna frustrasi, Anda dapat mencoba untuk terlibat kembali.

Push Notification API membutuhkan service worker. Karena dimungkinkan untuk menerima notifikasi push saat tidak ada tab browser yang terbuka, service worker akan menangani permintaan notifikasi di utas latar belakang. Itu dapat melakukan operasi asinkron, seperti membuat permintaan pengambilan ke API Anda sebelum menampilkan pemberitahuan kepada pengguna.

Untuk membuat pemberitahuan push, buat permintaan ke titik akhir yang disediakan oleh produsen browser. Untuk browser berbasis Chromium (Opera, Samsung, dan Chrome), ini adalah Firebase Cloud Messaging. Peramban ini juga berperilaku sedikit di luar spesifikasi.

Seseorang dapat menemukan detailnya dengan meminta izin pemberitahuan push:

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

Langganan adalah objek yang terlihat seperti ini:

 { "endpoint": "https://example.com/some/uuid" }

Pada contoh di atas, uuid secara unik mengidentifikasi browser yang sedang digunakan.

Catatan: Peramban berbasis Chromium berperilaku sedikit berbeda. Anda memerlukan ID aplikasi Firebase, yang harus dimasukkan dalam file manifes aplikasi web Anda (misalnya, "gcm_sender_id": "90157766285" ).

Juga, titik akhir tidak akan berfungsi dalam format yang diberikan. Server Anda perlu sedikit mengotak-atiknya agar berfungsi. Itu harus berupa permintaan POST , dengan kunci API Anda di head dan uuid di body .

Saat mengirim pemberitahuan push, dimungkinkan untuk mengirim data di badan pemberitahuan push itu sendiri. Ini rumit dan melibatkan enkripsi konten dalam permintaan API. Paket web-push untuk Node.js dapat menangani ini, tetapi saya tidak menyukainya.

Dimungkinkan untuk melakukan permintaan asinkron setelah pemberitahuan diterima, jadi saya lebih suka mengirim pemberitahuan minimal, yang dikenal sebagai "gelitik," ke klien, dan kemudian pekerja layanan akan membuat permintaan pengambilan ke API saya untuk menarik update terbaru.

Catatan: Service worker dapat ditutup oleh browser kapan saja. Fungsi event.waitUntil dalam acara push memberi tahu pekerja layanan untuk tidak menutup sampai acara selesai.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

Anda juga dapat mendengarkan interaksi klik atau tekan pada acara notifikasi. Gunakan ini untuk memutuskan bagaimana merespons. Anda dapat membuka tab browser baru, memfokuskan tab yang ada, atau membuat permintaan API. Anda juga dapat memilih apakah akan menutup notifikasi atau tetap membukanya. Gunakan fungsi ini dengan tindakan pada notifikasi untuk membangun fungsionalitas hebat ke dalam notifikasi itu sendiri. Ini akan memberikan pengalaman yang luar biasa, karena pengguna tidak perlu membuka aplikasi Anda setiap saat.

Jangan Abaikan Kekuatan Web

Poin terakhir dan terpenting adalah, dalam ketergesaan kami untuk mendapatkan pengalaman seperti aplikasi, kami tidak boleh lupa untuk tetap seperti web dalam satu aspek yang sangat penting: URL.

Aplikasi web yang diinstal sering kali menyembunyikan cangkang browser. Tidak ada bilah alamat bagi pengguna untuk membagikan URL saat ini, dan pengguna tidak dapat menyimpan halaman saat ini untuk nanti.

URL memiliki keunggulan web yang unik: Anda dapat membuat orang menggunakan aplikasi Anda dengan mengeklik, bukan dengan menjelaskan cara menavigasinya. Bagaimanapun, sangat mudah untuk melupakan hal ini kepada pengguna. Anda dapat menulis aplikasi terbaik di dunia, tetapi jika tidak ada yang dapat membagikannya, Anda telah merugikan diri sendiri.

Intinya begini: Sediakan cara untuk membagikan aplikasi Anda melalui tombol berbagi atau tombol untuk mengekspos URL.

Bagaimana Dengan Peramban yang Tidak Mendukung Aplikasi Web Progresif?

Lihat Apakah ServiceWorker siap? untuk status dukungan saat ini bagi pekerja layanan di seluruh browser.

Anda mungkin telah memperhatikan semua ini bahwa saya telah menyebutkan Chrome, Firefox dan Edge tetapi mengabaikan Safari. Apple memperkenalkan aplikasi web ke dunia dan telah menunjukkan minat pada aplikasi web progresif, tetapi masih tidak mendukung pekerja layanan atau manifes aplikasi web. Apa yang bisa kau lakukan?

Dimungkinkan untuk membuat situs web offline untuk Safari dengan AppCache, tetapi melakukannya sulit dan penuh dengan kasus tepi aneh yang dapat merusak halaman atau membuatnya kedaluwarsa secara permanen setelah memuat pertama.

Sebagai gantinya, bangun pengalaman aplikasi web yang hebat. Pekerjaan Anda tidak akan sia-sia karena pengalaman akan tetap bagus di Safari, yang merupakan browser yang sangat bagus. Saat pekerja layanan datang ke Safari, Anda akan siap memanfaatkannya.

Akhirnya, kita dapat menantikan banyak perkembangan menarik di dunia aplikasi web, dengan meningkatnya dukungan untuk teknologi di belakangnya dan fitur-fitur baru yang datang ke platform web, seperti Web Bluetooth API untuk berinteraksi dengan perangkat keras, WebVR untuk virtual realitas, dan WebGL 2 untuk game berkecepatan tinggi. Sekarang adalah waktu yang tepat untuk menjelajahi kemungkinan aplikasi web dan mengambil bagian dalam membentuk masa depan web.

Tautan

Tulisan Lain di Aplikasi Web Progresif

• “Blog Lain Tentang Keadaan dan Masa Depan Aplikasi Web Progresif,” Ada Rose Edwards

Tautan Diacu dalam Artikel

• “Bentuk App Store,” Charles Perry
• Pembantu Pekerja Layanan, Google, GitHub
• Kotak Alat Pekerja Layanan, Google, GitHub
• “Penundaan Klik 300 Milidetik dan iOS 8,” TJ VanToll
• “Cache Praktik terbaik dan Gotcha usia maksimal,” Jake Archibald