Převodník jednotek   –   verze CE 2.x.x

Už na začátku mé programátorské kariéry jsem věděl, že Převodník bude mít i placenou verzi, která nabídne uživateli něco víc. Hned po vydání posledních verzí (4.2.1, CE 1.1.1) jsem intenzivně promýšlel, co za funkci by to mělo být. Na mysl mi mimo jiné přišel i velmi důležitý prvek, kterým je vyhledávání jednotek. Něco ve mě mi ale šeptalo, že to není ta pravá funkce. Nepřijde mi fér, aby vyhledávání bylo výsadou těch, kteří přispějí na vývoj.

Jeden uživatel mi kdysi poslal námět na funkci, která zobrazí uživateli převodní koeficient. Velmi jednoduchá záležitost u kategorií, kde je přepočet závislý pouze na násobení daným koeficientem. Ale ta teplota! To je průser… Jelikož se zde i sčítá.

Jak toto vyřešit? Častá otázka, kterou mi můj mozek generoval v každé chvilce odpočinku. Dny ubíhaly, já se trápil, ale nakonec to stejně přišlo! Zobrazení kompletní převodní rovnice namísto pouhého převodního koeficientu. To je přesně Ona, funkce, která CE verzi razantně vylepší. V tu chvíli jsem ale netušil, co za mňamózní chuť ovčičku jsem si to naservíroval na následujících pár měsíců…

📛 Pozor! Trocha matematiky! 📛

Pro to, aby mohla aplikace převést jednotku do jiné jednotky, potřebuje v sobě mít samozřejmě uloženou rovnici převodu. Z metrů na centimetry je to [cm = m * 100], z metrů na kilometry je to [km = m / 1000] a tak dále. Je jasné, že musejí existovat rovnice i s opačným výpočtem, například [m = km * 1000]. Tím pádem se může zdát, že v kategorii musí existovat x² rovnic, kde x je počet jednotek v kategorii (pro jednoduchost algoritmu zahrnuji i převod jednotky ze sebe do sebe sama). Bezesporu je výhodou uvědomit si ekvivalenci (rovnost) [m = km * 1000] s [m = km / 0.001].

Určitě některé hlavičky ihned napadne, že rovnic nemusí být x². Stačí si zvolit v kategorii jednu základní jednotku a převody provádět přes ní. Přesně to je optimalizace. V délce si jako základní jednotku volím metr. Pak mi stačí pouze rovnice převodů z metrů na ostatní jednotky a z ostatních jednotek na metry, tudíž je najednou počet rovnic 2 * x (pro jednoduchost algoritmu obsahuje základní jednotka převod ze sebe do sebe sama dvakrát – jednou „z“ a podruhé „do“). V praxi probíhá převod z centimetrů na kilometry následovně: algoritmus provede převod z centimetrů na metry [m = cm / 100] a pak z metrů na kilometry [km = m / 1000]. Složená rovnice tedy vypadá takto [km = cm / 100 / 1000].

Pokud je v kategorii 15 jednotek, tak pro mě jako líného programátora je veliký rozdíl, jestli má být rovnic 15² (225) anebo 2 * 15 (30). Jednak se snižuje velikost aplikace a hlavně to šetří práci. Programátorovi, nikoliv výpočetní jednotce!

🌈 Konec matematiky! 🌈

Krátke matematické intro do problému máme za sebou. Varianta, že bych rovnice zobrazoval uživateli ve tvaru [km = cm / 100 / 1000] pro mě byla naprosto nepřijatelná. Logicky správně je to přeci [km = cm / 100000]. Ale těch nehezky vypadajících zbytečných nul! Mnohem lépe to vypadá přeci takto [km = cm / 10⁵], případně takto [km = 10⁻⁵ * cm].

Co s tím? Ihned mě napadlo vytvořit si vlastní zjednodušovač rovnic, který by je upravoval do elegantních podob. Stejně rychle jako nápad přišel, tak jsem ho zase nechal odejít, jelikož to není úplně sranda. Znamenalo by to vytvořit něco asi tak z miliontiny procenta podobného Wolfram|Alpha. Další možností bylo porozhlédnout se, zda-li už někdo nenabízí volně ke stažení kusy kódů, které by tento problém řešily. Pár řešení mi Google naservíroval, ale jak už jsem dopředu tušil, nic se nevyrovnalo mnou požadujícím kvalitám. Dále bych mohl využít Wolfram|Alpha a jeho služeb, kde bych rovnice po síti posílal na jeho servery a ten by mi z nich udělal to pravý ořechový. Ovšem, to by pro uživatele ve výsledku znamenalo mít zařízení připojené k internetu a já bych musel za takovouto službičku platit raketu.

