البحث في الموقع

صار اليوم من السهل تطبيق فكرة مشروع برمجي ما بطريقة واحدة ليأخذ العديد من الأشكال ويطبق في العديد من المجالات وهي المواقع الإلكترونية وتطبيقات الجوالات وتطبيقات سطح المكتب (مع اختلاف أنظمة التشغيل مثل: Android، IOS، Windows، macOS) وهذا كله بفضل تقنية تطبيقات الويب التقدمية (PWA / progressive web application). حيث كان يصنع كل من الموقع الإلكتروني وتطبيق الجوال وتطبيق الحاسوب على حدة. بل كان يصنع كل تطبيق في نظام تشغيل منفصلًا عن غيره، لنحصل على النتيجة المرجوة من الـ PWA لمشروع واحد. ألقي نظرة على الموقع expensive-time والذي قمت بإعداده محتويًا على هذه التقنية. مفهوم تطبيقات الويب التقدمية تطبيقات الويب التقدمية (progressive web application) تم تطويرها بناءً على علامات تبويب المتصفحات ليتم استخدامها كمواقع وتطبيقات بنفس الوقت، ويتم بنائها كما هو الحال في مشاريع الويب لتعمل على جميع الأجهزة بمختلف مشغلاتها من جوالات وحواسيب مكتبية أو محمولة أو لوحية، دون الحاجة لاختلاف طريقة البناء. حاضر مميز ومستقبل متوقع لاقت تطبيقات الويب التقدمية إقبالًا كبيرًا وانتشارًا واسعًا خلال فترة قصيرة، حيث حققت نجاحًا باهرًا في عالم المواقع والتطبيقات من فاعلية وسهولة في الصناعة والاستخدام، فهي جمعت بين ميزات التطبيقات والمواقع، ويتوقع لها مستقبل أكبر وأعظم من تطويرٍ ودعمٍ وانتشارٍ أكثر واستغناء أكثر عن الطرق المعروفة في صناعة التطبيقات، لما حققت من الأهداف العظيمة في العديد من المجالات وغيرها من الميزات نتحدث عن بعضها بالتفصيل. بعض من خصائص وميزات PWA لها من العظمة بمكان جمعت تطبيقات الويب التطورية بين ميزات التطبيقات والمواقع، بل إنها تخلصت من العديد من عيوب التطبيقات والمواقع. فمن ميزات التطبيقات التي حققتها PWA أنها تعطي للمستخدم تجربة وعلاقة أقوى منها في المواقع ومع ذلك فهي حافظت على ميزة السلاسة والسهولة في التعامل كما هو الحال في المواقع من عدم الاضطرار لتحميل ملفات كبيرة وبدون صعوبة وطول التحميل والثقل على الجهاز وغيرها من ميزات في المواقع والتطبيقات. ونجحت من التخلص من عيوب في التطبيقات مثل إجراءات وتقييدات المتاجر المتعبة وبعض العيوب في المواقع مثل عدم الاستقلالية عن المتصفحات في الاستخدام وغيرها من العيوب. تتميز هذه التطبيقات بأنها تعمل على كل جهاز(جوال، حاسوب لوحي، حاسوب مكتب …)، على كل نظام تشغيل (Android, IOS, Windows …)، على كل متصفح (Google Chrome, Mozilla Firefox, Safari …) باختلاف إصداره. والفضل في ذلك يعود على اعتماد PWA في بنائها على استراتيجية الويب Progressive enhancement فهي عمودها الفقري. (نتحدث عنها أكثر فيما بعد). وتميزت بالعديد من الخصائص العظيمة مثل السرعة الكبيرة في التحميل حتى مع الشبكات البطيئة بل إنها تعمل بدون اتصال شبكة والفضل في ذلك يعود لتقنية عامل الخدمة Service Worker (نتحدث عنها أكثر فيما بعد)، وهي آمنة ومحمية من خلال بروتوكول Transport Layer Security-TLS الذي يعمل على منع التطفل والتلاعب بالمحتوى، يقوم المستخدم بتحميل واستخدام هذه التطبيقات بكل سهولة وبساطة دون متاعب وإجراءات متاجر التطبيقات، بل تقوم هذه التطبيقات بتحديث نفسها تلقائيًا دون الحاجة لإعادة تحميل كامل التطبيق، وصنعت لتعمل مع جميع إصدارات المتصفحات ولكن تعطي تجربة أفضل من الدرجة الأولى مع المتصفحات الحديثة التي تدعم التقنيات المتقدمة مثل عامل الخدمة Service Worker والاشعارات وشارة الاضافة إلى الشاشة الرئيسية وغيرها. سهولة مشاركتها من خلال عنوان الموقع سهل النسخ والفتح مما يساعد على انتشارها، تتيح لنا استخدام البرنامج كموقع أو كتطبيق جوال أو كتطبيق سطح مكتب. نسخة الموقع الإلكتروني يقوم المستخدم بتجربة البرنامج واستخدامه دون تحميله فهو يجربه مباشرة بفتح الموقع الإلكتروني ويقوم بتحميله إن احتاج. بل إن بعض المستخدمين لن يحتاج استخدام البرنامج إلا مرة واحدة وبالتالي يقوم باستخدامه كموقع دون تحميله. والكثير من المستخدمين يميل لاستخدام البرنامج كموقع ولا يفضل تحميله وهنا نترك مساحة للمستخدم للاختيار بين تجربة الموقع والتطبيق. نسخة تطبيق الجوال يتمكن المستخدم بتحميل التطبيق مباشرة من الموقع واستخدامه بتجربة مستقل عن المتصفحات ومطابقة لتجربة التطبيقات المعتادة ويمتلك أيقونة على الشاشة الرئيسية كما هو الحال بالتطبيقات(يمكنك استخدام هذه الأداة realfavicongenerator لمعرفة شكل أيقونة تطبيقك على مختلف الأجهزة أو إن كان هنالك مشكلة فيها كما تبين الصورة في الأسفل) بل ويتعرف عليه الجهاز على أنه تطبيق مستقل، وهنا يبني المستخدم علاقة مع التطبيق بكثرة الاستخدام وتوافر النسخة على الجهاز بشكل مستقل مما يضفي متعة وراحة وسهولة في تجربة المستخدم. نسخة تطبيق سطح المكتب PC معظم ما ذكرنا في نسخة تطبيقات الجوال تنطبق على نسخة سطح المكتب، حيث يمكن أن تحمل تطبيقات PWA على الجهاز وتعمل بشكل مطابق للتطبيقات الأصلية في الجهاز في نافذة مستقلة بتجربة جذابة للمستخدم، وبالرغم من انتشار تطبيقات الجوال واستخدامها إلا أن ذلك لا يقلل من أهمية وكثرة استخدام أجهزة الحاسوب، لذا جاءت الأهمية بتوفر نسخة لها. تمثل الصورة في الأسفل توزيع استخدام الأجهزة (جوالات، حواسيب، حواسيب لوحية) في اليوم. عناصر ساهمت بانجاح وتحسين تجربة المستخدم في PWA التحسين التدريجي الاستراتيجية المعروفة بـ Progressive enhancement كما ذكرنا Progressive enhancement هي أساس PWA والعمود الفقري لها وباختصار فإنها تعتمد على تقسيم البرنامج إلى طبقات يتم عرض كل طبقة حسب دعم المتصفح لها، لذا فإن البرنامج يعمل لدى الجميع إذ يحتوي على طبقة أساسية (المحتوى) تعمل وتعرض على جميع الأجهزة ويتم إضافة الطبقات الأخرى عند دعمها، وطبقات الإضافية والتكميلية تضفي تحسينًا وتجربة أفضل وميزات أعلى. تقنية service workers الكلام يطول كثيرًا في هذه التقنية المضافة إلى عالم الويب مؤخرًا، لكن نتطرق لبعض ما يهمنا فيها بموضوع PWA. فكما ذكرنا سابقًا أن هذه التقنية مسؤولة عن عمل التطبيق في حالة عدم الاتصال بالشبكة وتلعب دورًا مهما في سرعة أداء البرنامج حتى مع الشبكات البطيئة، فهو يقوم بتخزين الموارد التي ترتبط بالأحداث والتفاعل في البرنامج لاستخدامها بدون اتصال الشبكة أو ببطئها. وأيضًا يقدم تحميل فوري وسريع جدًا للمستخدمين الذين تكرر زيارتهم. ويوفر تجربة للجهاز حقيقية مع التطبيق منفصلة عن المتصفح ولا يشترط أن تكون خلال المتصفح. وإن كانت تعتمد فكرة البرنامج بشكل كامل على اتصال الشبكة فإن المستخدم سيحصل على هيكل وشكل جذاب ومناسب بعدم اتصال الشبكة ويتوافق مع شكل التطبيق الأصلي، وهذه التقنية مسؤولة عن التحديث المستمر للتطبيق. لذا إضافته إلى مشروعك يلعب دورًا هامًا في إنجاحه (راجع مقالي مفهوم Service Worker وتأثيره في أداء وبنية مواقع وتطبيقات الويب لمزيد من التفاصيل). ملف manifest لتطبيق الويب ملف بسيط بصيغة json متاح لمبرمج التطبيق للتحكم بكيفية ظهور التطبيق على جهاز المستخدم مثل الأيقونة التي تظهر على الشاشة الرئيسية، وعمل التطبيق بشاشة كاملة، مع التحكم في ظهور الشريط الذي يحوي العنوان URL والإعدادات وغيرها كما في علامات التبويب في المتصفحات، ويمكن التحكم باتجاه الشاشة (من الأعلى إلى الأسفل والعكس, أو من اليمين إلى اليسار والعكس) ولون الشريط العلوي في الشاشة. تطبيقات بشكل رسمي ومعترف إذ يتم التعرف عليها من الأجهزة والمتصفحات على أنها تطبيق والفضل بذلك يعود لمنظمة w3c من خلال كشوفها المقدمة للمحركات عن الرابط المعني ومن خلال نطاق التسجيل لـservice worker. ويقوم المتصفح بإضافة APK للتطبيق حتى يتعرف عليه الجوال على أنه تطبيق ويسجل في إعدادات التطبيقات في الجهاز، وأما في جهاز الحاسوب PC يتم إضافته إلى نافذة التطبيقات. لافتات التحميل تظهر لافتة اسفل الشاشة تقترح إضافة البرنامج للشاشة الرئيسية عند فتح الموقع على الجوال، وحتى تظهر هذه اللافتة يجب توفر ما يلي في مشروعك: ملف Web App manifest أن يكون مخدوم على عناوين HTTPS يحتوي على service worker مسجل وفعال يتم الزيارة من قبل المستخدم مرتين على الأقل يفصل بين كل زيارة خمس دقائق على الأقل أما في جهاز الحاسوب تظهر لافتة التحميل أعلى الشاشة بجانب شريط العنوان. الإشعارات لو سألنا مجموعة مبرمجين سابقًا عن الفرق بين المواقع الإلكترونية والتطبيقات لأجاب معظمهم بالإشعارات، ولكن مع تطور عالم الويب أصبحت تدعم الإشعارات، وهذا عاد بالكمالية لتطبيقات PWA وساهم في إنجاحها. ولكن حتى تتمكن من تفعيل وتمكين الإشعارات لابد أن يحتوي مشروعك على ملف Web App manifest، وأن يحتوي على service worker مسجل وفعال. تعرف على تفاصيل أعمق حول الإشعارات هنا. إتاحة التحكم بواجهة برمجة التطبيقات (API) بدأ دخول إمكانيات التحكم بـAPI على الويب منذ فترة ليست بالبعيدة وما زال الدعم والتطوير لها بتزايد كبير في مجال الويب كما يوضح التوزيع في الأسفل. تعرف على تفاصيل أعمق حول API في الويب هنا. إطارات عمل الجافاسكريبت (frameworks) تنسجم وتساهم في فكرة PWA لا يوجد فعليًا قيود تحظر وتمنع إدراج أي تقنيات من مكتبات أو إطارات عمل أو غيرها إلى مشروعك في pwa بالعكس الكثير منها يدعم ويساهم بتحسين نتائجها ويسهل صناعتها من أشهرها VUE و React و svelte. وينصح باستخدامها لما تتيحه من إمكانيات وتسهيلات تدعم المشروع (قمت باستخدام VUE في صناعة تطبيقي المطروح كمثال سابقًا). لا يعني بأن بناء التطبيق بطريقة Vanilla JS (نسمي عدم استخدام أي من frameworks في الجافاسكربت Vanilla JS) ضعفه وانخفاض مستواه أو سيكون فاشل بل يوجد الكثير منها مبني بهذه الطريقة وقد حقق نجاحًا باهر مثل مشاريع نقاية. مثال ناجح مشاريع نقاية وهي مجموعة مشاريع PWA تعتبر مثالًا ناجحًا وإبداعيًا جدًا عليها، حققت انتشارًا ونجاحًا باهرًا، تخدم التراث العربي والإسلامي، فأنصحك بالاطلاع عليها وتجريبها على مختلف الأجهزة. مراجع Getting started with Progressive Web Apps Your First Progressive Web App Progressive Web Apps on Desktop Understanding Progressive Enhancement Push Notifications on the Open Web Web Push Notifications: Timely, Relevant, and Precise progressive-web-apps Service Workers The core foundations of a delightful web experience are… Add to Home Screen Support for theme-color in Chrome 39 for Android The Web App Manifest WebAPKs on Android Progressive Web Apps: Apple App Store, Google Play Store, It Was Nice Knowing You اقرأ أيضًا برمجة تطبيقات سطح المكتب

