Otvaranje postavki mobilnog uređaja iz Ionic aplikacije

Prilikom izrade Ionic mobilnih aplikacija jedan od zahtjeva može biti da se iz aplikacije mogu otvoriti neke od postavki mobilnoj uređaja. Npr. postavke vezane uz geolokaciju, WiFi ili nešto treće. Puno je jednostavnije omogućiti korisniku da klikom na jedan gumb ode direktno na postavke koje su mu u tom trenutku potrebne kako bi unutar Ionic aplikacije nešto obavio nego da sam mora tražiti te iste postavke.

Od postavki kojima je moguće pristupiti koristeći ovaj plugin dostupno je sljedeće:

Kreiranje aplikacije

Kreiram novi Ionic projekt i odmah dodajem Android platformu jer planiram aplikaciju pokrenuti na mobilnom uređaju.

Open Native Settings

Plugin Open Native Settings instaliram sljedećim naredbama:

Nakon toga ovaj plugin deklariram unutar app.module.ts datoteke.

Funkcionalnost se nalazi unutar home.ts datoteke tj. unutar HomePage klase, a sastojat će se od funkcija od kojih svaka otvara neku od ranije navedenih postavki mobilnog uređaja.

Open Native Settings

Ako neku od postavki pozivam na ovaj način this._openNativeSettings.open("accessibility") ekran s postavkama će se otvoriti umjesto ekrana Ionic aplikacije dok ako dodam parametar true na sljedeći način this._openNativeSettings.open(["accessibility", true]) otvara se novi ekran s postavkama što se može vidjeti na sljedećoj slici.

Open Native Settings

Ovo na ekranu izgleda ovako:

Open Native Settings

Zaključak

Struktura projekta prema package.json

Što je i čemu služi Ionic Native 4.x?

Prošlo je skoro 2 godine od kako sam objavio blog post pod naslovom “Čemu služi Ionic Native 3.x?“. S obzirom da su se od tada neke stvari promijenile, stigao je Ionic Framework verzije 4, pravo je vrijeme za novi blog post.

Ionic Native je kolekcija Cordova pluginova koji unutar Ionic aplikacije omogućavaju korištenje nativnih funkcionalnosti mobilnih uređaja.

Ionic Native je od sada dostupan u dva izdanja: Community Edition i Enterprise Edition.

Native Core

Ionic Native Community Edition

Ovo izdanje označava pluginove koje održava open source zajednica tj. Ionic tim ih ne održava, ne popravlja niti garantira da će bilo koji od njih ispravno raditi.

Način instalacije:

Ionic Native Enterprise Edition

Ovo izdanje označava pluginove koje održava, popravlja i za njih garantira Ionic tim.

Posebno je zanimljivo što uključuje Native Core set funkcionalnosti što znači da se unutar jednog plugina nalazi nekoliko važnijih funkcionalnosti.

Način instalacije:

Korištenje s Angularom

Svaki se plugin nakon instalacije dodaje unutar app.module.ts datoteke. Npr. u nastavku se nalazi primjer korištenja Camera plugina.

Ovdje je posebno važno paziti da svaki plugin korišten u Angular projektu ima na kraju oznaku /ngx. Oko ovoga u zadnje vrijeme ima dosta pitanja na Stackoverflowu.

Google Distance Matrix API – prikaz informacija o udaljenosti i vremenu putovanja između dvije lokacije na Google karti

U ovom ću blog postu pokazati kako koristiti Google® Distance Matrix API za prikaz informacija o udaljenosti i vremenu putovanja između dvije ili više lokacija na Google karti. Ideja za ovaj blog post došla je iz jednog projekta od prije nekoliko mjeseci, slično ovome, gdje smo kod kolege ugrađivali ovaj jednostavan, a vrlo koristan API.

The Distance Matrix API is a service that provides travel distance and time for a matrix of origins and destinations. The API returns information based on the recommended route between start and end points, as calculated by the Google Maps API, and consists of rows containing duration and distance values for each pair. – Developer Guide

Priprema projekta

Unutar Google Cloud Platform Console sučelja trebam prvo kreirati novi projekt ili odabrati postojeći.

Google Cloud Platform

S obzirom da sam prije koristio nekoliko različitih Google API-ja već imam postojeće projekte, ali ovaj API ne želim dodati niti u jedan od njih pa ću kreirati novi.

Google Cloud Platform

Novi projekt će se zvati APIs4Blog.

Google Cloud Platform New Project

Nakon što se novi projekt kreira pojavit će se sljedeći ekran. Ovdje me zanima gumb “ENABLE APIS AND SERVICES”.

Google Cloud Platform

Klikom na gumb “ENABLE APIS AND SERVICES” dolazim do sljedećeg ekrana gdje mogu vidjeti sve dostupne API-je.