Dny ubíhaly a nemohl jsem uvěřit tomu, že budu opravdu muset sepsat x² rovnic za každou kategorii tak, aby rovnice vypadaly podle mých očekávaní. Jakože najednou sepsat nejméně 3000 rovnic? Přemlouvání se trvalo dlouho, ale nakonec to bylo jediné řešení. Utěšování přicházelo v podobě toho, že to celé udělám vlastně jen jednou a pak při přidávání nových jednotek už to bude hračka. Jen jsem doufal, že se tím aplikace nijak razantně nezvětší. Této funkci bych obětoval maximálně 1 MB, což bylo navýšení velikosti zhruba o 88 %.

Téměř po 15 hodinách čistého času bylo hotovo! Tři kategorie! Rovnice musely mít totiž ještě specifický formát kvůli použitému vykreslovači, proto se to táhlo jako smrad v lese. Ale já každým okamžikem té otrocké práce věřil! Věřil jsem, že je to pro dobro lidstva! V tuto chvíli nebylo na škodu zkusit z aplikace vytvořit výsledný balíček a zjistit, o kolik kilobajtů narostla… Celková velikost 4,5 MB?! Po třech kategoriích?!… Tak jsem si zatleskal k příjemně stráveným pár hodinám a začal bušit hlavou do zdi. To přeci nejde, vždyť  by výsledná appka měla třeba 20 MB! Okamžitě započalo hledání nějakého bezeztrátového kompresního nástroje, který je schopen informace v podobě textu zmenšit. A to o dost! Ihned mi bylo jasné, že je bláznoství takovýto nástroj vůbec hledat, takový, jež by mi velikost textových dat stlačil nejméně o 95 %.

Nebudu nikomu lhát, byl jsem z toho trochu zarmoucený, ale Klárinka mě v tom opět nenechala. Děkuju! 🙏 Tušil jsem totiž, že napsat si svůj vlastní zjednodušovač rovnic zabere dost času. Protože bude muset být samozřejmě co nejvíce univerzální a připraven úplně na všechno!

Vlastní klávesnice. To je prvek, který jsem zamýšlel implementovat již delší dobu. Důvod? Android. Do této verze využíval Převodník nativní klávesnici systému. Tu si může vývojář do jisté míry přizpůsobit. V převážné většině kategorií se jako vstup využívají pouze čísla a znaky „.“ a „-⁠“. To lze nativní Android klávesnici také nastavit. Bohužel ale ne vždy tato funkce funguje. Přesněji řečeno, funkce funguje v každém Androidu a každé nadstavbě výrobce jinak. Většinou tak, že klávesnice nastavení „pouze číselný vstup“ úplně ignoruje a nabízí vždy kompletní alfanumerickou klávesnici. To mi hodně vadilo. Většina plochy klávesnice zabírala písmena, která ani na vstup nešla vložit.

Grafická stránka aplikace také nezůstala bez povšimnutí. Ať  už je řeč o zmenšení ikon v hlavní nabídce či o dodržení konzistentnosti týkající se velikosti mezer mezi prvky, nejzřetelnější změnou je dozajista úprava vysouvací roletky u Spinnerů. Dostala oranžové ohraničení a šedé pozadí. Určitě též potěší zvýraznění vybraných jednotek.

Ani tato verze se neobešla bez následné opravy ve verzi CE 2.0.1. Co je ovšem důležité – vydáním této verze jsem se zařekl, že dokud nedokončím přes jeden a půl roku dlouho rozpracované stránky s příběhem Převodníku (tehdy ještě na Facebooku ve formě Poznámek), tak další aktualizace aplikace nevyjde!

Nastala dlouhá doba neaktivity, kdy jsem se snažil zaměřit převážně na ThingWorx, mojí hlavní obživu. Přiznávám, že jsem si od Převodníku potřeboval i trochu odpočinout a začít se věnovat také nějakým běžným lidským aktivitám. Přeci jen netoužím celé mládí prosedět před monitorem. Ve volných chvílích jsem tedy alespoň tvořil obsah stránek, čemuž léto 2018 moc nepřispívalo – v permanentních čtyřicítkách se člověku nechce ani žít, natož něco srozumitelného vymýšlet.

Takže až o Vánocích 2018, kdy rtuť  teploměru spadla alespoň pod 288,15 kelvina, byly facebookové stránky konečně hotové (dnes nahrazeny těmito). Jejich odhadovaná časová náročnost jednoho týdne se protáhla na úctyhodných cca 19 měsíců. Ale jak se říká – lepší pozdě, nežli nikdy!

