Samozřejmě berte Guidelines i mé rady s rezervou. Nejsou to pravidla, ale jen rady. Například hry rozhodně nerespektují celistvost platformy – a nikomu to nevadí. Pokud programujete klávesnici, asi se bude těžko ovládat nosem. Většinou však ony rady fungují dobře.

Jak řekl Christian Robertson: „Neznovuvynalézejte seznam, pokud si nejste stoprocentně jisti, že potřebujete znovuvynalézt seznam.” (Hodně volně přeloženo.)

V podstatě vám už tohle může docela stačit.

Barevné suroviny

Stejně jako všechny řetězce by měly být v surovinách, měly by tam být i všechny barvy. Pro ně je soubor /res/values/colors.xml, který je téměř stejný jako strings.xml, až na to, že používáme elementy <color>, jejichž hodnotou může být hexadecimální zápis barvy ve formátu #rgb, #argb, #rrggbb či #aarrggbb. Barvy, které používá přímo Android, můžete najít v android.R.color  a díky nim můžete vaši aplikaci ještě více sjednotit se systémem. Na to jsou ale mnohem lepší tzv. style attributes, o nichž se zmíním později.

Na barvu odkazuje R.color.name resp. @color/name.

Rozměrové suroviny

S barevnými surovinami jsme dokonce i pracovali, ale rozměrové suroviny (dimension resources) pro vás mohou být novinkou, ačkoli je to opět jen omílání řetězců, barev a dalších. Soubor se tentokrát podle konvence nazývá dimens.xml, elementem je <dimen>, jeho hodnotou může být nějaké číslo s jednotkou ( 16dp, 22sp, 156px, …).

Přistoupíte k nim pomocí R.dimen.name resp. @dimen/name.

U barev má smysl použít surovinu vždy. Jednak to plní dokumentační funkci, jednak to umožňuje lépe udržet konzistenci barev v rámci projektu (podíváte se, které barvy už existují, a teprve, pokud vám žádná nevyhovuje, začněte vymýšlet novou) a v neposlední řadě stačí změnit barvu na jednom místě a změní se všechny její použití.

U rozměrů je to trochu složitější. Někdy to rozhodně smysl má (aplikace vypadá lépe, když její prvky používají stejný padding, a ne pixel sem, pixel tam), ale někdy je to asi zbytečná práce. Záleží na vás a také samozřejmě na velikosti projektu.

Motivy

Motivy (themes) jsou vlastně jen jiným využitím stylů. Takže nebojte, nebudete se muset učit ještě další elementy. Zatímco styl je aplikován na jedno View (i kdyby to View bylo GroupView a mělo potomky, jich se už ten styl absolutně netýká), motiv je aplikován na všechna View v rámci nějaké Activity nebo celé aplikace.

„A jak to dělaji, že vytvořím styl dohromady pro EditText a ListView, když každý má dost jiné atributy?” Výborná otázka, dělají to stejně, jako CSS – každé View si ze všech možných nastavených atributů vybere jen ty, které potřebuje.

Takže bychom mohli dál vylepšit naši „aplikaci”. Místo toho, abychom třikrát opakovali style="@style/MyText", můžeme celé Activity nebo dokonce celé aplikaci nastavit MyText jako motiv. Jak se to dělá? V manifestu na to existuje atribut android:theme, jehož hodnotou je identifikátor motivu. V našem případě přidáme elementu <application> nebo <activity> takovýhle atribut: android:theme="@style/MyText". A je to!

Moment, není, vždyť ten obrázek nevypadá stejně jako předchozí (ačkoli tedy vypadá lépe). Máte pravdu. Předchozí příklad totiž používal vestavěný motiv Theme.Holo.Light.DarkActionBar, který se nastavil automaticky při vytvoření projektu ADT pluginem v20, zatímco v tomto příkladu jsme původní motiv přepsali (ať už jsme doslova v kódu, anebo obrazně tím, že jsme nastavili motiv Activity) naším MyText. Jak to vyřešit? Za chvilku se k tomu dostaneme, ale nejdřív vám povím něco o dědičnosti stylů.

Dědičnost stylů

