Kako izdelati celostno rešitev na področju digitalizacije občin? Kako izboljšati komunikacijo med občinami in občani? Kako zagotoviti bolj priročne in digitalizirane občinske storitve ter učinkovitejšo uporabo digitalnih orodij? Vse to so bila vprašanja, ki so se pri procesu razvoja digitalnih rešitev za občine pojavljala Petru Aleksandru Bizjaku, vodji razvoja aplikacij in ekipi. Z njim smo spregovorili o celotnem procesu njenega nastanka.
“Ko sem se v začetku leta 2020 pridružil ekipi IPM Smart Community, se mi je zdela ideja digitalizacije občin glede na moje pretekle delovne izkušnje na področju raziskav in izdelave prototipov izjemen preskok. Kar naenkrat je bil pred mano izziv dejanskega razvoja izdelka, ki ga bo uporabljalo obče prebivalstvo. Takratni tehnični opis projekta še ni bil tako podrobno dodelan, toda s pomočjo mojega izjemnega kolega in sodelavca Pavla Remica-Weissa sem uspel pripraviti razdelan in precej realen načrt razvoja aplikacije,” pojasnjuje Peter in dodaja, da so bile odločitve o infrastrukturi in oblikovanju tehnološkega sklada, ki jo jih v tistem trenutku sprejeli, zastavljene kot zanesljive, moderne in modularne. Slednje – modularnost – je ključna beseda celotnega projekta.
“Zavedali smo se, da bo to potencialno največji projekt, ki smo ga kdajkoli izvedli in ki bo temeljito preizkusil naše sposobnosti reševanja problemov in programskega inženiringa,” brez zadržkov prve korake aplikacije, ki je trenutno v internem testiranju znotraj IPM ekipe in na občini, opiše Peter.
Torej, kako je ekipa razvila produkt?
Tehnični pregled
Prvi izziv, s katerim so se soočili, je izbira tehnologije za mobilno aplikacijo. Ker je bila velikost razvojne ekipe omejena, je bilo takoj jasno, da potrebujejo orodje, ki bo omogočilo hitro izdelavo prototipov z gladko učno krivuljo in hkrati ponujalo native zmogljivosti.
Odgovor, kot pove Peter, je bil Flutter in dodaja: “V primerjavi z drugimi frameworki, Flutter deluje bolje, ker ima krajši razvojni cikel. Na primer React Native za upodabljanje komponent uporablja Objective-C API-je na iOS-u in Java API-je na Androidu, medtem ko Flutter prevaja Dart kodo naravnost v platformi prilagojeno izvorno kodo, s pomočjo NKD oziroma LLVM.”
Za dani operacijski sistem so aplikacije ustvarjene s pomočjo Flutter-ja pakirane na enak način kot katerakoli druga native aplikacija. Poleg tega Flutter po novem ponuja podporo tako za spletne kot za namizne aplikacije in hkrati učinkovito nadomešča web-based rešitve, ko se odločimo za eno samo kodno bazo.
“Čeprav sem sam v osnovi pričel kot razvijalec native Android aplikacij (Java in kasneje Kotlin) je bil prehod na nov programski jezik razmeroma gladek; pogosto se pošalim, da Dart ni nič drugega kot izboljšan JavaScript – jezik, ki ga tudi osebno dobro poznam,” nam je z nasmehom pojasnil Peter ter nadaljeval z odgovorom na vprašanje, zakaj je prehod na povsem nov framework upravičen, ko bi lahko uporabili Kotlin Multiplatform in preprosto dodali logiko uporabniškega vmesnika za posamezno platformo?
“Zato, ker takrat Kotlin Multiplatform preprosto ni bil dovolj zrel. Ločeno programiranje za Android in iOS bi razdrobilo našo kodno bazo, s tem pa bi bil namen enotne kodne baze poražen,” pojasnjuje.
Zaledni sistem in API-ji
Ekipa se je omejitev, ki so se navezovala na zaledno stran, zavedala že na začetku. “Če bi za kaj takega razvili svoj lasten backend, bi potrebovali veliko časa in veliko sredstev, ob velikem tveganju (pre)hitrega razvoja, ki bi potencialno zanemaril varnostni vidik. Namesto tega smo se odločili za Firebase, platformo z odjemalskimi SDK-ji, od overjanja in NoSQL baze podatkov, do razvijalnih orodij za analitiko, A / B testiranja …,” pojasnjuje Peter. S pomočjo funkcij v oblaku so platformo lahko prilagodili in razširili tako, da je popolnoma ustrezala njihovim potrebam.
Razvoj jih je nato pripeljal do skrbniške plošče. Na začetku so imeli idejo za aplikacijo, ki temelji na Reactu, kasneje pa takšno, ki temelji na Flutterju. Peter ob tem pojasnjuje: “Oboje bi zahtevalo povsem nov projekt, Flutter Web pa je takrat imel tudi nekaj resnih težav z zmogljivostjo.”
“Sodelavec in član ekipe Pavel je predlagal Strapi, headless sistem za upravljanje vsebin, ki samodejno generira API in s pomočjo razširitve omogoča GraphQL podporo,” razlaga Peter in pri tem doda, da je takšen sistem priročen predvsem zaradi strukture mrežnih klicev, ki bi s tradicionalno arhitekturo REST zahtevali več povratnih potovanj, saj bi arhitektura mobilne aplikacije dosledno povzročala ti. over- ali under-fetching količine podatkov. “Na strani odjemalca sem lahko zaradi enostavnosti zahtev GraphQL (preprost HTTP POST s telesom zahteve JSON in eno končno točko) močno poenostavil API klice, ki je sedaj vključeval samo eno “abstraktno” metodo, ki tvori zahtevo in obravnava primer z ali brez avtentikacijske glave.”
Kot pravi je aplikacija razmeroma preprosta – gre za Flutter app, ki sledi BLoC arhitekturi in temelji na reaktivnem programiranju, zaradi varnostnih razlogov pa se v napravi shranjuje zelo malo podatkov.
Preverjanje pristnosti in elektronski postopki
“Osnovna ideja projekta je izdelava celostne rešitve na področju digitalizacije občin. Aplikacija oz. platforma bo omogočila boljšo komunikacijo med občino in občani, bolj priročne in digitalizirane občinske storitve ter učinkovitejšo uporabo digitalnih orodij za izvajanje tistih nalog, ki sicer zahtevajo oseben obisk občinske institucije,” funkcionalnosti aplikacije opisuje Peter in izpostavlja še, da je bila pandemija bolezni COVID-19 eno močnejših gonil oziroma pospeševalcev tako splošne digitalizacije kot tudi razvoja njihove rešitve.
Pri tem pa so naleteli na pomembno vprašanje: kako preveriti pristnost uporabnika, ali gre za državljana Republike Slovenije, občana dane občine? Peter nam je pojasnil, da se je odgovor skrival v digitalnih potrdilih. Vsak državljan Republike Slovenije lahko namreč zaprosi za digitalno potrdilo pri enem od razpoložljivih ponudnikov v pristojnosti SI-TRUST, ki jih izdaja in deluje pod okriljem Ministrstva za javno upravo RS.
“S prvo ratifikacijo tehničnih specifikacij nismo predvideli uporabe storitev SI-TRUST in smo se zanašali na neodvisne ponudnike – tako domače kot tuje.” A kljub temu, da so bili vsi neodvisni ponudniki odlični, bi po Petrovem mnenju takšna rešitev preveč zapletla uporabniško izkušnjo.
“Med tretjo ratifikacijo smo za svojo storitev preverjanja pristnost le izbrali SI-CAS. Primarni namen SI-CAS-a je vključiti funkcionalnost elektronske identifikacije v informacijske rešitve javnega sektorja. Zaradi politike avtorskih pravic in zasebnosti podjetja SETCCE na žalost ne morem deliti nobenih informacij o delovanju sistema,” pojasni Peter in z nasmehom doda, da bi bila to sicer zanimiva tema.
Naslednji korak je bil integracija elektronskih postopkov, pri čemer NIO (Nacionalni okvir interoperabilnosti) izpostavlja sistem JEP. Peter pojasnjuje, da JEP pošlje izpolnjeno uporabniško zahtevo pristojnemu javnemu organu ali mu dovoli, da obdeluje prijavni obrazec znotraj samega sistema, če organ svojega sistema za upravljanje dokumentov nima.
“Naši cilji so, da sčasoma te sisteme dopolnimo z lastno rešitvijo za digitalno občinsko identiteto (ODI). Ta je že pripravljena in implementirana, vendar smo glede uporabe omejeni z direktivo GDPR in povezano državno zakonodajo.”
Prihodnji načrti in povzetek
Po Petrovih besedah se ekipa trenutno nahaja v fazi razvoja dodatnih modulov in končuje implementacijo v aplikacijo. “Med internim preizkusnim obdobjem ugotovili tudi številne možne izboljšave zmogljivosti, tako da bomo še dodatno zmanjšali velikost aplikacije in sicer z odpravljanjem nepotrebnih segmentov izvorne kode in postopnim prehodom na prilagojene izvorne module,” še dodaja. Ekipi je uspelo namestitveno velikost Android aplikacije zmanjšati na manj kot 10MB, dejanska velikost pa je približno med 20 in 25MB (odvisno od naprave). Razloži, da “optimizacije za Android temeljijo na orodjih, ki jih je razvil Google, od krčenja kode in virov (code and resource shrinking) ter zatemnitve (obfuscation) z R8 in po meri prilagojenih pravil ProGuard.”
Z zadovoljstvom nam je zaupal, da je “glede na notranja merila uspešnosti naša mrežna logika uspešno dosegla zmogljivost, ki bi jo pričakovali v native aplikaciji, med profiliranjem pomnilnika smo pri kodi zaznali precejšnje izboljšave na področju natančnega upravljanja, ko je drago delo prenesla na ustrezne izolate v ozadju.”
Ob koncu pogovora je izpostavil še, da se zahvaljuje sodelavcem za pomoč pri pripravi in podajanju odgovorov za članek, ki je pred vami, in zaključi, da moramo skupaj spodbujati slovenski programski ekosistem v pravo smer, glede na tuje industrijske standarde in trende, hkrati pa zagotoviti, da uporabljamo čim več domačih izdelkov, gradnikov in storitev.
