Capacitor ili Cordova za razvoj Ionic aplikacija?

Ionic aplikacije razvijam od 2015. godine i sve do prije nešto više od godinu dana temeljio sam ih primarno na Cordovi.

Usput sam pratio razvoj Capacitora koji je sa verzijama 3 i 4 počeo “dobivati oblik” s kojim sam bio zadovoljan. Tada sam zaključio da može poslužiti kao temelj novih, ali i postojećih projekata.

Cordova pripada prošlosti

Ako se pogleda samo činjenica da je Cordova nastala 2009., a Capacitor 2018. više je nego jasno da među njima vrlo vjerovatno postoje dosta velike razlike. Bile one konceptualne ili praktične ipak su razlike.

Godinama je bilo gotovo nezamislivo pristupiti nekim značajkama mobilnih uređaja bez nekoliko Cordova pluginova u različitim stupnjevima razvoja i održavanja, a sada je stiglo nativno.

Također, kroz godine se povećavao naglasak na sigurnosti mobilnih aplikacija pa tako Google i Apple više neće pustiti bilo što u svoje trgovine aplikacijama. Pri tome održavanje postojećih, a pogotovo razvoj novih aplikacija temeljenih na Cordovi gubi svoj smisao.

Capacitor nije zamjena za Cordovu

Ovo je i najveća zabluda developera koji su toliko navikli na Cordovu da Capacitoru ne žele dati niti šansu jer misle da sada moraju sve mijenjati i raditi ispočetka.

Capacitor je kompatibilan sa Cordovom tako da niti migracija nije veliki problem i moguće ju je raditi postupno. Ako i dođete u slučaj da ipak trebate neki stariji Cordova plugin moći ćete ga dodati u postojeći Ionic Capacitor projekt.

Iako Capacitor i Cordova mogu raditi zajedno osobno mi je cilj u svim projektima postupno skroz napustiti Cordovu.

Prednosti Capacitora

Najveća prednost je skroz druga filozofija razvoja aplikacija, koja je više prilagođena današnjem tehnološkim potrebama. Ali da ne bi sve ostalo na filozofiranju evo i konkretnih prednosti koje mi se osobno sviđaju.

Brži i jednostavniji build/deploy aplikacija

Postavljanje na Google Play Store i Apple App Store nešto je čime završi svaki novi ciklus razvoja nove ili održavanja postojeće aplikacije. To je proces koji se ponavlja i kao takav je važno da bude što jednostavniji.

Capacitor omogućava brže i jednostavnije kreiranje produkcijskog builda. Kod Android aplikacija sve ide putem Android Studia. Kod iOS-a mi je isto kao i do sada, s tom razlikom da više nema problema s nekompatibilnosti verzija nekih pluginova.

Manja ovisnost o pluginovima

Capacitor donosi nativne funkcionalnosti, kao npr. Deep Link, za koje više nisu potrebni pluginovi što je bio slučaj sa Cordovom. Samim time manje toga je potrebno posebno ažurirati i usklađivati po pitanju verzija.

Svaki plugin manje donosi aplikaciju koju je lakše održavati.

Jednostavna migracija

Općenito kada se prelazi sa tehnologije na tehnologiju u dosta slučajeva su u pitanju toliko velike promjene da je jednostavnije sve raditi ispočetka. To nije slučaj kod Capacitora.

Iako donosi značajne promjene, Capacitor u prvoj fazi migracije može poslužiti samo kao temelj. Čak i kada se ostave postojeći Cordova pluginovi. Kada se savlada taj korak, onda lagano migrirati ili uklanjati plugin po plugin. Kod pluginova koji nisu kompatibilni sa Capacitorom potrebno je odmah planirati adekvatnu zamjenu.

Izrada nove aplikacije

Kada se kreira nova aplikacija u startu je sasvim lijepo vidjeti da više ne postoji ovisnost o config.xml-u. Platformske postavke su sada ondje gdje i trebaju biti – u datotekama pojedine platforme. Za Android je to AndroidManifest.xml, a za iOS Info.plist.

