Přidání funkcí Android Auto do stávající aplikace se může zdát jednoduché a matoucí zároveň.
Zde sdílíme některé z maličkostí, které jsme se naučili při přidávání podpory Android Auto do stávající aplikace s nadějí, že bude v budoucnu užitečná pro ostatní.
Co je Android Auto?
Pro začátek je Android Auto ne Android Automotive. Je to matoucí? Google si to myslí: https://source.android.com/devices/automotive/start/what_automotive#android-automotive-android-auto
Stojí za zmínku, že vývoj pro Android Auto vás nastaví na úspěch také s Android Automotive, protože používají stejnou službu «CarAppService», Android Automotive však bude potřebovat samostatný modul v rámci vašeho projektu. Pokud víte, že budete chtít v budoucnu podporovat Android Automotive, bylo by dobré nastavit kód Android Auto v modulu knihovny, abyste jej mohli oddělit od kódu hlavní aplikace a sdílet jej s budoucím vývojem Automotive! Více informací o vývoji Android Automotive naleznete zde: https://developer.android.com/training/cars/apps/automotive-os, ale zde budeme hovořit hlavně o Android Auto.
Klíčové koncepty
Jeden koncept, který stojí za zmínku, je hostitel. Hostitel spouští vaši aplikaci, řídí její životní cyklus, implementuje rozhraní API knihovny automobilů, vykresluje vaše šablony a informuje vaši aplikaci o interakci uživatele. Můžete si to představit analogicky k tomu, co systém Android dělá pro vaše standardní aplikace pro Android. Android Auto je hostitel a Android Automotive také obsahuje systémovou aplikaci, která slouží jako hostitel a umožňuje, aby knihovna automobilů fungovala s oběma.
Zajímavé je, že lze implementovat i jiné hostitele. Například Harman, známý Harman Kardon, ale nyní vlastněný společností Samsung, má platformu známou jako Harman Ignite, která je také hostitelem, a proto umožňuje vývojářům distribuovat aplikace Android Auto s minimálním dodatečným úsilím.
Další koncept, který stojí za zopakování z dokumentů, je Šablony. Šablony jsou modely pro uživatelské rozhraní. Android Auto nevyužívá systém zobrazení jako Android. Vytváří méně flexibilní, předem připravené komponenty, které odpovídají těmto modelům. Toto omezení je něco, o čem vy a váš tým budete muset vědět při navrhování uživatelských toků ve vaší aplikaci. Google nabízí skvělý zdroj odkazu na dostupné šablony a jejich omezení zde.
Poznámky k nastavení vašeho vývojářského prostředí
Většinu toho, co potřebujete vědět o nastavení vašeho vývojářského prostředí, najdete v dokumentech zde: https://developer.android.com/training/cars/testing.
Zde jsou některé důležité věci v dokumentech ne zmínit nebo vám není jasné, co byste možná chtěli vědět:
- Pokud používáte emulátor, musíte načíst aplikaci Android Auto (com.google.android.projection.gearhead), protože verze nainstalovaná ve výchozím nastavení na emulátorech nefunguje správně
- V nastavení vývojáře aplikace pro Android auto (viz https://developer.android.com/training/cars/testing#running-dhu) musíte povolit „Neznámé zdroje” pro použití Desktop Head Unit (DHU)
- Je užitečné zkontrolovat „Povolit překryvné ladění” v nastavení vývojáře aplikace pro Android auto, abyste viděli počet kroků vaší aplikace
Věci, které jsme se dozvěděli o omezeních šablon
Android Auto omezuje všechny aplikace na limit 5 plaveb hluboko pomoci snížit rozptylování při řízení. Pokud se vaše dobrodružná aplikace stane, že kdykoli překročí tento limit, Android Auto jí laskavě řekne, aby přestala tím, že ji srazí.
Dokumenty činí důležitý rozdíl, že toto počet kroků is ne stejný jako počet obrazovek v zadním zásobníku. Místo toho se počet kroků změní, kdykoli začnete zobrazovat novou šablonu. Stručně řečeno, existují dva způsoby, jak přidat „novou“ šablonu:
- Vytlačení nové obrazovky, která by mohla přidat nějaký počet šablon
- Změna informací v existující šabloně (například změna názvu šablony)
Zda se změna informací na obrazovce počítá jako krok, nebo ne, je diktováno danou šablonou Omezení šablony. Existuje mnoho užitečných případů, kdy změna informací v existující šabloně obejde omezení dané šablony a nezvýší počet kroků. Zde se pokusíme zahrnout většinu těch, na které jsme narazili.
Rozpětí se může změnit (někdy)
Věci jako barva textu nebo číselná vzdálenost k něčemu (z DistanceSpan) se při změně normálně nezapočítávají do počtu kroků.
Některá pole vůbec nepodporují rozsahy, takže změny textu v nich zvyšují počet kroků:
- Titulky obrazovek
- Zpráva šablony zprávy
Akce se mohou změnit
Ikony akcí na obrazovce se mohou změnit, nebo se dokonce mohou zcela objevit nebo zmizet, aniž by to ovlivnilo počet kroků.
Na jedné obrazovce jsme byli schopni aktualizovat ikonu akce na základě stavu, než se zbytek obrazovky načetl.
Stavy načítání
Stav načítání lze zobrazit před jakoukoli šablonou a přechod z tohoto stavu načítání se nepočítá jako krok. Šablona například nemůže aktualizovat žádné položky seznamu, ale může začít ve „stavu načítání“ bez položek seznamu a přejít ze stavu načítání bez ovlivnění počtu kroků.
Zpětná navigace na podobnou obrazovku
Může to být a užitečný jeden vědět. Obrazovka se může aktualizovat a zobrazovat zcela jiný obsah, když uživatel naviguje zpátky do něj, pokud typ šablony zůstane nezměněn.:
Jeden postup v naší aplikaci zahrnoval navigaci vpřed z obrazovky s podrobnostmi na seznam možností a poté znovu na podobnou obrazovku s podrobnostmi, která je aktualizována informacemi o výběru. Možnost aktualizovat obsah šablony na zadní navigaci nám umožnila přejít vpřed na seznam možností a poté přejít zpět na obrazovku s podrobnostmi, když uživatel klikl na svou volbu, čímž se aktualizoval starý obsah obrazovky s podrobnostmi. Využití tohoto chování pomohlo snížit maximální délku toku za tímto bodem o celé dva kroky!
Bez možnosti změnit obsah obrazovky při přechodu zpět by nebylo možné implementovat hlavní tok podrobností, jako je tento, bez dosažení limitu počtu kroků.
Položky seznamu lze přepínat/deaktivovat bez ovlivnění počtu kroků
Toto chování bylo užitečné v tom, že stavy přepínání uživatelských filtrů a nastavení se mohly v Android Auto dynamicky aktualizovat, pokud se v aplikaci změnily, na rozdíl od větších změn obsahu na jiných obrazovkách.
Umístění uživatele
Umístění uživatele a bod zaostření na mapě lze změnit a nastavit bez aktualizace počtu kroků.
Pátý a poslední „krok“ je omezenější než ostatní
Pátá (a poslední) šablona v toku může být pouze jedna z následujících:
- Navigační šablona
- PaneTemplate
- MessageTemplate
Architektura
Možná přidáváte Android Auto do stávající aplikace, jako jsme my, nebo možná začínáte od nuly. Ať tak či onak, zde jsou některá architektonická doporučení založená na našich zkušenostech.
Vložte svůj automatický kód do samostatného modulu
To vám umožňuje snáze sdílet kód mezi AA a AAOS a zároveň pomáhá prosadit další modularizaci funkcí, která vede k menší aplikaci AAOS.
Pozor na přehnanou reaktivitu
Pokud používáte reaktivní architekturu, jako je LiveData, Rx nebo Flow, musíte být opatrní, aby opětovné emise dat nezpůsobily neočekávané aktualizace šablon a neúmyslně nezvýšily počet kroků. Další věc, kterou víte, vaše aplikace se zavírá, než se dostanete na konec toku! To může být způsobeno řadou věcí, včetně změn stavu řízených z aplikace ve sluchátku, kruhových reaktivních závislostí nebo jiných. Nejčastěji tyto věci nebudou mít negativní vedlejší účinky na sluchátko, ale omezení šablony Android Auto znamenají, že musíte zůstat na vrcholu.
Během celého vývoje Android Auto doporučujeme povolit možnost ladění Android Auto pro zobrazení aktuálního počtu zásobníků. Kromě toho se ujistěte, že se odhlašujete z odběru svých streamů, jakmile získáte data nezbytná k zobrazení obrazovky, a ujistěte se, že se na obrazovku zobrazí všechna najednou. Nemůžete částečně načíst obrazovku a poté načíst zbytek bez dvojitého započítání přechodu.
CarViewModels
Obrazovky Android Auto nemají ekvivalent k ViewModels, jaké byste mohli načíst z fragmentu nebo aktivity. Vytvořili jsme třídu «CarViewModel» pro rozšíření a použití v našich obrazovkách.
CarViewModel slouží ke stejnému účelu jako ViewModel, jak je popsáno zde: https://developer.android.com/jetpack/guide#ui-layer. Pro každou obrazovku jsme zjistili, že je užitečné vytvořit model nazvaný „ViewData“, který bude reprezentovat stav obrazovky (běžně se tomu říká model pohledu, pojmenování třídy ViewModel komponent architektury budiž zatraceno). ViewData má vztah 1:1 se šablonou, takže když je model ViewData aktualizován, spustí aktualizaci obrazovky. Použití těchto ViewData také zjednodušilo testovací logiku obrazovky; v testu jednotky jsme mohli vytvořit instanci CarViewModel s předávanými falešnými závislostmi, manipulovat se stavem CarViewModel a zjistit, zda se ViewData pro obrazovku aktualizovala tak, aby odpovídala očekávání.
Toto nastavení CarViewModel také velmi zjednodušilo správu závislostí – mohli jsme do CarViewModels vložit závislosti pomocí dýky, stejně jako jsme to dělali v základní aplikaci. Abychom umožnili předávání CarContextu a jakýchkoli dalších manuálních argumentů spolu s ViewModelem vstřikovaným dýkou, použili jsme asistovanou injekci dýkou.
class DashboardScreen @AssistedInject constructor( @Assisted val carContext: CarContext, val viewModel: DashboardCarViewModel, val screen1Factory: Screen1.Factory, val screen2Factory: Screen2.Factory, val screen3Factory: Screen3.Factory, val screen4Factory: Screen4.Factory, ) : Screen < . @AssistedFactory interface Factory < fun create(carContext: CarContext): DashboardScreen >> Pomocí asistovaného vstřikování byla první továrna na obrazovky vstříknuta jako pole v naší implementaci CarAppService a jakékoli další obrazovky nebo závislosti byly vloženy přes konstruktor této první obrazovky nebo konstruktory jejích závislostí.
Vzor prezentujícího
Uživatelské rozhraní Android Auto je deklarativní. Když vrátíte šablonu k zobrazení, obsahuje widgety i jejich stav. Chcete-li aktualizovat zobrazení, musíte vyhodit starou šablonu a vrátit zcela novou. To umožňuje testu uživatelského rozhraní účinně potvrdit, že vrácená šablona obsahuje widgety a stav, které očekáváte.
Abychom lépe využili tuto testovací strategii, zjistili jsme, že je výhodné vytvořit samostatnou třídu Presenter pro každou obrazovku a vytvořit její šablonu. Obrazovka by vlastnila tuto instanci prezentujícího, předala by potřebná data a vrátila výstup tohoto prezentujícího. Toto nastavení nám umožnilo testovat Presenter v izolaci, aniž bychom se museli starat o vytváření instance obrazovky nebo jejích dalších závislostí.
Automatizované testování
Kromě testování Presenter popsaného výše jsme také zjistili, že je užitečné testovat určité navigační události. Toho lze dosáhnout využitím testovacích tříd poskytovaných společností Google: https://developer.android.com/reference/androidx/car/app/testing/package-summary. Třídy zde poskytují falešné implementace pro různá rozhraní specifická pro Auto, jako je ScreenManager a CarContext, což vám umožňuje testovat jakýkoli kód ve vaší implementaci, který je méně abstrahován od rozhraní Car API. Testování s těmito padělky je analogické psaní instrumentovaných nebo robotoelektrických testů proti vašemu kódu Android.
Umístění oprávnění
Android 10 a 11 se změnil, když mají aplikace povolený přístup k poloze uživatele. Před rokem 10 byl aplikacím implicitně udělován přístup k poloze na pozadí spolu s oprávněním k poloze. Poté v roce 10 bylo přidáno umístění na pozadí jako samostatné oprávnění, ale stále bylo možné jej udělit za běhu ze systémového řádku. V Androidu 11 zůstává poloha na pozadí samostatným oprávněním, ale již nelze udělit ze systémového příkazu a vyžaduje, aby uživatel pro udělení přešel na obrazovku nastavení svého zařízení.
Toto chování ovlivňuje Android Auto, protože celé prostředí je řízeno službou, kterou vaše aplikace vlastní. Pokud si tohoto rozdílu neuvědomujete a náhodou testujete s Androidem 10 nebo nižším, možná si neuvědomíte, že máte problém s rozbitím aplikace, dokud nebude příliš pozdě!
Existuje několik způsobů, jak zacházet s přístupem k poloze: požádat o přístup k poloze na pozadí nebo vytvořit službu CarAppService jako službu na popředí. První možnost přináší obavy z použitelnosti, protože uživatel musí být odeslán do nastavení svého systému, aby povolil umístění na pozadí, takže doporučujeme, aby se vaše služba stala službou na popředí. Používání služby v popředí znamená, že uživatel uvidí na svém zařízení trvalé upozornění, když je spuštěna vaše aplikace Android Auto, podobně jako se v Android Auto chovají Mapy Google (můžete vidět možnost, kterou Google s ohledem na tento problém použil).
