Převodník jednotek   –   verze 4.x.x

Po úspěšně zdolaných státnicích se naskytovaly dvě možnosti – jít dál studovat anebo být světu prospěšný. Bohužel UJEP neměl v nabídce navazující studium na obor aplikované informatiky; to, aby si na mě zvykali na další škole jsem už znovu podstupovat nechtěl, a tak jsem si zajistil práci ve společnosti Solitea CDL, a.s. (dříve CDL SYSTEM a.s.), kam vedla dál moje cesta. Nedlouho po ukončení školy jsem do firmy nastoupil jako programátor webové platformy SharePoint od společnosti Microsoft. V této době byl ještě můj postoj k Microsoftu a jeho produktům v čele s Windows, řekl bych, neutrální…

SharePoint je neuvěřitelně rozsáhlý projekt propojující neuvěřitelné množství neuvěřitelně splácaných kusů kódů od neuvěřitelného množství různých programátorů po celém světě. Naštěstí si toho byli vědomi i zaměstnanci a vedoucí osoby CDL, takže jsem měl dostatek času na to se vše naučit a se vším seznámit. Toto zaučovací období mělo trvat přibližně jeden rok. Nicméně po asi pěti měsících přišlo uvědomění toho, že se můj mozek pomalu transformuje v houbu. SharePoint se na mě začínal podepisovat a můj názor na Microsoft, nikoliv na CDL (!), se začal formovat. Nutně jsem se z tohoto kódového pekla potřeboval vyškrábat zpět do snesitelné reality a v tom jsem si vzpomněl na Android – a můj zanedbávaný Převodník, jehož kód mi po velkém množství nově nabraných zkušeností přišel jako bych ho ani nepsal já.

Aplikace musela být kompletně přepracována! Zde jsem pochopil, jak důležité je věnovat čas pořádnému návrhu i té nejjednodušší aplikace a vše dopředu detailně promyslet. Každý začínající programátor má totiž nesmírnou touhu vidět svůj pokrok co nejdříve, takže si bez většího promýšlení sedne k počítači a začne bastlit kód svého projektu. Projekt je to většinou menší a tudíž se v jeho průběhu začínají v hlavě rodit nápady na další vylepšení a obohacení softwaru o nové funkce. Právě zde ale často nástává problém, který nazývám lepení kódu – to znamená, že již vytvořený kód nemusí být na novou funkci dostatečně připraven a líný programátor začne novou funkcí obcházet již vytvořené mechanismy (například objektový model) a kód začne lepit, aby alespoň „tak nějak“ fungoval. To vede k tomu, že po vícero takto nalepených kusech kódu na sebe začne být kód nepřehledný, nepochopitelný a chybám začínají žně.

Musel jsem si tedy utvořit pevnou představu o tom, co od nové verze budu požadovat a jak ji nejlépe navrhnout s ohledem na její škálovatelnost. Z uživatelského hlediska jsem se chtěl zaměřit především na customizaci (individuální přizpůsobení) celé aplikace. Do této doby bylo možné pouze skrýt uživatelem nepoužívané jednotky a nastavit hodnotu zaokrouhlení. To už mi ale nestačilo – můj hlavní požadavek byl takový, aby si uživatel mohl jednoduše seřadit všechny jednotky a kategorie podle svých představ, případně je zneviditelnit. Dalším požadavkem byla co nejlepší možná optimalizace, hlavně co se velikosti aplikace týče. A v neposlední řadě bylo potřeba obohatit aplikaci o nějakou tu kategorii a nové jednotky.

Přiznám se, že následujících pár měsíců tohle všechno pro mě byla celkem dost výživná psychická zkouška. Za to, že jsem to přežil relativně bez újmy na zdraví, musím poděkovat jediné osobě, moji milované přítelkyni a budoucí již aktuální ženě Klárce, osobě s nesmírnou trpělivostí, která o mě vždy pečuje, jak nejlépe umí, a dává mi sílu překonávat ty nejtěžší překážky! ❤️🙏 Co si budeme nalhávat – život s programátorem není zrovna nejlepší předloha pro pohádkovou storku. Po zhruba čtyřech měsících neustálého střídání pracovního počítače, kde mi zabodával SharePoint jehly do mozku, a svého domácího notebooku, kde jsem bojoval s mým přílišným puntičkářstvím, vyšla dne 1. 4. 2017 nová verze Převodníku. Verze 4.0.0.

Nastavení se skládalo celkem ze tří karet – jazyk, kategorie a jednotky. Nemá asi smysl dlouhosáhle popisovat, co se dalo pod jednotlivými kartami nastavit. Stačí, že to měly karty v popisu (obrázek 2). Nastavení jazyka a kategorií bylo celkem intuitivní, ale nastavení jednotek mohlo působit zmatečně a bylo zdlouhavé. Přeskládat si totiž nějaké jednotky v konkrétní kategorii vyžadovalo lepší smysl pro orientaci, než má 96 % chlapů v nákupáku s oblečením.

