تعديل

لقد نشرت تطبيق الويب التقدّمي (PWA) الخاص بك: يستخدمه بعض المستخدمين من المتصفّح، بينما يثبّته آخرون على أجهزتهم. عند تحديث التطبيق، من المهم تطبيق أفضل الممارسات لتجنُّب المخاطر.

يمكنك تعديل ما يلي:

  • بيانات التطبيقات.
  • سبق أن تم تخزين مواد العرض مؤقتًا في الأجهزة.
  • ملف مشغّل الخدمات، أو تبعياته
  • البيانات الوصفية للبيان.

لنتحقق من أفضل الممارسات لكل عنصر من هذه العناصر.

تحديث البيانات

لتعديل البيانات، مثل البيانات المخزَّنة في IndexedDB، يمكنك استخدام أدوات مثل Fetch أو WebRTC أو WebSockets API. إذا كان تطبيقك يتيح استخدام أي ميزات بلا إنترنت، تذكّر تحديث البيانات التي تتيح الميزات باستمرار.

على المتصفّحات المتوافقة، تتوفّر خيارات لمزامنة البيانات، ليس فقط عندما يفتح المستخدم تطبيق الويب التقدّمي (PWA) ولكن أيضًا في الخلفية. هذه الخيارات هي:

  • المزامنة في الخلفية: يحفظ الطلبات التي تعذّر تنفيذها ويعيد محاولة إجرائها باستخدام المزامنة من مشغّل الخدمة.
  • المزامنة الدورية في الخلفية على الويب: تعمل على مزامنة البيانات بشكل دوري في الخلفية وفي أوقات محدّدة، ما يسمح للتطبيق بتوفير بيانات محدّثة حتى إذا لم يفتح المستخدم التطبيق بعد.
  • الجلب في الخلفية: يؤدي إلى تنزيل الملفات الكبيرة، حتى في حال كان تطبيق الويب التقدّمي (PWA) مغلقًا.
  • الدفع على الويب: يرسل رسالة من الخادم تعمل على تنشيط مشغّل الخدمات وإعلام المستخدم. ويُعرف هذا الإجراء عادةً باسم "الإشعارات الفورية". تتطلّب واجهة برمجة التطبيقات هذه الحصول على إذن من المستخدم.

ويتم تنفيذ جميع واجهات برمجة التطبيقات هذه من سياق مشغّل الخدمات. وتتوفّر هذه الإضافات حاليًا فقط على المتصفّحات المستندة إلى Chromium على أنظمة التشغيل Android والكمبيوتر المكتبي. عند استخدام إحدى واجهات برمجة التطبيقات هذه، يمكنك تشغيل رمز في سلسلة مشغِّل الخدمات، على سبيل المثال، لتنزيل البيانات من الخادم وتحديث بيانات قاعدة البيانات المفهرسة.

جارٍ تعديل مواد العرض

يتضمن تحديث مواد العرض أي تغييرات على الملفات التي تستخدمها لعرض واجهة التطبيق، مثل HTML وCSS وJavaScript والصور. على سبيل المثال، تغيير في منطق تطبيقك، أو صورة تمثل جزءًا من الواجهة، أو ورقة أنماط CSS.

تعديل الأنماط

في ما يلي بعض الأنماط الشائعة للتعامل مع تحديثات التطبيقات، ولكن يمكنك دائمًا تخصيص هذه العملية وفقًا لاحتياجاتك:

  • التحديث الكامل: كل تغيير، حتى لو كان بسيطًا، يؤدي إلى استبدال محتوى ذاكرة التخزين المؤقت بالكامل. يحاكي هذا النمط كيفية تعامل التطبيقات الخاصة بالجهاز مع التحديثات، كما أنه يستهلك المزيد من معدل نقل البيانات وسيستغرق المزيد من الوقت.
  • تعديل مواد العرض المتغيّرة: يتم فقط استبدال مواد العرض التي تغيّرت منذ آخر تعديل في ذاكرة التخزين المؤقت. ويتم تنفيذه غالبًا باستخدام مكتبة، مثل Workbox. يتضمن إنشاء قائمة بالملفات المخزنة مؤقتًا وتمثيل تجزئة للملف والطوابع الزمنية. باستخدام هذه المعلومات، يقارن مشغّل الخدمات هذه القائمة بمواد العرض المخزّنة مؤقتًا ويحدّد مواد العرض المطلوب تعديلها.
  • تعديل مواد العرض الفردية: يتم تعديل كل مادة عرض بشكل فردي عند تغييرها. تشكّل استراتيجية إعادة التحقق القديمة الموضّحة في فصل العرض مثالاً على تعديل مواد العرض بشكلٍ فردي.

الفترة المناسبة للتحديث