ناقش ديميان Demian التحديات التي تواجهها المواقع متعددة الأصول multiple origins عند محاولة إنشاء تطبيق ويب تقدمي واحد يشملها جميعًا، وذلك في مقال تطبيق الويب التقدمي على أصول متعددة. يعد موقع التجارة الإلكترونية الافتراضي www.example.com مثالًا على موقع متعدد الأصول، إذا كان: الصفحة الرئيسية مُستضافة على العنوان https://www.example.com. صفحات الفئات مستضافة على عنوان مختلف مثلًا: https://category.example.com. صفحات تفاصيل المنتج مستضافة على عنوان ثالث مختلف، مثلًا: https://product.example.com. تُقيِّد سياسة الأصل المشترك same-origin مشاركة عمّال الخدمة service workers وذاكرة التخزين المؤقت cache، والأذونات permessions، عبر الأصول المختلفة، لذا نوصي بشدة بتجنب هذا النوع من إعداد المواقع (سياسة الأصل المشترك)، ونوصي من لديهم مواقع مبنية بهذه الطريقة بالفعل، بالنظر في الانتقال إلى معمارية الموقع ذات الأصل الواحد single origin إذا أمكن. تجنب استخدام أصول مختلفة لأقسام نفس الموقع عند بنائك تطبيق PWA واحد يشملها جميعًا. سنعتني في هذا المقال بالحالة المعاكسة، بدلًا من توفير تطبيق ويب تقدمي واحد مجزأ على أصول مختلفة، فإننا سنهتم بحالة الشركات التي ترغب بتوفير تطبيقات ويب تقدمية PWA متعددة، تعمل على نفس اسم النطاق، وذلك لإعلام مستخدميها أن تطبيقات الويب التقدمية هذه تنتمي لنفس الشركة أو الخدمة. لكن قبل البدء سنراجع أهم المفاهيم التقنية التي ستلزمنا، وذلك بالاعتماد على رابط موقع التجارة الالكترونية الافتراضي https://www.example.com: مصطلحات تقنية النطاق Domain: هو أي تسلسل من العناوين الموجودة في نظام أسماء النطاقات DNS، مثلًا يعد com وexample.com نطاقان، لكن الفرق هنا أن com هو النطاق الرئيسي بينما تُعد example.com أو مثلًا test.com وblog.com نطاقات فرعية sub domains من النطاق الرئيسي com، أيضًا يعد كلًا من web.example.com وapp.example.com مثلًا وغيرها، نطاقات فرعية sub domains من نطاقها الرئيسي www.example.com الذي يُعد كما قلنا نطاق فرعي بالنسبة للنطاق الرئيسي العام com وهلم جرًا. اسم المضيف Host name: هو اسم مخصص لأي جهاز متصل بشبكة، يُحلّل إلى (ويقابل) عنوان IP الجهاز في نظام أسماء النطاقات DNS، مثلًا www.example.com هو اسم مضيف. الأصل Origin: هو تجميعة من كلًا من البروتوكول، واسم المضيف، والمنفذ (اختياريًا)، مثلًا يعد العنوان https://www.example.com:443 أصل. إنشاء علاقة بين تطبيقات الويب التقدمية PWA قد ترغب في بعض الحالات بإنشاء تطبيقات مستقلة، رغم أنك لا تزال مقررًا أنها متعلقة ببعضها وتنتمي لنفس المؤسسة أو العلامة التجارية brand. يُعد إعادة استخدام نفس اسم النطاق لجميع هذه المواقع طريقة جيدة لتأسيس علاقة قوية بينها، مثلًا: يريد موقع التجارة الإلكترونية https://www.example.com إنشاء تجربة موقع مستقلة تسمح للبائعين بإدارة مخزونهم، مع التأكيد لهم أن هذا الموقع بتجربته المستقلة ينتمي إلى موقع التجارة الرئيسي الذي يشتري المستخدمون منه المنتجات. تريد شركة إخبارية إنشاء تطبيق محدد لحدث رياضي عظيم، وذلك للسماح للمستخدمين بتلقي إحصائيات حول مسابقاتهم المفضلة عبر الإشعارات، وتمكينهم من تثبيت تطبيق PWA هذا على أجهزتهم بالتالي مشاهدة المحتوى الرياضي بسهولة، هذا مع التأكيد للمستخدمين أن التطبيق الرياضي يتبع لتلك الشركة الإخبارية. تريد إحدى الشركات إنشاء تطبيقات منفصلة لكلًا من الدردشة chat ورسائل البريد mail والتقويم calender وتريد أن تعمل هذه التطبيقات بشكل منفصل لكن تكون مرتبطة باسم الشركة. تريد الشركة المالكة لموقع example.com توفير ثلاثة تطبيقات PWA مستقلة، باستخدام نفس اسم المجال لتأسيس علاقة قوية بينها. استخدام أصول منفصلة الطريقة الموصى بها في مثل هذه الحالات، هي بناء كل تطبيق ذي هدف خاص على أصل origin خاص. إذا كنت تريد استخدام نفس اسم النطاق لجميع تطبيقات PWA المرتبطة ببعضها، فيمكنك القيام بذلك باستخدام النطاقات الفرعية sub domains. مثلًا يمكن لشركة تقدم خدمات إنترنت متعددة استضافة تطبيق بريد على الأصل https://mail.example.com وتطبيق تقويم على الأصل https://calendar.example.com، وتقديم الخدمة الرئيسية لأعمالها على الأصل https://www.example.com. وهناك مثال آخر لاستخدام النطاقات الفرعية للحصول على أصول مختلفة، وهو موقع رياضي يريد إنشاء تطبيق مستقل مخصص تمامًا لحدث رياضي مهم، مثل بطولة كرة القدم، وذلك على https://footballcup.example.com، يمكن للمستخدمين تثبيت موقع البطولة هذا على أجهزتهم واستخدامه بشكل مستقل عن موقع الرياضة الرئيسي المستضاف على https://www.example.com. قد تكون هذه الطريقة مفيدة أيضًا للأنظمة التي تتيح للعملاء إنشاء تطبيقاتهم المستقلة بهم تحت علامة الشركة التجارية، كأن يتيح أحد تطبيقات الويب للتجار إنشاء تطبيقاتهم الخاصة على نطاقات فرعية بأسمائهم مثل https://ahmad.example.com وhttps://ali.example.com وغيرها. يضمن استخدام أصول مختلفة العزل بين التطبيقات، أي يمكن لكل تطبيق من تطبيقات PWA المتعلقة ببعضها، إدارة ميزات المتصفح المختلفة بشكل مستقل، بما في ذلك: قابلية التثبيت Installability: حيث يوجد لكل تطبيق منها ملف بيان موارد Manifest، يوفر تجربة التطبيق الخاصة القابلة للتثبيت. التخزين Storage: يوجد لكل تطبيق منها ذاكرة تخزين مؤقتة cache، وميزات تخزين محلي local storage، وجميع أشكال التخزين المحلي للجهاز device-local بشكل أساسي. عمال الخدمة Service Workers: يوجد لكل تطبيق منها عامل خدمة مسؤول عن نطاقات التطبيق المسجلة فيه. الأذونات Permissions: يعطَى لكل تطبيق من تطبيقات PWA المرتبطة ببعضها عبر النطاقات الفرعية والمختلفة في الأصل، أذونات بشكل منفصل عن غيره، وهذا يفيد المستخدمين في معرفة الخدمة التي يمنحونها أذوناتهم بالضبط، كما تُنسب الإشعارات بدقة لكل تطبيق. يُوصى باتباع هذه الدرجة من العزلة (الأصول المختلفة) عند بناء عدة تطبيقات ويب تقدمية PWA مستقلة Independent. إذا أرادت تطبيقات النطاقات الفرعية مشاركة بياناتها المحلية مع بعضها البعض، فبإمكانها القيام بذلك عبر ملفات تعريف الارتباط cookies، أو بطريقة متقدمة أكثر، يمكنها مزامنة التخزين بواسطة الخادم. يعد بناء تطبيقات ويب تقدمية PWA مختلفة على نطاقات منفردة باستخدام النطاقات الفرعية ممارسة جيدة. استخدام نفس الأصل الطريقة الثانية هي بناء تطبيقات PWA المتعلقة ببعضها، على نفس الأصل same origin، ويتضمن ذلك السيناريوهات التالية: مسارات غير متراكبة أي تُستضاف تطبيقات PWA المتعلقة ببعضها على نفس الأصل، لكن مع مسارات paths غير متراكبة non-overlapping، مثلًا: https://example.com/app1 https://example.com/app2 المسارات المتراكبة أو المتداخلة أي تستضاف تطبيقات الويب التقديمة PWA المتعددة على نفس الأصل، لكن أحد نطاقاتها متداخل nested داخل الآخر، مثلًا: https://example.com (التطبيق الخارجي) https://example.com/app (التطبيق الداخلي) يسمح لك كلًا من الواجهة البرمجية Service Worker وتنسيق ملف بيان الموارد manifest بتطبيق الطريقتين السابقتين، وذلك بتحديد النطاقات فرعية أو رئيسية بناء على مستوى المسار path-level، لكن في كلتا الحالتين، يؤدي استخدام نفس الأصل إلى العديد من التحديات والمحدوديّات، النابعة من حقيقة أن المتصفح لن يعتبرها تطبيقات متمايزة، بالتالي لا يُنصح بهذا الأسلوب. سنحلِّل تلك التحديات بالتفصيل في الفقرة القادمة، وسنذكر ما الذي يمكن فعله إذا لم يكن من الملائم استخدام أصول منفصلة. لا يُنصح باستخدام المسارات المتداخلة وغير المتداخلة لاستضافة تطبيقين PWA مستقلين على نفس الأصل. التحديات التي تواجه تطبيقات PWA على نفس الأصل فيما يلي بعضًا من المشكلات العملية التي تواجهنا عند استخدام المسارات المتراكبة وغير المتراكبة لنفس الأصل: التخزين Storage: تُشارَك ملفات تعريف الارتباط cookies وبيانات التخزين المحلي local storage وجميع أشكال التخزين المحلي للجهاز device-local بين التطبيقات ذات نفس الأصل origin. لهذا، فإذا قرر المستخدم مسح البيانات المحلية لأحد تطبيقات PWA المتعلقة ببعضها، فستُمسح بيانات جميع التطبيقات المشتركة بنفس الأصل مع ذلك التطبيق، فلا توجد طريقة لمسح بيانات تطبيق واحد فقط منها بعينه. تحث بعض المتصفحات مثل Chrome وغيره المستخدمين دومًا على مسح البيانات المحلية عند إلغاء تثبيت أحد التطبيقات، وهذا سيؤثر على بيانات التطبيقات الأخرى المشتركة معه في نفس الأصل، والتحدي الآخر الممكن أن تواجهه بالنسبة للتخزين في التطبيقات المشتركة بنفس الأصل، هو أن هذه التطبيقات بطبعها تشارك بعضها حصة التخزين الخاصة بها، بالتالي إذا كان أيًا منها يشغَل مساحة تخزينية كبيرة جدًا، فسيتأثر الآخر سلبًا. الأذونات Permissions: إذا منح المستخدم إذنًا لأحد تطبيقات PWA المتعلقة ببعضها، فسيُمنح نفس الإذن لجميع التطبيقات المشتركة في نفس الأصل مع ذلك التطبيق، فالأذونات مرتبطة بالأصل أيضًا كما التخزين. قد يبدو هذا ميزة، بحيث لا تضطر جميع تلك التطبيقات إلى طلب نفس الإذن، أي طلب نفس الإذن عدة مرات، لكن التحدي هنا يكمن في حظر المستخدم إذنًا لأحد التطبيقات، فوقتها تُمنع التطبيقات الأخرى المشتركة في الأصل من طلب هذا الإذن، بالتالي لا تستطيع جميعها استخدام ميزة التطبيق التي تتطلب ذلك الإذن. إعدادات المستخدم User settings: تعيّن إعدادات المستخدم لتطبيقات الويب أيضًا بالإعتماد على الأصل، مثلًا، إذا كان لتطبيقان مشتركان في الأصل أحجام خطوط مختلفة، ويريد المستخدم ضبط تكبير حجم خط أحدهما فقط، فسيَكبُر حجم خط التطبيقات الأخرى المشتركة معه في نفس الأصل. تجعلنا التحديات السابقة نتجنب هذا النهج (الأصل المشترك). لكن، إذا كنت لا تستطيع استخدام أصل منفصل (مثل نطاق فرعي) لكل تطبيق من تطبيقات PWA المتعلقة ببعضها، فيمكنك ترشيح خيار المسارات غير المتداخلة بدلًا من خيار المسارات المتراكبة أو المتداخلة ضمن خيارَي استخدام نفس الأصل في الأعلى. تحديات إضافية للمسارات المتراكبة أو المتداخلة المشكلة الإضافية المتعلقة بنهج المسارات المتراكبة أو المتداخلة (حيث https://example.com هو التطبيق الخارجي والمسار https://example.com/app هو للتطبيق الداخلي)، هو أن جميع عناوين URL في التطبيق الداخلي ستُعتبر جزءًا من كلا التطبيقين الداخلي والخارجي. وهذا يسبب عمليًا المشكلات التالية: إمكانية التثبيت Installation: إذا زار المستخدم التطبيق الداخلي (مثلًا في متصفح ويب)، وكان التطبيق الخارجي مثبتًا بالفعل في جهاز المستخدم، فلن يعرض المتصفح لافتات لتثبيت التطبيق الداخلي. وذلك لأن المتصفح عندما يتحقق من إنتماء الصفحة الحالية إلى تطبيق مثبت بالفعل أم لا، فإنه سيعتبر التطبيق الداخلي مثبت على الجهاز كون التطبيق الخارجي مثبت بالفعل، ويمكن أن تُحل هذه المشكلة بتثبيت التطبيق الداخلي يدويًا (عبر خيار "إنشاء اختصار" في المتصفح)، أو تثبيت التطبيق الداخلي أولاً، قبل التطبيق الخارجي. الواجهتان البرمجيتان Notification و Padging: إذا تم تثبيت التطبيق الخارجي دون الداخلي، فستُنسب الإشعارات والشارات القادمة من التطبيق الداخلي عن طريق الخطأ إلى التطبيق الخارجي، إذ تنسب الإشعارات والشارات بدقة لكل تطبيق في حال ثبِّت كليها على جهاز المستخدم. التقاط الرابط Link Capturing: إذا تم تثبيت التطبيق الخارجي دون الداخلي، فلن يتم التقاط روابط التطبيق الداخلي المرتبطة بالتطبيق الخارجي، أي بدلًا من أن يُفتح الرابط الداخلي في نفس التبويبة ضمن نطاق تصفح التطبيق الخارجي، فإنه سيُفتح في تبويبة جديدة لأن المتصفح سعتبره تطبيقًا غريبًا (تطبيق مختلف غير مرتبط به). لكن إذا أضيفت تطبيقات PWA هذه إلى المتجر على نظامَي Chrome OS وAndroid، فسيلتقط التطبيق الخارجي تلك الروابط، وأيضًا إذا تم تثبيت التطبيق الداخلي، فسيظل نظام التشغيل يوفر للمستخدم خيار فتح تلك الروابط المتعلقة بالتطبيق الداخلي في التطبيق الخارجي. الخاتمة تطرقنا في هذا المقال إلى الطرق المختلفة الممكن للمطورين من خلالها إنشاء العديد من تطبيقات الويب التقدمية المتعلقة ببعضها على نفس النطاق (وهذا مختلف عن استخدام نطاقات وأصول مختلفة لأقسام موقع واحد كبير). باختصار، نوصي بشدة باستخدام أصل مختلف (مثلًا باستخدام النطاقات الفرعية) لاستضافة تطبيقات PWA المستقلة، إذ يؤدي استضافتها على نفس الأصل إلى عدة تحديات، كون المتصفح لن يعتبرها تطبيقات متمايزة، إذن الخلاصة أن هناك ثلاث حالات لاستضافة تطبيقات PWA المتعلقة ببعضها على نفس النطاق: على أصول منفصلة: موصى بها. على نفس الأصل بمسارات غير متداخلة: ليست مستحسنة. على نفس الأصل بمسارات متراكبة overlapping أو متداخلة nested: لا ينصح بها بشدة. إذا لم يكن بإمكانك استخدام أصول مختلفة، فاستخدم مسارات غير متداخلة، مثلًا https://example.com/app1 وhttps://example.com/app2، بدلًا من المسارات المتراكبة أو المتداخلة مثل https: //example.com (للتطبيق الخارجي) وعنوان https://example.com/app (للتطبيق الداخلي). ترجمة -وبتصرف- للمقال Building multiple Progressive Web Apps on the same domain من موقع web.dev. اقرأ أيضًا ما هي تطبيقات الويب التقدمية PWA استقبال تطبيقات الويب التقدمية البيانات المشاركة عبر الواجهة البرمجية Web Share Target جعل تطبيق الويب التقدمي PWA يبدو كتطبيق أساسي في نظام التشغيل إضافة اختصارات للمهام الشائعة في تطبيقات الويب التقدمية PWA

