Vývoj pro Android Automotive OS? Jsme připraveni.
PŘEČÍST ČLÁNEK
Jednu z našich Androidích aplikací jsme začátkem tohoto roku začali přepisovat do Jetpack Compose. Proč to děláme a přiděláváme si zbytečně práci? Chceme být sexy? Jít s programovacími trendy? Mít jako firma lepší pozici při hledání nových kandidátů? Anebo alespoň - když se partnerka doma zmíní, že si zase koupila nové boty, chceme mít možnost opáčit: “Lásko, to je krásné, já si zase updatoval paging libku a vyzkoušel novou implementaci map v Compose.”?
To asi nebudou ty pravé důvody, byť na nich něco bude. V tomto článku bych rád situaci přepsání aplikace do nového UI frameworku více rozebral a podíval se na tento problém z více úhlů za využití příkladu jedné z aplikací, kde přepis aktuálně řešíme.
Jako vývojáři moc dobře víme, v jak dynamickém prostředí se pohybujeme. To už ale nemusí být tak úplně zřejmé pro ty, kteří projekty řídí. Jedním z našich úkolů (tedy spíše asi těch seniornějších z nás) je proto tuto skutečnost pravidelně, trpělivě a postupně klientovi dávkovat. Jak v zájmu životnosti projektu, tak našeho duševního zdraví a tím pádem rychlosti vývoje.
Nové technologie totiž přicházejí kolikrát mnohem rychleji než módní trendy. To by samo o sobě nebylo zas až tak kritické, ale bohužel tím staré technologie (starší než ty zbrusu nové) rychle přestávají být od autorů udržované a aktualizované. O kompatibilitě s ostatními knihovnami a bezpečnostních rizicích ani nemluvě. Na vývojáře je tak kladen obrovský tlak - balancovat vývoj nových featur a snažit se aktualizovat již použité knihovny tak, aby nevznikal přílišný technický dluh.
Ti z vás, kteří četli Clean Code od strýčka Boba si určitě vzpomenou na křivku technického dluhu. Pro ty kteří knihu nečetli velice krátce: s rostoucím technickým dluhem rostou náklady na změnu exponenciálně. Přepsat tedy XML soubory do Compose je prostě “jen” další odstraňování technického dluhu. Jak si ale ukážeme, není to úplně triviální záležitost, a to z mnoha důvodů.
V našem případě řešíme středně až více komplexní mobilní aplikaci s mnoha zajímavými funkcemi (pagingové seznamy, volání platebních bran, volání bankovní identity, volání jiných aplikací, deeplinky), API endpointy a s dost přiohnutými UI prvky. Je tedy potřeba si uvědomit, že přepis celé aplikace není (a nebude) otázkou jednoho merge requestu, ale během na dlouhou trať. Z důvodu omezených kapacit je postupný přepis navíc jediné řešení, přijatelné jak pro klienta, tak pro vývojáře. A samozřejmě - je potřeba počkat na vhodný moment…
Interně jsme se proto předem domluvili na tom, že v první fázi budeme zcela nové features psát v Compose a staré necháme tak, jak jsou. Ze začátku (než opadne rozvířený prach po prvotních Compose záškytech) je alespoň budeme čistit od “balastu” utility metod a mazat, co půjde v rámci kontextuálních změn. Až poté budeme pomýšlet na samotnou extrakci a přepsání starších částí kódu do Compose.
Jakmile jsme dostali zelenou ke tvorbě zbrusu nové feature, mohli jsme začít:
Navigace do nových Compose features nebyla jediným kompromisním dočasným řešením, ke kterému jsme přistoupili. Namátkou bych rád uvedl pár dalších konkrétních příkladů, se kterými jsme se museli naučit žít:
Obecná kuchařka pro to, jak přistupovat k přepisu aplikace do zcela nového UI frameworku nejspíš neexistuje. Jelikož programování je činnost kreativní, každá aplikace může být psána jinak, např. v jiných architekturách, v jiných programovacích jazycích, používat jiné knihovny třetích stran, které ale mohou poskytovat stejnou funkcionalitu. A naopak, už jenom odlišné verze totožných knihoven stačí k tomu, abychom se na přepis mohli dívat jinak.
Co si tedy z tohoto článku odnést?
Přepis zkrátka není jednoduchá věc a obvykle má od ideálního scénáře poměrně daleko. I přesto doufám, že podobné eskapády u vás na pořadech dnů opravdu jsou - znamená to, že vaše codebase je zdravá a klient vaši snahu o její zachování v dobrém stavu chápe a podporuje. A to je podle mě zdravý byznys.