Google Cloud Platform

Pomoću tražilice pronalazim Distance Matrix API.

Distance Matrix API Google Cloud Platform

Ovdje se još jednom mogu vidjeti detalji kao i cijena korištenja Distance Matrix API-ja.

Distance Matrix API Google Cloud Platform

Klikom na “ENABLE” mogu vidjeti sučelje s informacijama o korištenju API-ja.

Distance Matrix API Google Cloud Platform

Odmah se prebacujem na Credentials tab kako bi ondje kreirao API KEY bez kojega ne mogu koristiti Distance Matrix API.

Distance Matrix API Google Cloud Platform

API KEY je uspješno kreiran i spreman za korištenje.

Google Matrix API KEY

Implementacija

URL za slanje zahtjeva izgleda ovako:

Format dobivenih rezultata.

outputFormat određuje format dobivenih rezultata koji može biti u dva oblika: json ili xml. Maksimalna dužina URL-a je 8192 znakova.

Obavezni parametri (parameters)

Primjer API poziva sa obaveznim parametrima:

Kod parametara je situacija nešto složenija i postoje razne kombinacije kao što su:

Polazište (origins)

Polazište označava početnu lokaciju. Može biti zadano u obliku adrese, koordinata ili place ID-a.

Ako se za početnu lokaciju koristi više adresa ili koordinata između njih je potrebno staviti sljedeći znak “|”.

Korištenje adrese kao polazišta:

Distance Matrix API Adresa

Korištenje koordinata kao polazišta:

Distance Matrix API koordinate

Korištenje Place ID-a kao polazišta:

Distance Matrix API place ID

Odredište (destinations)

Jednak oblik kao i za polazište.

API Ključ (API KEY)

Njega sam kreirao ranije u ovom blog postu.

Opcionalni parametri
  • mode – označava način prijevoza koji će se koristiti pri izračunavanju udaljenosti. Moguće je birati između: driving (vožnja, ako se ništa ne odabere uzima se ovaj parametar), walking (hodanje), bicycling (bicikl), transit (javni prijevoz, ako postoji).

Google Distance Matrix API mode walking

Google Distance Matrix API language

  • region – označava odabir države prema ccTLD. Ovaj parametar će utjecati na rezultate geokodera, ali ako relevantniji rezultati postoje izvan određenog područja, oni mogu biti uključeni u rezultat.
  • avoid – omogućava odabir ograničenja za rutu. Npr. izbjegavati cestarinu (avoid=tolls), autocestu (avoid=highways).

Više o ostalim parametrima.

Kasnije je unutar sučelja moguće vidjeti statistiku korištenja API-ja.

Google Distance Matrix API statistika

Ionic Card IO – prikupljanje podataka s bankovne kartice

U ovom ću blog postu pokazati kako napraviti jednostavnu Ionic aplikaciju koja će imati mogućnost prikupljanja podataka s bankovne kartice kako bi se moglo provesti plaćanje.

Važna napomena! Ovdje navedeni primjer tiče se samo klijentske strane i plaćanje neće biti provedeno. Za to je potreban i backend koji je moguće napraviti u npr. NodeJS-u.

Što je Card IO?

https://www.card.io/ omogućava skeniranje bankovne kartice kako bi se olakšalo i ubrzalo plaćanje.

Više o funkcionalnostima moguće je pronaći na poveznici https://github.com/card-io/card.io-Cordova-Plugin ili unutar dokumentacije Ionic Native 3.x Card IO plugina

Nekoliko je opcionalnih parametara koji se mogu koristiti prilikom skeniranja bankovne kartice unutar CardIOOptions objekta:

S druge strane, tu je i CardIOResponse objekt unutar kojega je moguće odrediti koje informacije želimo dobiti nakon što se uspješno obavi skeniranje bankovne kartice.

Kreiranje aplikacije

Kreiram novi Ionic projekt i odmah dodajem Android platformu.

Card IO implementacija

Za početak, instaliram Ionic Native 3.x plugin Card IO.

Nakon toga ovaj plugin deklariram unutar app.module.ts datoteke.

Sadržaj ekrana neće sadržavati ništa posebno. Glavna funkcionalnost krije se iza gumba tj. funkcije scanCard().

Ipak, kako bi se kartica mogla uslikati potrebno je dati odobrenje koje će biti automatski zatraženo prilikom prvog pokretanja aplikacije.

Ionic Card IO - početni ekran

Funkcionalnost se nalazi unutar home.ts datoteke tj. unutar HomePage klase.

Vezano uz ranije navedeni CardIOOptions objekt, ako ga postavim na sljedeći način

Ekran za skeniranje tj. za ručni unos podataka s bankovne kartice izgleda ovako:

Ionic Card IO

Međutim, ako to malo drugačije posložim