Kromě ručního řazení jednotek/kategorií přibyla také možnost zapnout si jejich automatické řazení. Ty se následně začaly v seznamech řadit podle nejčastěji používaných. Logicky z toho vyplývá fakt, že si aplikace musí pamatovat, které jednotky uživatel převáděl a také kolikrát je převáděl. Tudíž od této verze se tyto informace v aplikaci udržují.

Poslední vychytávkou byla možnost nastavit si formát výběru pro jednotky v kategoriích. Toto nastavení se aplikovalo na rolovací seznamy s výběrem převáděných jednotek v převodním rozhraní. Do této verze bylo možné vybírat jednotky pouze podle jejich zkratek. Neznám třeba moc lidí, kteří by mi z fleku povyprávěli něco o jednotce L⨀, takže pokud má uživatel možnost přepnout si formát výběru jednotky na celý její název, určitě to ocení. Mimochodem, L⨀ je sluneční zářivost. A upřímně ani teď  se mi nevybavuje moc lidí, kterým by zrovna tato jednotka vyvolala v mozku nějakou aktivitu. 😏

Kromě komplexního nastavení přibyly ve verzi 4.0.0 mimo jiné kategorie točivý moment a jednotky PSI a tekuté unce. Verze 4.0.1 pouze opravovala chybu při změně jazyka na starších verzích Androidu.

Stejně jako v první verzi, tak ani v té čtvrté, nebyl problém přidat do Převodníku další jazyk. Tím se stala slovenština. A poněvadž mě na mé cestě životem dlouho doprovázel slovenský brat Jarko Ročkár, tak kdo jiný by mohl provést korekturu nad překladem tohoto krásného jazyka. Díky! 🙏

Následoval čas odpočinku, alespoň co se Převodníku týče. Microsoft se mi za tu dobu zhnusil do té míry, až se ve mě začala rodit fobie z oken. Z bytu musely být odstraněny samozřejmě ty s mým tehdejším notebookem. A já konečně přešel na něco, co funguje, a na co se lze stoprocentně spolehnout! 🍏 Tento stroj mi opět dovolil začít věřit v dobro a můj mozek se přestal požírat. Nicméně, pořád jsem byl zaměstnán v CDL a snášel nástrahy SharePointu…

Už když jsem s programováním pro Android začínal, věděl jsem, že chci vydávat i placené verze aplikací, absolutně bez reklam, s přidaným obsahem. Bohužel jsem si byl i vědom toho, co všechno to přináší za starosti. Byrokratické starosti! Prodej aplikací přináší zisk a zisk je ze zákona nutné danit. K tomu je potřeba živnost a k živnosti hromada nezbytných informací. Podnikání pro mě celou tu dobu byla neznámá sféra, v mém okolí nebyl nikdo, kdo by mi spolehlivě poradil a dokonale mě zasvětil. Moje potřeba mít ve věcech, ve kterých se pohybuji, naprostý přehled mi to jen ztěžovala. Jinak to ale nešlo, přeci se nenechám odradit trochou papírování. Byla to pouze další zkouška v cestě.

Ponořil jsem se tedy do studia podnikání a i když jsem věděl, že mě Převodník a jeho následná placená verze nemá šanci uživit, SharePoint dostal pápá. Každé povolání je důležité a i kdybych měl den co den jezdit lidem nabízet vysavače z jiných vesmírů, dělal bych to s větší radostí. Avšak, rád vzpomínám na všechny lidi z CDL a firmě děkuji za výrazný profesní posun! 🙏 Ať  je na vás SharePoint milosrdný, především na kluky z oddělení DX.NET!

Nastal mrtvý bod. Živnost se vyřizovala, výpověď  podaná. Co dál? Zákony přitažlivosti na sebe nenechaly dlouho čekat. Na UJEPu jsem měl možnost jako student tutorovat programování, na které (občas) docházel i Kuba. Nějaký ten rok o něm nebylo doslechu, přesto mě však dokázal vyhledat přesně v době, kdy jsem ho potřeboval, a nabídl mi možnost podílet se na projektech v oblasti internetu věcí (IoT) pro firmu BM Communications. V tomto oboru jsem byl naprostý začátečník, nicméně přišlo mi to při nejmenším jako dobrá příležitost naučit se něco zajímavého.