من الممارسات الجيدة الأخرى تحديد وقت مناسب للبحث عن التحديثات وتطبيقها. وإليك بعض الخيارات:

  • عند استيقاظ عامل الخدمة. ما من حدث للاستماع إليه في الوقت الحالي، ولكن سينفذ المتصفِّح أي رمز في النطاق العمومي لعامل الخدمة عند تنشيطه.
  • في سياق النافذة الرئيسية لتطبيق الويب التقدّمي (PWA) بعد أن حمَّل المتصفّح الصفحة، لتجنُّب إبطاء عملية تحميل التطبيق.
  • عند تشغيل أحداث في الخلفية، مثلاً عند تلقّي تطبيق الويب التقدّمي (PWA) إشعارًا فوريًا أو تنشيط مزامنة في الخلفية. يمكنك تعديل ذاكرة التخزين المؤقت بعد ذلك، وسيتلقّى المستخدمون الإصدار الجديد من مادة العرض في المرة التالية التي يفتحون فيها التطبيق.

آخر المستجدات المباشرة

يمكنك أيضًا اختيار ما إذا كنت تريد تطبيق تحديث عندما يكون التطبيق مفتوحًا (منشورًا) أو مغلقًا. عند إغلاق نهج التطبيق، على الرغم من أنّ التطبيق قد نزّل مواد عرض جديدة، لن يجري أي تغييرات وسيستخدم الإصدارات الجديدة في عملية التحميل التالية.

ويعني التحديث المباشر أنّه بمجرد تعديل مادة العرض في ذاكرة التخزين المؤقت، سيحلّ تطبيق الويب التقدّمي (PWA) محلّ مادة العرض في التحميل الحالي. إنها مهمة معقدة لم يتم تناولها في هذه الدورة. بعض الأدوات التي تساعد في تنفيذ هذا التحديث هي livereload-js وCSSStyleSheet.replace() API لتحديث مواد العرض.

تعديل مشغّل الخدمات

يشغّل المتصفّح خوارزمية التحديث عند تغيير مشغّل الخدمات أو تبعياته. يكتشف المتصفح التحديثات باستخدام مقارنة بالبايت بين الملفات المخزنة مؤقتًا والموارد القادمة من الشبكة.

بعد ذلك، يحاول المتصفِّح تثبيت الإصدار الجديد من مشغّل الخدمات، وسيكون عامل الخدمة الجديد في حالة الانتظار، كما هو موضَّح في فصل مشغّلي الخدمات. ستؤدي عملية التثبيت الجديدة إلى تشغيل حدث "install" لمشغّل الخدمات الجديد. إذا كنت تخزِّن مواد العرض في ذاكرة التخزين المؤقّت في معالج الحدث هذا، ستتم أيضًا إعادة تخزين مواد العرض في ذاكرة التخزين المؤقت.

رصد تغييرات مشغّل الخدمات

لرصد أنّ مشغّل الخدمات الجديد جاهز ومُثبّت، نستخدم حدث updatefound من عملية تسجيل مشغّل الخدمات. يتم تنشيط هذا الحدث عندما يبدأ مشغّل الخدمات الجديد في التثبيت. علينا الانتظار حتى يتم تغيير الحالة إلى installed مع حدث statechange، ويمكنك الاطّلاع على ما يلي:

async function detectSWUpdate() {
  const registration = await navigator.serviceWorker.ready;

  registration.addEventListener("updatefound", event => {
    const newSW = registration.installing;
    newSW.addEventListener("statechange", event => {
      if (newSW.state == "installed") {
         // New service worker is installed, but waiting activation
      }
    });
  })
}

فرض الإلغاء

سيتم تثبيت مشغّل الخدمات الجديد ولكنه في انتظار التفعيل تلقائيًا. يمنع الانتظار عامل الخدمة الجديد من تولي العملاء القدامى الذين قد لا يكونون متوافقين مع الإصدار الجديد.

وعلى الرغم من أنّه لا يُنصح بهذا الإجراء، يمكن لعامل الخدمة الجديد تخطّي فترة الانتظار هذه وبدء عملية التفعيل على الفور.

self.addEventListener("install", event => {
   // forces a service worker to activate immediately
   self.skipWaiting();
  });

self.addEventListener("activate", event => {
  // when this SW becomes activated, we claim all the opened clients
  // they can be standalone PWA windows or browser tabs
  event.waitUntil(clients.claim());
});

يتم تنشيط الحدث controllerchange عندما يتحكّم مشغّل الخدمات في الصفحة الحالية. على سبيل المثال، تخطى العامل الجديد فترة الانتظار وأصبح العامل النشط الجديد.

navigator.serviceWorker.addEventListener("controllerchange", event => {
   // The service worker controller has changed
 });

تعديل البيانات الوصفية

يمكنك أيضًا تعديل البيانات الوصفية لتطبيقك، التي تم ضبطها بشكل أساسي في بيان تطبيق الويب. على سبيل المثال، عدِّل رمز التطبيق أو اسمه أو عنوان URL للبدء، أو يمكنك إضافة ميزة جديدة مثل اختصارات التطبيقات. ولكن ماذا يحدث لجميع المستخدمين الذين ثبَّتوا التطبيق بالرمز القديم على أجهزتهم؟ كيف ومتى يحصلون على الإصدار المحدَّث؟

