Rostoucí popularita AAOS mezi automobilkami i vývojáři

Narůstající popularitu AAOS můžeme vidět například v nedávném prohlášení společnosti Google, ve kterém oznámila přidání více než 70 aplikací pro AAOS do Google Play. Dalším indikátorem je i fakt, že se již nyní využívá ve Volkswagen Group, konkrétně v automobilce Audi, která ho jako první z koncernu uvedla ve svém modelu Audi Q6 e-tron. Najdeme ho také v nové Audi A6 e-tron. A z dalších kroků a prohlášení představitelů koncernu usuzujeme, že některé další značky budou následovat.

‍

Potenciálu Android Automotive OS a jeho expanzi do více automobilů věříme i my ve Flow. Celý ekosystém šablon, podporovaných kategorií aplikací a možnosti přizpůsobení jsou spíše na začátku – nové šablony a další podporované aplikace teprve přijdou. Tématu AAOS se věnujeme již nějakou dobu. Detailnější informace si můžete přečíst v předchozích článcích:

• Development for Android Automotive OS? We are ready
• Testing Android Automotive OS application in a Volvo XC60

Základní principy a využití AAOS Google šablon

AAOS obecně umožňuje vývoj uživatelského rozhraní aplikací podobným způsobem, jaký známe z mobilního prostředí. Například s využitím knihovny Jetpack Compose. Sami jsme si to ověřili na jednoduché Shared Car aplikaci pro monitorování využití vozidel zaměstnanci. Aplikace je spustitelná ve voze a funkční. Nejedná se však o preferovanou variantu, která by byla v souladu s dokumentací Androidu a požadavky Google Play.

‍

Oficiální Google dokumentace upřednostňuje využití šablon (tzv. Templates), které jsou optimalizované pro infotainment v automobilech a usnadňují dodržování definovaných UX požadavků. Cílem těchto požadavků je zjednodušit ovládání aplikací a zvýšit bezpečnost díky nižšímu rozptylování řidiče. 

‍

Požadavky jsou kategorizovány do tří kategorií.

• MUST (NOT): Požadavky označené jako MUST musí/nesmí být splněny. Např. Jednotlivé úkony v aplikací musí být dokončeny maximálně do pěti kroků.
• SHOULD: Požadavky označené jako SHOULD jsou doporučeny. Např. pro navigace by doba a vzdálenost měla být aktualizována během jízdy.
• MAY: Požadavky označené jako MAY jsou dobrovolné. Jejich splnění však může zlepšit uživatelský zážitek. Např. Vyhledávací pole může obsahovat nápovědu (hint).

Dále jsou definovány následující kategorie požadavků.

• Obecné požadavky se týkají všech aplikací.
• Požadavky pro konkrétní typ aplikací jsou aktuálně definovány pouze pro aplikace počasí a navigace.
• Požadavky pro konkrétní šablony specifikují a omezují její použití. Příkladem může být šablona *List template*, jejíž požadavek definuje, že v případě seskupování položek do sekcí, musí mít každá sekce záhlaví.

Google definuje základní komponenty a šablony.

• Mezi aktuálně dostupné komponenty patří Action strip, Map action strip, Button, Floating action button (FAB), Header, Row. 
• Jako šablony můžete vybrat Grid template, List template, Map + Content template, Message template, Long Message template, Navigation template, Pane template, Place List (map) template, Search template, Sign-in template, Tab template.

‍

Použití Android for Cars App knihovny ve vývoji

Šablony, komponenty a další stavební prvky pro vývoj AAOS aplikací s UI templatemi jsou součástí knihovny AndroidX –  Android for Cars App, která je dostupná v oficiálním Google Maven repozitáři. V projektu je lze definovat následujícími Gradle závislostmi.

Knihovna poskytuje rozhraní pro konfiguraci šablon pomocí builder patternu, který umožňuje nastavit pouze to, co daná komponenta podporuje. Pokud kombinace parametrů nevyhovuje, aplikace spadne za běhu (vyhodí výjimku). Hlavní nevýhodou tohoto řešení je omezená možnost přizpůsobení požadavkům aplikace, UI designérů a klienta. Chybí mi využití Kotlin DSL, které by celý kód zjednodušilo.

‍

Builder pattern je návrhový vzor umožňující postupné a čitelné sestavení složitých objektů bez nutnosti velkého konstruktoru. Namísto předávání mnoha parametrů do konstruktoru se používají metody builderu, které vracejí jeho instanci.

Základní komponenty šablonových AAOS aplikací

Vývoj AAOS aplikací využívajících šablony se výrazně liší od klasického vývoje. Chybí zde například jeden ze základních stavebních kamenů Android aplikací, a to Activity. Místo toho knihovna Android for Cars App definuje vlastní komponenty.

Host je komponenta, kterou při vývoji automotive aplikací neimplementujeme. Je součástí Android Automotive OS a zajišťuje kompletní správu AAOS aplikace – od jejího objevení přes řízení životního cyklu až po převod šablon na Android Views, jejich vykreslení a předávání uživatelských interakcí

‍

CarAppService je abstraktní třída (Service), kterou musí šablonová AAOS aplikace implementovat. Definuje hlavní připojení k aplikaci. Její hlavní činností je validace, zda je připojení k této CarAppService důvěryhodné a poskytování Session každému novému připojení.

‍

Session je další abstraktní třída, kterou musí šablonová AAOS aplikace implementovat. Tato třída poskytuje vstupní (první) obrazovku, tzv. Screen aplikace. Tato třída má přístup k životnímu cyklu aplikace, díky kterému dokáže například vyhodnotit, zda je aplikace viditelná uživateli či ne.

‍

Screen je třída, jejímž hlavním cílem je poskytovat uživatelské rozhraní pomocí již námi známých šablon. Tato třída má přístup i ke ScreenManageru , díky kterému můžeme navigovat mezi jednotlivými obrazovkami. Hlavní metodou třídy Screen je metoda *fun onGetTemplate(): Template* , která se volá při vytváření nové šablony s aktuálním stavem.

Jak aktualizujeme UI šablony v Etnetera Flow

Tvoříme aplikace, které dodržují principy Clean Architecture. Pro prezentaci stavu aplikace využíváme ViewModel, který poskytuje pozorovatelný stav. V případě jeho změny překreslujeme UI. U AAOS aplikací však musíme proces vykreslování stavu rozdělit do několika kroků.

‍

Mobilní aplikace:

• V UI vrstvě aplikace sledujeme nové stavy se změnami a tyto stavy rovnou vykreslujeme.

AAOS aplikace:

• Ve Screen sledujeme změny stavu
• Informujeme Screen, že je nutné vytvořit novou šablonu.
• Při vytváření nové šablony získáváme z ViewModelu aktuální stav a vykreslujeme jej

Při vývoji AAOS aplikací často narážíme na omezení tohoto řešení, která neodpovídají požadavkům UI týmu, analytiků nebo product ownera. Příkladem může být přidání tlačítka na konkrétní místo obrazovky, zakulacené rohy UI komponent neboi změna barev.

‍

Chcete se dozvědět více o vývoji pro Android Automotive OS? Sledujte náš blog nebo nás kontaktujte – rádi s vámi probereme naše zkušenosti a možnosti spolupráce!