Dohledná budoucnost zajištěna a teď  nastal čas pro opravdový oddych. Jelikož ale moc odpočívat neumím, tak mi v hlavě pořád šrotovalo, co by mohlo Převodník posunout zase o kus dál. Uvědomoval jsem si, že jediná zpětná vazba od uživatelů vedla přes Google Play pomocí recenzí anebo skrze email dostupný i v aplikaci. Emailů s připomínkami mi za celý čas dorazilo poskrovnu a v recenzích si lidé na nic moc nestěžovali. Nechtěl jsem věřit tomu, že by byla aplikace tak dokonalá, spíše se přikláním k tomu (a chápu to), že je dnes při nespokojení snazší appku odinstalovat a vyzkoušet jinou, než napsat vývojáři kus textu s nějakým nápadem a pak čekat… a čekat… a čekat na zrealizování.

No, a jelikož má potřeba byla odpočinout si hlavně od programování, pustil jsem se do tvorby stránek. Nějaký čas jsem rozmýšlel, v jakém duchu se ponesou. Nesčetněkrát jsem při různých příležitostech narazil na nového člověka, který se zajímal o můj profesní život a vždy konverzace vedla od školy přes SharePoint k Androidu a Převodníku. Napadlo mě spojit všechno dohromady a začalo z toho vznikat to, co právě čteš. Důležité pro mě je, aby si tu každý, kdo na tuto stránku narazí z jakéhokoliv důvodu, našel to svoje…

Samozřejmě jsem také rozmýšlel nejvhodnější prostředek pro publikování stránek. Existuje několik možností. Jednou z nich je naprogramovat si vlastní stránky, což je celkem časově náročné a vyžaduje to znalost dalších technologií – to je pro mě velmi lákavá oblast a jednou na ní určitě dojde. Další možností je nechat si stránky naprogramovat, což zase vyžaduje nějaké ty finanční prostředky. Potom je zde k dispozici nepřeberné množství nástrojů pro rychlou tvorbu webových stránek – těmto nástrojům se snažím vyhýbat, netvrdím, že jsou špatné, ale žádný z nich neumožňuje takovou volnost, jakou má programátor při vlastním vývoji – to se ale zase dostáváme na první popisovanou možnost… Vlastní webové stránky jsem pro tuto chvíli zavrhl a začal se do hloubky zajímat o to, co jsou vlastně zač ty Stránky, které potkávám denodenně na Facebooku. Rovnou jsem si jednu založil, prozkoumal, co všechno má v této oblasti Facebook v rukávu, a můj závěr byl takový, že pro začátek je to ideální volba. Věci na sociálních sítích se šíří rychle, kór na té největší a nejznámější, uživatelé zde mohou komentovat a líbítkovat co jen chtějí a já můžu v rámci možností rychle reagovat. Paráda. Teď už jen zbývalo stránky napsat… 👨🏽‍💻

Stránky dostaly logickou strukturu a ve mě se opět začaly probouzet spisovatelské schopnosti. Právě v tento moment začal vznikat příběh Převodníku. Zároveň s tím jsem zabředával víc a víc do oblasti internetu věcí a mojí hlavní platformou pro vývoj se stal ThingWorx. Oproti SharePointu obrat o 169 stupňů! Důležitým faktorem bylo hlavně to, že jsem ThingWorx nevyvíjel, nýbrž vyvíjel jsem v něm. ThingWorx je nástroj pro jednodušší vývoj aplikací zaměřených na internet věcí. Z předchozího odstavce přesně ten typ nástroje, kterým se snažím vyhýbat. Paradox. S ThingWorxem se ale navzájem až do teď  tolerujeme a to i přesto, že na úkor své univerzálnosti a rychlosti vývoje poskytuje celkem malou svobodu.

Facebookové stránky s příběhem šly stranou a další velký milník nastal 29. 6. 2017, kdy vyšla CE verze Převodníku! Den poté dostala neplacená verze aktualizaci na verzi 4.1.1, ve které přibyla na přání jednotka metr vodního sloupce a samozřejmě odkaz na CE verzi. V tu chvíli jsem byl šť asten a spokojen a nic nebránilo tomu příběh Převodníku dopsat. Jenže období spokojenosti trvalo asi týden a rovnou se přiznám, že příběh byl dokončen až dlouho po vydání verze CE 2.0.1, přesněji na konci roku 2018! Ale nepředbíhejme…

Co mi v noci totiž nedalo spát bylo to nešť astné nastavení aplikace. Nějak jsem se nemohl přenést přes jeho neintuitivnost. Pátral jsem po vhodnějším řešení. Do toho ke mě neustále začalo promlouvat mé programátorské svědomí – aplikace byla neustále dost velká! 2,79 MB! Měl jsem obrovskou potřebu toto číslo dostat pod 2 MB. V době, kdy není problém vyfotit si večeři ve velikosti čtyřech megabajtů, si asi normální člověk pomyslí, že jsem blázen. Ale opravdoví programátoři znají ten pocit, když víte, že z toho kusu křemíku můžete vyždímat mnohem (mnohem!) víc a ještě ho přitom nechat trochu oddychnout.

