لماذا تؤدي تحديثات التطبيقات في بعض الأحيان إلى تعطيل سمات الطبقة التحتية

إنه أمر شائع: يقوم المستخدمون بتطبيق سمات Substratum على هواتفهم ثم يقومون لاحقًا بتحديث Slack أو WhatsApp أو Instagram أو أي عدد من التطبيقات الأخرى من متجر Play. وفجأة، لم يتمكنوا حتى من فتح هذه التطبيقات حتى يتم تعطيل تراكبات السمات الخاصة بهم. لقد عبر الكثير من مستخدمي Substratum الجدد عن تجاربهم مع هذه المشكلة منذ إصدار سمات الطبقة التحتية بدون جذور لنظام Android Oreo.

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

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

جيريمي بيك، الذي يصنع نطاق موضوع الطبقة التحتية، و ديفيد ويلسون ل هيمنة شهرة.

وفقًا لهؤلاء المتعصبين في الطبقة التحتية، فإن بعضًا من أسوأ المجرمين في مجال التطبيقات سيئة الترميز هي من بين الأكثر شيوعًا. تعد WhatsApp وInstagram وSlack وFacebook وTelegram من الأمثلة التي ذكرها لنا أصحاب الطبقة التحتية عند سرد هذه المشكلة. في الواقع، قال ديفيد إنها أمثلة على تطبيقات "مُشفرة بشكل فظيع ومثير للاشمئزاز ومُشفرة بشكل حقير"، والتي توضح بشكل ملون الإحباط الذي يواجهه مطورو سمات Substratum عند إبقاء مستخدميهم سعداء أثناء محاولتهم توحيد تجارب Android الخاصة بهم حول موضوع مشترك.

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

التحذير هو أن ملفات xml الجديدة يجب أن تتضمن أيضًا كل حرف من التعليمات البرمجية من ملفات التطبيق الأصلية التي تحمل الاسم نفسه لذلك لا يتم فقدان أي وظيفة. وذلك لأن OMS يقرأ من ملف الموضوع البديل بينما يحاول التطبيق نفسه القيام بكل ما يسمح به الملف الأصلي. عندما يتم تحديث التطبيق و يتم إجراء حتى أدنى تغيير غير ذي صلة إلى ملفات xml الأصلية، ستفشل التراكبات في العمل.

وإليك كيف يشرح ديفيد ذلك:

ما يفعله هؤلاء "المطورون" السخيفون (أستخدم هذا المصطلح بشكل فضفاض عند وصف هؤلاء المهرجين) هو أنهم يستخدمون عناصر في تخطيط XML مما يجعل من الصعب علينا تصميم التطبيق بشكل صحيح دون إضافة تنسيق XML هذا إلى التراكب الخاص بنا.

لإعطائك مثالاً، لنأخذ تطبيق WhatsApp ونلقي نظرة على عنصر في /res/values/colors.xml وهو #ففففف

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

للتغلب على هذا النقص، سيقوم المصممون بإضافة ملفات XML للتخطيط إلى التراكب الخاص بهم وتغيير إما لون النص أو لون الخلفية أو كليهما من أن تكون شيئًا مثل Android: الخلفية = "@color/white" إلى شيء مثل android: الخلفية = "@* android: color/background_dark" لجعل الخلفية داكنة.

يعد هذا أمرًا رائعًا ويجعل الخلفية داكنة، لكن تخطيط XML يحتاج إلى تضمين كل ما يحتوي عليه تخطيط XML الأصلي والذي يمكن أن يختلف من بضعة أسطر إلى أكثر من 100 سطر. ضمن هذه السطور من تخطيط XML يمكن أن يكون هناك الكثير من الموارد المختلفة الموجودة داخل الكود الأصلي للتطبيق والتي يتم استدعاؤها مثل المعرفات والأبعاد والسلاسل والأنماط وما إلى ذلك.

والآن هنا تكمن المشكلة.. إذا قام أحد الأشخاص بعمل تراكب ليناسب WhatsApp 2.17.323 وتحديثات WhatsApp إلى 2.17.351 (على سبيل المثال)، إذا قرر WhatsApp بحكمته اللانهائية التغيير اسم سلسلة كانت موجودة في التراكب الذي تم إنشاؤه لـ 2.17.323 ولم تعد هذه السلسلة موجودة في 2.17.351، فلن ينجح التراكب يبني.

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

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

ماذا يمكنك أن تفعل بهذا الشأن؟

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

فقط عليك أن تدرك أن المشكلة ليست بسبب الطبقة التحتية نفسها أو سمات الطبقة التحتية، ويرجى عدم إلقاء اللوم على مطور السمات عندما يحدث خطأ ما. هذا هو السبب في أن محركات السمات الموجودة على نكهات OEM لنظام Android مثل EMUI أو Samsung Experience أو LG UX لا تسمح لك بوضع سمات أكثر من تطبيقات النظام وواجهة مستخدم النظام نفسها. للاستمتاع بمستوى التخصيص الذي توفره Substratum، تتمثل المقايضة في أنه قد يتعين عليك الانتظار لفترة قصيرة للاستمتاع بآخر تحديث للتطبيق.