To je super. Jer koliko god se prije pisalo “programiraš jednom za sve platforme” u praksi to često nije bio slučaju kada su u pitanju razlike između iOS-a i Androida.

Zaključak

Iz svega navedenog meni je Capacitor jedini logičan izbor i jedva čekam vidjeti što će novog donijeti.

Implementacija CorvusPay kartičnog plaćanja koristeći Node.js, Express.js i Angular

U ovom blog postu možete saznati kako implementirati CorvusPay kartično plaćanje koristeći Node.js tj. Express.js i Angular Framework.

Kartično plaćanje provodi se kroz Corvus Form Service što znači da korisnik nakon odabira artikala bude preusmjeren na URL za autorizaciju kreditne kartice. Na tom URL-u ispunjava se obrazac s potrebnim podacima o kreditnoj kartici nakon čega korisnik ponovno bude preusmjeren na web shop gdje se najčešće prikazuje poruka o ne/uspješnoj kupovini.

Tijek transakcije kroz CorvusPay sustav odvija se na sljedeći način:

  • Kupac u web trgovini odabire proizvod ili uslugu koju želi platiti karticom.
  • Kupac se preusmjerava sa stranice trgovca na CorvusPay platnu formu (stranicu) gdje unosi podatke potrebne za realizaciju kartične transakcije.
  • CorvusPay šalje banci zahtjev za autorizacijom.
  • Banka šalje odgovor na zahtjev za autorizacijom na CorvusPay.
  • CorvusPay preusmjerava kupca na cancel ili success url kojeg definira trgovac ovisno o ishodu transakcije.

Moguća je i integracija tog obrasca unutar web shopa, ali u tom slučaju trgovac mora imati PCI DSS certifikat.

Tijek implementacije

Proces se istovremeno odvija u dva smjera. Prvi se tiče administrativnih poslova u kojima Corvus od trgovca prikuplja potrebnu dokumentaciju za pokretanje procesa aktivacije kartičnog plaćanje koju prosljeđuje prema bankama/kartičnim kućama.

Paralelno trgovac (web shop) postavlja obavezan sadržaj na web trgovinu (uvjeti korištenja i plaćanja, logo CorvusPaya,…), vrši implementaciju prema dostupnim uputama i testira sustav pomoću razvojnog certifikata. Nakon obavljenih testova postavlja se produkcijski certifikat čime se proces implementacije završava.

Uvod

Komunikacija između trgovca i usluge CorvusPay vrši se putem HTTPS POST web zahtjeva.

Svaki web zahtjev prema Corvusu treba obavezno sadržavati tri parametra, a to su:

Store ID
Secret Key
Client Certificate (.p12).

Dobiju se dva seta ovih podataka. Jedan set za testiranje, a drugi za produkciju.

Obavezni CorvusPay parametri

Obavezni parametri su: version, store_id, order_number, language, currency, amount, cart, signature i require_complete.

U slučaju greške pri kreiranju parametara prikazat će se sljedeći ekran:

CorvusPay greška
Vaš zahtjev ne može biti obrađen – CorvusPay

order_number mora biti jedinstven jer sustav će provjeriti i odbiti svaki upit na Corvus API ako narudžba s istim brojem narudžbe već postoji.

signature se kreira koristeći HMAC-SHA256. On se sastoji od svih obaveznih i opcionalnih vrijednosti (key-value field pairs), poredanih abecedno i spojenih bez razmaka.

To onda izgleda ovako:

na osnovu čega se dobije signature

signature = HMAC-256(key, key-value field pairs)

~ ključ: UNV3-i2otJw0rUWzA2lpcNRqTOYRWdAeTw
~ parametri:
– version : 1.3
– store_id : 2029
– order_number : 1537270065109
– amount : 10.00
– currency : HRK
– cart : kindle paperwhite
– require_complete : false
– language : hr