Trvalo to další dva a půl měsíce, ale nakonec jsem to přeci jen dokázal. Velikost aplikace se mi podařilo stáhnout na 1,71 MB a nastavení se transformovalo, dle mého názoru, do mnohem elegantnější podoby. Zde se hodí dodat jednu drobnost – to, že se intervaly mezi verzemi pohybují i v řádech několika měsíců neznamená, že se vývoji věnuji každý den osm hodin. I když taková období tu také byla. 🤯 Bohužel mě aplikace neživí a věnuji jí pouze svůj volný čas, kterého je čím dál méně!

Další příjemnou novinkou byla možnost přeskládat si kategorie v hlavní nabídce přidržením a posouváním. Pouze ale pokud bylo nastaveno vlastní řazení kategorií! Tím se zase o něco snížila nutnost lézt do nastavení. Stejný princip jsem chtěl aplikovat i na jednotky v rolovacích seznamech v převodním rozhraní. V Android terminologii se tyto rolovací seznamy nazývají Spinnery. I když to zní neuvěřitelně, je snad nemožné této funkcionality v tomto prvku dosáhnout. Věřte mi, opravdu jsem se snažil!

Jak už to bývá zvykem, během chvilky vyšla opravná verze 4.2.1. Ta byla poslední čtyřkovou verzí, kterou mělo staženou na konci jejích dnů přibližně 13.794 lidí. A já pomalu začal promýšlet funkci, která konečně nabídne člověku pádný důvod k tomu pořídit si CE verzi.

Odborněji…

Jelikož jsem se až do nástupu do CDL vývoji webových aplikací vůbec nevěnoval, byla k seznámení se s SharePointem potřebná veškerá dostupná kapacita. Tudíž nebylo na Android nějaký čas ani pomyšlení. Jako první jsem se začal seznamovat s ASP.NET. To jest framework od Microsoftu pro tvorbu webových aplikací, který se snaží spojit programování backendu a frontendu aplikace dohromady. Obě části se píšou jak jinak než v C#, též vyvinut Microsoftem, čímž částečně vystrnadil z frontendu všemi programátory milovaný JavaScript – a z backendu převládající PHP. Pak už jen bylo potřeba míti nějaké znalosti HTML a CSS a weby bylo možné tvořit na počkání. Dlouhé počkání! Jelikož ve všem od Microsoftu se musí neustále na něco čekat. V tu dobu jsem to ještě tolik nevnímal, byl jsem především rád, že to všechno relativně v pohodě fungovalo. A pak přišel On… SharePoint!

Ti, co mají zkušenost s programováním nějakého produktu Microsoftu, moc dobře vědí, jaká je to pocta. Pro ty, co tu čest nemají: lze to přirovnat k déletrvajícímu lobotomickému zákroku. Ze začátku jsem byl samozřejmě plný nadšení, které ale začalo rychle opadávat. Vývoj SharePointu je takový nekonečný příběh – chyby, kam se jen podíváš, většinu času trávíš pouze jejich opravováním. Nějaká konzistentnost? Neexistuje! Jelikož je platforma vyvíjena lidmi po celém světě, promítá se do kódu jejich různá mentalita. Není tedy překvapením, že se například jedna a ta samá věc jmenuje v různých částech kódu jinak. Naopak také člověka nesmí zaskočit to, když se dvě naprosto odlišné věci jmenují stejně. Co ale bylo nejhorší? Ta doba! Build jednoduché aplikace trval něco kolem jedné až dvou minut. Když máš zrovna blbý den a po minutě zírání do zdi zjistíš, že se ti za for cyklem záhadně objevil středník a program nedělá, co by měl, počkáš si po opravě další minutu. V porovnání s Androidem, kde mi build trvá pár sekund, je to značný rozdíl. Abych ale na SharePoint neházel jen špínu – je mi jasné, že nemůžu porovnávat software typu Převodník jednotek s monstrózní webovou aplikací, jakou SharePoint je. Každopádně, tohle nebylo pro mě!

Když jsem se začal pomalu vracet k Převodníku, mým domácím strojem byl v té době celkem drahý ultrabook Lenovo IdeaPad U330 Touch s Windows 8. Jelikož to byl pro notebook výchozí systém, tak se na tom v rámci možností dalo i něco vytvořit. Ovšem, jednou z největších chyb v mém životě byl přechod na Windows 10! Bylo to v období, kdy Microsoft nabízel bezplatný upgrade na nejrychlejší a nejspolehlivější operační systém světa. Jelikož jsme měli desítky i v práci, a já mám konzistentnost rád, tak jsem na upgrade po delším váhání přistoupil. No prostě blbost. Počítač fungoval pár hodin v pohodě, dokud jsem do něj nenainstaloval mnou potřebný software, především ten pro vývoj. Ani se moc často samovolně nerestartoval. Přibližně pouze každý druhý den. 👌🏽