U konce popisu verze 4.x.x jsem se zmínil, že při jejím psaní mě napadlo, jak se zbavit těch proklatých Spinnerů. Tento nápad mě v hlavě při dokončování stránek hlodal často – byly momenty, kdy jsem chtěl opět stránky odložit a začít kódit aplikaci. Ale tímto stylem by to nešlo, jelikož už jsem stránky musel dodělat…

Na nové verzi jsem tedy začal pracovat hned začátkem dalšího roku (2019). A po dlouhých 14 měsících se Převodník dočkal další aktualizace – verze CE 2.1.0, případně 5.1.0.

Také mě napadlo, že by šlo výběr jednotek malinko urychlit – při kliknutí na horní (teď  už) tlačítko se vysune lišta pro výběr jednotky, ZE které se má převádět. Po výběru se lišta nezavře, ale je ihned umožněn výběr jednotky, DO které se má převádět. Ovšem při kliknutí na dolní (teď  už) tlačítko se vysune lišta pro výběr jednotky, DO které se má převádět. Zde už se ale vybírá pouze jednou. Nad tímto chováním jsem přemítal často – hlavně opět nad tím, zda je to tak žádoucí. Snad si uživatelé zvyknou a doufám, že je to krok k lepšímu.

Za tu dlouhou dobu nečinnosti u mě také přistálo pár požadavků od uživatelů, aby jsem do Převodníku přidal nějaké nové jednotky. Jednou z nich je centisekunda. Upřímně netuším, kde se tato jednotka používá, ale budiž. Další byly palce čtvereční a stopy čtvereční. Tím jsem si uvědomil, že dokonce i angloamerické jednotky mohou mít více rozměrů než jeden, a tak jsem jejich většinu obohatil o nejen druhý, ale rovnou i třetí rozměr. Ověřit si to lze samozřejmě v příslušných kategoriích – plocha a objem.

Posledním novým prvkem ve verzi CE 2.1.0 bylo v možnostech aplikace lákadlo na facebookové stránky.

Proč tomu tak bylo jsem z velké části odůvodnil zde. Vývoj aplikace mi zabíral velké množství volného času – ano, spoustu věcí jsem se díky tomu naučil, takže toho určitě nelituji, ale celý můj život se točil neustále kolem stejných aktivit a technologií – programování v práci, programování doma, pár chvilek s přítelkyní a sem tam nějaká hospoda a velmi zřídka i sport. Cítil jsem chtíč zkoušet a učit se nové věci a trochu svůj život přeorientovat.

Pořídili jsme si psa Nicka, začal jsem s ním aktivně a pravidelně chodit na procházky, přítelkyně se stala mou ženou, začali jsme jezdit na dovolené… Prostě normální dospělácký život, jehož chod mi začátkem roku 2021 narušil Kicom a jeho Bitcoinovej kanál.

Svou první kryptohorečku jsem sice zažil již v roce 2017, ale teprve až Kicom mě navnadil k tomu začít se zajímat o pravou podstatu kryptoměn (shitcoinů) a především pak Bitcoinu. Během tohoto období budily můj zájem i další věci, mimo jiné tvorba vlastních webových stránek, které by sloužily jako rozcestník mě samotného, mých projektů a i jako místo, kde bych si mohl vylévat srdíčko (blog). Výsledkem je samozřejmě projekt vsechnojejedno.cz. A co to má společného s Převodníkem?

Původně, jak už jsem tu několikrát zmiňoval, existovaly celé stránky Převodníku na Facebooku ve formě Poznámek. Jenže asi v roce 2020 Facebook zrušil možnost vytvářet nové a editovat staré Poznámky u svých Stránek – de facto zrušil podporu a vývoj Poznámek. Takže všechny odkazy v Převodníku směřující na facebookové Poznámky se staly neplatnými, respektive platné byly, ale Poznámky byly „zdeformované“ a nevypadaly tak, jak bylo zamýšleno. Tudíž jsem měl pádný důvod k tomu všechen obsah přenést na tyto webovky. Po tom už bylo potřeba pouze změnit odkazy v Převodníku.

To byl hlavní důvod toho, proč jsem se k Převodníku na chvilku vrátil a následkem čehož vyšla dne 1. 8. 2022 verze CE 2.2.0. Neplacená verze 5.2.0 vyšla o dva dny dříve. V obou verzích byly opraveny drobné chyby a bylo přidáno pár nových jednotek na základě přání uživatelů.

A proč jsem tu psal o Kicomovi a Bitcoinu? O tom více v další kapitole příběhu, které se to týká spíše…

Odborněji…

