První kroky při vývoji aplikací pro Android

Když jako vývojář dostanete návrh od designéra, často se soustředíte hlavně na to, aby kód fungoval. Ale UI a UX nejsou jen starostí designérů. I vy ovlivňujete, jak se bude aplikace používat. Tento průvodce vám ukáže, na co se zaměřit, abyste vytvořili rozhraní, které je nejen funkční, ale i příjemné pro uživatele.

Scrum není o tom, že budete dělat víc věcí za kratší dobu. Je o tom, že budete dělat ty správné věci a budete mít zpětnou vazbu dřív. Pro české týmy je klíčové, aby si ujasnily role, definici hotového a hlavně aby se nebály říct managementu, že něco nestihnou. Začněte malým pilotním projektem, ne celou organizací. Až uvidíte první výsledky, rozšiřte působnost. Jinak skončíte s byrokratickým monstrem, které nemá s agilitou nic společného.

Verzování kódu v projektech, kde se kombinují různé verze knihoven, bývá častým zdrojem chyb. Nejde jen o to, aby se aplikace sestavila, ale aby byla reprodukovatelná a aby každý člen týmu pracoval se stejnými závislostmi. Základní pravidlo zní: určete, co je pro projekt klíčové, a to verzujte explicitně. U malých projektů postačí zamknout přesné verze, u větších systémů je nutné zavést pravidla pro aktualizace a zpětnou kompatibilitu.

Interakce a zpětná vazba: co dělá UI živým Uživatel musí vždy vědět, co se děje. Když někdo klikne na tlačítko, mělo by se vizuálně změnit – ať už stisknutím, změnou barvy, nebo ikonou načítání. Pokud akce trvá déle než půl sekundy, zobrazte indikátor průběhu. Nikdy nenechávejte uživatele tápat, jestli se systém zasekl. Naučte se používat CSS přechody a animace s mírou – příliš mnoho pohybu odvádí pozornost, příliš málo působí stroze.

Začněte tím, že si rozdělíte závislosti na tři skupiny: stabilní knihovny s dlouhodobou podporou, aktivně vyvíjené knihovny a interní moduly. U první skupiny používejte striktní verzování, tedy přesné číslo verze bez wildcardů. U druhé skupiny si definujte rozsah, který povoluje menší aktualizace, ale ne zásadní změny rozhraní. Třetí skupinu, interní moduly, spravujte jako samostatné projekty s vlastním číslem verze a zveřejňujte je do lokálního úložiště. Tím získáte přehled, která verze čeho je v sestavení použita.

Prakticky doporučuji zavést automatizovaný skript, který ověří konzistenci verzí mezi všemi soubory projektu. Tento skript spusťte jako součást CI, tedy před každým nasazením. Měl by kontrolovat, že deklarované verze odpovídají skutečně použitým a že žádný modul neodkazuje na neexistující číslo. Dále nastavte pravidlo, že každá změna závislosti musí projít code review a musí být zapsána do changelogu. Tím se vyhnete situaci, kdy někdo tiše povýší knihovnu a až po měsíci se objeví problém v produkci.

Typické chyby a prevence Nejčastější chybou je spoléhání na „nejnovější dostupnou verzi". To vede k tomu, že se build chová odlišně na různých počítačích, protože prostředí stáhne pokaždé jinou verzi. Řešením je soubor zámků, který zaznamená přesnou verzi každé knihovny a také hash jejího zdroje. Tento soubor musí být commitnutý a nesmí se měnit ručně. Druhou častou chybou je aktualizace knihovny, která mění chování v jiné části projektu, aniž by to byl reflektováno v testech. Proto si před aktualizací spusťte celou testovací sadu a porovnejte výstup před a po změně.

Když se řekne agilní vývoj, většina českých týmů si představí Scrum. Není to ale žádná kouzelná hůlka – je to sada pravidel, která funguje jen tehdy, když jim všichni rozumí a dodržují je. Než začnete se sprinty a retrospektivami, ujasněte si jeden zásadní bod: proč vlastně chcete Scrum zavést? Pokud jen proto, že to „dělají všichni", narazíte. Scrum dává smysl u produktů s častými změnami priorit, kde zákazník neví přesně, co chce, a vy potřebujete rychlou zpětnou vazbu.

Základy, které musíte zvládnout, než půjdete dál Než se pustíte do složitějších funkcí, osvojte si práci s aktivitami a životním cyklem. Každá obrazovka v Androidu je aktivita a musíte vědět, kdy se vytváří, pozastavuje nebo ničí. Dalším nezbytným tématem jsou takzvané „intenty" – slouží k přechodu mezi obrazovkami nebo předávání dat. Zkuste si vytvořit aplikaci se dvěma obrazovkami, která po stisknutí tlačítka předá text do druhé aktivity. Tím získáte jistotu v základech, na kterých staví celá platforma.

Největší český problém je vztah k odhadům. Tým často vnímá odhady jako závazek vůči managementu, a proto buď nadhodnocuje, nebo se bojí říct pravdu. Odhady jsou ale pouze nástroj pro plánování, ne výkonnostní kritérium. Pokud management začne měřit rychlost týmu (velocity) a tlačit na vyšší čísla, tým začne uměle navyšovat odhady. Místo toho se zaměřte na stabilní tempo – pokud je rychlost konstantní, můžete plánovat s větší jistotou. A pokud tým dodává méně, než slíbil, řešte příčiny, ne čísla.