Waarom app-updates soms substraatthema's doorbreken

Substratumthema’s worden vaak negatief beïnvloed door de frequentie van updates van apps van derden, vooral wanneer thema’s zich moeten aanpassen aan slecht gecodeerde apps

Het komt vaak voor: gebruikers passen Substratum-thema's toe op hun telefoons en updaten later Slack, WhatsApp, Instagram of een aantal andere apps uit de Play Store. Plots kunnen ze die apps niet eens openen totdat hun thema-overlays zijn uitgeschakeld. Veel nieuwere Substratum-gebruikers hebben sinds de release van dit probleem hun ervaringen met dit probleem geuit rootless Substratum-thema voor Android Oreo.

Soms wordt het probleem opgelost door de overlays in Substratum opnieuw op te bouwen, maar soms werkt het pas als de thema-ontwikkelaar het thema opnieuw heeft bijgewerkt. In het laatste geval zitten gebruikers vast aan het gebruik van de getroffen apps in hun voorraadstatus zonder thema. Het hoeft geen betoog dat dit voor velen een frustrerende ervaring kan zijn.

Het probleem is meestal het resultaat van een combinatie van factoren: een slecht gecodeerde app van derden, frequente updates van genoemde apps die feitelijk meer problemen veroorzaken dan ze oplossen, en beperkingen in de Overlay Manager Service (OMS) kader. Ik sprak met een paar bekende thema's die waardevolle inzichten in het probleem gaven:

Jeremy Beck, wie maakt de Spectrum Substraatthema, en David Wilson van Overheersing roem.

Volgens deze Substratum-getrouwen behoren enkele van de ergste overtreders op het gebied van slecht gecodeerde apps tot de meest populaire. WhatsApp, Instagram, Slack, Facebook en Telegram zijn voorbeelden die deze Substratum-thema’s ons aanhaalden toen ze dit probleem vertelden. David zei zelfs dat het voorbeelden zijn van ‘vreselijk, walgelijk, verachtelijk gecodeerde’ apps, die op kleurrijke wijze de frustratie Substratum-thema-ontwikkelaars worden geconfronteerd wanneer ze hun gebruikers tevreden houden terwijl ze proberen hun Android-ervaringen te verenigen rond een gemeenschappelijk thema.

Een “verachtelijk gecodeerde” app kan bijvoorbeeld de tekstkleur koppelen aan de achtergrondkleur in het bestand Colors.xml. Als een thema in dit voorbeeld de achtergrondkleur wijzigt zodat deze niet langer wit is, wordt de tekst ook gewijzigd en kan deze moeilijker (of zelfs onmogelijk) leesbaar worden gemaakt. Bijgevolg zal het thema zijn eigen lay-out-XML-bestanden aan zijn thema-overlays moeten toevoegen om afzonderlijke kleuren voor tekst en achtergrond op te geven.

Het voorbehoud is dat de nieuwe XML-bestanden ook elk afzonderlijk codeteken uit de gelijknamige bestanden van de originele app er gaat dus geen functionaliteit verloren. Dit komt omdat OMS leest uit het vervangende bestand, terwijl de app zelf alles probeert te doen wat het originele bestand toestond. Wanneer de app is bijgewerkt en zelfs de kleinste niet-gerelateerde verandering wordt aangebracht naar de originele XML-bestanden, zullen de overlays niet werken.

Hier is hoe David het uitlegt:

Wat deze belachelijke ‘ontwikkelaars’ (ik gebruik die term losjes bij het beschrijven van deze clowns) doen, is dat ze items gebruiken in layout-xml's die het voor ons moeilijk maken om de app op de juiste manier te thematiseren zonder die layout-xml's aan onze overlay toe te voegen.

Om je een voorbeeld te geven: laten we WhatsApp nemen en naar een item in hun /res/values/colors.xml kijken, namelijk #ffffffff

Ze gebruiken @color/white voor zowel tekstkleuren als achtergrondkleuren in hun hele app. Dit betekent dat als een thema de kleur "wit" wil veranderen in iets donkers om de achtergrond donker te maken, dit ook veel tekst donker zal maken, wat erg slecht is.

Om deze tekortkoming te omzeilen, zullen thema's de lay-out-XML's aan hun overlay toevoegen en de tekstkleur of de achtergrondkleur of beide wijzigen. iets als android: background="@color/white" naar iets als android: background="@*android: color/background_dark" om de achtergrond donker te maken.

Dit is geweldig en maakt de achtergrond donker, maar de layout-xml moet alles bevatten wat de originele layout-xml heeft, wat kan variëren van een paar regels tot meer dan 100 regels. Binnen die regels van de lay-out-XML kunnen zich veel verschillende bronnen bevinden die zich in de originele code van de app bevinden en die worden aangeroepen, zoals ID's, dimensies, tekenreeksen, stijlen, enz.

Hierin schuilt nu het probleem... als een thema een overlay maakt die past bij WhatsApp 2.17.323 en WhatsApp-updates naar 2.17.351 (bijvoorbeeld), dan als WhatsApp in hun oneindige wijsheid besluit te veranderen de naam van bijvoorbeeld een string die in de overlay zat die voor 2.17.323 was gemaakt en die string bestaat niet meer in 2.17.351, dan zal de overlay niet succesvol zijn bouwen.

Hetzelfde geldt voor alles binnen de overlay dat zich in code bevindt die een bron aanroept die zich in de app bevindt, als die specifieke bron was in de app waarvoor de overlay is ontworpen en als de app vervolgens wordt bijgewerkt en de bron niet meer in de code van de app staat, wordt de overlay niet gecompileerd.

Dit is slechts één voorbeeld van het kat-en-muisspel van afwisselende app- en thema-updates waarmee Substratum-thema’s worden geconfronteerd. Wanneer thema's een groot aantal apps van derden ondersteunen, moeten ze dit spel bij elke thema-update meerdere keren vermenigvuldigen. Het is een eindeloze cyclus van het bijhouden van meerdere ondersteunde apps en hopen dat gefrustreerde gebruikers hun thema's tussen updates niet slecht beoordelen omdat Slack (voor een ander voorbeeld) drie updates naar hun app heeft gepusht in de twee weken sinds de laatste update van hun favoriete Slack-ondersteunende app thema.

Wat kun je eraan doen?

Persoonlijk wacht ik meestal op een update naar mijn favoriete thema's voordat ik de apps die ik gebruik update die een thema hebben. Dat gezegd hebbende, heeft niet elk thema de tijd om voortdurend updates te pushen om op de hoogte te blijven van deze app-updates, dus uw kilometerstand kan variëren. Als je het echt niet kunt verdragen om een ​​app zonder thema te gebruiken, dan is een paar uur of dagen wachten misschien niet zo'n groot probleem voor jou. Als dit echter een dealbreaker is, wil je misschien alleen systeemapplicaties thematiseren die waarschijnlijk niet snel zullen veranderen (zoals SystemUI of het Android Framework).

Erken gewoon dat het probleem niet te wijten is aan Substratum zelf of Substratum-thema's, en geef de thema-ontwikkelaar alstublieft niet de schuld als er iets misgaat. Dit is de reden waarom thema-engines op OEM-smaken van Android, zoals EMUI, Samsung Experience of LG UX, je niet toestaan ​​om meer te thematiseren dan systeem-apps en de systeem-UI zelf. Om te kunnen genieten van het aanpassingsniveau dat Substratum biedt, is de wisselwerking dat je misschien even moet wachten voordat je kunt genieten van de nieuwste app-update.