Ohjelmointikielet Suomen mobiilikehityksessä 2020 – Osa #4: React Native

Viimeisessä pääteknologiaosassa vaihdetaan tyystin perspektiiviä. Kaikki aikaisemmat julkaisun osat ovat olleet alustakohtaisia, keskittyen yhteen natiiviohjelmointikieleen. Alustakohtaisista ratkaisuista siirrytään valintaan, joka kattaa molemmat päämobiilialustat, vieläpä yhdellä kielellä. Näin yksittäisistä natiiviohjelmointikielistä siirrytään Web-pinon puolelle ja erityisesti siihen, miten JavaScriptillä voi luoda sovelluksia, jotka korvaavat kaksi eri natiivisovellusta.

Natiivi- ja Web-pinon leirien välillä on Punoksella jatkuvaa hyvähenkistä(?) pottuilua. Kaikista Ohjelmointikielet Suomen mobiilikehityksessä -blogijulkaisuista juuri tämä osa on kerännyt eniten sisäistä keskustelua ja kommentteja. Siksi ei olekaan yllätys, että tästä tuli laajin ja pisin. React Nativen syntytarina ei ole puhtaasti tekniikkavetoinen. Tästä syystä mukaan on otettu hieman laajempaakin perspektiiviä.

React Native on Facebookin vastaus mobiilikehityksen haasteisiin. Vastaukseen päädyttiin useiden eri mobiilisovelluskokeilujen kautta. Facebook oli kehittänyt uuden JavaScript-kirjaston nimeltä React, omia, vaativia Web-julkaisutarpeitaan ja toimintatapojaan varten. React Native pyrkii yhdistämään React-kehityksen ja natiivikehityksen parhaat ominaisuudet.  

React Native -sovelluskehityksen kulmakivenä on lupaus kehityskustannusten pitämisessä aisoissa silloinkin, kun sovelluksen pitää tukea useita alustoja. Tämä kaikki kiitos yhden ohjelmointikielen ja yhden ohjelmistoprojektin. Asia ei kuitenkaan ole näin yksinkertainen. React Native -valinnan hyödyt (ja haitat) riippuvat sekä sovelluksen teknisistä vaatimuksista että kehitysorganisaatiosta itsestään.

Aloitetaan organisaatiosta: React Native -valinta antaa parhaat edut nopealiikkeiselle Web-kehitysorganisaatiolle, joka on valinnut työkalukseen Reactin. React Native on kohtuullisen vaivatta omaksuttavissa React-kehittäjien näkökulmasta. Ohjelmointikieli ja toimintatavat ovat ennestään tuttuja. Mobiilisovelluksen toteuttaminen onnistuu siis samalla Web-jengillä, ilman mobiilialustakohtaisten tekijöiden palkkaamista. Käytännössä tämä säästää aikaa, rahaa ja vaivaa.

Mitä taas tulee itse mobiilisovellukseen, optimitapauksen reunaehdot ovat seuraavat:

1. Jo projektin lähtöruudussa tiedetään, että sovellus tullaan julkaisemaan molemmille alustoille.
2. Sovelluksen käyttöliittymä koostuu tyypillisistä komponenteista.
3. Suorituskykyvaatimukset asettuvat kohtuullisiin puitteisiin.
4. Sovellus tulee hyödyntämään korkeintaan tavallisimpia teknisiä sensoreita.
5. Sovelluksen ominaisuustarpeisiin vastaavat kirjastot ovat ajan tasalla ja niitä ylläpidetään aktiivisesti

Mitä kauemmaksi organisaation tai sovelluksen ominaisuudet erkanevat edellä mainittujen kahden kappaleen kuvailemasta, sitä huonommin React Native tilanteeseen sopii. 

Vaikka React Native soveltuu mainiosti suurimpaan osaan tyypillisistä mobiilisovellushankkeista, on kuitenkin olemassa joitakin teknisiä aspekteja, jotka saattavat jopa estää React Nativen valinnan toteutustekniikaksi. Arkkitehtuurista nimittäin seuraa rajoitteita, joilla on merkitystä erityisesti raskaaseen, rinnakkaiseen laskentaan ja hyvin monimutkaisiin käyttöliittymiin liittyen.