تعتمد الإجابة على المنصة. لنتناول الخيارات المتاحة.

Safari على متصفّحات iOS وiPadOS وAndroid

على هذه الأنظمة الأساسية، لا يمكن الحصول على البيانات الوصفية الجديدة في ملف البيان إلا من خلال إعادة تثبيت التطبيق من المتصفح.

Google Chrome على نظام Android باستخدام WebAPK

عندما يثبّت المستخدم تطبيق الويب التقدّمي (PWA) على جهاز Android باستخدام Google Chrome مع تفعيل WebAPK (معظم عمليات تثبيت تطبيق الويب التقدّمي Chrome)، سيتم رصد التحديث وتطبيقه استنادًا إلى إحدى الخوارزميات. يمكنك الاطّلاع على التفاصيل في مقالة تعديلات البيان هذه.

بعض الملاحظات الإضافية حول هذه العملية:

إذا لم يفتح المستخدم تطبيق الويب التقدّمي (PWA)، لن يتم تعديل WebAPK الخاصة به. في حال عدم استجابة الخادم مع إدراج ملف البيان (هناك خطأ 404)، لن يبحث Chrome عن تحديثات لمدة 30 يومًا على الأقل، حتى إذا فتح المستخدم تطبيق الويب التقدّمي (PWA).

يُرجى الانتقال إلى about:webapks في متصفِّح Chrome على نظام التشغيل Android للاطّلاع على حالة العلامة "بحاجة إلى تحديث"، وطلب تحديث. في فصل الأدوات وتصحيح الأخطاء، يمكنك قراءة المزيد عن أداة تصحيح الأخطاء هذه.

اتصال Samsung بالإنترنت على نظام Android باستخدام WebAPK

وتتشابه هذه العملية مع إصدار Chrome. في هذه الحالة، إذا كان بيان PWA يتطلب تحديثًا، سيتم تعديل WebAPK على شبكة Wi-Fi خلال الـ 24 ساعة القادمة بعد إصدار WebAPK الجديد.

Google Chrome وMicrosoft Edge على أجهزة الكمبيوتر المكتبي

على أجهزة الكمبيوتر المكتبي، عند تشغيل تطبيق الويب التقدّمي (PWA)، يحدّد المتصفّح آخر مرة تحقّق فيها من البيان المحلي بحثًا عن التغييرات. إذا لم تتم مراجعة البيان منذ آخر مرة تم فيها تشغيل المتصفِّح أو لم يتم التحقُّق منه خلال آخر 24 ساعة، سيطلب المتصفِّح إدخال بيان من الشبكة ثم يقارنه بالنسخة المحلية.

عند تعديل المواقع الإلكترونية المحدّدة، سيؤدي ذلك إلى إجراء تعديل بعد إغلاق جميع النوافذ.

تنبيه المستخدم

تتطلب بعض استراتيجيات التحديث إعادة تحميل أو تنقل جديد من العملاء. سيلزمك إخبار المستخدم بوجود تحديث في انتظار التثبيت، ولكن مع منحه الفرصة لتحديث الصفحة في الوقت المناسب له.

لإعلام المستخدم، تتوفّر لك الخيارات التالية:

  • يمكنك استخدام DOM أو canvas API لعرض إشعار على الشاشة.
  • استخدِم Web Notifications API. تعتبر واجهة برمجة التطبيقات هذه جزءًا من إذن الدفع لإنشاء إشعار في نظام التشغيل. ستحتاج إلى طلب إذن لإرسال الإشعارات على الويب لاستخدام هذه الخدمة، حتى إذا لم تكن تستخدم بروتوكول المراسلة الفورية من خادمك. هذا هو الخيار الوحيد المتاح لدينا في حال عدم فتح تطبيق الويب التقدّمي (PWA).
  • استخدِم Badging API لإظهار أنّ التحديثات متوفّرة في رمز تطبيق الويب التقدّمي (PWA) المثبَّت.

إشعار بالتعديل معروض في DOM..

مزيد من المعلومات حول واجهة برمجة التطبيقات Badging API

تتيح لك Badging API وضع رقم شارة أو نقطة شارة على رمز تطبيق الويب التقدّمي (PWA) على المتصفّحات المتوافقة. نقطة الشارة هي علامة صغيرة داخل رمز مثبّت وتعبّر عن وجود شيء في انتظارك داخل التطبيق.

مثال على Twitter مع ثمانية إشعارات وتطبيق آخر يعرض شارة نوع الإبلاغ

يجب طلب الرقم setAppBadge(count) بشأن الكائن navigator لضبط رقم شارة. ويمكنك إجراء ذلك من النافذة أو من سياق مشغّل الخدمات عندما تعرف أنّ هناك تحديثًا لتنبيه المستخدم.

let unreadCount = 125;
navigator.setAppBadge(unreadCount);

لمحو الشارة، عليك استدعاء clearAppBadge() على الكائن نفسه:

navigator.clearAppBadge();

المراجِع