الوقت الفعلي، العمل دون اتصال، الشاشات القديمة: كيف تم بناء ذلك

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

تعمل Smart-Signage في الاتجاه المعاكس. تحافظ المنصة على قناة دائمة نحو كل شاشة، عبر Server-Sent Events، وتدفع إليها الحدث لحظة وقوعه. تُعدّلون قائمة تشغيل أو جدولة: ينطلق التعديل فورًا وتطبّقه الشاشة في ثوانٍ معدودة. لا توجد دورة تحديث يجب انتظارها، ولا شيء يتنقل ما دام لا شيء يتحرك.

يُلزم هذا الاختيار البنية التحتية. يجب الحفاظ على عدد كبير من الاتصالات مفتوحة بشكل دائم، وهو ما لا يمثّل النظام الافتراضي الذي يُضبط عليه خادم الويب عادةً. تم اختيار وسيط الشبكة العكسي Caddy خصيصًا لصموده أمام هذه الاتصالات الطويلة.

تعمل القناة في الاتجاهين، وهذا ما يجعل الإشراف صادقًا:

• تُصدر كل شاشة نبضة منتظمة، تشير إلى أنها حية؛
• تعرض المنصة الحالة الفعلية للأسطول، شاشة بشاشة: متصلة، صامتة، وما تبثّه كل واحدة في تلك اللحظة؛
• تصبح الشاشة التي تتوقف عن الإرسال مرئية فورًا، دون أن يضطر أحد للتنقل إلى الموقع للتأكد من ذلك.

الشاشة التي تعتمد على الشبكة هي شاشة سوداء محتملة. لذلك يتم تخزين المحتويات محليًا في ذاكرة تخزين مؤقت بواسطة Service Worker: إذا انقطع الاتصال، يستمر البث بما هو موجود بالفعل في الموقع، وتُعيد الشاشة المزامنة فور عودة الشبكة. لا حاجة لأي تدخل ميداني.

يفرض قيد ميداني هنا احترازًا يستحق أن يُذكر: تضع WebView الخاصة بنظام Android سقفًا لحجم الملفات التي تقبل الاحتفاظ بها في ذاكرة التخزين المؤقت. الفيديو الثقيل الذي يُحمَّل دفعة واحدة يتجاوز هذا السقف ولن يُخزَّن مؤقتًا أبدًا، وبالتالي لن يكون متاحًا دون اتصال أبدًا. لهذا السبب تُقرأ الوسائط الثقيلة على شكل مقاطع متتالية بدلًا من دفعة واحدة. هذا التقسيم هو ما يجعل وضع العمل دون اتصال موثوقًا فعليًا على هذا النوع من الأجهزة.

المخاطرة الثانية ليست عطل الشبكة، بل التحديث نفسه. يعمل مشرف مكتوب بلغة JavaScript ES5 قبل تشغيل الكود التطبيقي ويتحكم في Service Worker. إذا لم تكن ثلاث عمليات تشغيل متتالية سليمة، تعود الشاشة تلقائيًا إلى آخر نسخة سليمة معروفة. كما يحدّ صمام أمان عمليات إعادة التحميل التلقائية إلى مرتين في الدقيقة، لاستبعاد سيناريو الشاشة التي تومض بشكل متكرر. النتيجة الملموسة: النشر الفاشل لا يعطّل أسطولًا مثبَّتًا، بل يُصلح نفسه بنفسه.

هذه هي النقطة التي نتنازل عنها أقل ما يمكن: البرمجية هي التي تتكيّف مع العتاد القائم، وليس العكس. يُسلَّم الـplayer في نسختين مشتقتين من الشيفافة المصدرية نفسها، نسخة حديثة للأجهزة الحديثة ونسخة ES5 للمتصفحات المدمجة القديمة. الوظائف نفسها، المنتج نفسه؛ ما يتغيّر هو طريقة تجميع الكود وتقديمه.

الأسطول الفعلي للعرض الديناميكي ليس أسطولًا حديثًا. تحمل شاشات كثيرة رُكِّبت قبل خمس أو ثماني أو عشر سنوات متصفحًا مجمَّدًا عند نسخته الأصلية، لن يُحدِّثه أحد أبدًا. Chrome 44 والنسخ اللاحقة مدعومة. تحمل LG webOS 4 محركًا مكافئًا لـChromium 53، لا يعرف CSS Grid: تتلقى هذه الأجهزة تخطيطات احتياطية مكتوبة خصيصًا لها، حتى يثبت التركيب بدلًا من التراكم عشوائيًا.

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

ما هو مدعوم:

• الويب، على أي جهاز مزوَّد بمتصفح؛
• Android، بتطبيق مخصص، بما في ذلك على WebView القديمة؛
• LG webOS، بما في ذلك الأجيال القديمة؛
• لا يُفرض أي عتاد احتكاري: اختيار مورّد الشاشات يبقى لكم.

تتم الاستضافة لدى OVH، على خوادم تقع داخل الاتحاد الأوروبي. لا تُستضاف أي بيانات خارج الاتحاد الأوروبي، والامتثال لـGDPR موثَّق.

على مستوى الشبكة، لا تحتاج الشاشة سوى إلى وصول صادر نحو المنصة. القناة الدائمة هي اتصال عادي تبادر به الشاشة نفسها: لا يوجد تدفق وارد يجب السماح به نحو مقراتكم، ولا خادم يجب تثبيته على بنيتكم التحتية.

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