Jak bylo zmíněno někde v úvodu – Převodník potřeboval celý předělat a vše muselo být dopředu detailně promyšleno. Aplikaci jsem začal vyvíjet pro Android API 14, což byl Ice Cream Sandwich, v té době vládla Java 7. A jelikož nemůžu kvůli zpětné kompatibilitě jednoduše přejít na novější verze Javy, obsahující celkem užitečné funkce, mezi které patří například lambda výrazy, tak jsem si řekl, že by nebylo na škodu vyzkoušet programování Android aplikací v jazyce C#. De facto to byl můj první OOP jazyk, syntax je v pohodě, obsahuje oproti Javě vcelku moderní mechanismy, tak proč to nevyzkoušet. Pátral jsem tedy po nejvhodnějším IDE. Do této doby bylo pro Android jediným mnou používaným vývojovým prostředím Eclipse. Kdybych se rozhodl vyvíjet v Javě, tak si už samozřejmě stáhnu Android Studio, já se ale rozhodl pro C# a po chvilce studia jsem sáhl po Xamarinu, který mimochodem také koupil Microsoft. Xamarin slibuje nativní vývoj (a výkon!) aplikací skrze různé platformy – od Windows přes Android až po iOS či macOS.

Pár dní mi trvalo prozkoumat všechna zákoutí Xamarinu a vůbec sžití se s vývojem pro Android v C#. Překvapivě se mi to i líbilo. Začalo tedy testování všech potřebných částí mnou promyšleného návrhu aplikace – vstupní data už jsem nechtěl mít jen tak někde poházená v kódu, XML mi vyšlo jako nejlepší řešení tohoto problému. Dále byl také potřeba například důkladný systém pro ukládání dat, o tom ale až později… Neustále jsem se totiž sr*l s tím, že na notebooku věčně něco nefungovalo! Nehorázně mě to vytáčelo! Člověk prostě nemá chuť budovat na něčem, co má základy z bláta.

Zlomový okamžik přišel v jeden hezký podvečer. To si takhle programuješ a vyskočí ti hláška operačního systému: „Uložte si veškeré rozpracované dokumenty, počítač bude restartován… 3:00… 2:59… 2:58… 2:57…“. Říkám si, že jsem nejspíše opomněl vypnout automatické aktualizace/restart, kouknu do nastavení a tam vše zakázané. Odpočet běží dál a já se snažím o to dát Windowsům nějak vědět, že NECHCI restartovat počítač. Marně! Myslel jsem, že sním, ale systém opravdu po třech minutách ukončil všechny programy, restartoval se, začal aktualizovat, a jak už to bývá u Windows zvykem, trvalo jim to zhruba 15 minut. Jakože cože?! Co kdybych byl zrovna v tu chvíli na záchodě? To jako přijdu o svou neuloženou práci? Anebo, co kdybych na počítači zrovna prezentoval nějaký projekt před sálem plného lidí? No, alespoň by si kuřáci mohli dojít na cigárko… Lze to přirovnat asi k následující situaci – koupíš si nějaké modernější auto, upaluješ si to po německé (!) dálnici 240 km/h a najednou se objeví časomíra s tím, že auto bude aktualizovat firmware. Máš chvilku na to někde bezpečně zastavit, jelikož vozítko bude za okamžik mimo provoz. Pokud to nestihneš, Tvou brzdou se stane třeba kamion odnaproti!

Má zoufalost neznala mezí! Přeci jen ale existovala naděje. Na MacBook od Applu nebyly peníze, takže tou nadějí se stal Linux, respektive jedna z jeho distribucí. Nebyl jsem (a pořád nejsem) zkušený uživatel Linuxu, ale je všeobecně známé, že tento OS je pro práci s počítačem nenahraditelný. Bohužel, už jeho instalace nešla podle očekávání. Tím, že byly původně na notebooku Windows 8 a poté 10, tak byl disk nějak špatně naformátovaný a zůstaly na něm oddíly, které nešly smazat a způsobovaly chyby. Opravdu jsem zkoušel vše možné, při obnovení do továrního nastavení se nainstalovaly už jen desítky a problém beztak přetrvával. Žádný nástroj pro správu disku mi nepomohl. Nakonec jsem na disk nějakým záhadným způsobem nainstaloval linuxovou distribuci Ubuntu, která šla spustit. Okamžitě jsem chtěl disk naformátovat do stavu, kdy z něj nebude nikdy možné zjistit, že tam nějaký Windows byl. Překvapivě, s tím měl i Linux problém a při pokusu nad diskem cokoliv udělat házel chyby. Byl jsem notebookem tak znechucený, že mě to dále přestalo bavit řešit.