يقدم هذا المقال إرشادات تصميم حول كيفية إنشاء تجربة مستخدم رائعة لتطبيقات الويب التقدمية PWAs على كلًا من الشبكات البطيئة وغير المتصلة. يمكن أن تتأثر جودة اتصال الشبكة بشكل عام بعدة عوامل مثل: تغطية ضعيفة من المزود. ظروف طقس شديدة. انقطاع التيار الكهربائي. الدخول في مناطق ميتة الاتصال دائمًا dead zones مثل البنايات ذات الجدران المانعة لاتصالات الشبكة. الدخول في مناطق ميتة الاتصال مؤقتًا مثل السفر في قطار وعبور نفق. اتصالات الإنترنت المقيدة زمنيًا time-boxed مثل الاتصالات الموجودة في المطارات أو الفنادق. الممارسات الثقافية التي تتطلب وصولًا محدودًا أو معدومًا للإنترنت في أوقات أو أيام محددة. هدفك هو تقديم تجربة مستخدم جيدة في وضع عدم الاتصال تقلل من تأثير التغيُّر في حالة التطبيق عندما يستعيد المستخدم اتصاله بالشبكة. حدد ما تريد إظهاره للمستخدمين في حالة ضعف الاتصال بالشبكة اطرح على نفسك أولًا السؤال التالي: كيف سيبدو نجاح وفشل اتصال الشبكة في تطبيقك؟ الاتصال الناجح هو التجربة العادية لتطبيقك بوجود اتصال بالشبكة، بينما يُمثِّل فشل الاتصال كيفية تصرف تطبيقك في حالة عدم الاتصال بالشبكة أو الاتصال البطيئ بها. عند التفكير في نجاح أو فشل اتصال الشبكة، عليك أن تسأل نفسك أسئلة حول تجربة المستخدم UX المهمة هذه: ما هي المدة التي تنتظرها لتحديد نجاح أو فشل الاتصال؟ ماذا يمكنك أن تفعل أثناء تحديد نجاح أو فشل الاتصال؟ ماذا تفعل في حال فشل الاتصال؟ كيف تبلِّغ المستخدم بما ورد أعلاه (أنه في مرحلة انتظار تحديد حالة التطبيق، أو أن اتصاله فشل أو أن اتصالة استُعيد)؟ بلغ المستخدمين عن حالتهم الحالية وعن تغيُّر حالة التطبيق أخبر المستخدم بالإجراءات التي لا يزال بإمكانه القيام بها عندما يكون في حالة فشل الاتصال، وأيضًا أخبره بحالة التطبيق الحالية، مثلًا ممكن أن يقول الإشعار: بلّغ المستخدم بوضوح عند حدوث تغيُّر في حالة التطبيق في أسرع وقت ممكن. استخدام تطبيق Google I/O مربع إشعار لإخبار المستخدم عندما يكون في حالة عدم اتصال بالشبكة، إذ يقول الإشعار "أنت بلا اتصال، تغييراتك في My Schedule ستُحفظ لوقت لاحق". بلِّغ المستخدمين عندما يتحسن اتصال الشبكة لديهم أو يعود يعتمد كيفية إبلاغك المستخدم بتحسُّن اتصال الشبكة على تطبيقك، فالتطبيقات مثل تطبيق حالة الطقس الذي يعطي الأولوية للمعلومات الآنية، يجب أن يُحدَّث تلقائيًا عند استعادة الاتصال، وإشعار المستخدم في مثل هكذا تطبيقات يجب أن يتم في أقرب وقت ممكن. يوصَى بإِعلام المستخدم أنه قد تم تحديث تطبيق الويب في الخلفية، وذلك باستخدام تلميح مرئي عبر تنبيه أو أي وسيلة إشعارات تؤدي الغرض. أحد الأمثلة على استخدام هذه التجربة هو متصفح Chrome Status التي تُظهر ملاحظة للمستخدم عند تحديث التطبيق في الخلفية. تحتاج بعض التطبيقات مثل تطبيق الطقس إلى تحديث تلقائي، لأن البيانات القديمة ليست مفيدة مع تقلبات الطقس المستمرة. يتيح تطبيق ana (أنا) للمستخدم معرفة وقت تحديث المحتوى عبر مربع إشعار في أعلى الشاشة. يمكنك تخصيص مساحة ثابتة تُظهر من خلالها آخر مرة تم فيها تحديث التطبيق، سيكون هذا مفيدًا لتطبيق تحويل العملات مثلًا. تطبيق Material mony يُظهر آخر تحديث للتطبيق. وينبّه المستخدم عند تحديث التطبيق. يمكن أن تعرض تطبيقات مثل تطبيقات الأخبار إشعارًا بسيطًا بالنقر للتحديث، لإعلام المستخدم بالمحتوى الجديد، فقد يتسبب التحديث التلقائي في فقدان المستخدمين لمكان تصفحهم. صحيفة الانترنت Tailpiece تُنزّل آخر الأخبار تلقائيًا. وتسمح للمستخدمين بالتحديث يدويًا حتى لا يفقدوا مكان تصفحهم في المقال. تحديث واجهة المستخدم UI لتعكس الحالة السياقية الحالية لكل بِت bit من واجهة المستخدم سياقُه ووظائفه الخاصة التي تتغير بناءً على كونها تتطلب اتصالًا ناجحًا بالشبكة أو لا، أحد الأمثلة على ذلك هو مواقع التجارة الإلكترونية التي يمكن تصفحها في وضع عدم الاتصال، فوقتها يُعطَّل زر الشراء إلى حين استعادة الاتصال. يمكن أن تتضمن الأشكال الأخرى للحالات السياقية، البيانات، مثلًا يتيح التطبيق المالي Robinhood للمستخدمين شراء الأسهم، ويَستخدِم الألوان والرسومات لإعلام المستخدم عندما يكون السوق مفتوحًا، وعند إغلاق السوق تتحول الواجهة بالكامل إلى اللون الأبيض ثم تتحول إلى اللون الرمادي، أيضًا عندما تزيد قيمة السهم أو تنقص، يتحول كل عنصر واجهة مستخدم للسهم إلى اللون الأخضر أو الأحمر حسب حالته. توضيح للمستخدم نموذج العرض الخاص بوضع عدم الاتصال يعد وضع عدم الاتصال بالشبكة نموذج عرض جديد لجميع المستخدمين، كون نموذج العرض في الوضع المتصل بالشبكة هو الأساسي والمعروض دائمًا لديهم، لذا تحتاج إلى تعليم المستخدمين التغيّرات التي ستحدث عندما لا يكون لديهم اتصال بالشبكة، أبلغهم بالمكان الذي يتم فيه حفظ البيانات الكبيرة وامنحهم الإعدادات لتغيير سلوك التخزين الافتراضي، وتأكد من استخدام عدة مكونات لتصميم واجهة المستخدم مثل اللغة الغنية بالمعلومات والرموز والإشعارات واللون والصور لتوصيل نموذج العرض بدلاً من الاعتماد على خيار تصميم واحد لذلك. تقديم تجربة افتراضية لوضع عدم الاتصال إذا كان تطبيقك لا يتطلب بيانات كثيرة في عمله، فخزِّن البيانات التي يعتمد تطبيقك عليها مؤقتًا افتراضيًا، إذ إن المستخدمين يمكن أن يشعروا بالإحباط أكثر فأكثر إذا لم يكونوا قادرين على الوصول إلى بياناتهم إلا في وضع الاتصال بالشبكة. حاول أن تجعل التجربة مستقرة قدر الإمكان، فالاتصال غير المستقر سيجعل تطبيقك يبدو أنه غير جدير بالثقة، على عكس التطبيقات التي تقلل من تأثير فشل الاتصال بالشبكة التي تبدو خلَّابة بالنسبة للمستخدم. يمكن لمواقع الأخبار الاستفادة من التنزيل التلقائي والحفظ التلقائي لآخر الأخبار بحيث يُتاح للمستخدم قراءة أخبار اليوم دون الاتصال بالشبكة، ولو على الأقل تنزيل النص بدون صور الخبر، أيضًا يمكن لتلك المواقع التكيُّف مع سلوك المستخدم، مثلًا إذا كان قسم الرياضة هو ما يشاهده المستخدم عادةً، تجعل تلك المواقع تنزيل أخبار هذا القسم هو الأولوية. إذا كان الجهاز غير متصل بالشبكة، فسيُشعر Tailpiece المستخدم بذلك. ويُعرِّف المستخدم أنه لا يزال بإمكانه استخدام التطبيق جزئيًا على الأقل. عندما يتعلق الأمر بالإبلاغ عن حالة أحد التطبيقات، فإن قول "الشبكة معطلة" يرسل رسالة مفادها أن شبكة التطبيق تواجه مشكلات، بينما توضح عبارة "أنت غير متصل" للمستخدم أن المشكلة من طرفه. إبلاغ المستخدم عندما يكون التطبيق جاهزًا للاستخدام دون اتصال بالشبكة يجب أن توضِّح للمستخدمين عند تحميلهم تطبيقك لأول مرة، ما إذا كان بالإمكان استخدام التطبيق في وضع عدم الاتصال أم لا، يمكنك القيام بذلك باستخدام وِدجِت widget يوفر ملاحظات موجزة حول عملية ما، من خلال رسالة أسفل الشاشة مثلًا عند مزامنة قسم أو تنزيل ملف. فكر مرة أخرى في اللغة التي تستخدمها وتأكد من أنها مناسبة لجمهورك، إذ يُسيئ مثلًا الجمهور غير التقني عمومًا فهم مصطلح "غير متصل"، لذا استخدم لغة قائمة على الإجراء action-based تساعد جمهورك على فهمها والاندماج معها. يظهر تطبيق Google I/O إشعارًا مفاده: اكتمل التخزين المؤقت، وستعمل الزيارات المستقبلية في وضع عدم الاتصال. يتضمن موقع Chrome Platform Status معلومات حول المساحة المشغولة بالتخزين المؤقت. اجعل "التخزين في وضع عدم الاتصال" جزءًا واضحًا من واجهة التطبيقات كثيفة البيانات إذا كان أحد تطبيقاتك يستخدم بيانات كثيرة، فتأكد من وجود مفتاح تبديل switch لاضافة عنصر ما للاستخدام دون اتصال save for offline بدلاً من التنزيل التلقائي له، وتأكد أن ذلك المفتاح غير محجوب من عناصر واجهة المستخدم الأخرى وأنه واضح للمستخدم. أحد الأمثلة على ذلك هو مشغل الموسيقى الذي يحتاج ملفات ذات بيانات كبيرة، قد يرغب مستخدم هذا التطبيق في استخدام المشغل دون اتصال بالشبكة، فهنا تنزيل الموسيقى لاستخدامها لاحقًا يتطلب تخطيط مسبق من المستخدم كون الملفات ستحجز مساحة تخزين كبيرة، ووقتها يكون اطلاع المستخدم حول هذا الأمر لازمًا أثناء تهيئته للتطبيق. توضيح ما هو متاح حاليا كن واضحًا فيما يتعلق بالخيار الذي تقدمه، قد تحتاج إلى إظهار نافذة معينة أو إعداد ما يعرض مثلًا "المكتبة غير المتصلة بالشبكة" offline library أو فهرس المحتوى content index، الذي يمكن للمستخدم من خلاله رؤية ما خزّنه في هاتفه بسهولة. أيضًا تأكد أن الإعدادات موجزة وكن واضحًا بشأن مكان تخزين البيانات ومن يمكنه الوصول إليها. إظهار التكلفة الفعلية للإجراء يساوي العديد من المستخدمين قدرة التطبيق في وضع عدم الاتصال بقدرته على "التنزيل"، وغالبًا ما يستغل المستخدمون في البلدان ذات التغطية الضعيفة وقت الاتصال بالشبكة لحفظ محتوى التطبيق للاستخدام دون اتصال. قد يتجنب مستخدمو الباقات المحدودة ذات الكلفة المرتفعة للاتصال بالإنترنت تنزيل ملفات كبيرة خوفًا من زيادة التكلفة، لذا يلزمك أيضًا عرض تكلفة تحميل الملفات أو تكلفة أداء المهام بشكل عام في تطبيقك، مثلًا عندما يكتشف تطبيق الموسيقى المذكور كمثال في فقرة سابقة أن المستخدم في خطة البيانات المدفوعة data plan، يعرِض حجم الملف المُشغَّل، ويتيح للمستخدم رؤية تكلفة تحميله. ساعد في منع التجارب الساخرة غالبًا ما ينجز المستخدمون تجربة ما ساخرة في التطبيق دون أن يدركوا ذلك، مثلًا قبل انتشار تطبيقات مشاركة الملفات المعتمدة على السحابة cloud-based، كان من الشائع أن يحفظ المستخدمون الملفات الكبيرة ويرفقوها برسائل البريد الإلكتروني ليواصلوا تحريرها من جهازٍ مختلف. من المهم عدم الإنجرار إلى تجربتهم الساخرة تلك، بل النظر إلى ما يحاولون تحقيقه منها، بمعنى، بدلاً من التفكير في كيفية جعل إرفاق ملف كبير أسهل، حُل مشكلة مشاركة الملفات الكبيرة عبر أجهزة متعددة باستخدام التخزين السحابي. اجعل العمليات قابلة للنقل من جهاز لآخر عند إنشاء تطبيقات لشبكات غير مستقرة الاتصال، حاول إجراء المزامنة بمجرد أن يتحسن الاتصال حتى تكون تجربة المستخدم قابلة للنقل من جهاز لآخر، مثلًا تخيل أن تطبيق سفر ما يفقد اتصال الشبكة في منتصف مهمة الحجز، وعند استعادة الاتصال، تتيح عملية تزامُن بيانات التطبيق مع حسابات المستخدمين لهم مواصلة الحجز على حواسيبهم المكتبية. ينزعج المستخدمين للغاية من التطبيقات غير القادرة على نقل تجاربهم بين الأجهزة. أيضًا بلّغ المستخدمين بالحالة الحالية لبياناتهم، مثلًا يمكنك إظهار ما إذا تم مزامنة التطبيق أم لا، أعلمهم بكل المستجدات في حالة التطبيق لكن حاول ألا تثقل عليهم بالرسائل والإشعارات. إنشاء تجارب تصميم متكاملة تجارب التصميم المتكاملة inclusive تشمل تصميمًا ذا مغزى، ولغة بسيطة، وأيقونات معيارية، وتمثيلات هادفة، ستساعد المستخدم لإكمال مهمته في التطبيق بسلاسة وبساطة دون أي إعاقة. استخدم لغة بسيطة وموجزة تجربة المستخدم الجيدة لا تتعلق فقط بواجهة مصممة جيدًا، بل تتضمن المسار الذي يسلكه المستخدم بالإضافة إلى الألفاظ المستخدمة في التطبيق. تجنب المصطلحات التقنية عند شرح حالة التطبيق أو مكونات واجهة المستخدم، وضع في اعتبارك أن عبارة "التطبيق غير متصل" قد لا تنقل للمستخدم الحالة الحالية للتطبيق. تجنب المصطلحات غير المفهومة للمستخدمين غير التقنيين مثل: "عامل الخدمة". استخدم اللغة الواضحة التي تصف الإجراء مثل: "تنزيل". استخدم طرق تصميم متعددة لتسهيل تجربة المستخدم استخدم اللغة واللون والمكونات المرئية لإظهار تغيُّر حالة التطبيق أو وضعه الحالي، فقد لا يلاحظ المستخدم حالة التطبيق إذا عُرضت باستخدام اللون فقط. استخدام واجهة مستخدم رمادية لتمثيل وضع عدم الاتصال هو بديهة المصممين، لكن في الويب، يمكن أن يُفهم من هذه الواجهة أن العنصر محمّل، كما أن عناصر واجهة المستخدم الرمادية مثل عناصر الإدخال في النماذج تعني أيضًا أن العنصر معطل، بالتالي استخدام اللون فقط لتصوير الحالة يمكن أن يسبب لبسًا في فهمها. لمنع هذا اللبس، عبِّر عن حالات المستخدم المختلفة بعدة طرق، مثلًا باستخدام كلًا من الألوان والتسميات والأيقونات ومكونات واجهة المستخدم الواضحة وغيرها. لا تستخدم اللون كوسيلة وحيدة لوصف الحالة، كما في الصورة التالية مستخدَم اللون الأحمر فقط للدلالة على تجاوز النص المكتوب للعدد المسموح به من الحروف. بل استخدم مزيجًا من عناصر التصميم لتوصيل المعنى، مثل اللغة الواضحة بالإضافة للون، لاحظ عند استخدم التعبير اللفظي الموضح للخطأ "تجاوزْت الحد الأقصى لعدد الأحرف" مع اللون المعبّر لإزالة اللبس بشأن سبب الخطأ. استخدم أيقونات بليغة تأكد من إيصال المعلومات للمستخدم بشكل صحيح وذلك باستخدام تسميات نصية ذات معنى مع الأيقونات، إذ يمكن أن يسبب استخدام الأيقونات لوحدها لبسًا. قد يسيء المستخدمون فهم بعض الأيقونة المستخدمة في التطبيقات، مثلًا يعد استخدام أيقونة القرص المرن لحفظ البيانات أمرًا منطقيًا بالنسبة للجيل الأكبر سنًا، لكن قد تسبب هذه الأيقونة لبسًا للمستخدمين الأصغر سنًا الذين لم يروا قرصًا مرنًا في حياتهم، وبالمثل فإن أيقونة القائمة التي تشبه البرغر hamburger menu قد تشوِّش المستخدمين عند عرضها دون تسمية. أيقونة الحفظ دون اتصال التي على شكل التنزيل النموذجي -أو ربما إذا كان الإجراء يتضمن مزامنة- قد تكون على شكل أيقونة مزامنة، لذا عند تقديم أحد الأيقونات المتعلقة بوضع عدم الاتصال، حاول أن توفر معها تسمية نصية ووصف. قد تفسَّر بعض الإجراءات على أنها حفظ دون اتصال بدلاً من إظهار حالة الشبكة، لذا فكر في الإجراء الذي تحاول الإبلاغ عنه بدلاً من عرض أيقونات مجردة (ذات طابع عام) للمستخدم، كأن يكون شكل أيقونة حفظ البيانات أو تنزيلها قائمًا على الإجراء action-based أي يدل على طبيعة استخدامها بالضبط. يمكن أن يعني وضع عدم الاتصال عددًا من الأشياء اعتمادًا على السياق، مثل التنزيل، والتصدير، والتثبيت، وما إلى ذلك. لمزيد من المعرفة، راجع مجموعة أيقونات التصميم Material Design. استخدم عناصر نائبة في التخطيط ريثما يجهز المحتوى مخطط الهيكل skeleton layout للتطبيق هو عناصر نائبة توضع في هيكل التطبيق الرئيسي ريثما يُحمّل المحتوى الفعلي، يمكنك استخدامه لتوضّح للمستخدم أن محتوى الصفحة على وشك التحميل. ضع في اعتبارك أيضًا استخدام واجهة التحميل المسبق preloader UI، مع رسالة نصية تخبر المستخدم أنه يجري تحميل التطبيق الآن، يمكنك أيضًا تحريك محتوى ما أو وضع شريط حالة أو حلقات دوارة لإشعار المستخدم أن التطبيق حي وجاري تحميل محتواه، بالتالي إقناع المستخدم بعدم إعادة طلب عنوان التطبيق أو تحديثه. وضع عناصر نائبة في هيكل التطبيق الرئيسي مكان المحتوى ريثما تُحمّل مع عرض إشعار يخبر المستخدم بمعدل التنزيل. ثم وضع المحتوى مكان تلك العناصر النائبة متى ما انتهت عملية التحميل وأصبح المحتوى جاهزًا للعرض. لا تعيق المحتوى عندما يشغِّل المستخدم إجراء مثل إضافة عنصر جديد، فإن التطبيق يتصل بالخادم لمزامنة العنصر الجديد، وللدلالة على ذلك فإنه يعرض عنصر تدخُّلي للتحميل يغطي الشاشة بأكملها (غالبًا أيقونة التحميل الدائرية تتدخل وسط الصفحة وتحجب تنفيذ اي عملية ريثما ينتهي التحميل لتختفي بعدها). قد يعمل هذا بشكل جيد إذا كان لدى المستخدم اتصال شبكة ثابت، لكن إذا كان اتصال الشبكة غير مستقر، فلا يمكن للمستخدمين التخلص من عنصر التحميل الذي يغطي الشاشة أثناء تحميل بياناتهم، فكأن الواجهة تمنعهم من القيام بأي شيء في التطبيق وتعيق ظهور محتواه. هذه ليست تجربة جيدة، بل يجب أن يتجنب تطبيقك التعامل مع طلبات الشبكة التي تعيق ظهور في وضع الاتصال غير المستقر، والسماح بدلًا من ذلك للمستخدمين بالاستمرار في تصفح تطبيقك ومهام قائمة الانتظار التي ستُنفَّذ وتُزامَن بمجرد تحسُّن الاتصال. أظهر حالة الإجراءات من خلال تزويد المستخدمين برد فعل، مثلًا إذا كان أحد مستخدمي تطبيق مستنداتك يُحرِّر مستند عند انقطاع الاتصال، ففكر في تغيير تصميم رد الفعل بحيث يكون مختلفًا بشكل مُلاحَظ عما كان عليه قبل انقطاع الاتصال، لكن حافظ على إظهار أنه قد تم حفظ ملفه وستتم مزامنته عندما يُستعاد الاتصال بالشبكة، فذلك سيؤدي إلى إعلام المستخدم بمختلف الحالات المتاحة وطمأنته بأن قد تم تخزين مهمته أو إجراءه، كما لهذا فائدة إضافية تتمثل في زيادة ثقة المستخدم في استخدام تطبيقك. صمم لجميع طبقات المستخدمين تعد الأجهزة منخفضة الجودة في بعض المناطق أمرًا شائعًا، وكذلك اتصال الشبكة غير المستقر، الذي بالنسبة للعديد من المستخدمين، لا يمكنه تحمّل نقل البيانات، لذا تحتاج في مثل هكذا حالات إلى كسب ثقة المستخدم من خلال الشفافية والاقتصاد في التعامل مع البيانات، وذلك بأن تفكِّر في طرق لمساعدة مستخدمي الاتصالات الضعيفة وطرق لتبسيط الواجهة بهدف تسريع إنجاز المهام. حاول دائمًا سؤال المستخدمين قبل تنزيل محتوى ضخم من البيانات. اعرض خيارات النطاق الترددي المنخفض low bandwidth للمستخدمين ذوي اتصال الشبكة الضعيف، أي قدِّم أصولًا قليلةً للتطبيق إذا كان اتصال الشبكة بطيئ. أيضًا وفِّر ميزة للاختيار ما بين الأصول عالية الجودة و منخفضة الجودة. الخلاصة يعد إعلام المستخدم بحالة التطبيق وبياناته مفتاحًا لتجربة المستخدم غير المتصلة بالشبكة. حاول إنشاء ارتباطات بأشياء مألوفة، مثلًا اجعل تجربة مشاهدة البيانات دون اتصال نفس التجربة المألوفة التنزيل للاستخدام لاحقًا. تذكر هذه الإرشادات عند تصميم تجربة المستخدم للشبكات غير المستقرة: فكر في كيفية التصميم في حالة نجاح الاتصال بالشبكة وحالة فشل الاتصال وأيضًا عدم استقراره. إذا كانت تكلفة نقل أو تخزين البيانات مرتفعة في تطبيقك، يجب مراعاة إعلام المستخدم بذلك. بالنسبة لمعظم المستخدمين على مستوى العالم، فإن البيئة الفنية لاتصال الشبكة (مثلًا مكان المستخدم بالنسبة للموجِّه أو الرواتر) تكاد تكون متنقلة بحتًا. الأجهزة القديمة ذات الأداء المنخفض، بالإضافة لسعة تخزين وذاكرة وقدرة معالجة محدودة، وشاشات صغيرة بجودة قليلة، فتأكد أن يكون مراعاة الأداء على مثل هذه الأجهزة جزء من تصميمك. اسمح للمستخدمين بتصفح تطبيقك عندما يكونوا في وضع عدم اتصال. أعلِم المستخدمين بوضعهم الحالي وتَغيُّر حالتهم. حاول توفير وضع عدم الاتصال افتراضيًا إذا كان تطبيقك لا يحتاج بيانات كثيرة. إذا كان تطبيقك يعالج كمية كبيرة من البيانات، فأعلِم المستخدمين حول كيفية تنزيل البيانات للاستخدام دون اتصال. اجعل المستخدم قادر على التنقل بين الأجهزة مع المحافظة على نفس التجارب بينها لنفس التطبيق. استخدم كلًا من اللغة والأيقونات والتمثيل والكتابة واللون للتعبير عن الأفكار للمستخدم. قدم تشجيع وتطمين وردود أفعال لمساعدة المستخدم في فهم حالات التطبيق المختلفة. ترجمة -وبتصرف- للمقال Offline UX design guidelines من موقع web.dev. اقرأ أيضًا ما هي تطبيقات الويب التقدمية PWA مفهوم Service Worker وتأثيره في أداء وبنية مواقع وتطبيقات الويب مشاركة تطبيقات الويب التقدمية البيانات عبر الواجهة Web Share إضافة اختصارات للمهام الشائعة في تطبيقات الويب التقدمية PWA