CorvusPay HTTPS POST
CorvusPay Integration Manual v5.1.0

Neobavezni CorvusPay parametri

Osim obaveznih parametara moguće je koristiti i neobavezne. U ovom slučaju to će biti parametri vezani uz plaćanje na rate.

Tri su načina pokretanja transakcije na rate:
• Fiksni broj rata
• Fleksibilan broj rata
• Samostalan odabir rata za određenu karticu

Napomene:
• Ako se za određenu platnu karticu ne pošalje parametar payment_brandName kartica neće biti dostupna za odabir
• Prvi znak parametra payment_ trebao bi biti jednak N ili Y jer to označava je li dozvoljeno jednokratno plaćanje ili ne
• Posljednja četiri znaka određuju raspon broja rata. Kupac može odabrati broj rata u rasponu između prvog dvoznamenkastog broja i drugog dvoznamenkastog broja

CorvusPay plaćanje na rate
CorvusPay Integration Manual v5.1.0

Web aplikacija (Angular)

Unutar forme pomoću POST metode poziva se API za pokretanje kartičnog plaćanja.

Sve navedene vrijednosti su promjenjive tako da ih prilikom svake promjene unutar .ts datoteke treba osvježiti i unutar forme </form>.

Parametri signature i payment_ mogu se kreirati na frontendu i backendu. U ovom slučaju oni će se kreirati na frontendu i prosljeđivati kroz formu na API.

Za potrebu kreiranja HmacSHA256 potpisa koristi se crypto-js. Uz to, unutar environment varijable nalaze se razvojni i produkcijski parametri secretKey i storeId.

Glavna razlika u ovom dijelu tiče se ukupne cijene tj. ovisno o tome prelazi li iznos od 500kn plaćanje na rate biti će odobreno ili onemogućeno. U oba slučaja kreira se različit signature.

Za ukupan iznos veći ili jednak 500kn koristi se sljedeće:

CorvusPay - plaćanje na rate

Dok se za iznose manje od 500kn koristi:

CorvusPay - jednokratno plaćanje

Backend API (Express.js)

Backend logika nalazit će se u server.js datoteci. Kako ju kreirati možete se vidjeti u blog postu “Izrada RESTful API-ja koristeći Node.js i Express.js“. Razlika između primjera iz tog blog posta i ovoga sada je što više nije potrebno koristiti body-parser.

Ova će se datoteka sastojati od tri krajnje točke (API endpoints).

Prva krajnja točka, '/corvusPay', preusmjerit će korisnika na formu za plaćanje.

Nakon unosa i obrade podataka o kartici

CorvusPay - obrada u tijeku
CorvusPay – obrada u tijeku

korisnik je preusmjeren na dodatnu sigurnosnu autentifikaciju kartice.

CorvusPay - sigurnosna autentifikacija kartice
CorvusPay – sigurnosna autentifikacija kartice

Ako je sve prošlo uspješno korisniku će se prikazati obavijest

CorvusPay - transakcija-uspjela
CorvusPay – transakcija uspjela

i na e-mail će dobiti obavijest o uspješnoj narudžbi.

CorvusPay - obavijest o uspješnoj narudžbi
CorvusPay – obavijest o uspješnoj narudžbi

Druga krajnja točka, '/corvusPaySuccess' , prihvaća odgovor od Corvusa kada je plaćanje uspješno provedeno.

CorvusPay - uspješno plaćanje

Treća krajnja točka, '/corvusPayCancel' , prihvaća odgovor od Corvusa kada je plaćanje neuspješno ili otkazano.

CorvusPay - neuspjelo plaćanje

DevExtreme Pivot Grid & Angular: prikaz i analiza višedimenzionalnih podataka

U ovom ću blog postu pokazati kako implementirati DevExtreme Pivot Grid UI komponentu u Angular projekt. Ona omogućava prikaz i analizu višedimenzionalnih podataka iz lokalne pohrane ili OLAP kocke.