Co tedy dál? Začal jsem pátrat po tom, proč má Apple vlastně takové stádo věrných oveček. S produkty Applu jsem neměl žádné zkušenosti, ale po vyslechnutí pár přátel, kteří nějaký jabkoprodukt vlastní, a po přečtení několika článků na internetu, jsem měl jasno. Co mě ale hlavně přesvědčilo bylo uvědomění toho, kolik lidí mi vlastně macOS doporučilo kvůli naprosté spokojenosti s ním. Opravdu jsem nikdy nepotkal člověka, který by pronesl: „Ty vole, kámo, pořiď si Windows 10! Je to pro práci to nejlepší, co mě v životě potkalo!“. Další věcí bylo to, že macOS zakládá na jádře Unix, na kterém je postaven Linux. Samozřejmě pozitivních věcí, které Apple odlišuje od Microsoftu, jsou neuvěřitelná kvanta. Jediné, co to trochu kazí, je ta cena! Za kvalitu se holt platí. Jsem odpůrce půjček (a následných splátek), přesto mě ale Microsoft k jedné donutil… A rozhodně toho nelituji!

Klárka už si zvykla 😘 – mou další láskou se stal MacBook Pro 2015. Ihned jsme si padli do oka. Rychlost a hlavně chuť  do práce se rapidně zvýšily. Notebook byl najednou schopný při stejné rychlosti pracovat bez restartu i několik týdnů. Neuvěřitelné! A k onomu restartu mě beztak většinou donutila až nějaká větší aktualizace. Počítač se ovšem ale vždy zeptá, zda-li si uživatel, jeho pán, aktualizaci přeje nainstalovat a samozřejmě se o restart systému nejdříve dovolí. Prostě vše funguje, jak se očekává. Každopádně nechci, aby z předešlých řádků vyplynulo, že je macOS a celý Apple dokonalý. Nějaká chyba se sem tam také najde, ale v porovnání s Windows a Microsoftem je to jako porovnávat Teslu S s Multiplou. Doma už mi nic nebránilo pokračovat pohodlně ve vývoji Převodníku. Nicméně, všední den co den jsem se musel v CDL k Windowsům beztak vracet. O to víc jsem se ale těšil domů.

Opět přede mnou stálo nemalé rozhodnutí. Jaké IDE zvolit pro vývoj na novém stroji? S Xamarinem jsem vlastně problém neměl, s C# také ne. Xamarin byl, jako dnes už většina nástrojů, také pro macOS, pokračování tedy probíhalo v něm. Ihned po instalaci jsem ale začal litovat – spolu s ním se do počítače automaticky nainstalovalo různé harampádí (mnou nepotřebné aplikace), které se nedalo částečně odinstalovat/smazat, což vyloženě nesnáším. Prostě co jedna aplikace, to jedna zástupná položka (ikona) v seznamu aplikací – stejně jako to má Xcode, IntelliJ IDEA či Android Studio. Následoval import projektu z dřívějších Windows. Opět problém! Chyběly různé knihovny, neseděly reference… Řešením jsem strávil nějaký čas a stejně se mi nepodařilo projekt rozjet bez toho, aniž bych musel natvrdo vypnout kontrolu některých typů chyb, což je mi opravdu proti srsti. Navíc jsem v tomto období narazil v CDL na primitivní chybku jazyka C#, díky níž jsem dokázal naprosto odrovnat celý virtuální Windows server, kde běžel SharePoint… Pohár trpělivosti přetekl a já se v tomto bodě zařekl, že pokud to půjde jinak, tak nechci mít s Microsoftem a jejich produkty nic společného! Bez sebemenšího zaváhání jsem přešel na Android Studio a zpět na Javu. Také se ve mě vzbudilo přesvědčení, že nejlepší možností pro vývoj jakékoliv aplikace pro jakoukoliv platformu, je její programování v nativním jazyce.

