افرض تحديث التطبيق أو فعّل وضع الصيانة دون نشر إصدار جديد

موقفان يواجههما كل فريق تطبيقات جوال عاجلاً أو آجلاً:

• إصدار قديم يجب أن يختفي. يتعطل مع الـ API الجديدة، أو فيه ثغرة أمنية، أو يحسب سعراً خاطئاً. نشرتَ الإصلاح، لكن المتاجر لا تُلزم أحداً بالتحديث، وبضعة آلاف ما زالوا على الإصدار 1.8.
• الخادم يحتاج أن يتوقف. ترحيل قاعدة بيانات، أو عطل عند مزوّد خدمة، أو إطلاق تريد تأجيله حتى التاسعة صباحاً. وفي الأثناء تستمر التطبيقات في مناداة الـ API وتعرض لمستخدميها سيلاً من الأخطاء.

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

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

كيف تصل القواعد إلى التطبيقات

تُقيَّم القواعد على خوادم ليركس. يسأل التطبيق "ما الذي ينطبق عليّ؟" فيتلقى إجابة لمنصته وإصداره ورقم بنائه وبيئته ودولته تحديداً.

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

والإجابات التي لم تتغير لا تكلّف شيئاً تقريباً: يرسل التطبيق ما لديه، فيرد ليركس بأنه "لم يتغير".

قواعد التحديث: اقتراح، توصية، إلزام

لكل منصة قاعدة خاصة بها لكل بيئة (prod ما لم تختر غيرها). ويمكن أن تحتوي القاعدة على:

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

ويفحصها ليركس بهذا الترتيب: الإصدار المحظور إلزامي، والأقدم من الحد الأدنى إلزامي، والأقدم من الأحدث اختياري أو موصى به (أو إلزامي بعد فوات الموعد)، وإلا فلا يُعرض شيء. وتُقارن الإصدارات كأرقام جزءاً جزءاً، فالإصدار 1.10.0 أحدث من 1.9.2.

حجب المستخدمين قرار جاد، لذا تعرض لوحة التحكم أثره أثناء الكتابة، مثل "This will block 1,240 devices (31%)"، وتطلب منك التأكيد إذا كانت القاعدة ستوقف نصف أجهزتك النشطة أو تضع حداً أدنى أعلى من كل إصدار مستخدم فعلياً. وتعرض قائمة Versions in the wild ما يستخدمه الناس حقاً.

يفتح زر Update صفحة المتجر: Google Play حسب اسم الحزمة، أو App Store حسب معرّف التطبيق الذي تستطيع لوحة التحكم البحث عنه لك.

وضع الصيانة

الصيانة في تبويب Emergency. ولكل نافذة صيانة:

• نطاق: المنصات، والبيئة، وإصدارات بعينها أو الإصدارات الأقدم من إصدار ما، والدول؛
• عنوان ورسالة بالعربية والإنجليزية، ووقت "العودة المتوقعة" اختياري يُعرض بالمنطقة الزمنية للجهاز؛
• بداية: الآن، أو مجدولة حتى 30 يوماً مقدماً. تعلم الأجهزة بالنافذة المجدولة قبل بدئها بما يصل إلى 24 ساعة وتحتفظ بها لنفسها، فتبدأ في موعدها حتى على هاتف انقطع عن الشبكة؛
• نهاية: لكل نافذة نهاية، بعد 24 ساعة من البداية افتراضياً و7 أيام كحد أقصى، فلا تحبس نافذة منسية المستخدمين إلى الأبد. وترفعها الأجهزة بنفسها في موعدها حتى دون اتصال.

وميزتان تجعلان استخدامها في العجلة آمناً:

• قائمة سماح بمعرّفات مستخدمين أو أجهزة يُسمح لها بالمرور، لفريقك.
• Test on allow-listed devices only: تنطبق النافذة على أجهزتك أولاً. وحين تطمئن اضغط Go live، فيرى كل جهاز ضمن النطاق شاشة الصيانة خلال دقيقة.