Než jsem se vůbec pustil do řešení zobrazování rovnic, musel jsem se nadobro zbavit toho otravného šimrání za pravým okem, které zapříčiňoval způsob uložení vstupních dat. Sice už data nebyla uložena v XML, nemusela se parsovat, ale jejich styl uložení pro mě přesto nebyl dokonalý. Tou dobou jsem do hloubky začal prozkoumávat výčtové typy jazyka Java, které právě v Javě fungují diametrálně jinak, než v ostatních jazycích. V Javě se podobají spíše klasickým objektům – mají konstruktor, metody, mohou implementovat rozhraní, k dokonalosti jim chybí pouze možnost dědit. Všechny členy výčtového typu jsou defaultně konstanty (final static) – musejí být definovány ihned. Přesně to se mi hodilo do krámu. Uvědomuji si, že lze výčtové typy jednoduše nasimulovat klasickými třídami, ale věřím, že pokud existuje prostředek vytvořený konkrétně pro daný účel (zde práce s konstantami), tak může být v jádře mnohem lépe optimalizovaný, nejlépe už při překladu aplikace.

Když už jsem byl v tom, rovnou jsem provázal výpočty a rovnice jednotek mezi sebou tak, z čeho jsou doopravdy odvozeny. Tudíž pokud je v rychlosti jednotka kilometr za sekundu, tak se její rovnice skládá z rovnic kilometru z délky a sekundy z času. V délce je zase kilometr odvozen z metru a z předpony kilo – právě proto vznikla v této verzi nově kategorie předpony. Z toho také vyplývá, že výsledné rovnice vypadají ještě hrůzostrašněji, než jsem je popisoval v matematické části výše, zjednodušovač byl prostě potřeba!

Před započetím prací na zjednodušovači rovnic bylo ještě vhodné vyřešit zádrhel s jejich výsledným zobrazováním. Vykreslit rovnice tak, aby vypadaly krásně, tedy aby zlomky vypadaly jako zlomky, které jsou zároveň zarovnány se znaménky, odmocniny vypadaly jako odmocniny, mocniny jako mocniny, to není rozhodně běžná věc a určitě žádná legranda. Ihned mě napadlo, že si napíšu takovou věc sám. Ale žádné strachy, nejsem magor!

Opět nastalo to úmorné období hledání vhodného způsobu, testování různých knihoven, zabydlování se na fórech. Věděl jsem, že se zobrazováním takové věci vyvstanou další problémy – každá rovnice je přeci jinak velká, vykreslovač musí umět měnit velikost. Musí také umět měnit barvu písma, nejlépe i styl. Nějaké knihovny od fanoušků pro Android existují, ale žádná překvapivě nevyhovovala mým nárokům. Setkal jsem se opět i s online řešením, kdy aplikace odešle na server rovnici v textové podobě a ten následně rovnici pošle nazpět ve formě obrázku. K tomu jsem se nechtěl uchýlit.

Spása nakonec přišla v podobě knihovny KaTeX. Je to opravdu excelentní projekt řešící přesně můj problém. Knihovna vykresluje rovnice velmi rychle, zabírá několik desítek kilobajtů, má výbornou dokumentaci a podporu na GitHub. Jediné, co mě na ní zezačátku odrazovalo, bylo její určení pro web. Knihovna využívá skriptovací jazyk JavaScript, značkovací jazyk HTML a stylovací jazyk CSS. Takže vlastně s Javou v Androidu to nemá nic společného. Pro ty, co nevědí – JavaScript s Javou mají společná pouze čtyři písmena v názvu.

Přesto všechno však není v Androidu potíž tyto jazyky používat. Vždyť  ve webovém prohlížeči na mobilu může uživatel také surfovat po internetech. Stačí mít pouze kódy, v tomto případě knihovnu KaTeX, staženou lokálně v projektu (v Převodníku) a pro vykreslení webového obsahu krásně poslouží nativní Android prvek WebView. Pak už to chce jen čas na pohrání si s KaTeXem, ovládat výše zmíněné webové technologie a generování rovnic je brnkačka.

Jedinou nepěknou věcí je né úplně korektní vykreslení rovnic na starších Androidech, přesněji na starších verzích než je Android 4.4 KitKat. Právě v této verzi došlo v prvku WebView k nahrazení webového vykreslovacího jádra WebKit od Applu, používaného především v Safari, za renderer Chromium od Googlu, základního kamene prohlížeče Chrome. Hlavní vadou na kráse je, že zlomky nejsou horizontálně zarovnány s ostaními matematickými znaménky. Tímto se dotčeným uživatelům omlouvám a věřím v malý a stále se snižující počet zařízení s takto „starým“ Androidem.