Zatímco v CSS může několik různých bloků cílit na stejný element, který potom všechny jejich styly zkombinuje, Android žádné kaskády neumí, a každé View tak může mít jen jeden styl. Přesto se v něm ale dá vyřešit problém, kdy potřebuji, aby měly všechny EditTexty v aplikaci stejný vzhled, až na to, že polovina bude mít tučné písmo a polovina ne. S tím, co známe doposud, bychom skončili buď u dvou duplikujících se stylů, až na to, že jeden má navíc android:textStyle="bold", anebo u jednoho stylopisu a ručně přidaného atributu android:textStyle="bold" každému EditTextu, který má být tučný.

Tím, že od sebe styly mohou dědit, můžeme vytvořit styl MyEditText, kde definujeme všechno pro netučné EditTexty, tedy všechno, co mají společné, a potom styl  MyEditText.Bold, který bude dědit od MyEditText a přidá jen tučný text.

Samotný fakt, že nějaký styl dědí od jiného, můžete deklarovat dvěma způsoby.

Dědit od nějakého stylu můžete pomocí atributu parent elementu <style>, jehož hodnotou je odkaz na style surovinu – rodiče.

Druhou možností jak dědit, ale to lze pouze od vlastních stylů, nikoli od androidích, je pomocí tečky. Pokud máte vytvořený styl MyEditText, od nějž chcete dědit a přidat tučné písmo, stačí nový styl pojmenovat MyEditText.Bold (za tečkou místo Bold může být cokoli). Android už pozná, že chcete dědit.

Následující tři elementy <style> dělají to samé (přičemž poslední dodržuje pojmenovávací konvence a celkově ho považuji za nejlepší):

<style name="MyBoldStyle" parent="MyStyle">
    <item name="android:textStyle">bold</item>
</style>

<style name="MyBoldStyle" parent="@style/MyStyle">
    <item name="android:textStyle">bold</item>
</style>

<style name="MyStyle.Bold">
    <item name="android:textStyle">bold</item>
</style>

Vestavěné motivy

Do Gingerbreadu (Android 2.3) bylo všechno jednoduché. Ale pak přišel Honeycomb (3.0) s novým holografickým stylem a věci zkomplikoval. No a aby toho nebylo málo, Ice Cream Sandwich (4.0) přidal ještě další motivy (ačkoli tam není změna tak markantní).

Všechny možné motivy naleznete v souboru {složka adk}/platforms/android-{verze}/data/res/values/themes.xml a v případě ICS a výše ještě {složka adk}/platforms/android-{verze}/data/res/values/themes_device_defaults.xml, my si ukážeme ty základní důležité:

Theme

Výchozí motiv na Androidu < 3.0. Můžete předpokládat, že budete pracovat s tmavým pozadím a světlým textem navrchu. Viz  R.style.Theme.

Theme.Light

Víceméně inverzní k Theme. Viz R.style.Theme_Light.

Theme.Black

Motiv, jehož pozadí je úplně černé (já nevidím rozdíl oproti Theme). Viz  R.style.Theme_Black.

Holo

Výchozí, tmavý holografický motiv na Androidu 3.x. Viz  R.style.Theme_Holo.

Holo.Light

Světlá verze Holo. Viz R.style.Theme_Holo_Light.

Holo.Light.DarkActionBar

S API 14 přišla ještě jedna varianta holografického motivu, a to světlý s tmavým Action Barem. Viz  R.style.Theme_Holo_Light_DarkActionBar.

DeviceDefault

Výchozí na ICS a výše.

Asi jste si všimli, že je tento vzhled totožný s Holo. Řeší totiž problém, kdy výrobci zařízení upravovali Holo tak, aby zapadlo do jejich UI nadstaveb. A to přinášelo problémy. Na zařízeních od ICS výše, na nichž je Play Store, Google garantuje, že Holo bude vždycky přesně Holo, zatímco DeviceDefault si mohou výrobci upravovat dle libosti. Na zařízeních z rodiny Nexus, emulátorech a telefonech bez nadstaveb je DeviceDefault v podstatě jen alias příslušného holografického motivu. Proto už u zbylých dvou DeviceDefault motivů screenshoty vynechám, dokážete si je jistě domyslet. (Zdroj: Holo everywhere)

Viz R.style.Theme_DeviceDefault.

DeviceDefault.Light

Viz Holo.Light.

DeviceDefault.Light.DarkActionBar

Viz Holo.Light.DarkActionBar.

Použil/a jsem DeviceDefault.Light, ale na Androidu 2.3 mi aplikace padá.

