Субстратните теми често се влияят неблагоприятно от честотата на актуализации на приложения на трети страни, особено когато темите трябва да се адаптират към лошо кодираните
Това е често срещано явление: потребителите прилагат теми на Substratum към своите телефони, след което по-късно актуализират Slack, WhatsApp, Instagram или произволен брой други приложения от Play Store. Изведнъж те дори не могат да отворят тези приложения, докато техните наслагвания на теми не бъдат деактивирани. Много по-нови потребители на Substratum изразиха своя опит с този проблем още от пускането на Тема Substratum без root за Android Oreo.
Понякога повторното изграждане на наслагванията в Substratum решава проблема, но понякога няма да работи, докато разработчикът на темата не актуализира темата отново. В последния случай потребителите са блокирани и трябва да използват засегнатите приложения в техните безтематични, налични състояния. Излишно е да казвам, че това може да бъде разочароващо преживяване за мнозина.
Проблемът обикновено е резултат от комбинация от фактори: лошо кодирано приложение на трета страна, чести актуализации на споменати приложения, които всъщност причиняват повече проблеми, отколкото коригират, и ограничения в услугата Overlay Manager (OMS) рамка. Говорих с няколко добре познати теми, които предоставиха някои ценни прозрения по проблема: Джереми Бек, който прави Спектър Тема на субстрата и Дейвид Уилсън на Доминация слава.
Според тези непоколебими привърженици на Substratum някои от най-лошите нарушители в областта на лошо кодираните приложения са сред най-популярните. WhatsApp, Instagram, Slack, Facebook и Telegram са примери, които тези теми на Substratum ни цитираха, когато разказваха за този проблем. Всъщност Дейвид каза, че те са примери за „ужасно, отвратително, презряно кодирани“ приложения, което колоритно илюстрира разочарованието, с което се сблъскват разработчиците на Substratum теми, когато поддържат своите потребители щастливи, докато се опитват да обединят изживяванията си с Android около обща тема.
Например „презрително кодирано“ приложение може да свърже цвета на текста с цвета на фона в неговия файл colors.xml. Ако темата промени цвета на фона, така че вече да не е бял в този пример, текстът също ще бъде променен и може да стане по-труден (или дори невъзможен) за четене. Следователно тематизаторът ще трябва да добави свои собствени xml файлове с оформление към техните наслагвания на теми, за да посочи отделни цветове за текст и фон.
Уговорката е, че новите xml файлове също трябва да включват всеки един знак от кода от едноименните файлове на оригиналното приложение така че не се губи функционалност. Това е така, защото OMS чете от заместителя, файла на themer, докато самото приложение се опитва да направи всичко, което позволява оригиналният файл. Когато приложението се актуализира и се прави дори и най-малката несвързана промяна към оригиналните xml файлове, наслагванията няма да работят.
Ето как Дейвид го обяснява:
Това, което правят тези нелепи „разработчици“ (използвам този термин свободно, когато описвам тези клоуни) е, че използват елементи в оформление xml, което ни затруднява да тематираме правилно приложението, без да добавяме тези оформление xml в нашето наслагване.
За да ви дам пример, нека вземем WhatsApp и разгледаме елемент в техния /res/values/colors.xml, който е
#фффффффф Те използват @color/white както за цветовете на текста, така и за цветовете на фона в цялото си приложение. Това означава, че ако темистът иска да промени цвета на „бялото“ с нещо тъмно, за да направи фона си тъмен, тогава ще направи много текст също тъмен, което е много лошо.
За да заобиколят този недостатък, участниците в темата ще добавят xml оформлението в своето наслагване и ще променят или цвета на текста, или цвета на фона, или и двете от като нещо като android: background="@color/white" до нещо като android: background="@*android: color/background_dark", за да направи фона тъмен.
Сега това е страхотно и прави фона тъмен, но xml оформлението трябва да включва всичко в него, което има оригиналното xml оформление, което може да варира от няколко реда до над 100 реда. В тези редове на xml оформлението може да има много различни ресурси, които се намират в оригиналния код на приложението, които се извикват, като идентификатори, размери, низове, стилове и т.н.
Сега тук е проблемът... ако един тематик направи наслагване, за да отговаря на WhatsApp 2.17.323 и WhatsApp актуализира до 2.17.351 (например), тогава ако WhatsApp в своята безкрайна мъдрост реши да промени името на да речем низ, който е бил в наслагването, направено за 2.17.323 и този низ вече не съществува в 2.17.351, тогава наслагването няма да бъде успешно изграждане.
Същото важи за всичко в наслагването, което е във всеки код, който извиква ресурс, който е в рамките на приложението, ако този конкретен ресурс е в приложението, за което е проектирано наслагването и след това приложението се актуализира и ресурсът вече не е в кода на приложението, тогава наслагването няма да се компилира.
Това е само един пример за играта на котка и мишка на редуващи се актуализации на приложения и теми, пред които са изправени участниците в Substratum. Когато участниците в темата поддържат голям брой приложения на трети страни, те трябва да умножават тази игра няколко пъти с всяка актуализация на тема. Това е безкраен цикъл на поддържане на множество поддържани приложения и надежда, че разочарованите потребители няма да оценяват лошо темите си между актуализациите тъй като Slack (за друг пример) изпрати три актуализации на тяхното приложение през двете седмици след последната актуализация на любимата им поддръжка на Slack тема.
Какво можете да направите по въпроса?
Лично аз обикновено чакам за актуализирайте до любимите си теми, преди да актуализирам приложенията, които използвам които са тематични. Въпреки това, не всеки тематик има време постоянно да изпраща актуализации, за да бъде в крак с тези актуализации на приложенията, така че вашият пробег може да варира. Ако наистина не можете да използвате приложение в неговото безтематично състояние, тогава може би чакането на няколко часа или дни не е толкова голяма работа за вас. Ако обаче това е прекъсвач на сделката, тогава може би бихте искали да тематизирате само системни приложения, които е малко вероятно да се променят скоро (като SystemUI или Android Framework).
Просто признайте, че проблемът не е заради самия Substratum или темите на Substratum и моля, не обвинявайте разработчика на темата, когато нещо се обърка. Ето защо тематичните машини на OEM разновидности на Android, като EMUI, Samsung Experience или LG UX, не ви позволяват да темизирате повече от системни приложения и самия потребителски интерфейс на системата. За да се насладите на нивото на персонализиране, което предлага Substratum, компромисът е, че може да се наложи да изчакате малко, за да се насладите на последната актуализация на приложението.