Takže vykreslování by bylo zařízeno, stačí už jen rovnice zjednodušit a dostat do formátu, se kterým si KaTeX bude notovat. Zjednodušovač jsem samozřejmě tvořil jako modul, nezávislý na aplikaci. Bylo zapotřebí vymyslet objektový model, vstupní/výstupní formát rovnic a vůbec to, jakým způsobem bude ve skutečnosti zjednodušování probíhat.

Nejtěžší na tom všem bylo zvážit, jaká pravidla vlastně musí výsledné rovnice dodržovat. Jde přesně o takové to rozhodování „Co je lepší?“, přičemž co člověk, to názor. Například pro 1.000.000 je určitě hezčí zápis 10⁶. Ale zase 100 je podle mě vhodnější nechat tak, jak je, než-li ho zobrazovat jako 10². Co je tedy tou hranicí, kdy je lepší použít exponenciální tvar čísel? Kolik nul má být na konci čísla tolerováno? Kolik nul má být tolerováno na začátku čísla, jestliže se hodnota pohybuje třeba v jednotkách miliontin? Je příjemnější pohled na rovnici v podobě [m = 1000 * km] anebo [m = km * 1000]? A co případ [-x + y]? To už radši [y – x], ať  tam není zbytečně znaménko navíc, nebo ne? Řešení závorek, hlavně v případě teploty, to je kapitola sama o sobě. Totiž [-(-x + y)] vypadá asi lépe takto [x – y], [-(x – y)] zase takto [y – x]. Nesmíme zapomínat na krácení čísel, [25 / 15] není nic jiného než [5 / 3]. A tak dále a tak dále… No, co k tomu víc dodat… Mordovačka!

Vlastní klávesnice. Další vychytávka. Upřímně – v plánu jsem jí měl již dlouho, ale v této verzi se vyskytovat zatím neměla. Donutila mě k ní do teď  neznámá chyba, kdy se při rotaci zařízení s použitím nativní klávesnice systému občas nevykreslovaly rovnice a renderer už do znovuotevření aplikace rovnice nevykresloval. Každý programátor uzná, že chyby vyskytující se „jen někdy“ jsou z těch horších. Nicméně jsem teď  moc rád za to, že se mi nepodařilo chybě přijít na kloub. Donutilo mě to tu vlastní klávesnici prostě udělat. A opět musela být co nejuniverzálnější, a opět jsem k tomu využil moje oblíbené výčtové typy.

A když už klávesnice, tak alespoň s nějakou přidanou hodnotou. Mazání textu je samozřejmost. Zakomponoval jsem do ní ale možnost hýbat kurzorem do stran a při držení tlačítek i označovat text pro potřeby kopírování, což běžné nativní klávesnici chybí. Označování textu mě v Androidu totiž občas přivádí k telefonupoškozujícím sklonům.

U verzí CE 2.1.0 a 5.1.0 se toho po odborné stránce moc neudálo. Odstraněním Spinnerů jsem dosáhl zase o něco lepší optimalizace, jelikož jsem mohl odstranit zbytečné náplasti kvůli chybám, které tato komponenta přinášela.

Upřímně jsem měl choutky se k Převodníku vrátit trochu dříve, ale řešil jsem jistý problém s hardwarem. V roce 2020 jsem si totiž koupil MacBook Pro M1, který jako první zařízení na světě obsahoval nový čip z dílny Applu s ARM architekturou. Mimo to, že tento čip s sebou přinesl neuvěřitelný výkon, tak vývojářům macOS aplikací naservíroval i trochu problémů. Aplikace napsané pro původní architekturu čipů x86 nebyly s novou ARM architekturou kompatibilní. Apple vyvinul nástroj Rosseta 2, který dokázal starou architekturu emulovat na architektuře nové. Při emulaci jsem neměl problém s žádnou aplikací, vše běželo bezchybně. Až na Android Studio.

Android Studio jako takové fungovalo relativně dobře. Co nefungovalo byly emulátory Android zařízení. V jednoduchosti – nešlo rychle testovat vyvíjené aplikace a bylo k tomu potřeba vlastnit nějaké fyzické Android zařízení, které už jsem ale nevlastnil. Navíc testování na fyzických zařízeních vývoj velmi zpomaluje. Na fyzických zařízeních jsem testoval vždy až ve finálních fázích vývoje.

A tak jsem holt musel čekat, než Google „přepíše“ Android Studio včetně emulátorů Android zařízení nativně pro ARM architekturu Apple čipů. Čekání se rozhodně vyplatilo, jelikož M1 čip je oproti čipům od Intelu diametrálně jinde a Android Studio už mi nedělá z notebooku topinkovač. 🚀