يطلب تفعيل الصيانة سبباً وكتابة الاسم المختصر للمشروع، ويُسجَّل كل تغيير في History مع من أجراه. وزر Lift all ينهي كل نوافذ الصيانة ويوقف كل التحديثات الإلزامية بخطوة واحدة، للحظة التي تكتشف فيها أن القاعدة كانت خطأً.

داخل التطبيق

في Flutter يكون التحكم بالإصدارات مفعّلاً افتراضياً بمجرد إعداد lerix_flutter. لا عنصر واجهة تضيفه: تضع الحزمة شاشاتها فوق الـ navigator الرئيسي لتطبيقك.

Lerix.init(
  url: 'https://api.lerix.dev/v1/your-project-slug',
  apiKey: 'your-api-key',
  projectId: 'your-project-slug',
  appControl: const LerixAppControlOptions(
    enabled: true,  // false: no checks, no screens, no events
    ui: true,       // false: draw your own screens
  ),
  builder: () => runApp(const MyApp()),
);

الشاشات الجاهزة: صفحة صيانة بملء الشاشة مع زر Try again، وصفحة Update required بملء الشاشة، ونافذة حوار للتحديثات الاختيارية والموصى بها. وتأتي أزرارها بالعربية والإنجليزية، مع دعم الكتابة من اليمين إلى اليسار.

وعلى أندرويد يمكنك أن تخطو خطوة أبعد: أضِف حزمة lerix_app_update فيفتح التحديث الإلزامي التحديث داخل التطبيق من Google Play بدل صفحة المتجر، للتطبيقات المثبّتة من Play. والتطبيقات التي لا تستخدم Play لا تحمل تلك المكتبة.

وعلى الويب اضبط release على الإصدار الذي تنشره. لا متجر هناك، فيعيد زر Update تحميل الصفحة:

import { Lerix } from '@lerix-dev/lerix-core';

await Lerix.initialize({
  apiKey: 'your-api-key',
  projectId: 'your-project-slug',
  release: '1.4.0', // update rules need it; use numbers, not a commit hash
});

شاشاتك الخاصة

اضبط ui: false وارسمها بنفسك. تستمر الحزمة في الجلب والحفظ والتطبيق، بما في ذلك قواعد العمل دون اتصال؛ الرسم وحده عليك:

ValueListenableBuilder<LerixAppControlState>(
  valueListenable: Lerix.appControl,
  builder: (context, state, _) {
    final maintenance = state.maintenance;
    final update = state.update;
    if (maintenance != null) {
      return MaintenanceScreen(
        title: maintenance.title,
        message: maintenance.message,
        onRetry: () => Lerix.appControl.refresh(),
      );
    }
    if (update != null && update.state == LerixUpdateState.required) {
      return ForceUpdateScreen(
        message: update.message,
        onUpdate: () => Lerix.appControl.openStore(),
      );
    }
    return child;
  },
);

وفي React الشيء نفسه عبر الـ hook ‏useLerixAppControl()، وفي Angular عبر LerixAppControlService.

هل حدّث الناس فعلاً؟

تسجّل الحزمة الأحداث $update_prompt_shown و$update_prompt_action (تحديث أو لاحقاً أو تخطٍّ) و$maintenance_shown. ومع تغيّرات إصدار التطبيق تكوّن مساراً تحويلياً في Analytics ← Funnels: كم شخصاً رأى التنبيه، وضغط Update، ووصل إلى الإصدار الجديد. ويعرض مقياس Propagation في تبويب Emergency عدد الأجهزة النشطة التي وصلها آخر تغيير أجريته.

حدود تستحق المعرفة

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

قائمة مراجعة

1. اضبط أحدث إصدار لكل منصة مع كل إصدار تنشره، ليتلقى أصحاب الإصدارات الأقدم تنبيهاً لطيفاً.
2. استخدم الحد الأدنى أو الإصدارات المحظورة فقط للإصدارات المعطوبة فعلاً.
3. فضّل الموعد النهائي على الحجب الفوري حين يتسع الوقت: موصى به أولاً، ثم إلزامي.
4. للصيانة: جدولها، واختبرها على أجهزتك، ثم اضغط Go live.
5. تذكّر Lift all دائماً. إنه زر التراجع.