Nechť  si z předešlých odstavců vezme každý to své. Po dlouhé době jsem měl před sebou opět čistý stůl s promyšleným objektovým modelem Převodníku. Ten samozřejmě zahrnoval rozdělení částí na MVC (Model-View-Controller), což je návrhový vzor, zde spíše architektonický vzor. Zobrazovací vrstvu (View) asi nemá cenu popisovat, jedná se o propojení logiky programu s vrstvou, kterou vidí uživatel – v tomto případě jde tedy o to pochopit platformu Android a dokázat na ní svůj program navázat. Logiku programu (Controller) má určitě cenu popisovat, a to především v dokumentaci, kterou programátoři dozajista nadevše milují. Je to ta část, která se jednoduše řečeno dá vzít a přenést do jiné platformy či do jiného jazyka s minimálním množstvím úprav – většinou by mělo jít pouze o přizpůsobení danému jazyku. Hlavní náplní kontroleru je propojit zobrazovací vrstvu s datovou vrstvou (Model) a vhodně obě části řídit v závislosti na uživatelově interakci. V tento moment jsem byl zaměřen hlavně na datovou vrstvu. Což ovšem neznamená, že bych ostatním dvěma nevěnoval potřebnou péči…

Potřeboval jsem vyřešit dva zásadní problémy datové vrstvy – kde/jak mít uložena vstupní konstantní data a jak/kam ukládat konfigurační data. Vstupní data jsou například názvy a zkratky jednotek, případně jejich převodní rovnice. Konfigurační data jsou především ta, která udržují uživatelovo nastavení. Jelikož aplikace najednou umožňovala nastavit opravdu dost věcí, od pořadí a viditelnosti všech jednotek a kategorií až po zaokrouhlení a formát výběru v každé kategorii, tak jsem přesvědčen o tom, že by uživatel nerad nastavoval vše při každém spuštění znovu. Mezi konfigurační data řadím i ukládání interních informací, kterými jsou třeba data o využívání jednotek pro možnost automatického řazení.

Možností, jak mít vstupní data uložena, existuje celá řada. Porovnáváním metod a následným testováním jsem strávil nemálo času. Samozřejmě byla nutná ta nejlepší, rozumějme ta nejrychlejší a nejlépe optimalizovaná. Na jedné straně váhy stála SQLite databáze, na straně druhé XML soubor. Nejsem databázový expert, ale při testech ve mě vyvstával pocit, že SQLite není tou správnou volbou – přeci jen databáze by měly sloužit pro ukládání většího množství měnících se dat, ne pro pár názvů jednotek a jejich zkratek. Vítězem se tedy stal formát XML. Následovalo zkonstruovat co možná nejlépe optimalizovaný parser. S výsledkem jsem byl spokojený, nicméně mě neustále něco šimralo za pravým okem…

Pro ukládání konfiguračních dat jsem zvolil binární soubor, interní pouze pro aplikaci. V tomto období bylo mou největší zálibou generické programování, čehož jsem využil a napsal si tak vlastní jednoduchou generickou třídu pro ukládání jakýchkoliv serializovatelných datových typů, nazvanou jednoduše Saver. Tuto třídu jsem si oblíbil natolik, že na její popud vznikla má první Android knihovna, která byla časem pěchována mými dalšími a dalšími kódy. Knihovna dostala i patřičný název, pojmenoval jsem ji Android Little Servant (ALS), v češtině Android služebníček. Dle mého názoru, každý Programátor si syslí nějakou vlastní knihovničku svých majstrštyků. Je to logické a hlavně nevyhnutelné!

Jednou z dalších tříd hodna užívat si slávu v ALS se stala třída Updater. Jedná se o třídu, která řeší transformaci konfiguračních dat při updatu aplikace na novější verzi. Samozřejmě bere v potaz i například situaci, jakou je aktualizace s přeskočením nějaké verze atp. Uživatelé dřívějších verzí si mohli všimnout toho, že si museli aplikaci při některých updatech znovu nastavovat. Stávalo se tak v momentech, když jsem potřeboval provést nějakou transformaci uložených dat a aplikace na takovou situaci nebyla připravena. Naštěstí ale ještě nebylo toliko co nastavovat. 🤭

Jeden z mých hlavních požadavků na tuto verzi aplikace byl snížit její velikost na minimum. V tom mi pomohl nástroj ProGuard, který je součástí Android Studia, respektive součástí jednoho z jeho pluginů – automatizačního nástroje Gradle. ProGuard dokáže analyzovat bajtkód a následně ho zoptimalizovat a to například tak, že vyhledá nedosažitelný kód, který z programu vyřadí. Ostatní černá magie pro mě zůstává nadále záhadou. Mezi další fajnové věci, které Gradle dokáže, můžeme zařadit obfuskaci kódu. Tento proces si vezme do parády lidsky čitelný kód programu a vytvoří z něj skvělý rébus na dlouhé zimní večery. Kód zůstane funkčně naprosto totožný, avšak jeho obsah (například názvy tříd, metod či proměnných) je zaměněn za nic nevypovídající. Pochopit tak logiku většího obfuskovaného projektu je pro člověka nadlidský úkol. Je to tedy výborná věc proti nechtěnému modifikování a kopírování kódu. Nicméně, obfuskace je dobrý sluha, ale zlý pán – dokázala mě totiž pěkně ztrestat.

