Blog | Jak jsem programoval čtečku

Jak jsem programoval čtečku

Pro zákazníka teď vyvíjím aplikaci pro chytrou čtečku čárových kódů. Čtečka běží na Androidu a je napojená na ABRA sklad. Z čtečky může skladník ovládat celý sklad a zvládne vše od naskladňování až po inventuru.

Postupně jsem vyzkoušel 4 přístupy.

1) Xamarin

Zákazník má celý svůj vývoj v C# a C. Firmware vyvíjí v C a software v C#. Aby byli schopni si sami udržovat řešení, začal jsem s vývojem taky v C# v Xamarinu, kde jsem chtěl vyvinout aplikaci pro Android.

Nicméně exotičnost platformy mě zastavila. Po dvou dnech jen rozjíždění Hello World v Androidu jsem se rozhodl, že půjdu do nativního rozhraní.

V podstatě mě zastavilo:

  • exotičnost platformy
  • vysoká prvotní investice do nastavení vývoje
  • C# umím na začátečnické úrovni, takže ani z pohledu produktivity mi to nepřinášelo výhody

2) Java

Tak jsem chtěl vyřešit problém exotičnosti tím, že použiju nejstandardnější prostředí, jaké pro Android najdete. Rozhodl jsem se napsat čtečku v Javě v Android Studiu.

Musím vyzdvihnout to, že tady je start vývoje pokrytý mnohem snáz. Člověk, který se rozhodne vyvíjet aplikace pro Andoid, nemá větší problém začít. Zapne developer mód v telefonu, který připojí kabelem a ten si ve Studiu napáruje. Rozhodně se mi moc líbí programování s Intenty, doufám, že se jednou dostanou i do iOSu.

Ale:

  • Android Studio je to nejpomalejší IDE, které jsem kdy viděl a to jsem provozoval kdysi dávno Delphi 3 na 586ce z pár desítkami mega RAM, to jsou 2 minuty, než se nastartuje (na MacBooku Pro), další 2 minuty každá kompilace a nahrátí do přístroje. Jestli něco označit za pomalou zpětnou vazbu, tak je to tohle.
  • v Javě na tom nejsem o nic lépe, než v C#

3) React native

Pořád jsem chtěl mít aplikaci přímo v čtečce, ale chtěl jsem vyřešit problém s tím, že neumím Javu. Chvilku jsem koketoval s React native.

Aplikaci bych mohl napsat v JavaScriptu, který umím. Nicméně se ukázalo, že toto řešení opět trpí problémem, který jsem měl s Xamarinem. Je to příliš exotické, okrajové, když jsem potřeboval poradit, nebylo kde googlit.

Toto řešení jsem taky zavrhl.

Naštěstí jsem si uvědomil, že čtečka nemá offline vůbec důvod k fungování a tak můžu všechno udělat na serveru.

4) Nette+Materialize

A tak jsem celou aplikaci naprogramoval v PHP, Nette a k tomu jsem využil CSS framework Materialize. To se ukázalo jako skvělé řešení.

Naučit jsem se musel pouze Materialize, všechno ostatní jsem už uměl.

Výsledkem je rozhraní, které je responzivní, dotykové, používá gesta, ale zároveň skvěle podporuje i přímo ovládání jen z čtečky a fyzických tlačítek. Běžné operace jako inventura, vyskladňování, naskladňování, získávání informací o skladových položkách, se obejde bez toho, aby se musel skladník displeje byť jedenkrát dotknout.

Rychlost reakce je, pravda, kolem 200ms, což je víc než čtyřikát pomalejší, než nativní řešení (kde zpomaluje pouze čekání na data z API), ale pořád je to dost rychlé pro běžné používání. Navíc se dá snadno převést na Single Page App, pokud to někdy bude potřeba.


Celé mě to přivádí k úvaze, jaké technologie volit. Vychází mi z toho, že nejproduktivnější nebudete na těch nejvíc moderních technologiích s největším hypem, ale na technologiích, které už umíte a které existují roky. Z neprověřených knihoven pak využijete pouze ty, které přináší zásadní úsporu času i poté, co započítáte čas věnovaný učení, nastavování, odlaďování.

Už jsem vyvíjel aplikace ve víc cool technologiích. Udržuju IS napsaný v Clojure a Angularu. V Inteloadu bylo vše v Clojure a Ansible. Pro zákazníky jsem letos vyvíjel věci v node.js, D, Go a menší měrou v dalších. Ale když je tlak na cenu a musí to být co nejdřív, pořád se nic nevyrovná technologiím, které dělám roky a které jsem použil na spoustě webů i webových aplikací.

Občas je ale vhodné adoptovat něco nového, protože i malá investice přidá hodně (použití Materialize mi zajistilo použitelnost i na dotykovém displeji včetně gest bez vlastní řádky JavaScriptu). A někdy je přechod na novou technologii výhodná riskantní investice. Dřív to pro mě bylo i Clojure, které by mi dalo podobnou produktivitu jako PHP, rychlejší rendering (ale zase víc zabrané RAMky), kratší zdrojáky (možná i o polovinu) a více možností, pokud se vyskytne potřeba dělat něco paralelně.

Programování

Předejte zkušenosti i dalším a sdílejte tento článek!

Předchozí článek
Následující článek


Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích