První kroky s API: praktický průvodce pro začátečníky

Prvním krokem je vytvoření testovacího projektu. V Visual Studiu nebo přes dotnet CLI přidáte nový projekt typu xUnit, ale pro NUnit si vyberete šablonu NUnit Test Project. Po vytvoření projektu získáte třídu s atributem [TestFixture] a metodami s [Test]. Atribut [TestFixture] označuje třídu, která obsahuje testy, a [Test] označuje jednotlivé testovací metody. Pro běžné testování stačí tyto dva atributy, ale v praxi využijete i [SetUp] a [TearDown] pro inicializaci a úklid prostředí před a po každém testu.

První funkční verze dříve než dokonalá Mnoho lidí tráví týdny nastavováním složitých architektur, které nikdy nepoužijí. Mnohem užitečnější je vytvořit jednoduchou aplikaci, která zobrazí text a po kliknutí na tlačítko změní barvu. Tento miniprojekt vás naučí práci s událostmi, změnou stavu a překreslením obrazovky. Když to zvládnete, přidejte druhou obrazovku s předáním dat. Takto postupně budujte funkčnost po malých krocích, nikoli skokově.

Základním stavebním kamenem je role produktového vlastníka. V českých týmech se často stává, že tuto roli převezme manažer nebo technický lead, ale to je cesta do pekel. Produktový vlastník musí mít čas na komunikaci se zákazníky, musí umět říkat ne a musí rozumět byznys hodnotě jednotlivých funkcí. Pokud tuto roli nikdo neobsadí na plný úvazek, sprinty se promění v nekonečné diskuse o tom, co je důležitější. Typická chyba? Backlog je neuspořádaný, položky nemají jasnou prioritu a tým si vybírá, co se mu zrovna líbí.

Častou chybou je testovat implementaci místo chování. Pokud testujete, že soukromá metoda vrací určitou hodnotu, znamená to, že test je závislý na vnitřním uspořádání třídy. Při jakékoli refaktorizaci pak test selže, i když chování zůstává správné. Místo toho testujte veřejné rozhraní a používejte mockování pro závislosti, jako je databáze nebo HTTP klient. Pro mockování v NUnit běžně používáte knihovnu Moq, ale lze i psát vlastní falešné objekty. Vždy se ujistěte, že testy jsou rychlé a nevyžadují síťové připojení – pokud potřebujete testovat přístup k API, použijte rozhraní a simulujte odpovědi.

Začít s vývojem pro Android není otázka talentu, ale správného postupu. Nejdříve si nainstalujte oficiální vývojové prostředí, které vám umožní psát kód, spouštět emulátor i ladit aplikace. Po spuštění vytvořte nový projekt s prázdnou aktivitou – to je základní obrazovka, kterou uživatel uvidí. Systém vám vygeneruje soubory s rozložením a logikou, ale nepokoušejte se hned vše přepsat. Projděte si strukturu, pochopte, kde se definuje vzhled a kde chování, a teprve poté začněte dělat první změny.

Pro testování nemusíte mít fyzický telefon, stačí emulátor, který je součástí vývojového prostředí. Ten dokáže simulovat různé velikosti obrazovek i verze systému. Důležité je ale testovat na více konfiguracích, protože to, co funguje na velkém displeji, se může rozbít na malém. Připravte se na to, že emulátor je pomalý, a proto si vytvořte vlastní zařízení s menším rozlišením, které se spouští rychleji. Ušetříte tím čas při každém spuštění.

Klíčové je naučit se číst dokumentaci. Většina API má popsány jednotlivé endpointy, povinné parametry a strukturu odpovědí. Začněte tím, že si najdete příklad požadavku, který si vyzkoušíte v prohlížeči nebo v nástroji pro testování API, jako je třeba Postman. Napište adresu podle vzoru, přidejte případné hlavičky a sledujte, co přijde. Pokud dostanete chybovou hlášku, nepanikařte – většinou říká přesně to, co se pokazilo. Často jde o chybějící parametr, špatnou metodu (GET vs. POST) nebo neplatný klíč.

Na závěr si osvojte práci s logy a výpisy chyb. Když aplikace spadne, nástroje vývojového prostředí vám ukáží přesný řádek s problémem. Místo hledání na internetu nejprve důkladně přečtěte chybovou hlášku – často obsahuje jasné vysvětlení. Pokud je příliš dlouhá, zaměřte se na první řádek, který obvykle popisuje jádro problému. Tento návyk vám ušetří hodiny zmatku a pomůže vám stát se samostatným vývojářem.

Klíčové je osvojit si dva základní jazyky: Kotlin pro logiku aplikace a XML pro popis rozhraní. Pokud neznáte žádný z nich, začněte Kotlinem, protože je modernější a oficiálně doporučovaný. U XML se naučte pouze základy – deklaraci tlačítek, textů a kontejnerů. Vyhněte se ale častému začátečnickému omylu, kdy se snažíte vše generovat z kódu. Rozhraní se má definovat v XML, ne v Kotlinu, jinak ztratíte přehled a aplikace bude nepřehledná.

Při psaní kódu vždy pamatujte na životní cyklus aktivity – metody, které se volají při vytvoření, pozastavení nebo zničení obrazovky. Typická chyba začátečníků je provádět těžké operace přímo v metodě pro vytvoření, což způsobí zpomalení nebo pád aplikace. Ukládejte data do proměnných, ale pro trvalé hodnoty používejte paměť zařízení nebo databázi. S tou ale začněte až po zvládnutí základů, jinak se utopíte v detailech.