To je proto, že na Androidu 2.3 žádné DeviceDefault.Light není. Jak to ale vyřešit, pokud chci, aby má aplikace používala světlý motiv, a to ten nejnovější dostupný?

Článek Suroviny, Intenty, jednotky se mimo jiné věnoval modifikátorům. A modifikátor verze je přesně to, co potřebujeme. Do složky /res/values/styles.xml vložíme něco takového:

<style name="MyBaseTheme" parent="android:Theme.Light" />

Do složky /res/values-v11/styles.xml dáme následující řádek:

<style name="MyBaseTheme" parent="android:Theme.Holo.Light" />

A do třetice všeho dobrého, pokud netrváme na tom, že musíme mít neupravený holografický motiv, do /res/values-v14/styles.xml půjde tohle:

<style name="MyBaseTheme" parent="android:Theme.DeviceDefault.Light" />

MyBaseTheme potom buď nastavíme jako motiv aplikace či Activity, nebo od ní necháme v /res/values/styles.xml  dědit dejme tomu MyTheme, v níž nastavíme všechny atributy, které chceme, aby se změnily, nehledě na verzi Androidu (pokud chcete něco nastavit třeba jen u Theme.Light, můžete deklaraci MyBaseTheme v příslušné složce samozřejmě obohatit i nějakými  <item>-y):

<style name="MyTheme" parent="MyBaseTheme">
    <item name="android:padding">@dimen/padding</item>
</style>

Pozitivní je, že práci s vytvářením složek a souborů pro moderní, ale kompatibilní motivy za nás udělal ADT plugin v20 sám, takže je potřeba akorát případně změnit jednotlivé rodičovské motivy.

