نقل مصدر تطبيقات الويب التقدّمية بسلاسة: تغيير النطاقات بدون فقدان المستخدمين

Dibyajyoti Pal

Dan Murphy

Marijn Kruisselbrink

تاريخ النشر: 3 يونيو 2026

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

عندما أردت تغيير العلامة التجارية أو إعادة هيكلة بنية موقعك الإلكتروني (مثلاً، الانتقال من www.example.com/social إلى social.example.com)، كان عليك الاختيار بين خيارين صعبين. لم يكن هناك طريقة "لنقل" تطبيق ويب تقدّمي مثبَّت. واضطر المستخدمون إلى إلغاء تثبيت التطبيق القديم يدويًا والعثور على زر التثبيت الخاص بالتطبيق الجديد.

يسرّ فريق تطبيقات الويب التقدّمية أن يقدّم ميزة نقل مصدر تطبيقات الويب التقدّمية في الإصدار 150 من Chrome. تتيح لك ميزة المنصة الجديدة هذه نقل تطبيقات الويب التقدّمية المثبَّتة بسلاسة إلى مصدر جديد على الموقع نفسه، مع الحدّ من مقاطعة المستخدمين، مع إبقائهم على اطّلاع كافٍ.

ما يتيحه نقل البيانات من المصدر

يمكنك تعديل بنية موقعك الإلكتروني بدون التأثير سلبًا في تجربة المستخدم:

• حرية البنية التقنية: يمكنك تغيير النطاق الفرعي أو مسار تطبيقك.
• إصلاح حالات التطبيق المقسّم: تم حلّ المشكلة التي تؤدي إلى إنشاء عمليات تثبيت مكرّرة للتطبيق عند تغيير start_url بدون رقم تعريف ثابت.

يمكن للمستخدمين نقل تطبيقاتهم من خلال مربّع حوار بسيط للتحديث. ويتم إعلامهم بعملية نقل البيانات بطريقة مشابهة لتحديث التطبيق العادي. بنقرة واحدة، يتم إلغاء تثبيت التطبيق القديم وتثبيت التطبيق الجديد وتشغيله.

كيفية نقل تطبيق ويب تقدّمي

لنقل تطبيق ويب تقدّمي، اتّبِع الخطوات التالية، وسنتناول بقية التفاصيل في بقية المشاركة:

1. تنفيذ المصافحة:
   • أضِف migrate_from إلى التطبيق الجديد.
   • أضِف الحقل allow_migration إلى الملف /.well-known/web-app-origin-association على المصدر القديم.
2. اختيار السلوك: يؤدي الخيار suggest (أو ترك الحقل فارغًا) إلى تجنُّب مقاطعة المستخدم، ومن المحتمل أن يكون مفيدًا أثناء عملية الطرح الأوّلية. يؤدي الخيار force إلى حظر المستخدم ويتطلّب عملية النقل إذا لم يتمكّن المستخدم من مواصلة استخدام عناوين URL القديمة.
3. الحفاظ على تحديث التطبيق القديم: إذا كان الموقع الإلكتروني القديم يعيد التوجيه إلى الموقع الإلكتروني الجديد، استخدِم السمة install_url في الحظر migrate_from لضمان أن يتمكّن المتصفّح من العثور على البيان القديم للتحديثات المحتملة.
4. تنفيذ id في بيان التطبيق الوجهة: يتطلّب Chrome أن يتضمّن بيان التطبيق الوجهة الحقل id، ما يضمن عدم وقوع التطبيق في الخطأ الشائع المتمثل في إنشاء تطبيقات مقسّمة عن طريق تغيير start_url بدون ضبط id.

المصافحة ثنائية الاتجاه: طريقة عملها

لضمان الأمان ومنع عمليات الاستيلاء العدوانية، تتطلّب عملية نقل البيانات مصافحة آمنة بين المصدر القديم والمصدر الجديد. يضمن هذا الإجراء أن يتحكّم الكيان نفسه في كلا الموقعَين الإلكترونيَين.

الخطوة 1: يعرّف التطبيق الجديد التطبيق السابق (مطلوب)

أضِف حقل migrate_from إلى بيان تطبيق الويب الخاص بالتطبيق الجديد.

// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    "https://drive.google.com/"
  ]
}

الخطوة 2: تأكيد عملية نقل البيانات من المصدر القديم (مطلوبة)

لمنع موقع إلكتروني جديد من الاستيلاء من جانب واحد على تطبيق قديم، يجب أن يمنح المصدر القديم إذنًا صريحًا بعملية النقل، وذلك باستخدام ملف إعداد .well-known.

// File at https://drive.google.com/.well-known/web-app-origin-association
{
  "https://fileman.google.com/files/": {
    "allow_migration": true
  }
}

الخطوة 3: الإشارات الاستباقية (اختيارية)

لتفعيل التحديث بدون انتظار المستخدم للانتقال إلى الموقع الإلكتروني الجديد، عدِّل ملف البيان القديم للتطبيق لكي يشير إلى الملف الجديد.

// Manifest at https://drive.google.com/manifest.json
{
  "name": "Drive",
  "start_url": "/",
  "migrate_to": {
    "id": "https://fileman.google.com/files/",
    "install_url": "https://fileman.google.com/drive/installwebapp?usp=migrate"
  }
}

الخطوة 4: التعامل مع عمليات إعادة التوجيه (اختيارية)

كبديل لاستخدام الحقل migrate_to، يمكنك الإشارة إلى عملية نقل البيانات من خلال إعادة توجيه عناوين URL القديمة للتطبيق إلى التطبيق الجديد، والاعتماد على scope_extensions كي لا يتم عرض بانر خارج النطاق في التطبيق القديم. وهذا يعني أنّه لن يتم عرض بيان التطبيق القديم أبدًا، وبالتالي لن يمكن تعديله. للسماح للتطبيق القديم بمواصلة التحديث قبل نقل البيانات، اضبط install_url داخل migrate_from لإعلام المتصفّح بعنوان URL يمكنه جلب البيان القديم المرفق بدون إعادة توجيه.

// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    {
      "id": "https://drive.google.com/",
      "install_url": "https://drive.google.com/drive/installwebapp?usp=migrate"
    }
  ]
}

هذا كل شيء! تشبه تجربة المستخدم تلك المستخدَمة في تحديث التطبيقات، حيث يتم إعلام المستخدم في أعلى يسار نافذة التطبيق:

يؤدي النقر على مراجعة تحديث التطبيق إلى عرض تجربة المستخدم التالية (حسب التغييرات التي تم إجراؤها في البيان):

التحكّم في تجربة المستخدم

يمكنك اختيار مدى سرعة عملية نقل البيانات باستخدام العلامة behavior:

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

يوضّح المثال التالي كيفية ضبط هذا الخيار:

"migrate_from": [
  { 
    "id": "https://example.com/social/",
    "behavior": "force" // or suggest
  }
]

الخاتمة

تتيح ميزة "نقل التطبيقات المتوافقة مع الويب" للمطوّرين مواصلة إنشاء بنى ويب حديثة ومرنة بدون إهمال المستخدمين.