يمكن لتطبيقات الويب استخدام نفس إمكانيات المشاركة التي توفرها التطبيقات المثبتة على نظام التشغيل platform-specific، وذلك باستخدام الواجهة البرمجية Web Share التي تعمل في الخلفية Web Share API، إذ تتيح هذه الواجهة لتطبيقات الويب إمكانية مشاركة الروابط والنصوص والملفات مع التطبيقات الأخرى المثبتة على الجهاز كما التطبيقات المخصوصة بالنظام (تطبيقات النظام الأصلية أو التطبيقات المثبتة في النظام). مشاركة البيانات في تطبيقات الويب ليس كل شيء، إذ يمكن أن تشاركها التطبيقات الأخرى المحتوى، بمعنى أن بإمكان تطبيقات الويب تلقي البيانات والروابط والنصوص والملفات من التطبيقات المخصوصة بالنظام أو تطبيقات الويب الأخرى. المفاهيم والاستخدامات تتيح الواجهة البرمجية Web Share مشاركة البيانات في تطبيقات الويب ضمن قدرات استخدامها ومحدودياتها، موضّح فيما يلي هذه القدرات كما مذكور أيضًا طريقة استخدام هذه الواجهة في مشاركة محتوى تطبيقات الويب. القدرات والمحدوديّات تمتلك الواجهة البرمجية Web Share القدرات والمحدوديّات التالية: يمكن استخدامها فقط في المواقع الآمنة، التي يُوصل إليها عبر بروتوكول HTTPS. يجب أن تُستدعى استجابةً لإجراء مستخدم مثل النقر click، إذ لا يمكن استدعائها من خلال معالج التحميل onload. يمكن بواسطتها مشاركة عناوين URL أو نصوص أو ملفات. أصبحت متاحة على متصفحات Safari و Android و Chrome OS و Chrome على Windows، اعتبارًا من يناير كانون الأول 2021، أما إتاحتها في Chrome على MacOS لا تزال قيد التطوير، اطلع على MDN للحصول على التفاصيل. مُنتقي وُجْهة المشاركة على مستوى النظام مع تطبيق ويب تقدمي PWA مثبت كخيار للمشاركة إليه. مشاركة الروابط والنصوص إن أردت مشاركة الروابط والنصوص عبر الواجهة البرمجية Web Share، فاستخدم الدالة ()share، وهي دالة تعتمد على الوعد promise مع كائن خصائص properties مطلوب، ولمنع المتصفح من رمي خطأ TypeError، إذ يجب أن يحتوي ذلك الكائن على واحدة على الأقل من الخاصيات التالية: title أوtext أوURL أوfiles، مثلًا يمكنك مشاركة نص بدون عنوان URL أو العكس، وإتاحة إمكانية مشاركة الخصائص الثلاثة يؤدي إلى زيادة مرونة حالات الاستخدام. تخيل أنه بعد تشغيل الشيفرة التالية، اختار المستخدم تطبيق بريد إلكتروني كوُجْهة مشاركة، فحينها يصبح المعامل title هو موضوع رسالة subject والمعامل text هو نص الرسالة والمعامل files يصبح هو مرفقات الرسالة. if (navigator.share) { navigator.share({ title: 'web.dev', text: 'Check out web.dev.', url: 'https://web.dev/', }) .then(() => console.log('Successful share')) .catch((error) => console.log('Error sharing', error)); } إذا حوى موقعك على عناوين URL متعددة لنفس المحتوى، فشارِك عنوان URL الأساسي للصفحة بدلاً من عنوان URL الحالي، أي بدلاً من مشاركة document.location.href؛ يمكنك إيجاد عنوان URL الأساسي في وسم <meta> ضمن <head> الصفحة ومشاركته، فهذا سيوفر تجربة أفضل للمستخدم، ليس فقط على صعيد تجنب عمليات إعادة التوجيه، ولكنه يضمن أيضًا أن عنوان URL المشارك يخدم تجربة المستخدم الصحيحة لعميل معين، مثلًا إذا شاركك صديقك عنوان URL من هاتفه المحمول وفتحته عبر حاسوبك المكتبي، فيجب أن ترى إصدار سطح المكتب من الموقع او التطبيق المُشارك: let url = document.location.href; const canonicalElement = document.querySelector('link[rel=canonical]'); if (canonicalElement !== null) { url = canonicalElement.href; } navigator.share({url}); مشاركة الملفات إذا أردت إتاحة ميزة مشاركة الملفات في تطبيقك، اختبر أولًا إمكانية المشاركة عبر استدعاء التابع ()navigator.canShare، ثم ضمِّن مجموعة من الملفات في استدعاء التابع ()navigator.share: if (navigator.canShare && navigator.canShare({ files: filesArray })) { navigator.share({ files: filesArray, title: 'Vacation Pictures', text: 'Photos from September 27 to October 14.', }) .then(() => console.log('Share was successful.')) .catch((error) => console.log('Sharing failed', error)); } else { console.log(`Your system doesn't support sharing files.`); } لاحظ أن المثال يعالج الكشف عن ميزة إمكانية المشاركة عبر التابع ()navigator.canShare بدلاً من التابع ()navigator.share. كائن البيانات الممرر للدالة ()canShare في هذا المثال يدعم خاصية files فقط، لكن يمكن مشاركة ملفات الصور والفيديو والصوت والنص. (راجع امتدادات الملفات المسموح بمشاركتها حاليًا في Chromium). دراسة حالة لبرنامج Santa Tracker يعد Santa Tracker مشروعًا مفتوح المصدر، وهو تطبيق ترفيهي سنوي تحت عنوان عيد الميلاد أطلقته Google، يتيح للمستخدمين اللعب ومشاهدة وتعلم الأنشطة الصغيرة التي تُضاف يوميًا من بداية ديسمبر كل عام، كما يتيح تعقب السانتا (بابا نويل) أثناء عشية عيد الميلاد. في عام 2016، استخدم فريق Santa Tracker الواجهة البرمجية Web Share على منصة Android، وكانت هذه الواجهة مناسبة تمامًا لتطبيقات الهاتف المحمول، على عكس الأعوام السابقة التي أزال الفريق فيها أزرار المشاركة من نسخة الهاتف المحمول لأن مساحة تلك الأزرار كانت كبيرة في الشاشة، ولم تكن قادرة على إثبات وجود العديد من التطبيقات لمشاركتها المحتوى. لكن باستخدام الواجهة البرمجية Web Share تمكن فريق Santa Tracker من تقديم زر مشاركة واحد ويؤدي الغرض، مما يوفر مساحة ثمينة في الشاشة. توجه إلى Santa Tracker لمشاهدة فعاليِّة مشاركة الويب. زر المشاركة في تطبيق Santa Tracker. دعم المتصفحات هناك فروقات دقيقة في دعم المتصفحات للواجهة البرمجية Web Share، ويوصَى باستخدام استراتيجية اكتشاف الميزات (كما هو موضح في نماذج الشيفرات السابقة) بدلاً من افتراض دعم دالة معينة. دعم متصفحَي Safari و Chrome استخدام الواجهة Web Share لمشاركة العناوين والنصوص وعناوين URL بداية عام 2021 بالإصدارات التالية: Safari الإصدار 12 أو أحدث على macOS و iOS. Chrome الإصدار 75 أو أحدث على Android، والإصدار 89 أو أحدث على Chrome OS و Windows. كما دعم المتصفحان استخدام الواجهة Web Share لمشاركة الملفات أيضًا، وذلك بالإصدارات التالية: Safari الإصدار أو أحدث على macOS وiOS. Chrome الإصدار 75 أو أحدث على Android، والإصدار 89 أو أحدث على Chrome OS و Windows. تتمتع معظم المتصفحات المبنية على متصفح Chromium، مثل Edge، بنفس الدعم لميزة المشاركة مثل الإصدار المقابل من Chrome. ترجمة -وبتصرف- للمقال Integrate with the OS sharing UI with the Web Share API من موقع web.dev اقرأ أيضًا استقبال تطبيقات الويب التقدمية البيانات المشاركة عبر الواجهة البرمجية Web Share Target ما هي تطبيقات الويب التقدمية PWA جعل تطبيق الويب التقدمي PWA يبدو كتطبيق أساسي في نظام التشغيل إضافة اختصارات للمهام الشائعة في تطبيقات الويب التقدمية PWA