Tím jsme mimochodem vyřešili i problém, kdy se nám po aplikování motivu MyText změnil vzhled aplikace. Stačilo by, aby MyText dědil od nějakého vestavěného motivu (v našem případě by to u API >= 14 bylo  Theme.DeviceDefault.Light.DarkActionBar.

Proč mají některé motivy přípony typu NoActionBar?

Trochu jsem vám totiž lhal, když jsem tvrdil, že mezi kódem motivu a stylu není žádný rozdíl. Motiv může narozdíl od stylu obsahovat i tzv. okenní atributy, které se netýkají žádného View, ale celého okna. Pomocí nich můžete skrýt ActionBar, udělat Activity průhlednou, nastavit wallpaper jako pozadí nebo celou Activity skrýt. Všechny okenní atributy najdete v R.attr  počínaje R.attr.windowActionBar (všechny začínají na  window).

R.attr

Přemýšlíte, které atributy můžete ve stylech použít? Odpovědí je třída R.attr. A protože se s atributy dá dělat plno zajímavých věcí, budeme se jim teď chvilku věnovat.

Než ale začneme, musíte na chvíli přestat považovat slovo atribut za něco, co přímo souvisí s XML (layouty). Někdy ano, někdy ne.

Atributy jsou totiž mimojiné velmi šikovný způsob, jak v rámci svých stylů nebo v rámci View použít části motivů. Vzpomeňte si kupříkladu, jak jsem úplně na začátku pro barvu textu použil @android:color/primary_text_light a pro pozadí @android:color/background_dark. Už tehdy výsledek nevypadal dvakrát hezky, příliš neladil s motivem. Ale co je horší, při změně motivu tyhle barvy zůstávaly stejné. A to my přece rozhodně nechceme.

Díky atributům může uživatel ve svém kódu použít části motivu. Například právě barvy. Text bude mít určitě jinou barvu ve světlém motivu a jinou ve tmavém. Pozadí jakbysmet.

Já atributy použil už při vytváření screenshotů pro jednotlivé motivy, jen jsem vám to zatajil. Bez atributů by to však vypadalo divně. A ptáte se, jak vypadal kód třeba prvního TextView?

<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:gravity="center_horizontal"
    android:textAppearance="?android:attr/textAppearanceLarge"
    android:color="?android:attr/textColorPrimary"
    android:text="@string/title" />

Jak vidíte, v atributu android:color jsem použil atribut R.attr.textColorPrimary. Ale nachází se tam ještě jeden atribut, který nám už je vlastně dlouho známý! Samozřejmě i u vzhledu textu se hodí, když ho může motiv nastavit.

Některé atributy si tedy přivlastňují různá View, zatímco jiné slouží pouze pro definování balíčku vzhledových dat, která může pak uživatel někde použít.

Pokud si vytváříte vlastní motiv, můžete atribut android:textColorPrimary nastavit na nějakou vlastní barvu. Já třeba mohu udělat toto (pokud předpokládám, že AppTheme je motiv automaticky vygenerovaný ADT Pluginem a snaží se používat vždy ten nejmodernější vestavěný motiv). Pomiňme, prosím, že tam mám barvu vepsanou přímo a nikoli jako surovinu.

<style name="MyTheme" parent="AppTheme">
    <item name="android:textColorPrimary">#f00</item>
</style>

A když ještě nastavím MyTheme jako motiv v manifestu…

Na atributech je také zajímavé, že mohou obsahovat řetězec, barvu, číslo, může to být enum, jejich hodnotou mohou být flagy spojené bitovým OR, dokonce může být jejich hodnotou i celý styl (to je právě případ textApperanceLarge atp.)! Věnovat se tomu nebudeme, odkážu vás na StackOverflow, kde Qberticus poskytl opravdu vynikající odpověď, případně na soubor attrs.xml ve složce  {složka adk}/platforms/android-{verze}/data/res/values.

R.styleable

Třída R.styleable je odpovědí na nevyřčenou otázku „Jak poznám, které (nejen) View přijímá které atributy?” Více se jí věnovat nebudeme, pokud vás to zajímá, opět vizte výše odkazanou otázku na StackOverflow případně zdrojáky ( styleable.xml). Tak se můžete i naučit, jak vytvářet vlastní atributy pro vlastní View.

Jak nastavit motiv v kódu?

Není to úplně jednoduché a doporučuju se tomu vyhnout, může to být zdrojem chyb. V případě Activit lze použít metodu setTheme(), ale ta musí být zavolána před tím, než se začne vytvářet nějaký layout (tzn. v praxi prostě před  setContentView()).

DialogFragment na to má také metodu, setStyle(), která kromě nastavení motivu (pravděpodobně budete chtít použít nějaký s příponou .Dialog, bez toho se může stát, že se dialog zobrazí přes celé okno. Opět musíte volat před tím, než se nějaké UI vytvoří, v praxi v  onCreate() .

U Fragmentů je to docela složité. Abychom to pochopili, musíme si vysvětlit, jak to s těmi motivy vlastně je.

Informace o motivu je totiž uložena v Contextu. A podle toho, jakýContext použije LayoutInflater vytvářející vaše View (šikovná může být metoda cloneInContext()), takový motiv budou View mít.

Pokud chcete použít stejný motiv, jako obsahující Activity, je to jednoduché – LayoutInflater je už nasatven. Pokud chcete vlastní, musíte si vytvořit kontext s příslušným motivem a s ním naklonovat inflater.

Zajímavé následky to může mít i u Adapterů. Těm totiž také předáváte kontext, mimojiné aby si mohly vytvořit LayoutInflater. A pokud máte na <activity> nastavený jiný motiv než na <application>, je rozdíl jestli Adapteru jako Context předáte samotnou Activity, anebo objet vrácený metodou  getApplicationContext().

Závěr

Dnes jsme si prošli stylování od úplně začátečnických věcí až po poměrně pokročilé, které ani nejsou v oficiální dokumentaci (na tom by mohli soudruzi zapracovat…). Doufám, že jsem na nic důležitého nezapomněl, ačkoli vím, že jsem toho plno nestihl. Například takový color state list je rozhodně zajímavý, a navíc nepostradatelný, když chcete třeba změnit barvu položky ListView, která je právě stisknutá (viz android:listSelector). Nezmínil jsem se o 9-patchi a celkově jsem vůbec nepovídat o různých drawable surovinách, což vůbec nejsou jen nudné obrázky!

Doufám, že se vám dnešní článek líbil a že pro vás byl užitečný. Příště se budeme věnovat práci s internetem, broadcast receiverům, tomu, jak opakovaně provádět nějakou akci v určitý čas a možná se dostane i na notifikace.

Tip na konec

Chcete vyzkoušet, jak vaše aplikace funguje na telefonu bez hardwarových tlačítek? Stačí jako hardware property přidat Hardware Back/Home keys a její hodnotu nastavit na no. Pak se můžete třeba podívat, jak se chová naše aplikace z dílu Preference, menu a vlastní Adapter.