3.1 Progressiivinen web-sovellus (PWA)
3.2 Hybridisovellus
3.2.1 Cordova ja Capacitor
3.2.2 Ionic
3.3 Natiivi hybridisovellus
3.3.1 Nativescript
3.3.2 React Native
3.4 Mobiilisovelluskehityksen pilvialustat
3.4.1 Firebase
Tehtävät
Mobiilisovelluskehitys web-teknologioilla (5op) kuuluu Jyväskylän Ammattikorkeakoulun (JAMK) Tietojenkäsittelyn tutkinto-ohjelman (Tiko) vaihtoehtoisiin ammattiopintoihin.
Opettaja Tommi Tuikka, tuito(at)jamk.fiMuut perustiedot ovat kurssin Moodle-työtilassa.
Kurssilla käytetään ohjelmointikielinä Javascriptiä ja Typescriptiä. Ohjelmointiympäristönä käytetään normaalia JS-ekosysteemiä ja kehitysvälineenä Visual Studio Code -editoria, eli ohjelmointiympäristö on sama kuin aiemmilla kursseilla.
Mobiilisovelluskehitys on ollut perinteisesti mobiililaitteen käyttöjärjestelmän päälle rakennettavien natiivien sovellusten kehittämistä. Perinteisessä natiivissa kehityksessä sovelluksesta joudutaan tekemään eri alustoille erilliset versiot eri ohjelmointikielillä. Esimerkiksi Android-sovellukset tehdään Kotlinilla/Javalla ja iOS-sovellukset Swiftillä.
2010-luvulla web-teknologiat eli HTML, JavaScript ja CSS ovat
kehittyneet varteenotettaviksi vaihtoehdoiksi mobiilisovellusten
rakentamisessa. Etuna on se, että web-sovelluskehittäjät voivat
kehittää mobiilisovelluksia ennestään tutuilla web-teknologioilla.
Olemassa olevan web-sovelluksen koodista voidaan kehittää
mobiilisovellus melko pienillä muutoksilla. Lisäksi samasta
web-teknologioilla tehdystä koodipohjasta "buildaaminen" eri
alustoille (Android, iOS), on kustannusten kannalta tehokkaampaa
kuin erillisten sovellusten kehittäminen eri alustoille eri
kielillä. Ongelmina ovat olleet natiivia huonompi suorituskyky,
mobiililaitteen laiterajapintojen natiivia heikompi toimivuus sekä
UI:n ja UX:n poikkeaminen natiivista. Ongelmat ovat kuitenkin
vuosi vuodelta vähentyneet ja suurimmaksi osaksi poistuneet.
Web-teknologiat sopivat parhaiten älypuhelimelle kehitettävien
mobiilisovellusten tuottamiseen, joissa alustana ovat yleensä Android tai iOS. Tällä kurssilla esitetyt
teknologiat soveltuvat kuitenkin myös älykellojen
sovelluskehitykseen WearOS tai WatchOS -käyttöjärjestelmille, jotka
perustuvat Androidiin ja iOS:iin. Älykellojen tapauksessa
suorituskykyyn ja laiterajapintoihin liittyvät vaatimukset
saattavat kuitenkin suosia kehitystä natiiveilla teknologioilla.
Erityisiä huomion aiheita mobiilikehityksessä web-teknologioilla ovat:
Web-sovellusten yleiseksi vaatimukseksi on tullut se, että web-käyttöliittymän rinnalla pitäisi pystyä tarjoamaan sovelluskaupasta ladattava mobiiliapplikaatio, tai uutena vaihtoehtona progressiivinen web-sovellus (PWA). PWA-teknologia mahdollistaa myös sen, että voidaan tehdä vain yksi sovellus joka voi toimia samanaikaisesti web-käyttöliittymänä tietokoneella ja applikaationa mobiililaitteessa. On myös mahdollista jakaa sovelluksen käyttö osaksi tietokoneelle ja osaksi mobiililaitteelle. Sovelluksen hallinnointi ja vaativampi sisällöntuotanto voidaan tehdä tietokoneella web-käyttöliittymässä (admin-tila), ja sovelluksen käyttö eli kevyempi sisällöntuotanto ja sisällön kuluttaminen mobiililaitteella (user-tila).
Mobiilisovelluksen kehittämiseen web-tekniikoilla on olemassa kolme erilaista lähestymistapaa: 1)Progressivinen web-sovellus eli PWA, 2)Hybridisovellus ja 3)Natiivi hybridisovellus. Näiden välillä voidaan tehdä valinta seuraavilla kriteereillä:
Ennen mobiilisovellusprojektin varsinaisen työn aloittamista kannattaa selvittää että tarvittavien laitteen ominaisuuksien (esim. kamera, liiketunnistimet, laitteen muisti yms.) käyttö onnistuu hyvin valitulla teknologialla. Kannattaa myös kokeilla että mahdolliset välttämättömät ulkopuoliset kirjastot toimivat valitun teknologian kanssa. Heti projektia aloitettaessa kannattaa myös selvittää olisiko mobiilisovelluksessa mahdollista ja/tai järkevää hyödyntää esim. Firebasea tai vastaavaa MBaaS (Mobile Backend as a Service) -pilvipalvelua, joka voi helpottaa huomattavasti sovelluksen backendin kehitystä.
Milloin mobiilikehitykseen kannattaa käyttää web-teknologioita ja milloin ei?
Web-teknologioita kannattaa käyttää mobiilisovelluksen kehittämiseen silloin, kun kehittäjä osaa hyvin web-teknologiat, mutta muuta mobiilisovelluskehitysosaamista ei ole. Myöskin jos valmis web-sovellus on jo olemassa, ovat edellä esitellyt web-teknologiat nopein tapa muuntaa web-sovellus mobiilisovellukseksi. Jos sovelluksessa tarvitaan JS-kirjastoja, tai jos tarkoituksena on nimenomaan toteuttaa PWA-sovellus, tehdään sovellus web-teknologioilla. Web-teknologoilla, ja esim. Angularilla toteutettu mobiilisovellus mahdollistaa kehittyneen arkkitehtuurin, jolloin suurempi ja monimutkaisempikin sovellus pysyy hallinnassa.
Jos tarkoituksena on tehdä melko yksinkertainen mobiilisovellus sovelluskauppaan "puhtaalta pöydältä", eli mitään web-sovelluskoodia ei ole olemassa, eikä JS-kirjastoja tarvita, niin Flutter on kätevä ja helppo vaihtoehto. Tosin kehittäjien tulee silloin osata siinä käytettävä Dart-kieli, jonka esim. Typescriptiä osaava kehittäjä oppii kuitenkin varsin helposti. Flutter-koodaus ei ole varsinaista web-sovelluskehitystä, mutta Dart-koodi voidaan muuntaa Javascriptiksi. Flutterin ongelmana on ollut arkkitehtuurin heikkous isommissa sovelluksissa. Flutteria ei tällä kurssilla käsitellä, koska se ei kuulu web-teknologioihin.
Jos kehitettävä mobiilisovellus on yksinkertainen, ja se tehdään tarkasti määriteltyyn tarkoitukseen, eikä sovelluksen jatkokehitykselle, uudelleenkäytölle tai laajentamiselle ole suurempaa tarvetta, voi myös no-code/low-code-sovelluskehitin olla hyvä vaihtoehto. Esim. AppGyverin avulla saa nopeasti aikaan pieniä mobiilisovelluksia. AppGyver perustuu web-teknologioihin, sillä se tuottaa React Native -koodia. Lisäksi AppGyverissa voi käyttää Javascriptiä hieman vaativampien toimintojen toteuttamiseen.
Täysin natiivi mobiilikehitys älypuhelimille on menettänyt
merkitystään web-teknologioiden, Flutterin ja
no-code/low-code-sovelluskehittimien vallatessa alaa. Vain
erittäin kovaa suorituskykyä vaativat ja monimutkaiset
mobiilisovellukset kannattaa enää tehdä täysin natiivisti
Kotlinilla, Javalla, Swiftillä tai C++:lla. Sen sijaan
älykelloissa (WearOS ja WatchOS), täysin natiivit teknologiat ovat
edelleen selvästi eniten käytettyjä, johtuen älykellojen
heikommasta suorituskyvystä.
Mobiilisovelluksia on jo pitkään tehty web-tekniikoilla suoraan selaimelle. Selain on piilotettu sovelluksen alle siten, että sovellus näyttää natiivilta applikaatiolta vaikka se onkin tavallinen SPA (Single Page Application) web-sivu. Sovellusta ei ole tarvinnut jaella sovelluskaupasta, vaan sen on voinut hakea suoraan web-osoitteesta. Sovelluksen data on voitu ladata selaimen välimuistiin, jolloin sovellusta on voitu käyttää myös ilman webbiyhteyttä. Aiemmin tällaisten sovellusten kehittämiseen ei ole ollut yhtenäistä standardia, mutta vuonna 2015 Google kehitti Progressiivisten web-sovellusten (PWA) epävirallisen standardin.
PWA:n toimintaperiaate ja sovelluksen kehittäminen
PWA toimii aivan samalla tavalla kuin sovelluskaupasta ladattava mobiiliapplikaatio, mutta sitä ei tarvitse ladata sovelluskaupasta. Kun käyttäjä saapuu PWA-sovelluksen web-osoitteeseen, mobiililaitteen näytölle ilmestyy ilmoitus jossa kysytään, haluaako käyttäjä ladata sovelluksen mobiililaitteeseensa. Hyväksymisen jälkeen sovelluksen ikoni ilmestyy mobiililaitteen ruudulle, ja sovellus on sen jälkeen käytettävissä, aivan kuin mikä tahansa mobiilisovellus. Samalla tavalla PWA-sovellus ladataan kannettavalle tietokoneelle, jossa se toimii kuin asennettu työpöytäsovellus. Asennuskysely ilmaantuu selaimen osoiterivin oikeaan laitaan.
Kun PWA-sovellus avataan ensimmäisen kerran, ja sitä käytetään, serveriltä tuleva data siirtyy selaimen välimuistiin (cache). Cachen sisältö määritellään esim. taulukkomuuttujassa jossa ovat hakemistot ja/tai tiedostot, jotka cacheen haetaan. Määrittely voi sisältyä service workerin js-tiedostoon, mutta se voi olla myös erillisessä JSON-muotoisessa tiedostossa (esim. Angularin buildatussa dist-kansiossa on ngsw.json). HTML5 standardiin perustuva service worker hakee dataa selaimeen pelkästään cachesta tai cachesta ja palvelimelta riippuen siitä onko web-yhteys tarjolla. Service worker toimii yleensä vain jos palvelimella on käytössä SSL-protokolla (https://...). Testaaminen kuitenkin onnistuu, kun PWA-sovellusta kehitetään omalla koneella, sillä http://localhost -alkuisista osoitteista service worker toimii, vaikka SSL-protokolla ei olisikaan käytössä. PWA:n toiminnan testaaminen kehitysvaiheessa on helppoa, sillä toiminta on samanlaista tietokoneella ja mobiililaitteessa. Eroja tulee vain silloin, jos sovellus käyttää sellaista mobiililaitteen laitteistoa, jota ei ole tietokoneessa.
PWA:n voi muuntaa .apk-paketiksi ja laittaa myös sovelluskauppaan. Tällöin sovellus toimii Android tai IoS-käyttöjärjestelmän WebViewin päällä. WebView on pienikokoinen selainmoottori, joka nykyään sisältyy mobiililaitteiden käyttöjärjestelmiin. Käytännössä PWA-sovelluksesta tulee tällöin hybridisovellus, kts luku 3.2. Paketointiin on automaattisia työkaluja:
1) Pwa-to-apk
2) PWABuilder
3) BubbleWrap
PWA-sovellus Angularilla
PWA -sovelluksia on helppo kehittää yleisimmillä JS-sovelluskehyksillä ja -kirjastoilla. Angularilla tehdyn sovelluksen muuntaminen PWA:ksi on automatisoitu. Projektista tulee PWA-sovellus kun projektin juuressa antaa komennon:
ng add @angular/pwa
Projektiin syntyvät automaattisesti yleisimmät PWA:n piirteet, mutta cachen määrittelyä voi joutua muokkaamaan, jos haluaa että sovelluksen ulkopuolelta (esim. web-API:sta) tulevan datan käyttö cachesta toimii mahdollisimman hyvin (ohje). Index.html:ään pitää lisätä käsin muutamia metatietoja, esim. Applen selaimen tarvitsemat tiedot. Myös sovelluksen kuvakkeet pitää vaihtaa, jos ei halua käyttää oletuskuvakkeita. Huomaa että service-worker toimii vain tuotantoon buildatussa sovelluksessa, joten anna komento:
ng build
Tämän jälkeen voit kokeilla dist-kansioon syntynyttä sovellusta, ajamalla sitä testiserverillä. Hyvä testiserveri on http-server, jolla voit ajaa buildatun sovelluksen projektin juuresta portissa 8080, antamalla seuraavan komennon terminaalissa:
http-server -p 8080 dist/<projektin-nimi>
PWA-sovelluksen service worker Workboxilla
Workbox on apukirjasto perusteellisempaan service workerin rakentamiseen ja säätämiseen. Edellä esitetyt ratkaisut soveltuvat yksinkertaisiin tapauksiin, mutta joskus voidaan tarvita edistyneempää cachen säätöä. Workbox helpottaa normaalisti varsin vaativaa service workerin ja cachen säätämistä.
- Progressive Web Apps:Working with Workbox
PWA:n hyvät ja huonot puolet
Tietyiltä ominaisuuksiltaan PWA on sovelluskaupasta ladattavaa natiiviapplikaatiota parempi: PWA-sovelluksen asentaminen on helpompaa ja nopeampaa, ja cachen ansiosta PWA yleensä käynnistyy nopeammin. PWA-sovelluksia voi hakea hakukoneilla, ja linkittää webissä, eikä käyttäjän tarvitse ladata niihin päivityksiä. Sovelluskehittäjälle PWA:n kehittäminen ja päivittäminen on perinteiseen mobiilisovellukseen verrattuna helpompaa. Mahdollisuus tarjota PWA web-sivustoa täydentävänä lisäpalveluna, ja lataamisen helppous, ovat tehneet PWA:sta tietyissä tapauksissa parhaan vaihtoehdon mobiilisovelluksen tarjoamiseksi. PWA on erityisen kätevä lyhytaikaiseen käyttöön tarkoitetuissa mobiilisovelluksissa. Ei ole erityisen järkevää ladata sovelluskaupasta esim. 30 erilaista messu- tai festivaalisovellusta, jotka jäävät sitten laitteelle, kun niitä ei viitsi poistaa. PWA ratkaisee tämän ongelman, ja mahdollistaa periaatteessa yhden ja saman sovelluksen julkaisemisen tärkeimmillä alustoilla: mobiiliapplikaationa, web-sovelluksena ja tarvittaessa myös työpöytäsovelluksena.
PWA:n ongelmina voivat olla selaimeen perustuvien laiterajapintojen huono toimivuus ja natiivisovelluksesta poikkeava UI/UX. Selain-API:t eivät vielä tarjoa yhtä toimivia ratkaisuja mobiililaitteen laitteiston käyttöön kuin natiivi-API:t tai hybridi-API:t. Selaimen tarjomat rajapinnat ovat kuitenkin koko ajan parantuneet.
PWA-sovelluksen UI/UX voidaan kehittää tarvittaessa lähes natiivia vastaavaksi sopivien ulkoasukirjastojen eli CSS-apukirjastojen tai UI-komponenttikirjastojen avulla. Esimerkkejä tavallisimpien ulkoasukirjastojen käytöstä Angularin kanssa on tässä. Ulkoasukirjastot eivät välttämättä takaa täydellistä responsiivisuutta, vaan niiden lisäksi tarvitaan usein responsiivisen sivun suunnittelu Media Queryjen avulla.
JS/HTML5-rajapinnat ja mobiililaitteen laitteiston käyttö
PWA-sovellus voi käyttää kaikkia selaimen tukemia JS/HTML5-rajapintoja. Edellä esitetty Service Worker API on sellainen ja toinen
esimerkki on Push API jolla luodaan push-notifikaatoita
serveriltä. JS/HTML5-rajapintojen avulla voidaan käyttää myös
mobiililaitteen laitteistoa kuten GPS, kamera, accelerometri jne. What Web Can
Do Today esittää listan siitä mitä web-tekniikoilla
pystytään esim. mobiilisovellukseen toteuttamaan. JS/HTML5
-laiterajapintojen toimivuus pitää aina testata hyvin ennen kuin
niitä käytetään sovelluskehityksessä. Myös selainten toteutuksissa
on eroja, ja Chromessa JS/HTML5-API:t toimivat yleensä parhaiten.
-Google developers progressive web apps
-Step-By-Step Guide for turning Angular
application into a PWA
Toinen lähestymistapa mobiilisovelluskehitykseen web-tekniikoilla
on sovelluksen kehittäminen HTML:llä, CSS:lla ja JS:llä, ja sen
"paketointi" käyttöjärjestelmän (Android, ioS) natiivia sovellusta
muistuttavaksi sovellukseksi, eli .apk- tai .ipa -paketiksi.
Käytännössä paketointi tapahtuu siten, että automaattisesti luodun
yksinkertaisen Android- tai IoS-sovelluksen ensimmäisestä ruudusta
aukeaa WebView-näkymä, josta
käytetään selainsovellusta. Syntynyt sovellus on siis pieni
Android-tai IoS-sovellus, jonka sisältä aukeaa web-sovellus.
Sovelluksessa on tärkeimmät mobiilisovelluksen piirteet, joten se
voidaan laittaa myyntiin sovelluskauppoihin.
Apache
Cordova on avoimen lähdekoodin sovelluskehys, jonka avulla
kehitetään hybridiapplikaatioita. Cordova-projekti voidaan luoda
Cordova-client -komentotyökalulla, joka asennetaan npm:llä.
Cordova.js tarjoaa pluginit eli laiterajapinnat, joilla
päästään käsiksi laitteen ominaisuuksiin, ja kirjaston jolla
web-sovellus voidaan "paketoida" natiivia muistuttavaksi
mobiilisovellukseksi. Cordovan lisäksi tarvitaan käyttöliittymän
kehittämiseen yleensä jokin kirjasto, jolla voidaan luoda
mobiililaitteeseen soveltuva käyttöliittymä JS:n, HTML:n ja CSS:n
avulla. Yleisin hybridisovellusten käyttöliittymäkirjasto on Ionic. Cordovan avulla on mahdollista
paketoida käytännössä mikä tahansa JS:n avulla tehty frontend
web-sovellus mobiiliapplikaatioksi. Sitä voi käyttää myös Javascript-pelien paketoimiseen .apk- tai
.ipa-paketeiksi (Android tai Ios).
-Cordova Android Platform Guide
-Cordova Best Practices
-Cordova Docs
Capacitor on Ionicin kehittämä laiterajapinta- ja paketointikirjasto, joka perustuu Cordovaan. Sillä voidaan siis tehdä samat asiat kuin Cordovalla, mutta se on kehitetty paremmin Ionicin tarpeisiin soveltuvaksi. Capacitoria voi käyttää myös itsenäisesti ilman Ionic-frameworkia, ja sillä voidaan paketoida käytännössä mikä tahansa JS:n avulla tehty frontend web-sovellus Android- tai IoS-sovellukseksi, aivan kuten Cordovalla.
Ionic on
erityisesti hybridiapplikaatioiden luontiin kehitetty
web-teknologioihin perustuva käyttöliittymäsovelluskehys, joka
käyttää sovelluksen paketoimiseen Capacitor-
tai Apache
Cordova -kirjastoa. Ionic-sovellus toimii siis WebViewin päällä.
Capacitorin laiterajapinnoilla päästään käsiksi mobiililaitteiden ominaisuuksiin: kamera, GPS, värinähälytys, QR-skanneri yms. Lisäksi capacitorissa on paljon muitakin plugineja. Käytännössä laiterajapinnat perustuvat HTML5-API-rajapintoihin, eivätkä ne ole natiiveja.
Ionic-sovellusten käyttöliittymän voi toteuttaa Angularilla, Reactilla, Vue:lla tai puhtaalla JS:llä. Ionic sisältää paljon valmiita käyttöliittymäkomponentteja, ja sovelluksesta voidaan Ionicin komponentteja käyttämällä tehdä täysin natiivin mobiilisovelluksen näköinen. Ionic on todennäköisesti helppokäyttöisin ja nopein väline, jos on tarkoitus kehittää applikaatio sovelluskauppaan web-teknologioilla. Ionicin valmiit käyttöliittymäkomponentit eivät sovellu hyvin esim. kannettavan tietokoneen näytölle, vaan ne on tarkoitettu esitettäväksi mobiililaitteen näytöllä.
Angular-käyttöliittymän kehittäminen Ionicilla on samanlaista kuin esim. Angular Materialilla. Katsotaan mallia dokumentaatiosta, kopioidaan valmiskomponetteja HTML-templaatteihin, ja laitetaan mahdolliset valmiskomponenttiin liittyvät ts-koodit ts-luokkiin. Sovelluksen toimintalogiikka tehdään siis ts-luokkiin ja serviceihin, aivan kuten tavallisessa Angular-kehityksessä.
Ionicin ongelmana natiivisovelluksiin verrattuna on ollut hiukan hitaampi toiminta, ja UI/UX:n pienet eroavaisuudet. Ionic on kuitenkin kehittynyt uusimmissa versioissa sille tasolle, että kohtuullisen kokoisissa ja tavallisimpia käyttöliittymäratkaisuja käyttävissä sovelluksissa eroa natiiviin ei pysty havaitsemaan. Ionicilla on tehty menestyksekkäästi myös suuria mobiilisovelluksia, kuten Sworkit jolla on yli 25 miljoonaa käyttäjää.
Ionic-sovelluskehityksessä käytettävät ohjelmakirjastot ovat siis:
1) Käyttöliittymäkirjasto (Angular, React tai Vue)
2) Käyttöliittymäkomponenttikirjasto, joka sisältää ion-alkuisilla tageilla esitettäviä komponentteja (Ionic API index)
3) Capacitor- tai Cordova-kirjasto, joka sisältää laiterajapinnat, ja jota käytetään sovelluksen paketointiin esim. .apk-paketiksi. Koska Ionic-sovellus tehdään selaimen päälle, se voi käyttää myös kaikkia HTML5 API-rajapintoja ja kaikkia selainsovellusten JS-kirjastoja.
Ionic-sovelluksen perusrunko eli boilerplate luodaan Ionic CLI-työkalulla. Ionic CLI:llä luodun rungon kehitystä voi jatkaa VSCodella ja rungon päälle voi kopioda valmiita Ionic-komponentteja. Nopeasti rakennetun valmiskomponenteista muodostuvan UI:n pohjalta voi aloittaa varsinaisen koodauksen. Ionic-sovellusta voi testata aluksi selaimella, ja applikaatioksi paketoitua sovellusta voidaan testata emulaattorilla tai suoraan mobiililaitteella.
Ionic PWA
Ionic tukee hyvin myös PWA-sovelluksen luontia: ionicframework.com/pwa. Ionicilla voi siis varsin helposti tehdä samasta codebasesta sekä hybridiapplikaation sovelluskauppaan että PWA-sovelluksen. Ohje: Publishing a Progressive Web App. Angular-sovelluspohjasta luodaan PWA aivan samalla tavalla kuin Angularilla ilman Ionicia. Ionicilla tehty PWA ei tosin sovellu kovin hyvin isolta näytöltä esitettäväksi, sillä Ionicin tyylit on optimoitu pienikokoiselle mobiililaitteen näytölle.
-The Good and the Bad of Ionic Mobile Development
-Virallinen Ionic-Angular -tutoriaali, jossa
käytetään camera-pluginia.
Natiivi hybridisovellus on mobiilisovellus, joka toteutetaan web-teknologioilla (JS/TS ja CSS), mutta se ei toimi selaimen päällä, vaan mobiilisovelluksen natiivissa ympäristössä. Täysin natiivi UI/UX ja natiivit laiterajapinnat voivat olla joissain tapauksissa tärkeitä sovelluksen toiminnan kannalta. Natiivi hybridisovellus toimii yleensä hieman nopeammin kuin selaimelle (WebView) tehty hybridisovellus, ja erityisesti monimutkaisemmissa ja raskaammissa sovelluksissa nopeudella voi olla merkitystä.
Web-tekniikoilla luotu natiivi hybridisovellus ei ole täysin natiivi, mutta sen käyttöliittymä ja laiterajapinnat ovat käytännössä natiiveja. Nativescript ja React Native ovat sovelluskehyksiä, jotka mahdollistavat sovelluksen rakentamisen Androidin tai IoS:n natiivin ympäristön päälle. Natiivissa hybridisovelluksessa ei käytetä web-selainta, HTML:n DOMia eikä HTML-tageja, vaan käyttöliittymän elementit toteutetaan sovelluskehyksen käyttöliittymätageilla. Sovelluskehykset sisältävät myös laiterajapinnat, joilla saadaan suora yhteys mobiililaitteen laitteistoon. Ohjelmointikielenä on kuitenkin Javascript tai Typescript, ja CSS-tyylejä käytetään.
Nativescript-kehityksessä käytetään useimmiten Angularia ja Typescriptiä, mutta NS -sovelluksia voi kehittää myös Vuella, Reactilla, Sveltellä tai puhtaalla JS/TS:llä. Nativescriptissä käyttöliittymä rakennetaan NS:n UI-komponenteilla, eli UI widgeteillä jotka ovat XML-muotoisia. NS:ssä on melko vähän sisäänrakennettuja käyttöliittymäkomponentteja, mutta lisää voi ladata plugineina (esim. accordion).
Mitään selaimeen sidottua koodia kuten HTML:ää tai selainriippuvaista JS:ää ei voi Nativescriptissä käyttää, koska sovellusta ei tehdä selaimelle. Nativescriptissä voi kuitenkin käyttää samanlaisia CSS-tyylimäärityksiä kuin web-sivulla, mutta tyylejä on käytössä rajoitettu määrä. Käyttöliittymän layoutin tekemiseen NS:ssä on omat layout-ratkaisunsa.
Kun sovellus käännetään (build) mobiilisovellukseksi, muunnetaan NS-komponentit Androidin tai IoS:n natiiveiksi komponenteiksi, riippuen siitä kummalle alustalle sovellus käännetään.
Nativescript-Angular -sovelluksen toimintalogiikka tehdään Typescriptillä, ja se on samanlainen kuin tavallisessa Angular web-sovelluksessa. Angularin moduulikirjastojen lisäksi käytössä ovat Nativescriptin core-moduulit, joilla tehdään NS-sovellukselle spesifisiä toimintoja. Nativescriptillä pääsee suoraan käsiksi mobiililaitteen hardwareen pluginien avulla, (kamera, GPS, accelerometri yms.) aivan kuten natiivikehityksessä. Huomaa, että monet NS-pluginit on tehty vanhoille NS-versioille, eivätkä ne toimi enää suoraan uusissa versioissa. Kannattaa tarkistaa Githubista, että pluginia on päivitetty lähiaikoina, ennen kuin harkitsee sen kokeilua ja käyttöönottoa.
Nativescript-sovelluskehityksen välineet
Nativescript-sovelluskehitykseen sopii sama VSCode-asennus kuin
Angular-sovelluskehitykseen. Nativescript-projektia lähdetään
tekemään Nativescript CLI:llä, joka asennetaan
seuraavasti:
npm i -g nativescript
Kehitysympäristö pitää säätää kuntoon tämän ohjeen avulla. Eri käyttöjärjestelmille on omat ohjeensa. CLI:n ja kehitysympäristön toimivuuden voi tarkistaa komennolla:
ns doctor
Nativescript-kehitys aloitetaan yleensä ottamalla käyttöön valmis
sovelluspohja eli templaatti tai boilerplate. Yksinkertaisia
templaatteja on täällä. Monipuolisempia valmiita pieniä
sovelluksia täällä (valitse Templates tai hae
hakusanalla template). Esimerkkinä Angularin blank-templaatti:
ns create ns-testapp --template
@nativescript/template-blank-ng
Huomaa että jotkin Angularin templaatit voivat noudattaa vielä Angularin versiota 18, ja olla modulaarisia. Uusinta Angularin versiota noudattavan NS-sovelluksen saat tehtyä aina komennolla:
ns create ns-testapp --ng
NS-projekti muistuttaa tavallista Angular-projektia, mutta pieniä
eroja on havaittavissa. Projektissa on App_Resources-kansio, jossa
ovat Android- ja IoS -projektien tarvitsemat resurssit. Kun
seuraavissa vaiheissa projekti ajetaan emulaattorissa tai
buildataan, syntyy projektiin platforms-kansio, jonne rakentuvat
Android- tai IoS -projektit, samalla tavalla kuin Ionicissa.
Sovelluskehityksen apuna voi käyttää VsCoden NS-pluginia.
Sovelluksen ajaminen ja debuggaus eivät onnistu selaimessa, vaan
ne on tehtävä esim. Android-emulaattorissa joka tulee Android
studion mukana. Avaa emulaattori ja anna VSCoden projektissa
komento:
ns run android
jolloin sovellus avautuu emulaattoriin. Koodatessa sovellus päivittyy emulaattoriin automaattisesti livesyncin ansiosta.
Valmis sovellus buildataan .apk:ksi komennolla:
ns build android
Polku Android SDK:hon pitää olla määritelty käyttöjärjestelmän polkuasetuksissa, jotta SDK löytyy. Valmis .apk-paketti löytyy platforms/android/app/build/outputs/apk -kansiosta.
Nativescript Preview -sivuston avulla voi tutustua NS:iin ilman tarvetta asentaa ohjelmointiympäristöä. Koodaus tapahtuu selaimessa (StackBlitz), ja sovelluksen esikatselu mobiililaitteessa. Esikatselua varten pitää ladata Preview-applikaatio. NS Previewin avulla voi kehittää julkaistavia sovelluksia, mutta pääasiassa se on tarkoitetettu NS:iin tutustumiseen.
React Nativen toimintaperiaate on käytännössä sama kuin Nativescriptillä, mutta sovelluksia on mahdollista kehittää ainoastaan React-kirjaston avulla. Koska React on JS frontend-kirjastoista suosituin, on myös React Native suosituin kirjasto natiivien hybridisovellusten kehityksessä. React Native sisältää samantyylisiä käyttöliittymäkomponentteja kuin Nativescript. CSS-tyylit täytyy React Nativessa tehdä Javascript-oliomuodossa, mikä poikkeaa hieman tavallisista web-sivun CSS-tyyleistä, joita voi käyttää Nativescriptissä.
React Native -sovelluskehityksen välineet
React Native -sovelluskehitykseen sopii sama VSCode-asennus, jota
olemme koko ajan käyttäneet. VSCoden React Native Tools -lisäosa on hyödyllinen,
mutta ei välttämätön. RN-projektia on helpointa lähteä tekemään
Expo-työkalulla. Expo mahdollistaa sovelluksen ajamisen selaimessa, vaikka kyseessä
on natiivi hybridisovellus, joka ei sisällä HTML:ää. Tyhjä, erittäin yksinkertaisen näköinen
JS-sovellus nimeltään "rn-testapp" luodaan seuraavilla
komennoilla:
npx create-expo-app rn-testapp
Kun olet käynnistänyt sovelluksen komennolla npx expo start, niin sitä voidaan ajaa selaimessa komennolla: w
Jos avaat Android-studion ja käynnistät Android-emulaattorin, voit ajaa sovellusta emulaattorissa komennolla: a
Kun teet muutoksia koodiin, sovellus päivittyy automaattisesti sekä selaimeen että emulaattoriin. Kehitysvaiheessa sovelluksesta ei vielä luoda .apk-pakettia. Tässä on ohje .apk-paketin luomiseksi React Native -sovelluksesta. RN-projektin sisälle syntyy Android-projekti, jonne syntyy .apk-paketti aivan samalla tavalla kuin Ionic- tai Nativescript-sovelluksissa.
-React Native -sovelluksen julkaisu Google Playssa.
Jos haluat luoda aiemmin esitettyä Angular Nativescript-tabs -sovelluspohjaa vastaavan React Native -sovelluspohjan, anna komento:
npx create-expo-app --template
ja valitse Navigation-templaatti (TS). Kuten huomaat, niin RN-sovellus, jossa on käytössä TS ja johon on tehty hieman arkkitehtuuria, ei näytäkään enää yhtään yksinkertaisemmalta kuin vastaava Angular Nativescript-sovellus.
Expon ansiosta React Native -sovellusta voi siis ajaa myös selaimessa, joten kokeiluun ei aluksi välttämättä tarvita mobiililaitetta. Käytännössä sovelluksen kehitystyö kuitenkin vaatii sovelluksen debuggaamisen laitteessa, jolloin voidaan käyttää Android-emulaattoria tai Expo-sovellusta, joka asennetaan älypuhelimeen. Expo-sovellus on yleensä ollut varsin buginen, joten emulaattori lienee parempi vaihtoehto.
Jos React ei ole ennestään tuttu, kannattaa React Nativen opiskelu aloittaa tästä oppaasta, jossa selvitetään Reactin alkeet React Native -sovelluksessa. Alkuun pääsee tyhjällä yksinkertaisella JS-templaatilla. Jos haluaa oppia Reactia paremmin, kannattaa suorittaa myös Tikon "virallinen" React-kurssi eli Full Stack open, josta 3 op:n alkuosa on alkuun pääsemiseksi riittävä.
-React Native Tutorial: Create Your First App
-How to Create a Camera
App with Expo and React Native
Mobiilikehitystä voidaan helpottaa huomattavasti ottamalla käyttöön pilvialustojen tarjoamia serverless-sovelluskehityspalveluita, eli ns. MBaaS-palveluita (Mobile Backend as a Service). Samoja palveluita voidaan yleensä käyttää myös tavallisten web-sovellusten kehityksessä. Serverless-termi tarkoittaa siis sitä että palvelun käyttäjän ei tarvitse huolehtia palvelimien toiminnasta tai säätämisestä, vaan palvelinten palvelut saadaan/ostetaan palveluntarjoajalta valmiina. MBaaS-palvelut voivat olla myös Backendless-palveluita, eli backendiä ei tarvitse toteuttaa itse lainkaan, koska frontendistä voidaan ottaa yhteys suoraan tietokantaan. Mobiilisovelluksissa backendin tarve on yleensä vähäisempi kuin isommissa web-sovelluksissa, joten pilvipalveluiden serverless-palvelut ovat mobiilisovellusten tarpeisiin useimmiten riittäviä. Mobiilisovelluksissa ei useinkaan tarvita muuta kuin yksinkertainen ja helppokäyttöinen tietovarasto, sekä autentikaatio.
MBaas -palveluista yleisimpiä ovat: Google Firebase, AWS Amplify ja Back4App. Lisää MBaaS-palveluntarjoajia täällä. MBaaS-palveluiden avulla saa helposti aikaan full-stack mobiilisovelluksen, ja alkuun pääsee ilmaiseksi. Huonona puolena on se, että sovellus joudutaan sitomaan määrättyyn MBaaS-palveluun, ja palvelun vaihto voi vaatia huomattavia muutoksia koodiin. Jos sovellus saa hieman enemmän käyttäjiä, alkaa laskutus, ja suuremmilla käyttäjämäärillä hintojen nopea nousu.
Firebase (Wikipedia Firebase) on Googlen omistama helppokäyttöinen pilvialusta, joka on keskittynyt erityisesti pilvipalveluiden tarjoamiseen mobiilisovelluksille, mutta sen palveluita voidaan yhtä hyvin käyttää tavallisissa web-sovelluksissa ja muissakin sovelluksissa, kuten peleissä. Firebase tarjoaa BaaS-palveluita (Backend as a Service), sekä serverless-funktioita (Functions as a service).
Firebasen ilmainen Spark Plan mahdollistaa viisi Firebase-projektia, joista jokainen voi sisältää useita sovelluksia ja palveluita. Projektin sisältämien sovellusten ja palveluiden määrää ei ole rajoitettu, kunhan pysytään Spark Planin operaatiomäärä- ja kiintolevytilarajoitusten sisällä. Spark Plan soveltuu hyvin ei-kaupalliseen tai demotarkoitukseen tehdyn sovelluksen pyörittämiseen. Palvelu pysyy ilmaisena, vaikka käyttäjiä olisi jo kohtalaisen paljon, eli muutamista kymmenistä satoihin. Suuremmilla käyttäjämäärillä palvelut ovat maksullisia ja hinnat nousevat nopeasti.
Firebasen käytetyimmät ilmaiset (Spark Plan) palvelut ovat:
1) Firestore
NoSQL-tietokanta
2) Hosting
(frontend-sovelluksille)
3) Autentikaatio
4) Cloud Storage
Firestore
Firebasen käytetyin tietovarasto on Firestore NoSQL-tietokanta. Firestoren tarjoamien metodien avulla on varsin helppo toteuttaa web- tai mobiilisovellukselle CRUD-backend, joka perustuu Firestore-tietokantaan. Firestoren metodien ansiosta koodi voidaan toteuttaa lähes kokonaan asiakaspuolelle, jolloin esim. palvelinpuolen sovellusta, jossa on REST-API, ei tarvita ollenkaan. Kyseessä on siis ns. Backendless-sovellus. Mikäli ei haluta käyttää Firestoren metodeja, voi Firestore-tietokannan osoite toimia suoraan myös REST-API:na.
Angularia varten on kehitetty Angularfire-kirjasto, joka hyödyntää Firestoren metodeja. Angularfiren CRUD-metodeja käytettäessä tiedon haku kannasta palauttaa tiedon observablena, ja muut operaatiot (lisäys, poisto, päivitys) palauttavat promisen. Varmista että käytät AngularFire 7.x tai uudemman version tutoriaaleja. Uusimmat AngularFiren versiot noudattavat samaa versionumerointia, kuin mikä on Angularissa. Jos Angularin versio on 17.x, on myös AngularFiren versio 17.x. Versio 17.x on täysin yhteensopiva version 7.x kanssa, koska 7.x vain nimettiin uudelleen versioksi 17.x.
Ennen kuin valitsee Firestoren sovelluksen backendin perustaksi,
kannattaa ottaa huomioon että Firestore soveltuu vain
toiminnoiltaan suhteellisen yksinkertaisten sovellusten alustaksi.
Monimutkaisempia tietokantaoperaatioita vaativille sovelluksille
se ei sovellu. Firestore good to know.
-Angular Firebase CRUD Operations Using
AngularFire - Firestoren käyttö Angularfire7:n avulla
-Build Your First Ionic App with Firebase using
AngularFire7 - Angularfire7 Ionic-sovelluksessa
Firestore on ns. reaaliaikatietokanta, eli liikenne asiakkaalta kantaan ja toisinpäin tapahtuu socket-pohjaisen protokollan avulla. Firestore perustuu vanhempaan Realtime Databaseen, eli on sen uudistettu versio. Firestore soveltuu siis myös reaaliaikasovellusten, kuten chat-sovellusten, alustaksi. Firestoren skaalautuvuus ei ole kuitenkaan paras mahdolllinen, joten jos reaaliaikasovelluksessa hyvin paljon liikennettä ja yhtäaikaisia käyttäjiä, Firestoren kapasiteetti ei riitä. Pienimuotoisempiin reaaliaikasovelluksiin, joissa on esim. muutamia kymmeniä yhtäaikaisia käyttäjiä, Firestore soveltuu hyvin.
-Building a realtime chat application using WebSockets with Angular and Firebase
Cloud storage
Firebasen Cloud Storage -palvelu on "säiliö eli bucket", jonne voidaan tallentaa binääridataa kuten kuvia, videoita yms. dokumentteja. Angularfire-kirjastossa on metodit myös sen hyödyntämiseen.
-AngularFireStorage dokumentaatio - Cloud
Storagen käyttöohje
Autentikaatio
Firebasen autentikaatiopalvelussa on mahdollista käyttää tavallista sähköpostiosoitteeseen ja salasanaan perustuvaa autentikaatiota, tai Googlen, Facebookin tms. sosiaalista autentikaatiota. Lisäksi on olemassa passwordless-autentikaatio, joka toimii emailiin lähetettävää linkkiä klikkaamalla, ilman että tarvitsee muistaa mitään tunnusta tai salasanaa.
-Firebase Authentication Tutorial With
AngularFire7 - Tavallinen ja Google-autentikaatio
-Firebase Authentication & File Upload using
AngularFire7 - Autentikaatio ja Cloud Storage
Toimivat esimerkit Angularfire7-autentikaatiosta:
-Yksinkertainen email/password-autentikaatio: ang-firebase-auth.zip
-Yksinkertainen Google-autentikaatio: ang-firebase-googleauth.zip
-Frontendin reitin suojaus Google-autentikaatiolla: ang-firebase-googleauth-route.zip
***