يُشارك المحتوى مباشرةً في الأجهزة المحمولة وأجهزة سطح المكتب، بالنقر على زر "مشاركة" واختيار أحد التطبيقات المراد مشاركة البيانات معها. مثلًا قد ترغب بمشاركة مقال مثير للاهتمام، إما عبر إرساله كرسالة بريد إلكتروني إلى أصدقاءك أو نشره في مجتمعك على تويتر أو مشاركته مع أي تطبيق آخر متاح لك المشاركة إليه في جهازك. كان فقط بإمكان التطبيقات المثبتة على نظام التشغيل platform-specific التسجيل في نظام التشغيل لاستقبال البيانات المشاركة من التطبيقات المثبتة الأخرى، لكن باستخدام الواجهة البرمجية Web Share Target (وُجهة مشاركة الويب) التي تعمل في الخلفية Web share Target API، أصبح بإمكان تطبيقات الويب المثبتة على الجهاز أيضًا التسجيل مع نظام التشغيل كهدف مشاركة لاستقبال بيانات من التطبيقات الأخرى. إمكانية استقبال تطبيقات الويب البيانات المُشاركة يُعد مكمّلًا لإمكانية تطبيقات أخرى على مشاركة البيانات، يمكنك مراجعة مقال مشاركة البيانات عبر الواجهة Web Share في تطبيقات الويب التقدمية. تجريب الواجهة البرمجية Web Share Target إن أردت تجريب الواجهة البرمجة Web Share Target، اتبع الخطوات التالية: افتح العرض التوضيحي لهذه الواجهة Web Share Target Demo وذلك على متصفح Chrome، بالإصدار 76 فما فوق على نظام أندرويد، أو 89 فما فوق على سطح المكتب. انقر زر المشاركة في العرض التوضيحي. اختر أحد التطبيقات الظاهرة في مُنتقي جهات المشاركة كوجْهة للمشاركة. بعد إتمامك عملية المُشاركة، ستُشاهد النص المُشارَك في التطبيق الذي اخترته. منتقي وجهة المشاركة على مستوى النظام. تسجيل التطبيق كهدف مشاركة يجب أن يستوفي تطبيقك معايير Chrome الخاصة بقابلية تثبيت التطبيقات لتسجيله كوجهة مشاركة، أيضًا حتى يتمكن المستخدم من مشاركة محتوى ما إلى تطبيقك، فيجب أن يكون تطبيقك مثبتًا في شاشته الرئيسية، فهذا يمنع المواقع من إضافة نفسها عشوائيًا إلى منتقي وُجهات المشاركة Share Target Picker المتاح للمستخدم مشاركة المحتوى إليها. حدِّث ملف بيان موارد تطبيق الويب لتسجيل تطبيقك كهدف مشاركة، أضف الخاصية share_target إلى ملف بيانه manifest، فهي تخبر نظام التشغيل بتضمين تطبيقك كخيار في منتقي وُجْهات المشاركة، وبشكل عام ما تضيفه إلى الخاصية share_target يضبط البيانات التي سيقبل تطبيقك أن تشارُكها. هناك ثلاثة طرق شائعة لضبط الخاصية share_target: قبول محتوى المشاركة الأساسي. قبول بيانات مشاركة تُحْدِث تغييرات في التطبيق. قبول تشارُك الملفات. قبول محتوى المشاركة الأساسي إذا أردت لتطبيقك المحدد كوُجْهة مشاركة أن يقبل فقط محتوى المشاركة الأساسي مثل البيانات والروابط والنصوص، فأضف ما يلي إلى ملف بيانه manifest.json: "share_target": { "action": "/share-target/", "method": "GET", "params": { "title": "title", "text": "text", "url": "url" } } إذا كان تطبيقك يتيح المشاركة بواسطة بروتوكول عنوان URL Scheme، وكان يستخدم القيمة body للحقل text بدلاً من القيمة text، يمكنك استبدال text": "text"‎" في الشيفرة السابقة بالقيمة "text": "body". النوع الافتراضي لنوع طلبية http والمعبر عنه بالحقل method هو "GET". يشير حقل enctype غير الظاهر في الشيفرة السابقة إلى نوع تشفير البيانات، يعيَّن هذا الحقل بالقيمة "application / x-www-form-urlencoded" افتراضيًا عندما تكون الطريقة هي "GET". قبول بيانات مشاركة تُحْدِث تغييرات في التطبيق إذا كانت البيانات المشاركة تُحدِثْ تغييرات في التطبيق الوجْهة بطريقة ما، مثلًا تحفظ إشارات مرجعية فيه، وقتها عيّن الحقل method بالنوع "POST" واضبط الحقل enctype. يُنشئ المثال التالي إشارة مرجعية في التطبيق الوُجْهة، لذا فإنه يستخدم "POST" للحقل method و القيمة "multart/form-data" للحقل enctype: { "name": "Bookmark", "share_target": { "action": "/bookmark", "method": "POST", "enctype": "multipart/form-data", "params": { "url": "link" } } } قبول مشاركة الملفات كما هو الحال مع البيانات المُشاركة التي تُحْدِث تغييرات في التطبيق، يتطلب قبول مشاركة الملفات أن تكون طريقة المشاركة method هي "POST" وأن يكون نوع enctype هو "multipart/form-data"، ويجب إضافة الحقل files، التي تمثل مصفوفة أنواع الملفات التي يقبلها تطبيقك، عناصر المصفوفة عبارة عن كائنات مكونة من حقلين: name وaccept. يمثل حقل accept نوع MIME للملف أو إمتداده أو مصفوفة تحتوي كليهما. يفضّل توفير مصفوفة تتضمن كلاً من نوع MIME وامتداد الملف لاختلاف أنظمة التشغيل في ما تفضِّل منهما. { "name": "Aggregator", "share_target": { "action": "/cgi-bin/aggregate", "method": "POST", "enctype": "multipart/form-data", "params": { "title": "name", "text": "description", "url": "link", "files": [ { "name": "records", "accept": ["text/csv", ".csv"] }, { "name": "graphs", "accept": "image/svg+xml" } ] } } } معالجة المحتوى المشارك طريقة التعامل مع البيانات المُشارَكة أمر متروك لك ويعتمد على تطبيقك، مثلًا: يمكن لتطبيق البريد الإلكتروني، صياغة بريد إلكتروني جديد من المحتوى المشارَك، باستخدام العنوان title كموضوع للبريد الإلكتروني، والنص المُشارك text والرابط url متسلسلَين معًا كجسم لرسالة البريد. يمكن لتطبيق تواصل إجتماعي صياغة منشور جديد من المحتوى المشارَك، بتجاهل العنوان title، والاستفادة من text كنص للمنشور، وإضافة url كرابط للمنشور أو حتى كنص أساسي وذلك إذا كان text مفقود، وإذا كان url مفقودًا، فقد يفحص التطبيق النص text بحثًا عن أي عنوان URL ويضيفه كرابط. يمكن لتطبيق مشاركة الصور إنشاء عرض شرائح جديد من المحتوى المشارَك، باستخدام العنوان title كعنوان لعرض الشرائح و النص text كوصف للعرض والملفات files (ملفات الصور) كشرائح تتحرك في العرض. يمكن لتطبيق الرسائل النصية صياغة رسالة جديدة من المحتوى المشارَك وذلك باستخدام النص text وurl متسلسلَين معًا كنص للرسالة وتجاهل العنوان title. معالجة مشاركات GET إذا اختار المستخدم تطبيقك كوُجْهة مشاركة، وكانت طريقة المشاركة method في تطبيقك هي "GET" (الافتراضية)، يفتح المتصفح نافذة جديدة على عنوان URL بقيمة الحقل action ضمن الخاصية share_target، ويولِّد المتصفح بعدها استعلامًا نصيًا بسيطًا، مثلًا إذا كان التطبيق المشارِك يوفر عنوان title ونص text بقيم معينة، فإن سلسلة الاستعلام التي يولّدها المتصفح ستكون ?title=hello&text=world. ولمعالجة هذا الاستعلام، استخدم مستمع الحدث DOMContentLoaded (يحصل هذا الحدث عند الانتهاء من تحميل المستند وبناء DOM) في الواجهة الأمامية foreground وحلِّل نص الاستعلام: window.addEventListener('DOMContentLoaded', () => { const parsedUrl = new URL(window.location); // searchParams.get() will properly handle decoding the values. console.log('Title shared: ' + parsedUrl.searchParams.get('title')); console.log('Text shared: ' + parsedUrl.searchParams.get('text')); console.log('URL shared: ' + parsedUrl.searchParams.get('url')); }); تأكد من استخدام عامل الخدمة لتخزين صفحة الإجراء action مؤقتًا بحيث تُحمَّل بسرعة وتعمل بموثوقية، حتى إن لم يكن المستخدم متصلًا بالشبكة. يمكن أن تساعدك الأداة Workbox في تنفيذ تخزين مؤقت مسبق preaching بالاستفادة من عامل خدمة تطبيقك. معالجة مشاركات POST إذا كانت طريقة المشاركة method في تطبيقك هي "POST"، أي كان تطبيقك يقبل بيانات مُشاركة تُحْدِث تغييرات فيه أو يقبل تشارُك ملفات، فسيحتوي جسم طلب POST الوارد على البيانات التي مرَّرها التطبيق المُشارِك، والمشفرة باستخدام قيمة enctype المعيّنة في ملف البيان. لا يمكن للواجهة الأمامية معالجة هذه البيانات مباشرة، بل تعاملها كطلب تمرره إلى عامل خدمة تطبيقك، الذي بواسطته يمكنك اعتراضها ومعالجتها باستخدام مستمع الحدث fetch. self.addEventListener('fetch', event => { const url = new URL(event.request.url); // If this is an incoming POST request for the // registered "action" URL, respond to it. if (event.request.method === 'POST' && url.pathname === '/bookmark') { event.respondWith((async () => { const formData = await event.request.formData(); const link = formData.get('link') || ''; const responseUrl = await saveBookmark(link); return Response.redirect(responseUrl, 303); })()); } }); التحقق من المحتوى المُشارَك تحقق من معالجة البيانات المُشاركة، فللأسف ليس هناك ما يضمن أن التطبيقات الوجهة ستشارك المحتوى المخصص في المكان المناسب بناء على معاملاته (معاملات المحتوى المشارك). مثلًا يبقى حقل الرابط url فارغًا في نظام Android كما ترى في الصورة التالية، كونه غير مدعوم في نظام مشاركة Android، فغالبًا ما تظهر عناوين URL في حقل النص، أو أحيانًا في حقل العنوان. معالجة المحتوى المشارَك في التطبيق الوجهة. دعم المتصفحات دعَم متصفحَي Chrome وEdge الواجهة البرمجية Web Share Target اعتبارًا من أوائل عام 2021 على النحو التالي: الإصدار 76 فما فوق من كلا المتصفحين (Chrome وEdge) على نظام Android الإصدار 89 فما فوق من Chrome على نظام Chrome OS. تذكر بالنسبة لجميع أنظمة التشغيل الأساسية، أنه يجب تثبيت تطبيق الويب حتى يظهر كهدف محتمل لاستقبال البيانات المُشاركة. ترجمة -وبتصرف- للمقال Receiving shared data with the Web Share Target API من موقع web.dev اقرأ أيضًا ما هي تطبيقات الويب التقدمية PWA ميزات تطبيق الويب التقدمي مشاركة تطبيقات الويب التقدمية البيانات عبر الواجهة Web Share إضافة اختصارات للمهام الشائعة في تطبيقات الويب التقدمية PWA مفهوم Service Worker وتأثيره في أداء وبنية مواقع وتطبيقات الويب

يدعم نظام الويب الآن ميزة اختصارات التطبيقات، وذلك لتسهيل إنجاز مهام التطبيق الرئيسية، فهذه الاختصارات تسمح لمطوري الويب بتوفير وصول سريع إلى أهم الإجراءات الشائعة التي يحتاجها مستخدمو التطبيق كثيرًا. ستتعلم من هذا المقال كيفية تعيين اختصارات للتطبيقات، مع بعضٍ من أفضل الممارسات الممكن اتباعها لرفع مستوى هذه الاختصارات. نبذة عن اختصارات التطبيق تساعد اختصارات تطبيقك المستخدمين على إجراء المهام الشائعة بسرعة في تطبيقاتك، ويؤدي الوصول السهل إلى هذه المهام من أي مكان توجد فيه أيقونة التطبيق إلى زيادة تفاعل المستخدمين مع تطبيقك. تُستدعى قائمة اختصارات التطبيق عن طريق النقر بزر الفأرة الأيمن على أيقونة التطبيق في شريط مهام نظام Windows أو شريط Dock في نظام macOS لبيئة سطح المكتب، أو الضغط لفترة طويلة على أيقونة مشغل التطبيق في نظام Android. قائمة اختصارات التطبيق في Android. قائمة اختصارات التطبيق في Windows. تظهر قائمة اختصارات التطبيقات فقط لتطبيقات الويب التقدمية PWAs المثبتة على سطح مكتب أو جهاز المستخدم المحمول. يعبر كل اختصار من اختصارات تطبيقك عن إجراء ينوي المستخدم فعله، وكل منها مرتبط بعنوان URL ضمن مجال التطبيق، يُفتح هذا العنوان عندما ينقر المستخدمون على الاختصار المعنِي. وفيما يلي أمثلة على الإجراءات المحتملة لاختصارات التطبيق: صفحات التطبيق الرئيسية (الوصول إلى صفحة التطبيق الرئيسية أو صفحة آخر الطلبات مثلًا) مهام البحث في التطبيق مهام إدخال البيانات (مثلًا كتابة رسالة بريد أو منشور) الأنشطة (مثلًا بدء محادثة مع جهات الاتصال الشائعة) تحديد اختصارات التطبيق في بيان تطبيق الويب manifest تُحدَّد اختصارات التطبيقات اختياريًا في ملف بيان موارد تطبيق الويب manifest، والذي هو عبارة عن ملف JSON يخبر المتصفح عن تطبيق الويب التقدمي PWA وكيف يجب أن يتصرف عند تثبيته على حاسوب المستخدم المكتبي أو جهازه المحمول، وتُعرَّف اختصارات التطبيقات في مصفوفة shortcuts بالتحديد ضمن هذا الملف كما في المثال التالي: { "name": "Player FM", "start_url": "https://player.fm?utm_source=homescreen", … "shortcuts": [ { "name": "Open Play Later", "short_name": "Play Later", "description": "View the list of podcasts you saved for later", "url": "/play-later?utm_source=homescreen", "icons": [{ "src": "/icons/play-later.png", "sizes": "192x192" }] }, { "name": "View Subscriptions", "short_name": "Subscriptions", "description": "View the list of podcasts you listen to", "url": "/subscriptions?utm_source=homescreen", "icons": [{ "src": "/icons/subscriptions.png", "sizes": "192x192" }] } ] } كل عضو في مصفوفة الاختصارات shortcuts هو كائن اختصار يتكون على الأقل من حقل الاسم وعنوان url، أما الحقول الأخرى فهي اختيارية. حقل الاسم name: التسمية الممكن للمستخدمين قراءتها لاختصار التطبيق. حقل الاسم المختصر short_name (اختياري): التسمية الممكن للمستخدمين قراءتها لاختصار التطبيق عندما تكون المساحة محدودة، ويوصى بتعيين هذا الحقل حتى لو كان اختياريًا. حقل الوصف description (اختياري): الغرض من اختصار التطبيق. حقل عنوان URL: عنوان URL الذي يُفتح عندما ينقر المستخدم على اختصار التطبيق، ويجب أن يكون عنوان URL هذا موجودًا في نطاق بيان تطبيق الويب. حقل الأيقونات icons (اختياري): مصفوفة من كائنات الصور، يتكون كل كائن منها خاصية src وsize بشكل أساسي، بالإضافة للخاصية الإختيارية type. إذا كنت تريد تعيين أيقونات مثالية الحجم، فاجعلها بالحجم الموصى به 48dp، والذي يتوافق مع كثافات القياسات التالية بوحدة البكسل بناء على معادلة التحويل التالية: px = dp * (dpi / 160) في الشاشات منخفضة الكثافة ldpi والتي تكافئ 120 dpi، الحجم 48dp يساوي 48*0.75=36px في الشاشات متوسطة الكثافة mdpi والتي تكافئ 160 dpi، الحجم 48dp يساوي 48px (نفسه)، أي يكون حجم الأيقونة 48x48 بكسل في الشاشات عالية الكثافة hdpi والتي تكافئ 240 dpi، الحجم 48dp يساوي 48*1.5=72px، أي يكون حجم الأيقونة 72x72 بكسل في الشاشات عالية الكثافة جدًا xhdpi والتي تكافئ 320 dpi، الحجم 48dp يساوي 48*2=96px، أي يكون حجم الأيقونة 96x96 بكسل في الشاشات عالية الكثافة جدًا جدًا xxhdpi والتي تكافئ 480 dpi، الحجم 48dp يساوي 48*3=144px، أي يكون حجم الأيقونة 144x144 بكسل في الشاشات عالية الكثافة جدًا جدًا جدًا xxxhdpi والتي تكافئ 640 dpi، الحجم 48dp يساوي 48*4=192px، أي يكون حجم الأيقونة 192x192 بكسل اختبر اختصارات تطبيقك للتحقق من تعيين اختصارات التطبيق بشكل صحيح، استخدم قائمة Manifest في لوحة Application في أدوات المطور DevTools. تظهر الصورة اختصارات التطبيقات في DevTools توفر هذه القائمة إمكانية معاينة عدة خصائص محفوظة في ملف البيان، بما في ذلك اختصارات التطبيقات، ما يسهل التحقق من تحميل أيقونات الاختصارات إذا تم تعيينها (كونها اختيارية)، بالشكل الصحيح. أفضل الممارسات فيما يلي نصائح بمارسات يوصى اتباعها لزيادة كفاءة اختصارات تطبيقك. طلب اختصارات التطبيق حسب الأولوية يفضَّل تعيين اختصارات التطبيقات حسب الأولوية، وذلك بوضع اختصارات التطبيقات الأكثر أهمية في بداية مصفوفة الاختصارات shortcuts ضمن ملف mainfest، نظرًا لأن الحد الأقصى لعدد الاختصارات التي تظهر في قائمة اختصارات التطبيق يختلف باختلاف نظام التشغيل. مثلًا يتيح Chrome وEdge حتى 10 اختصارات للتطبيق في نظام Windows، بينما يأخذ Chrome في الاعتبار أول 4 اختصارات للتطبيق فقط في نظام Android، ويسمح متصفح Chrome 92 الآن بثلاث اختصارات للتطبيقات فقط على نظام Android 7 استخدم أسماء اختصارات فريدة للتطبيق يجب استخدام اسم مميز لكل اختصار تطبيق. لا تعتمد على الأيقونات للتمييز بين اختصارات التطبيقات لأنها قد لا تكون ظاهرة على جميع الأجهزة، فنظام macOS مثلًا لا يدعم إظهار أيقونات اختصارات التطبيقات المثبّته في شريط Dock. قياس استخدام اختصارات التطبيق يمكنك تعقب عناوين (الخاصية url) اختصارات تطبيقك لأغراض إحصائية، مثلًا لقياس مدى استخدام مستخدمي تطبيقك تلك الاختصارات. دعم المتصفحات يدعم متصفحَي Chrome وEdge اختصارات تطبيقات الويب التقدمية على النحو التالي: الإصدار 84 فما فوق من Chrome على نظام Android. الإصدار 85 فما فوق من كلا المتصفحين (Chrome وEdge) على نظام Windows. الإصدار 92 فما فوق من Chrome على نظام Chrome OS. الإصدار 96 فما فوق من كلا المتصفحين (Chrome وEdge) على نظامَي MacOS ولينكس Linux. دعم فاعليِّة الويب الموثوق فاعليِّة الويب الموثوق Trusted Web Activity هو طريقة لتغليف تطبيق الويب التقدمي بحاوية container تجعله يتصرف كتطبيقات الهواتف المعيارية. تقرأ الأداة Bubblewrap المستخدمة لإنشاء تطبيقات Android باستخدام فاعليِّة الويب الموثوق، اختصارات تطبيق الويب من ملف بيانه manifest، وتولِّد تلقائيًا الإعدادات المقابلة لها لتطبيق Android. لاحظ عند استخدام Bubblewrap أنه يجب تحديد أيقونات لاختصارات التطبيقات وبحجم لا يقل عن 96×96 بكسل. أداة باني تطبيق الويب التقدمي PWABuilder تحوِّل تطبيق الويب التقدمي بسهولة إلى فاعليِّة ويب موثوق، وتدعم اختصارات التطبيقات. نموذج راجع نموذج اختصارات التطبيق ومصدره. ثبت تطبيق PWA هذا وجرب اختصاراته. ترجمة -وبتصرف- للمقال Get things done quickly with app shortcuts من موقع web.dev اقرأ أيضًا ما هي تطبيقات الويب التقدمية PWA ميزات تطبيق الويب التقدمي جعل تطبيق الويب التقدمي PWA يبدو كتطبيق أساسي في نظام التشغيل التحسين التدريجي لتطبيقات الويب التقدمية PWA شرح ملف البيان manifest لتطبيق الويب التقدمي PWA

تشترك معظم التطبيقات الشهيرة مثل مُساعد جوجل Google Assistant وتطبيق الدردشة سلاك Slack وتطبيق اللقاءات الافتراضية زووم Zoom بأنها تُقدّم خدمات محدودة جدًا في وضع انقطاع الاتصال، أي أنه يُمكن تشغيلها والدخول إليها ومعاينة بعض الواجهات فيها على الرغم من انقطاع الاتصال. تُبين اللقطات التالية أن تطبيقات المنصات الخاصة تعرض شيئًا ما في وضع انقطاع الاتصال. مثلًا اللقطة التالية للمُساعد Google Assistant: أما اللقطة التالية لتطبيق سلاك Slack: واللقطة التالية لتطبيق زووم Zoom: على النقيض من ذلك، لا نحصل على شيء على الويب عند انقطاع الاتصال. مثلًا، قد يُظهر المتصفح Chrome اللعبة البسيطة dino على أنظمة التشغيل iOS: وعلى أنظمة التشغيل macOS: سنتعلم في هذا المقال كيفية إنشاء صفحة احتياطية لوضع انقطاع الاتصال وإضافتها إلى تطبيقات الويب التقدمية PWA. إنشاء صفحة احتياطية باستخدام عامل خدمة مخصص من المناسب تخصيص سلوك صفحات الويب التقدميّة في حال انقطاع الاتصال لاسيما أنه أصبح بالإمكان توفير تجربة استخدام مخصصة باستخدام عامل خدمة service worker وواجهة برمجة التطبيقات ذات التخزين المؤقت Cache Storage API . يُمكن عادًة إنشاء صفحة احتياطية بسيطة تُبين للمستخدم أنه في وضع انقطاع الاتصال، إلا أنه يُمكن أيضًا إيجاد حلول إبداعية أجمل. لنلقي نظرة مثلًا على موقع الحجز trivago والذي يوفر في صفحته الاحتياطية لعبة متاهة مسلية للمستخدم خلال انقطاع الاتصال مع زر لتجريب إعادة الاتصال Reconnect وعدّاد تنازلي لإظهار الزمن المتبقي لإعادة محاولة الاتصال تلقائيًا كما يُبين الشكل التالي: تسجيل عامل الخدمة لإنشاء الصفحة الاحتياطية، يجب أولًا تسجيل عامل خدمة في الصفحة الأساسية كما تُبين الشيفرة التالية والتي تُنفّذ عند تحميل التطبيق: window.addEventListener("load", () => { if ("serviceWorker" in navigator) { navigator.serviceWorker.register("service-worker.js"); } }); شيفرة عامل الخدمة نعرض فيما يلي مثالًا عن شيفرة عامل الخدمة والتي قد تبدو للوهلة الأولى معقدة قليلًا ولذا أُضيفت بعض التعليقات المُساعدّة. تكمن الفكرة بالتخزين المؤقت المسبق لملف ندعوه offline.html والذي يعرضه المتصفح في حال فشل طلبات التنقل navigation فقط، وفي بقية الحالات يتابع المتصفح معالجاته الاعتيادية. /* معلومات رخصة الاستخدام Copyright 2015, 2019, 2020, 2021 Google LLC. All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ // (1) // يُمكن إضافة أي تعليق مناسب لمنقح الصياغة // eslint-disable-next-line no-unused-vars const OFFLINE_VERSION = 1; const CACHE_NAME = "offline"; يُمكن تخصيص مُحدّد موارد URL مختلف إذا دعت الحاجة // const OFFLINE_URL = "offline.html"; self.addEventListener("install", (event) => { event.waitUntil( (async () => { const cache = await caches.open(CACHE_NAME); // (2) await cache.add(new Request(OFFLINE_URL, { cache: "reload" })); })() ); إرغام عامل الخدمة المنتظر ليصبح العامل النشط // self.skipWaiting(); }); self.addEventListener("activate", (event) => { event.waitUntil( (async () => { // السماح بالتنقل قبل التحميل إذا كان ذلك مدعومًا // See https://developers.google.com/web/updates/2017/02/navigation-preload if ("navigationPreload" in self.registration) { await self.registration.navigationPreload.enable(); } })() ); // الطلب من عامل الخدمة أن يتحكم بالصفحة فورًا self.clients.claim(); }); self.addEventListener("fetch", (event) => { إذا كان الطلب لصفحة HTML نستدعي event.respondWith// if (event.request.mode === "navigate") { event.respondWith( (async () => { try { نحاول أولًا استخدام جواب التنقل قبل التحميل إذا كان مدعومًا // const preloadResponse = await event.preloadResponse; if (preloadResponse) { return preloadResponse; } تجريب الشبكة أولًا // const networkResponse = await fetch(event.request); return networkResponse; } catch (error) { // (3) console.log("Fetch failed; returning offline page instead.", error); const cache = await caches.open(CACHE_NAME); const cachedResponse = await cache.match(OFFLINE_URL); return cachedResponse; } })() ); } // (4) }); (1) تؤدي زيادة قيمة المتغير OFFLINE_VERSION إلى تنشيط حدث التثبيت وتحديث الموارد المخبئة سابقًا عبر الشبكة، المتغير مُعرّف عمدًا مع أنه غير مستخدم. (2) يؤدي ضبط {cache: 'reload'‎} في الطلب الجديد إلى استيفاء الطلب HTTP من الشبكة وليس من الذاكرة المؤقتة. (3) رُفع استثناء يُنشّط الالتقاط catch والذي يكون على الأغلب بسبب خطأ في الشبكة، ولن تُستدعى catch إذا أعادت fetch جواب HTTP صالح، مع كود الجواب محصور بين 4xx - 5xx. (4) إذا كان شرط التعليمة if خاطئًا فلن يقاطع معالج الجلب fetch الطلب، يُمكن أن يُستدعى التابع event.respondWith في حال وجود معالجات جلب أخرى مسجلة، إذا لم يستدع أي معالج جلب التابع event.respondWith فعندها يعالج المتصفح الطلب كما لو أنه لا يوجد عامل خدمة. الصفحة الاحتياطية لوضع انقطاع الاتصال يُعدّ ملف الصفحة الاحتياطية offline.html المكان المناسب لإظهار بعض الإبداع لجذب المستخدم وإبراز العلامة التجارية للمنتج مثلًا، حيث يُمكن تكييف هذا الملف مع الاحتياجات المطلوبة. يُبين المثال التالي الحد الأدنى الممكن القيام به كإظهار زر إعادة التحميل، إضافًة لمحاولات إعادة التحميل الآلية والتي تعتمد على حدث الاتصال online وعلى اقتراع خادم منتظم regular server polling. يجب تخزين جميع الموارد التي تتطلبها الصفحة الاحتياطية لوضع انقطاع الاتصال. من الحلول المُمكنة لذلك تضمين كل شيء وبذا تُصبح الصفحة الاحتياطية حاوية لنفسها، وهو ما يُبينه المثال التالي: <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <title>You are offline</title> <!-- Inline the page's stylesheet. --> <style> body { font-family: helvetica, arial, sans-serif; margin: 2em; } h1 { font-style: italic; color: #373fff; } p { margin-block: 1rem; } button { display: block; } </style> </head> <body> <h1>You are offline</h1> <p>Click the button below to try reloading.</p> <button type="button">⤾ Reload</button> <!-- Inline the page's JavaScript file. --> <script> // ميزة إعادة التحميل اليدوي document.querySelector("button").addEventListener("click", () => { window.location.reload(); }); //(1) window.addEventListener('online', () => { window.location.reload(); }); //(2) async function checkNetworkAndReload() { try { const response = await fetch('.'); // التحقق من الحصول على جواب صالح من الخادم if (response.status >= 200 && response.status < 500) { window.location.reload(); return; } } catch { // تجاهل إذ لا يُمكن الاتصال مع الخادم } window.setTimeout(checkNetworkAndReload, 2500); } checkNetworkAndReload(); </script> </body> </html> حيث أن: (1) متابعة تغييرات حالة الشبكة وإعادة التحميل عند انقطاع الاتصال حيث ينشط المعالج التالي في حالة انقطاع الاتصال كليًا. (2) إعادة تحميل الصفحة إذا كان الخادم متجاوبًا حيث ينشط المعالج التالي في حال انقطاع الاتصال عن الجهاز أو عدم تجاوب الخادم بشكل صحيح. مثال توضيحي يُمكن معاينة الصفحة الاحتياطية في المثال والموضح لقطة منه أدناه. كما يُمكن الحصول على الشيفرة المصدرية الموافقة من المستودع Glitch. يُمكن، بعد الانتهاء من إنشاء الصفحة الاحتياطية لوضع عدم الاتصال، تحقيق إمكانية تثبيت التطبيق بإضافة بيان تطبيق الويب واختيار استراتيجية التثبيت. كما يُمكن، للسهولة، استخدام مكتبات Workbox.js والتي توفر الشيفرة اللازمة لإنشاء الصفحة الاحتياطية. ترجمة -وبتصرف- للمقال Create an offline fallback page للمؤلفين: Thomas Steiner و Pete LePage. اقرأ أيضًا ما هي تطبيقات الويب التقدمية ولماذا يجب على المصممين الاهتمام بها؟ استئناف رفع الملفات بعد فقدان الاتصال في جافاسكربت 3 أخطاء شائعة عند رفع الملفات باستخدام بروتوكول FTP وكيفية إصلاحها أنظمة التشغيل للمبرمجين

يُحدّد ملف بيان تطبيق الويب web app manifest مظهر وسلوك صفحات الويب التقدميّة PWA كما يجب أن يعرضها المتصفح بعد تثبيت التطبيق على سطح مكتب أو جوّال المستخدم، وهو عبارة عن ملف مكتوب بصيغة جيسون JSON. تدّعم معظم المتصفحات ملف بيان تطبيق الويب مثل Chrome و Edge و Firefox و UC Browser و Opera و Samsung أما المتصفح Safari فيوفر دعمًا جزئيًا فقط. إنشاء ملف بيان تطبيق الويب يُمكن تسمية ملف بيان الويب بأي اسم، إلا أن الشائع تسميته بـ manifest.json ووضعه في الجذر (المجلّد الأعلى لموقع الويب). تنص التوصيات القياسية على وجوب استخدام اللاحقة webmanifest لاسم الملف، إلا أن اللاحقة json يُمكن أن تُستخدم أيضًا لاسيما أنها مألوفة لجميع المطورين. نٌبين فيما يلي مثالًا عن محتوى بيان الويب: { "short_name": "Weather", "name": "Weather: Do I need an umbrella?", "icons": [ { "src": "/images/icons-192.png", "type": "image/png", "sizes": "192x192" }, { "src": "/images/icons-512.png", "type": "image/png", "sizes": "512x512" } ], "start_url": "/?source=pwa", "background_color": "#3367D6", "display": "standalone", "scope": "/", "theme_color": "#3367D6", "shortcuts": [ { "name": "How's weather today?", "short_name": "Today", "description": "View weather information for today", "url": "/today?source=pwa", "icons": [{ "src": "/images/today.png", "sizes": "192x192" }] }, { "name": "How's weather tomorrow?", "short_name": "Tomorrow", "description": "View weather information for tomorrow", "url": "/tomorrow?source=pwa", "icons": [{ "src": "/images/tomorrow.png", "sizes": "192x192" }] } ], "description": "Weather forecast information", "screenshots": [ { "src": "/images/screenshot1.png", "type": "image/png", "sizes": "540x720" }, { "src": "/images/screenshot2.jpg", "type": "image/jpg", "sizes": "540x720" } ] } أهم خصائص ملف بيان الويب سنشرح أهم الخصائص التي يحويها ملف بيان الويب والتي عليك ضبطها لتطبيقك. الاسم القصير short_name و/أو الاسم name يجب تضمين، على الأقل، إحدى الخاصيتين: الاسم القصير short_name أو الاسم name. وفي حال توفر كلتيهما يُستخدم الاسم القصير في شاشة المستخدم الرئيسية home screen وفي مُشغّل التطبيق launcher وفي أي مكان لا تتوفر فيه المساحة الكافية لعرض الاسم كاملًا؛ أما الاسم فيُستخدم عند تثبيت التطبيق. الأيقونات icons يُمكن تحديد مجموعة من الأيقونات ليعرضها المتصفح على الشاشة الرئيسية home screen وعلى مُشغّل التطبيق launcher وعلى مُبدّل المهام task switcher وعلى شاشة البداية splash screen وغيرها، بعد أن يقوم المستخدم بتثبيت صفحات الويب التقدميّة. تكون قيمة خاصية الأيقونات icons مصفوفة من العناصر، يحوي كل عنصر منها خاصية المصدر src وخاصية القياسات sizes وخاصية نوع الصورة type. يجب إضافة "purpose": "any maskable" إلى خاصية الأيقونة icon في حال الحاجة لاستخدام الأيقونات المقنّعة maskable icons والتي تُدعى أيضًا بالأيقونات المتكيفة في أندرويد. يتطلب استخدام المتصفح توفير أيقونات بقياس 192x192 بكسل وبقياس 512×512 بكسل على الأقل. إذا توفر هذان القياسان فقط سيقوم المتصفح Chrome بتحجيم الأيقونات لتتناسب مع الجهاز المستخدم. في حال أردت الوصول لكمال الإظهار pixel-perfection فعليك توفير أيقونات بقياسات من مضاعفات 48dp. عنوان بدء التطبيق start_url توجه الخاصية المطلوبة start_url المتصفح إلى عنوان أو رابط الصفحة التي يجب أن يبدأ منها التطبيق عند تشغيله، وتمنع التطبيق من البدء من الصفحة التي يتصفحها المستخدم عند إضافة التطبيق لشاشته الرئيسية. توجه الخاصية start_url المستخدم مباشرًة إلى التطبيق عوضًا عن صفحة الهبوط landing page لمنتج ما. يجب دومًا التفكير بما يريد المستخدم أن يقوم به حال فتح التطبيق ومن ثم وضعه في المكان المناسب. لون الخلفية backgroud_color تُستخدم خاصية لون الخلفية لشاشة البداية splash screen عند تشغيل التطبيق لأول مرة على الجوّال. العرض display يُمكن تخصيص واجهات المستخدم عند تشغيل التطبيق على المتصفح مثل إخفاء شريط العنوان للمتصفح Chrome، كما يُمكن أيضًا التشغيل بوضعية ملء الشاشة لحالة الألعاب مثلًا. يُبين الجدول التالي بعض قيم هذه الخاصية: ملء الشاشة fullscreen فتح تطبيق الويب دون أي واجهة متصفح متاحة للمستخدم وشغل مساحة العرض المتاحة بالكامل. مستقل standalone فتح تطبيق الويب ليبدو وكأنه تطبيق مستقل. يعمل التطبيق في نافذته الخاصة المنفصلة عن المتصفح والذي تُخفى عناصره القياسية مثل شريط العناوين. الحد الأدنى من الواجهة minimal-ui يشبه هذا الوضع الوضع المستقل السابق إلا أنه يوفر للمستخدم مجموعة صغيرة من عناصر التنقل (مثل الرجوع back وإعادة التحميل reload). متصفح browser يتيح هذا الوضع تجربة استخدام متصفح تمامًا. تجاوز العرض display_override تُحدّد خاصية العرض display في ملف بيان تطبيق الويب وضع العرض كما هو موضح أعلاه. ليس مطلوبًا من جميع المتصفحات أن توفر كل أوضاع العرض السابقة إلا أن عليها أن تدعم السلسلة الاحتياطية وفق المواصفات المحدّدة spec-defined fallback chain أي التسلسل: ("ملء الشاشة" fullscreen← "مستقل" standalone← "الحد الأدنى من الواجهة" minimal-ui← "المتصفح "browser) والتي تُحتّم على المتصفح في حال عدم إمكانية دعمه لوضع معين أن يوفر الوضع التالي له في السلسلة. يُمكن أن يؤدي هذا السلوك غير المرن لبعض المشاكل في حالات نادرة جدًا كعدم استطاعة المطور أن يطلب وضع الحد الأدنى minimal-ui دون العودة بشكل قسري إلى وضع المتصفح browser وذلك إذا كان وضع الحد الأدنى غير مدعوم أصلًا. يُمكن أن يؤدي هذا السلوك أيضًا إلى مشكلة عدم القدرة على تضمين أوضاع عرض جديدة متوافقة مع الإصدارات السابقة، مثلًا: لا يُمكن التوافق مع وضع التبويب tabbed application mode غير الموجود في السلسلة الاحتياطية. تحل خاصية "تجاوز العرض" display_override جميع هذه المشاكل حيث يعتمد المتصفح هذه الخاصية قبل خاصية العرض display. توضع قيمة هذه الخاصية على شكل تسلسل مرتب من السلاسل النصية وبحيث يُطبّق أول عرض منها مدعوم من قبل المتصفح، وفي حال عدم وجود أي عرض مدعوم يعود المتصفح إلى خاصية العرض display. تكون السلسلة الاحتياطية في المثال التالي كما يلي (مع ملاحظة أن تفاصيل الوضع window-control-overlay خارج إطار هذه المقالة): وضع تراكب عناصر النافذة window-control-overlay (أولًا ننظر إلى الخاصية display_override). وضع الحد الأدنى من الواجهة minimal-ui. الوضع المستقل standalone (إذا استُنفذت كل الأوضاع في display_override نعود إلى الخاصية display). وضع الحد الأدنى من الواجهة minimal-ui (نعود في النهاية للسلسلة الاحتياطية للخاصية display). وضع المتصفح browser. { "display_override": ["window-control-overlay", "minimal-ui"], "display": "standalone", } لا يقوم المتصفح باستخدام الخاصية display_override ما لم تكن الخاصية display موجودة. النطاق scope يُحدّد النطاق scope عناوين URLs الصفحات التي يعتبرها المتصفح واقعة ضمن التطبيق وتُستخدم لمعرفة وقت مغادرة المستخدم لهذا التطبيق. يتحكم النطاق ببنية هذه المحدِّدات والتي تتضمن جميع نقاط الدخول والخروج للتطبيق. بالطبع، يجب أن يكون رابط URL للبداية start_url ضمن محدِّدات النطاق هذه. تحذير: في حال نقر المستخدم لأحد روابط التطبيق الذي يُخرجه من النطاق، فسيُفتح الرابط للعرض ضمن نافذة صفحات الويب التقدميّة الحالية. إذا كان المطلوب فتح الرابط ضمن تبويب جديد للمتصفح فيجب إضافة "target="_blank لوسم الرابط <a>. تُفتح مثل هذه الروابط في أندرويد بتبويب مخصص للمتصفح Chrome Custom Tab. يجب أخذ الملاحظات التالية حول النطاق scope بعين الاعتبار: في حال عدم تحديد النطاق scope في ملف بيان الويب، فسيكون النطاق الافتراضي هو المجلد الذي يحوي ملف بيان الويب. يُمكن أن تُحدّد قيمة النطاق مسارًا نسبيًا (/..) أو أي مسار لمستوى أعلى (/) مما يسمح بتغطية أكبر للتنقلات في التطبيق. يجب أن يكون رابط URL للبداية start_url ضمن محدِّدات النطاق scope. يكون رابط URL للبداية start_url نسبي للمسار المُعرّف في النطاق scope. إذا ابتدأ start_url بالمحرف / فسيكون دومًا الجذر للبداية. لون النمط theme_color يُحدّد لون النمط theme_color لون شريط الأدوات، وقد يُستخدم في عرض التطبيق ضمن محوّل المهام task switchers. يجب أن يُطابق لون النمط اللون المحدّد في السمة meta في ترويسة الصفحة. بدءًا من نسخ المتصفحات Chromium 93 و Safari 15، يُمكن ضبط لون النمط باستخدام استعلام وسائط media query للخاصية media في السمة meta وباعتماد أول لون مطابق. يُمكن مثلًا تحديد لون ما للوضع الساطع وآخر للوضع الداكن. لايُمكن، حتى وقت كتابة هذه المقالة، تحديد هذا السلوك في ملف بيان الويب (يُمكنك العودة لمناقشة هذه المشكلة في w3c/manifest#975 GitHub issue) <meta name="theme-color" media="(prefers-color-scheme: light)" content="white"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="black"> الاختصارات shortcuts تسمح هذه الخاصية بتعريف مجموعة من الاختصارات للمهام الأساسية للتطبيق وهي عبارة عن مصفوفة يكون كل عنصر فيها من النوع "كائن اختصار" app shortcut. يُعرّف الكائن باستخدام قاموس من الأزواج مفتاح/قيمة ويجب أن يحوي على الأقل المفتاح name والمفتاح url. الوصف description تشرح هذه الخاصية الهدف من التطبيق. اللقطات screenshots تكون قيمة هذه الخاصية مصفوفة من كائنات الصور لبعض لقطات سيناريوهات الاستخدام الشائعة للتطبيق. يجب أن يتضمن كل كائن خاصية المصدر src والقياسات sizes و النوع type. يجب أن تحترم الصورة المعايير التالية في المتصفح Chrome: لا يقل قياس كل من العرض والارتفاع عن 320 بكسل ولا يزيد عن 3840 بكسل. لا يزيد البعد الأكبر عن 2.3 ضعف البعد الأقل. لجميع اللقطات نفس نسبة الطول إلى العرض aspect ratio. تنسيقات الصور JPEG أو PNG فقط. إضافة ملف بيان الويب إلى صفحات التطبيق يُمكن، بعد الانتهاء من إنشاء ملف بيان الويب، إضافة الوسم <link> لجميع صفحات الويب التقدميّة للتطبيق. مثلًا: <link rel="manifest" href="/manifest.json"> اختبار ملف البيان يُمكن استخدام جزء البيان Manifest في لوحة التطبيق Application من أدوات التطوير DevTools في المتصفح Chrome للتحقق من إعداد ملف البيان بشكل صحيح. يسمح جزء البيان Manifest بمعاينة معظم خصائص ملف البيان بشكل مرئي، ويُسهّل التحقق من تحميل جميع الصور بشكل صحيح. شاشة البدء على الجوال قد يستغرق تشغيل التطبيق، لا سيما التشغيل الأول، بعض الوقت. يعرض المتصفح شاشة البداية Splash screen حتى ظهور الواجهة الأولى للتطبيق منعًا من إظهار شاشة بيضاء قد توحي للمستخدم بوجود مشكلة ما في التطبيق. يقوم المتصفح بإنشاء شاشة البداية آليًا معتمدًا على خصائص ملف البيان ولا سيما: الاسم name. لون الخلفية background_color. الأيقونات icons. يجب أن يكون لون الخلفية background_color نفس لون صفحة التحميل لتوفير انتقال سلس من شاشة البداية إلى واجهة التطبيق الأولى. يختار المتصفح Chrome الأيقونة الأنسب لدقة الجهاز. يُمكن أن يكون توفير أيقونات بقياس 193 بكسل و512 بكسل كافيًا في معظم الحالات، إلا أن توفير أيقونات إضافية بقياسات مختلفة يوصل لكمال الإظهار بشكل عام. ترجمة -وبتصرف- للمقال Add a web app manifest للمؤلفين: Pete LePage و François Beaufort و Thomas Steiner. اقرأ أيضًا مدخل إلى تطبيقات الويب التقدمية PWA ما هي تطبيقات الويب التقدمية ولماذا يجب على المصممين الاهتمام بها؟ صيغة JSON وتوابعها في جافاسكربت صيغة JSON وXML في PHP