Monisäikeistykseen ja suorituskykyhaasteisiin löytyy toki ratkaisu: natiivikoodin kutsuminen React Native -sovelluksesta. Natiivisillan käyttäminen vain tuo välittömästi mukanaan aspektin, jota ei ainakaan puhtaassa Web-talossa kaivattaisi. Tässä vaiheessa projektiin nimittäin uhkaa astella sisään natiivikielen osaaja.

Koska kyse on käyttöjärjestelmän ulkopuolisesta ohjelmointikehyksestä, uusien ominaisuuksien tuominen alustalle saattaa kestää. Eli siinä missä natiiviohjelmointikielellä uuteen tekniseen ominaisuuteen pääsee yleensä välittömästi julkaisun yhteydessä käsiksi, kyseisen ominaisuuden saapuminen kolmannen osapuolen ohjelmointikehykseen ei aina tapahdu ihan samassa ajassa. 

Eräs React Native -kehityksen ominaispiirre liittyy kolmansien osapuolten kirjastoihin. Tyypillisen React Native -mobiilisovelluksen toiminnallisuuskokoelma koostuu lähes poikkeuksetta runsaslukuisesta kokoelmasta kolmansien osapuolten kirjastoja. Open Source -kirjastokavalkadin käyttämisestä seuraa hyviä ja huonoja puolia. Hyvänä puolena on mahdollisuus kasata valikoimasta parhaiten juuri itselle sopiva kokoelma. Riskinä on kirjaston ylläpidon laahaaminen jäljessä tai jopa päivitysten totaalinen puuttuminen.

React Native julkaistiin alkuvuodesta 2015. Sen jälkeinen versiojulkaisujen lukumäärä on edellä esiteltyihin kieliin verrattuna aivan toiselta planeetalta. Tätä kirjoitettaessa uusin versio on 0.62. Versiokokoelma kasvaa hyvin nopeasti.

React Native on julkaistu avoimena lähdekoodina GitHubissa, MIT-lisenssin alla. Samasta paikasta löytyy myös visio React Nativen tulevaisuudesta. 

TypeScript

Mistä ihmeestä on kyse, kun usein “JavaScript-projektia” lähdetäänkin toteuttamaan ihan toisella ohjelmointikielellä nimeltä TypeScript? 

TypeScript on Microsoftin kehittämä ohjelmointikieli, jonka tavoitteena on laajentaa JavaScriptia siten, että sen ominaisuudet ja työkalut tukisivat paremmin suurten ohjelmistoprojektien tarpeita. 

Kuten nimikin jo vihjaa, TypeScript lisää JavaScriptiin tyypityksen. Tämä puolestaan tukee turvallisempien ja vakaampien sovellusten ohjelmointia mm. React Nativella.

Messenger – Project Lightspeed

Kesän korvilla 2019 kuultiin mielenkiintoisia uutisia: Facebook oli käynnistänyt Lightspeed-nimisen projektin, jonka tarkoituksena oli päivittää Facebook Messenger -sovellus. Keväällä 2020 saatiin lukea tarkempi kuvaus lopputuloksesta. Facebook uudelleenkirjoitti Messenger-sovelluksensa niin lähelle natiivia kuin mahdollista. Mikäli tarvittiin alustojen kesken jaettavaa sovelluslogiikkaa, se kirjoitettiin C-kielellä. Lopputuloksena koodirivien lukumäärän romahtaminen ja huomattavasti tehokkaampi sovellus.

Kun tieto uudelleenkirjoituksesta saavutti Internetin, some räjähti. Tätä pidettiin vakavana iskuna React Nativelle. Todellisuudessa Facebookin Messenger ei koskaan ollutkaan React Native -sovellus.