Fokusirat ću se na prikaz podataka prema specifičnim parameterima te načinu na koji te podatke uređivati jer Pivot Grid nativno ne nudi takvu mogućnost.

Pivot Grid prikaz podataka

Prva i osnovna značajka Pivot Grida je prikaz i analizu višedimenzionalnih podataka.

U ovom ću primjeru koristiti strukturu podataka prikazanu u JSON-u kojega je moguće vidjeti ispod. S jedne strane biti će poslovnice, a s druge automobili. Cilj je prikazati količinu naručenih tj. isporučenih automobila ovisno o poslovnici.

Logika aplikacije nalazit će se unutar angular-devextreme.component.ts datoteke koja se temelji na PivotGridDataSource objektu. Za sada će se unutar njega nalaziti samo fields niz i store objekt.

Poslovnice će se nalaziti krajnje lijevo area: "row", a automobili na vrhu area: "column". Sve ostalo tj. narudžbe prikazuju se kao podaci area: "data".

Izgled sučelja biti će definiran unutar angular-devextreme.component.html datoteke.

Od Pivot Grid UI svojstva koristit ću ih nekoliko:

  • showBorders – želim da vanjski rubovi budu vidljivi.
  • showColumnGrandTotals – ne želim prikazivati ukupne vrijednosti za kolone. Ovo bi se inače prikazivalo krajnje desno.
  • showRowGrandTotals – želim na dnu prikazati ukupne vrijednosti.
  • Sve to zajedno na kraju daje sljedeće:

    DevExtreme Pivot Grid - osnovni prikaz

    Pivot Grid – promjena izgleda polja

    Ako želim dodatno prilagoditi prikaz određenih polja to mogu napraviti koristeći onCellPrepared metodu.

    U ovom slučaju hoću napraviti tri grafičke izmjene. Stupac “Naručeno” će imati sivu pozadinsku boju i podebljane brojeve, ukupne vrijednosti na dnu također će biti podebljanje, a vrijednosti koje za “Isporučeno” imaju null će imati crvenu pozadinsku boju kako bi bila uočljivija.

    Na ekranu bi to izgledalo ovako:

    Pivot Grid onCellPrepared

    Međutim, niti jedno polje nema crvenu pozadinsku boju. Razlog je što Pivot Grid sve null vrijednosti vidi kao 0 i zato uvjet e.cell.value === null nije zadovoljen. Ali ako stavim e.cell.value === 0 stanje će biti puno drugačije.

    Pivot Grid onCellPrepared

    Iz podaciDemo niza se može vidjeti da narudzba_isporucenakolicina može imati vrijednosti null. To znači da bi vrijednost za “POSLOVNICA VK” i automobil “Fiat Panda” trebala imati crvenu pozadinsku boju jer je narudzba_isporucenakolicina = null, a kombinacija POSLOVNICA VK” i “Kia Rio” ne bi trebala imati crvenu pozadinsku boju jer ima vrijednost narudzba_isporucenakolicina = 0.

    Pivot Grid – prikaz null vrijednosti

    Kako bi u PivotGridu mogao prikazati null vrijednosti i razlikovati ih od vrijednosti 0 koristiti ću calculateCustomSummary funkciju. Tu ću funkciju vezati uz polje dataField: "narudzba_isporucenakolicina".

    Sada se na ekranu može vidjeti da istovremeno imam prikazane vrijednosti za isporučenu količinu i kao null i kao 0.

    Pivot Grid calculateCustomSummary

    Omogućiti klik na odabrano polje

    Želim omogućiti klik samo na polje koje pokazuje isporučenu količinu, ali isključivo za poslovnice i automobile koji imaju unesenu naručenu količinu. Znači, ne želim da se u koloni sa isporučenom količinom može kliknuti na prazno polje jer nema smisla unositi isporučenu količinu ako ništa nije naručeno.

    Za to ću koristiti onCellClick funkciju.

    Iz prikazanog se može vidjeti da klik na prazno polje ne radi ništa, klik na crveno polje dohvaća vrijednost null, a klik na polje za unesenom količinom dohvaća tu vrijednost. U ovom slučaju ta vrijednost je 10.

    Pivot Grid onCellClick

    Pivot Grid dohvaćanje vrijednosti polja

    Pivot Grid je primarno kreiran s ciljem prikaza podataka tj. prema dokumentaciji nema mogućnost jednostavnog uređivanja podataka kao što je to slučaj kod Data Grida, barem ju nisam našao, ali sam znao da mora postojati neko rješenje.

    Za početak želim prikazati nekakvu formu unutar koje će se vrijednost polja moći urediti. Za to ću iskoristiti Popup UI komponentu. Unutar nje definiram dxTemplate što mi omogućava daljnju prilagodbu sučelja za uređivanje isporučene vrijednosti.

    Za dohvaćanje vrijednosti kliknutog polja koristit ću Drill Down.

    Klikom na polje isporučene količine prikazat će se sljedeće:

    PivotGrid DxPopup DrillDown

    Kao što se iz prikazanog može vidjeti dohvaćeni su podaci prikazani na vrhu blog posta.

    Pivot Grid uređivanje vrijednosti polja

    Popup iz gornjeg primjera je potrebno prilagoditi na način da se kreira input polje za izmjenu isporučene količine. Klikom na polje sa već unesenom isporučenom količinom ista će se prikazati unutar input polja. Ako je polje prazno isto će biti i input polje.

    U GIF-u se može primjetiti da uređivanje isporučene količine uredno prolazi, ali uz jedan problem. Prilikom svakog spremanja isporučene količine cijeli se Pivot Grid osvježi i vrati u krajnju lijevu poziciju. Naravno da to nije praktično. Uz to, prilikom otvaranja popupa polje za unos količine nije fokusirano (crvena podcrtana linija) nego je na njega prvo potrebno kliknuti.

    U nastavku ću pokazati kako riješiti oba problema.

    Pivot Grid uređivanje

    Osvježavanje samo uređenog podatka

    Jedan od problema koji se stvorio nakon što je omogućeno uređivanje podataka je to što se sada cijeli ekran osvježi i onda se svaki put iznova mora skrolati do točno određenog polja kako bi se nastavilo uređivanje. To nikako nije praktično i bilo je potrebno pronaći rješenje.

    U ovom će mi slučaju pomoći ArrayStore, ali tek kada prilagodim prikaziNarudzbe() funkciju. Kao što se može vidjeti this.podaciDemo se sada dohvaćaju upravo kroz ArrayStore. Kroz key parametar identificiram unikatnu vrijednost pomoću koje Pivot Grid može znati koju vrijednost će osvježiti.

    Podatke nakon unosa osvježavam pomoću update(key, values) metode unutar funkcija spremiKolicinuButton() i spremiKolicinuEnter().

    Uz to, kada se popup otvori polje za unos isporučene količine nije fokusirano i prije unosa potrebno je na njega kliknuti. To također nije praktično. Ovo se vrlo lako riješi kroz onShown funkciju.

    Na kraju to izgleda ovako:

    PivotGrid Reload

    Zaključak

    Naravno, ovo je samo dio mogućnosti koje DevExtreme Pivot Grid ima, ali dovoljno da pohvatate osnove i shvatite na koji način funkcionira.

    Što napraviti kada izgubite Android keystore lozinku?

    Za početak, važna napomena. Jedna stvar mora biti jasna. Ova metoda neće raditi u 100% slučajeva i treba se koristiti kao zadnja opcija.

    Olakotna okolnost može biti ako ste sami kreirali keystore za koji više nemate lozinku jer lakše ćete dobiti inspiraciju za potencijalne mogućnosti kada znate koje najčešće kombinacije koristite No, ako želite doći do lozinke keystore datoteke koju je netko drugi kreirao onda najveću ulogu igra sreća i dovoljno vremena provedenog u čekanju da ovaj alat dođe do lozinke.

    P.S. Prije korištenja ovog alata dobra je opcija kontaktirati Google kroz njihovu General Play Console issues formu (I have a key or keystore related issue -> I have an upload key-related issue -> I forgot the password to my keystore).

    Android keystore!?

    Ono što se u svim uputama može pronaći je važna napomena koja se tiče upravo keystore datoteke za koju je navedeno da se uvijek mora čuvati na sigurnom mjestu i da se nikako ne smije izgubiti pripadajuća lozinka. U suprotnom neće biti moguće napraviti ažuriranje aplikacije na Google Play Store. Druga opcija je da se aplikacija potpisuje sa certifikatom kojim upravlja Google direktno kroz Google Play Store.

    …if you’re not opted in to app signing with by Google Play and you lose your app’s signing key, you lose the ability to update your app.

    Više o načinu kako se Android keystore datoteka kreira i koristi za postavljanje Ionic aplikacija na Google Play Store moguće je pronaći u blog postu pod naslovom “Priprema i objava Ionic aplikacije na Google Play Store“.

    No, vratimo se scenariju u kojemu lozinka keystore datoeke nije poznata.

    Što napraviti u tom slučaju?

    Priprema

    Alat se pokreće naredbom

    Mogući argumenti:

  • -m <1..3> – metoda 1, 2 ili 3
  • -k <putanja> – putanja do keystore datoteke
  • -d <putanja> – putanja do datoteke sa popisom riječi (za metodu 2 i 3)
  • -p – korištenje uobičajene zamjene poput “@” za “a” (3. metoda). VAŽNO – vrlo sporo!
  • -start <String> – postavljanje početnog niza za lozinku (za brute force)
  • -w – kreira novu keystore datoteku s istom lozinkom
  • -h – prikaz pomoći
  • Korištenje AndroidKeystoreBrute alata

    Prilikom pokretanja dobiju se alias i datum tj. vrijeme kreiranja keystore datoteke. U ovom slučaju to su:

    1. metoda – Simply Bruteforce

    Najsporija metoda. Ovdje se ne koristi riječnik s popisom mogućih riječi nego se vrte sve kombinacije počevši od zadanog argumenta -START AAAAAA

    Android keystore lozinka

    2. metoda – Dictionary Attack

    Metoda koja će vrtiti popis zadanih riječi u točnom obliku kako su navedene. Znači neće ih kombinirati kao što to radi u 3. metodi. Potreban je puno veći popis riječi i sve moguće kombinacije.

    3. metoda – Smart Wordlist Attack (preporuka)

    Najbolja metoda jer će od svih riječi iz riječnika napraviti sve moguće kombinacije. Brojevi se dodaju automatski i nije ih potrebno posebno navoditi. Ipak, ako znate da se lozinka sastoji od npr. broja godine “2020” dobro je to navesti jer će ubrzati pronalazak ispravne kombinacije.

    Popis riječi koje sam koristio u wordlist.txt:

    Ispravnu kombinaciju lozinke dobio sam za 22 sekunde:

    Android keystore lozinka

    Naslovna slika preuzeta sa https://android-developers.googleblog.com/2018/12/new-keystore-features-keep-your-slice.html

    Prikaz podataka API-ja Sudskog registra u Angular formi

    U ovom ću blog postu pokazati kako napraviti upit na API Sudskog registra i dohvatiti informacije o poslovnom subjektu prema OIB-u/MBS-a. U dokumentaciji se može vidjeti koje je sve informacije i preko kojih ruta moguće napraviti, ali ja ću se zadržati na onoj po meni najzanimljivijoj subjekt_detalji_Get.

    Projekt je dostupan na GitHubu.

    Uvod

    Za kreiranje forme koristiti ću FormBuilder, a mogao sam isto tako koristiti i ngModel ili FormControl. Više o tome objavio sam u jednom od prijašnjih blog postova. Forma će se sastojati od nekoliko polja od kojih će većina biti obavezna. Prilikom unosa OIB-a ili MBS-a odmah ide provjera na API Sudskog registra i tek nakon te provjere moguće je kliknuti na gumb “Spremi” nakon kojega se podaci mogu spremiti u bazu podataka.

    Provjera rada API-ja

    Prije nego krenem s izradom Angular forme idem se uvjeriti da API radi na način kako je prikazano u dokumentaciji i da mi vraća podatke koje želim koristiti. API je moguće testirati i na ovoj adresi. Da nema te forme koristio bi Postman.

    URL na koji radim upit je:

    Obavezni parametri upita su sljedeći:

    • tipIdentifikatora* (string) – moguće koristiti oib (osobni identifikacijski broj) ili mbs (matični broj subjekta)
    • identifikator* (integer) – oib ili mbs koristim u obliku broja (int64)
    • Ocp-Apim-Subscription-Key* (string) – ide u header, a dobije se nakon registracije

    Kreiranje API servisa

    U servisu će se nalaziti dvije funkcije. Jedna će dohvaćati podatke prema OIB-u, a druga prema MBS-a.

    HTML forma

    Kreiram formu sa poljima:
    oib – dužina 11 znakova. Obavezno polje.
    mbs – dužina 9 znakova. Obavezno polje.
    nazivtvrtke – Obavezno polje.
    ulica – Obavezno polje.
    grad – Obavezno polje.
    e-mail

    Prilikom unosa OIB-a ili MBS-a odmah se vrši provjera na API putem funkcije provjera(angularForma). Tek nakon što se forma ispuni podacima tj. kada se zadovolji unos obaveznih polja moguće je kliknuti na gumb “Spremi”.

    Funkcionalnost forme

    Unutar ngOnInit() funkcije radim inicijalizaciju forme. Ovdje odmah dodajem i Validators kako bi mogao validirati potrebna polja i spriječiti klik na gumb “Spremi” pomoću [disabled]="!angularForma.valid" u slučaju kada forma nije ispravno ispunjena.

    Kada se unutar polja forme unesu OIB ili MBS poziva se funkcija provjera(angularForma). Prvo vršim provjeru koja vrsta identifikatora (OIB ili MBS) je unesena jer ću kasnije na osnovu toga pozivati pripadajući API Sudskog registra iz ApiService i paralelno provjeravam da su ispravne dužine. Nakon toga provjeravam da unutar unesenih znakova nema slova tj. da su samo brojevi match(/^[0-9]+$/). Kada su svi navedeni uvjeti zadovoljeni pozivam this._apiService.sudskiRegistarOIB ili this._apiService.sudskiRegistarMBS te prikazujem dobivene podatke console.log(res) i odmah popunjavam formu.

    Kada je forma ispravno validirana podaci će se uspješno dohvatiti.

    Angular forma: Sudski Registar

    Ne međutim, ostaje problem kod popunjavanja forme sa nasumičnim brojevima koji će ispravno biti validirani prema dužini iako ne postoje u Registru. Npr. netko za OIB može unijeti 11 nula ili za MBS 9 nula i forma će biti validna te će se taj poslovni subjekt moći spremiti u bazu podatka.

    Angular forma

    To mogu spriječiti koristeći setValue ili patchValue. Znači, ako mi API Sudskog registra ne vrati podatke neću dopustiti da forma prođe kao validna i da se uopće može kliknuti na “Spremi”.

    this.angularForma.controls['oib'].setValue(null);
    this.angularForma.controls['oib'].patchValue(null);

    Angular - Sudski Registar

    Što se adrese tiče stavio sam uvjet da se prikaže ispravna vrijednost neovisno o tome ima li prikazana adresa uz broj i podbroj tj. slovo (res.sjedista[0].kucni_podbroj ? (res.sjedista[0].kucni_podbroj) : '') .

    Npr. u adresi Dragutina Žanića Karle 27a je ‘a’ podbroj .