Jak jsme rozšířili aplikaci MyŠkoda o podporu Wear OS

Myšlenka podporovat Wear OS

Mobilní aplikace MyŠkoda, hlavní B2C kanál pro komunikaci s majiteli a uživateli vozů Škoda, vzniká ve spolupráci Green:Code a Škoda Auto a stala se standardní součástí prodávaných vozů. Před několika lety byla kompletně přepsána do aktuálních technologií, jako jsou Kotlin, Jetpack Compose, Koin či Škoda Flow design systém. Cílem bylo zajistit vysokou kvalitu při dodržení clean architecture principů a pokročilé modularizace. Když pak ze Škoda Auto přišla myšlenka podporovat i hodinky s operačním systémem Wear OS, tak jsme se namísto vytvoření úplně nového projektu rozhodli rozšířit současnou implementaci.

Ověření návrhu

Abychom si byli jisti, že se vydáváme správnou cestou, dali jsme nejdříve dohromady prototyp (Proof of Concept), který celou myšlenku potvrdil. Zároveň jsme se zaměřili na:

• ověření integrace Wear OS části do současné architektury
• ověření synchronizace dat mezi Wear OS a mobilní aplikací
• ověření vzdáleného otevření mobilní aplikace z Wear OS
• ověření výkonu (aplikace využívá DB s šifrováním, networking a MQTT komunikaci a další náročnější operace)
• prozkoumání testování a ladění Wear OS aplikace

Kromě toho jsme identifikovali několik úprav, které jsme museli v dalších fázích vývoje zakomponovat:

• extrahovat část logiky kostry aplikace do knihoven (logika navigace mezi obrazovkami, architecture testy a další)
• rozhodnout se, zda současné funkce rozšíříme o Wear OS podporu, či zda napíšeme úplně nové a oddělené
• upravit část sdíleného kódu, aby byl ještě více nezávislý (obecný)

Na co je potřeba myslet při návrhu Wear OS aplikace

Vývoj aplikace pro Wear OS přináší specifické výzvy, které se výrazně liší od klasického vývoje pro mobilní zařízení. Je nutné zohlednit výkonové omezení hodinek, které mají často méně výpočetního výkonu, menší paměť a omezenější kapacitu baterie. Z pohledu uživatelského rozhraní (UI) je důležité navrhovat jednoduché, přehledné a čitelné obrazovky přizpůsobené malému kulatému nebo čtvercovému displeji. Uživatelský zážitek (UX) by měl reflektovat to, že interakce na hodinkách jsou krátké a často probíhají v pohybu. Dále je třeba myslet na kompatibilitu s různými typy zařízení, včetně různých verzí Wear OS a různých výrobců.

Co nová Wear OS aplikace umí

Nová MyŠkoda pro Wear OS je navržena tak, aby uživatelům umožnila mít ty nejdůležitější informace a funkce spojené s vozidlem vždy po ruce. Zároveň musí být funkce rychle dostupné a přehledné na malém displeji hodinek. Současná verze zahrnuje:

• přehledný dashboard se základními informacemi (např. stav nabití baterie či dojezd automobilu)
• funkci vzdáleného odemknutí a zamknutí vozidla
• funkci vzdáleného zapnutí a vypnutí nabíjení

Na dalších funkcích aktivně pracujeme.

Architektura

Původní architektura

Android projekt aplikace MyŠkoda využívá principů clear architecture s využitím většího množství zapouzdřených Gradle modulů. V současné době jich je více než 180. Několik z nich plní podpůrnou funkci během vývoje, většina však pokrývá logiku celé komplexní aplikace. Tyto moduly jsou kategorizovány do složek podle jejich typu.

Před rozšířením kódu o Wear OS podporu obsahoval kód moduly následujících typů:

• library : Kód, který může být využit v ostatních typech modulů. Typickým příkladem je modul obsahující networking. Patří sem však i sdílený kód, který využívá například více modulů typu feature či section. Příkladem může být obecná mapa, která umí vykreslit pin či trasu.
• feature : Jednotlivé funkce aplikace. Moduly tohoto typu nemohou využívat kód uvedený v další modulech tohoto typu. Tím je zaručena jejich nezávislost a možnost jednotlivé funkce přidávat či odebírat bez ovlivnění ostatních.
• section : Moduly tohoto typu slouží ke sjednocení více funkcí. Jako příklad lze uvést dashboard, který zobrazuje funkci pro ovládání klimatizace a funkci pro ovládání nabíjení. Stejně jako u modulů typu feature nesmí tyto moduly záviset na jiných modulech tohoto typu.
• app: Top-level spustitelná Android aplikace. Obsahuje základní kostru aplikace a integruje ostatní potřebné moduly. Typickým příkladem je produkční typ mobilní aplikace. Tento typ modulu však pokrývá i případnou demo aplikaci či aplikaci pro jiný typ zařízení.
  

Rozšíření architektury o Wear OS

Při návrhu architektury Wear OS funkcí jsme uvažovali nad dvěma možnostmi - rozšířit stávající funkce, či implementovat Wear OS funkce odděleně. První z možností přináší jednodušší zapouzdření jednotlivých funkcí, jelikož společná logika pro mobilní i Wear OS funkce je uvedena v rámci jednoho Gradle modulu. Druhá naopak přináší lepší oddělení logiky a nižší komplexnost, jelikož funkce pro Wear OS může mít diametrálně odlišné chování. Nevýhodou je nutnost extrakce některé společné logiky z feature modulu do library modulu, aby byla dostupná i pro feature-wear modul. Po diskuzi s Android vývojáři v rámci Community of Practice schůzky a zvážení možností jsme se přiklonili k oddělení logiky. Nově nám přibyly dva typy modulů.