Huolimatta siitä, että Facebook Messenger oli alkujaankin natiivisovellus, Facebookin perustelut Project Lightspeedin teknisiin valintoihin ovat mielenkiintoisia, koska ne asettuvat osin suoraan React Nativen keskeisiä ominaisuuksia vastaan. Näistä mainittakoon esimerkkinä natiivikäyttöjärjestelmän ominaisuuksien välitön hyödyntäminen, jolloin ei tarvitse odottaa jonkin ominaisuuden saapumista cross-platform-kirjastoon.

Tämä ei kuitenkaan tarkoita sitä, että Project Lightspeedin valitsema lähestymistapa olisi käypä kenelle tahansa. Facebookin tekninen osaaminen on erittäin korkealla tasolla. Kuten edellä mainitusta blogimerkinnästä käy ilmi, teknisiä ja arkkitehtonisia haasteita on ratkaistu hyvin elegantisti ja tehokkaasti, mutta kyseiset ratkaisumallit eivät välttämättä ole vaihtoehto yhdellekään mobiilisovelluksesta haaveilevalle yritykselle, saati Web-tekniikoita käyttävälle organisaatiolle.

No code React Native

No code -ohjelmistoilla voi luoda täysin toimivia mobiilisovelluksia kirjoittamatta riviäkään koodia. No code -palveluilla kuka tahansa ei-ohjelmointitaitoinen henkilö voi siis päästä samaan lopputulokseen kuin ammattimainen sovelluskehittäjä. 

No code -lähestymistavalla kaikki sovelluskehitystehtävät toteutetaan graafisin työkaluin. Käyttöliittymäpuolella tässä ei ole mitään uutta. WYSIWYG-UI-työkalut ovat olleet osa eri valmistajien IDE-ratkaisuja jo vuosikymmeniä. Uutta on sovelluslogiikan luominen visuaalisia objekteja yhdistelemällä ja konfiguroimalla.

Myös React Native -sovelluksia voi toteuttaa koodittomilla työkaluilla. Suomalaisen AppGyverin Composer Pro sisältää graafiset työkalut niin käyttöliittymän kuin sovelluslogiikankin puolelle. Harva nykyisistä sovelluksista toimii pelkästään paikallisena appina. Mikäli integraatioratkaisuna Composer Pron markkinapaikan esiluodut integraatiot eivät riitä, sovelluksen ohjattu toiminto auttaa käyttäjää REST API -integraation luomisessa. On myös syytä selvittää, onko koodi miten hyvin ylläpidettävissä muilla kuin toimittajan työkaluilla. Käsityksemme mukaan ei, josta voi seurata mahdollinen toimittajalukko.

Punoksen mielipide

Päätös toteuttaa mobiilisovellus React Nativella pohjautuu poikkeuksetta tavoitteeseen säästää rahaa. Kyseinen ohjelmointikehys nähdään menetelmänä napata kaksi lintua yhdellä kivellä, eli kehittämällä yhden mobiilisovelluksen, saataisiin mobiilisovellukset kahdelle alustalle. 

React Native -lähestymistavan tuomat hyödyt riippuvat useista eri asioista kuten organisaation osaamisprofiilista, toimintatavoista ja sovelluksen tavoitteista. Näihin liittyvää keskustelua löytyy tarkemmalla tasolla runsaasti yläpuolelta. 

Ideaalitapauksessa organisaation osaamisprofiili ja toimintatavat tukevat React Nativen käyttämistä, eli kyseessä on lähinnä Reactiin keskittynyt, ketterä Web-talo. Lisäksi, työn alla on teknisiltä vaatimuksiltaan tyypillinen massamarkkinamobiilisovellus, joka tarvitaan molemmille mobiilialustoille. 

Summa summarum: React Native on käypä valinta valtaosaan mobiiliprojekteista, tietyt ominaispiirteet kuitenkin huomioiden.

Kotlin on Kotlin Foundationin tavaramerkki. Android on Google LLC:n tavaramerkki. Java on Oracle Corporationin rekisteröity tavaramerkki. Swift, Objective-C, OS X ja Xcode ovat Applen rekisteröityjä tavaramerkkejä. Linux on Linus Torvaldsin rekisteröity tavaramerkki.