i ekrani će izgledati drugačije

Ionic Card IO

S obzirom da u ovom primjeru ne želim koristiti svoju karticu iskoristit ću dostupne demo podatke sa adrese https://www.datatrans.ch/showcase/test-cc-numbers

Test card numbers

Prikupit ću podatke s dvije kartice.

Ionic Card IO

Što unutar Chrome Developer konzole izgleda ovako:

Ionic Card IO

Zaključak

Struktura aplikacije prema package.json

Optimizacija razvojnog okruženja za 95% slučajeva umjesto za preostalih 5%

Nedavno sam naletio na ovaj vrlo zanimljiv tekst što me navelo na razmišljanje jer sam se prepoznao u tome.

Autor gore navedenog teksta naišao je na vrlo zanimljiv naslov “Why I wrote 33 VSCode extensions and how I manage them” gdje se među komentarima moglo vidjeti sljedeće:

My problem with adding plugins or extending my environment much past the default is that eventually I have to deal with a co-worker’s non-extended default installation. I end up relying too much on the add-ins.

Shvatio sam da sam i ja do nedavno na takav način, za onih “što ako” 5%, donosio odluke. Komentar koji mi je posebno “zapeo za oko” kaže:

I strongly dislike the reasoning that suggests you should hamstring yourself 100% of the time to accommodate a potential situation that may affect you 5% of the time.
“I don’t use multiple monitors because sometimes I’m just with a laptop”.
“I don’t customize my shell because sometimes I have to ssh to a server”
“I don’t customize my editor because sometimes I have to use a coworkers editor”.

Sada vidim koliko takav način razmišljanja nije imao smisla, ali tada mi se sve to činilo sasvim logično i vrlo sam odlučno branio svoje stavove.

Sjećam se da dugo vremena nisam htio koristiti nikakvu drugu temu niti većinu proširenja za Visual Studio Code ili Sublime Text jer što kada budem morao koristiti PC od kolege, a on koristi zadanu temu ili nema određeno proširenje.

Znači u startu sam se ograničavao i umjesto da sebi olakšam 95% slučajeva ja sam više razmišljao i radio na preostalih 5% jer tada nisam shvaćao sljedeće – optimizacija za 5% je primjer optimizacije za scenarij “što ako”.

Činio sam sve što je u mojoj moći da svoje razvojno okruženje učinim dovoljno generičkim da može raditi svugdje i da mogu biti spreman za onih 5%, ali sam zapravo otežavao sam sebi 95% vremena, a to je vrijeme koje je najvažnije.

Takve vrste odluka ne utječu samo na razvojno okruženje nego i na kod.

Personally, I often try and over optimize before I’ve even begun. Consequently I get overwhelmed and rarely build any of the ideas I was thinking about. – izvor

Ako se nešto ide programirati da bi odgovaralo “što ako” scenariju to znači da vjerojatno u potpunosti ne odgovara traženoj specifikaciji. Možemo mi kao developeri misliti što god hoćemo i htjeti unaprijed napraviti pripremu za sve moguće scenarije, ali ako to nije traženo po specifikaciji može doći samo do još više grešaka koje će samo oduzimati dodatno vrijeme za rješavanje, a do tih grešaka nije niti trebalo doći.

Premature optimization is the root of all evil.

Ipak, kada vidimo na koji način radi Google i druge velike tvrtke opet je moguće doći do izgovora za “što ako” scenarij i raditi nešto što nam realno nije potrebno pri čemu fokus opet odlazi na dio od 5%.

Ako neka velika tvrtka nešto koristi na određeni način to ne znači da taj način odgovara svim ostalim tvrtkama.

Instead of just getting your app up and running and seeing how it goes, you try to make decisions so that your application can be developed by 100 different teams sprawling across 5,000 developers.

Do 5% može doći i prilikom procesa implementacije tj. postavljanja aplikacije u produkciju.

To često može uključivati mjesece potrošene na detalje poput savršenog skaliranja, automatizacije određenih procesa i sl. što na kraju ne dovede do očekivanih rezultata jer sva dostupna rješenja, ma koliko tvrdila drugačije, ne mogu dati odgovor za sve vrste scenarija. Velike tvrtke koje su ta rješenja kreirala i koje ih koriste iza toga skrivaju mnoštvo specifičnih prilagodbi da bi sve radilo na određeni način.

When you try to optimize your deployment strategy to handle a billion requests a second from day 1, you’re just setting yourself up for an endless loop of theory based research.

Zaključno, energiju je pametnije usmjeriti prema 95% i vidjeti kako će se stvar ponašati. Ovisno o povratnim informacijama raditi dodatne optimizacije. Drugim riječima, raditi optimizaciju onda kada postoji realna potreba za tim, a ne zbog “što ako” slučajeva.