Dobrá rada všem, kteří ještě nenarazili: opravdu si dávejte pozor na vražednou kombinaci v podobě obfuskovaného kódu s ukládáním vlastních serializovaných tříd! Samo o sobě to vypadá neškodně a funkčně. Což také je, do doby, než se rozhodnete v nové verzi aplikace přidat do balíčku třídu, která abecedně předchází třídě, která se serializuje a ukládá. Postačí klidně přidat i nějaký nový balíček, třídu přemístit anebo nějakou jinou třídu smazat. Obfuskací nové verze aplikace se totiž může narušit cesta ke třídě a ta se potom nemusí shodovat s uloženou serializovanou třídou z verze minulé! I když je to v podstatě ta samá třída. Existují možnosti, jak se tomuto problému vyvarovat, jedna z nich je například vyřadit třídy, které se serializují, z procesu obfuskace. To si ale musíte uvědomit dříve, než aplikaci vydáte. To mě bohužel nenapadlo a tak jsem se při vydání verze 4.2.0 pořádně potrápil. Musel jsem zabrousit hluboko do tajů serializace Javy a tento zásadní omyl tam napravit.

Verze 4.2.0 také zmírnila mé šimrání za pravým okem. Neustále jsem přemýšlel nad parsováním vstupních dat ze souboru XML. Samotné parsování trvalo při spuštění Převodníku pár set milisekund a tím, že se parsovala všechna data, zabírala také několik stovek kilobajtů v RAMce. Zanedbatelné. Přesto zbytečné! Co mi vadilo nejvíce bylo, že 95 % rozparsovaných dat nebylo uživatelem za dobu spuštění využito. A další velký problém byl v tom, že jsem do XML nemohl rozumně zapsat převodní rovnice. U všech kategorií, které Převodník zatím obsahuje, si člověk vystačí u převodu pouze s převodním koeficientem, což je jedno číslo, kterým se buď  násobí nebo dělí, celé to ovšem boří kategorie teplota, kde se navíc sčítá a odčítá. Převodní rovnice jsem měl nakonec tedy zapsané v kódu, tím pádem byla vstupní data rozházená na vícero místech. Touha po tom to všechno zrychlit, optimalizovat a sjednotit se neustále zvyšovala. Rozhodl jsem se posléze vrátit ke starému způsobu uložení dat s mírným vylepšením. To vyústilo v řešení, kdy jsem vytvářel předem zkonstruované objekty jednotek a kategorií v kódu lenivým vykonáváním. Objekty byly tvořeny až když to bylo skutečně potřeba a téměř okamžitě. Navíc jsem tím umožnil Javě případnou automatickou optimalizaci kódu při kompilaci aplikace.

V této verzi došlo i k další optimalizaci velikosti aplikace. Tentokrát pomocí online nástroje pro kompresi PNG obrázků. Takovýchto nástrojů existuje celá řada, mě se zalíbil nástroj TinyPNG, který dokázal komprimovat velikost obrázků při zachování stejné kvality průměrně o 90 %. A to chceš!

No, a jak už jsem se o tom rozpovídal v první části článku, zde nastal hlavní převrat ve způsobu nastavení. Samotná vysouvací lišta se zatmavením pozadí není žádná věda. Toto řešení přineslo ovšem další problém k řešení. Jelikož už nastavení neprobíhalo v oddělené aktivitě, nýbrž nad aktivitou, jejíž části byly nastavovány, musel jsem díky mému smyslu pro detail zajistit promítnutí nastavení v reálném čase do potřebných komponent. To znamená, že pokud například uživatel v nastavení v hlavní nabídce přesouvá (řadí) kategorie, musí se v ten samý okamžik řadit kategorie na pozadí (ve ztmavené části vedle lišty). To samé platí u z(ne)viditelnění, přepnutí na automatické či manuální řazení atd. Vše se muselo samozřejmě přizpůsobit tomu, aby se hlavně při rychlém přesouvání pozadí nesekalo a obraz zůstal pěkně plynulý. Každopádně ten největší problém nastal u Spinnerů. S tímto prvkem mám celkově v Androidu vždy největší starosti. V tomto případě metoda notifyDataSetChanged nad adaptérem Spinneru nefunguje úplně podle očekávání jako všude jinde. O tom jsem ale v první verzi Převodníku neměl ani tušení a vzdát se Spinneru, jakožto hlavního rysu aplikace, mě bolí na srdéčku. Navíc nevím, jak bych ho adekvátně nahradil. I když – v momentě psaní těchto řádků už se mi nějakou dobu jistý nápad rýsuje… ✌🏽

PS: Další povídání budou už jen kratší… Slibuji!