• feature-wear : Jednotlivé funkce Wear OS aplikace. Mají stejná pravidla jako feature moduly.
• section-wear : Zahrnuje section moduly dedikované pro Wear OS aplikaci.

Zvolením této architektury jsme pro Wear OS aplikaci dostali velké množství logiky, která je součástí library modulů, téměř zadarmo (kód byl již vyvinut pro mobilní aplikaci).

Ušetřili vyšší jednotky měsíců vývoje v porovnání s vývojem na zelené louce. Zároveň aplikace pro Wear OS využívá na pozadí identický kód, který je již několik let neustále rozvíjen a laděn.

Synchronizace dat mezi hodinkami a mobilním zařízením

Mobilní a Wear OS aplikace jsou na sobě téměř nezávislé aplikace, které spolu sdílí pouze kód a procesy během vývoje. Wear OS aplikace tu mobilní potřebuje jen pro prvotní přihlášení uživatele, nadále probíhá komunikace se vzdáleným backend API napřímo. Navzdory tomu je z uživatelského hlediska žádané některé stavy mezi oběma aplikacemi synchronizovat. K tomu využíváme rozhraní Data Layer API.

Data Layer API

Pro efektivní přenos dat mezi zařízeními využíváme Data Layer API. Toto API je součástí Google Play services a poskytuje robustní a optimalizované řešení pro komunikaci mezi chytrými hodinkami a spárovaným mobilním zařízením. Vývojář má k dispozici několik způsobů přenosu:

• DataItems pro synchronizaci stavových dat,
• Assets pro větší binární soubory jako jsou obrázky,
• Messages pro jednorázové události v reálném čase,
• Capability API pro zjišťování možností spárovaného zařízení.

Díky těmto nástrojům je možné vytvářet plynulou a responzivní interakci mezi mobilní a wearable částí aplikace.

S využitím Data Layer API aktuálně probíhá synchronizace přihlášení a vybraného automobilu.

Synchronizace přihlášení

Pro přihlášení uživatele do Wear OS aplikace využíváme přihlášení z mobilní aplikace, a to z několika důvodů:

• Hodinky obecně mají malý displej, na kterém se hůře zadávají přihlašovací údaje.
• Synchronizace přihlášení z mobilní aplikace je jeden z doporučených přístupů dle Android dokumentace.
• Některé funkce v hodinkách jsou navázané na funkce v mobilní aplikaci.

Synchronizace upozornění

V základu Android synchronizuje přijatá upozornění v mobilním telefonu do hodinek. V našem případě však umí MyŠkoda Wear OS aplikace přijímat a zobrazovat upozornění sama. Protože by tím docházelo k duplikacím, bylo nutné upravit konfiguraci:

• zakázat automatickou synchronizaci upozornění mezi zařízením

• nastavit stejným upozorněním stejné unikátní ID pro synchronizaci odstranění upozornění (při odstranění upozornění na jednom zařízení zmizí i na druhém)

‍

Vývoj UI

MyŠkoda aplikace pro Wear OS využívá knihovnu Jetpack Compose for Wear OS, kterou doplňuje Jetpack Compose implementace Škoda Flow Design systému. Knihovna Jetpack Compose for Wear OS usnadňuje vývoj a zajišťuje konzistentní chování napříč zařízeními. Škoda Flow Design systému zajišťuje stejný jazyk designu v podobě barev, fontů, komponent a ikon.

Během vývoje nám dost pomohla sada knihoven Horologist. Jednou z nejpoužívanějších funkcí je Compose modifier fillMaxRectangle() , který nastaví velikost UI komponenty do maximálního možného viditelného obdélníku. Díky tomu máme zaručeno správné zobrazení všech definovaných UI komponent nezávisle na tvaru displeje hodinek (kulatý vs. hranatý).

Ladění Wear OS aplikace

Ladění aplikací pro Wear OS probíhá standardně prostřednictvím Android Studia a ADB (Android Debug Bridge), přičemž jsou podporována připojení přes WiFi, USB kabel či Bluetooth.

Jakmile je spojení navázáno, lze aplikaci ladit stejně jako na běžném Android zařízení – sledovat výpisy pomocí adb logcat, instalovat buildy přes adb install, provádět debugging v Android Studiu nebo využívat adb shell pro přístup na nižší úrovni.

Pro připojení přes WiFi je potřeba na hodinkách zapnout Developer options, povolit Wireless debugging a následně spárovat zařízení s vývojovým počítačem. To se provádí pomocí ADB příkazu:

Po úspěšném spárování se zařízení připojí klasickým příkazem:

Občas se nám ale stává, že se hodinky připojené přes WiFi sami odpojují a už se nedají opětovně propojit. Proto jsme ve většině případů testování na fyzickém zařízení využívali propojení přes USB kabel. Během běžného vývoje doporučujeme využívat emulátory.

Dostupné v Google Play Beta

Wear OS aplikace MyŠkoda je již nyní dostupná v Google Play Beta kanálu. Budeme rádi, když jí vyzkoušíte a dáte nám podněty, co zlepšit.