Laji tai lukumäärä häviää kesken tallennuksen

[Jari Kårlund]

Johtuukohan meikäläisen kalustosta (Lenovo tab TB311XU) vai jostain muusta se kun kesken tallennuksen jo kertaalleen näpytellyt tiedot poistuvat tallennuslomakkeelta? Tätä tapahtuu varsinkin tai ehkä jopa ainoastaan lajin ja lukumäärän kanssa. Kumpikin voi hävitä kokonaan ja laji myös osittain. Siis 'grugru' on seuraavaa kenttää täytettäessä muuttunut muotoon 'grug'. En ole huomannut että sillä olisi merkitystä olenko kirjoittanut koko lajinimen itse vai valinnut sen parin kirjaimen jälkeen ilmestyvästä valikosta. Tätä tapahtuu sen verran usein, ehkä noin joka neljännessä havainnossa, että koen vaivan jossain määrin kiusalliseksi.

[jtp]

Minulla on ollut outouksia paikannimen kirjain kirjaimelta kirjoittamisen kanssa sekä geokoordinaattien syötön kanssa. Molemmissa käyttöliittymä sekaantuu kesken kirjoitustyöni ja merkit menevät väärään paikkaan tai häviävät.

Yhtä kaikki, tätä ja muita bugeja ei korjata, koska uusiTiira kirjoitetaan käyttöliittymän osalta kuulemma uudestaan Vue-kirjastolla, josta on koulutus- ym. materiaalia yllin kyllin ja tekoälykin osaa sitä – verrattuna nykyiseen Aurelia-kirjastoon, jota käyttää harvempi kuin joka miljoonas websivusto. Tässä uudessa uusiTiiran versiossa on sitten omat buginsa, joita on oletettavasti vähemmän kuin nykyisessä uusiTiirassa. Käyttöliittymän suunnittelijan ei tarvitse olla luontorakas vaan riittää että hän ei ole ihmisvihaaja ja että hänellä on hyvä eläytymiskyky käyttäjän kohtaamiin haasteisiin. Nyt olen ihmetellyt, minkälainen suunnittelija ajattelee, että mobiililaitteen näppäimistön pitää pompsahtaa näytölle peittämään kaiken muun, kun klikkaa ”Lisäkentät”-linkkiä. Kyse lienee sadismista.

[Pave]

Suurin osa softaprojekteista kaatuu ennen kuin ainuttakaan riviä on kirjoitettu. Niin myös uusiTiira. Siellä asiasta tietämättömät ovat uskoneet, että webbiteknologialla sadaan aikaan Tiiran vaatima käyttöliittymä mikä toimii hyvin mobiililaitteissa. Ei saada, eikä yhden webbikirjaston vaihtaminen toiseen ratkaise perustavanlaatuisia ongelmia.

Jos halutaan sulava käyttöliittymä jonka avulla ihmiset voivat tehdä havaintoja maastossa, niin silloin pitää tehdä natiivi mobiilisovellus. Kaikki muu on enemmän tai vähemmän ajan haaskausta. Ja nyt ollaan Investment Fallacy ansassa, jossa ei pystytä myöntämään tätä ja jatketaan vain vanhan vuotavan laivan paikkaamista purkalla.

[jtp]

UusiTiiran back-end ja front-end on erotettu toisistaan, joten olemassa olevan taustajärjestelmän rajapinnan päälle voitaisiin toteuttaa myös natiivit front-endit Apple- ja Android-puhelimille. Tällöin havaintojen säilyvyys offline-tilassa olisi varmempaa kuin selainpohjaisissa ratkaisuissa käyttäen service workereitä. Esim. Firefox-selainta on perinteisesti ollut vaikea saada uskomaan, ettei paikallista välimuistitietoa saa tyhjentää oma-aloitteisesti.

Natiivit apit osaavat hallita katvealueita ja synkronoida datan palvelimen kanssa tehokkaammin kuin selainpohjaiset sovellukset, jotka saattavat keskeyttää toimintansa selaimen nukkuessa. Lisäksi natiiveilla apeilla on suorempi pääsy käyttöjärjestelmän omiin palveluihin. Vaikka nykyiset tekoälytyökalut tekevät kahden erillisen natiivikoodikannan (iOS ja Android) kirjoittamisesta helpompaa, niiden pitkäaikainen ylläpito, päivitykset ja bugikorjaukset kolmessa eri ympäristössä (työpöytänetti, iPhone, Android) olisi merkittävä rasite resurssien kannalta. Siksi kustannustehokkain ja järkevä kompromissi voisi olla hybridiratkaisu: Vue.js-front-end pakattuna mobiiliympäristössä natiiviin Capacitor-kehykseen (ks. https://capacitorjs.com/), jolloin saadaan mobiilissa natiivien appien hyödyt ilman kahden erillisen koodikannan ylläpitotaakkaa. Tällainen ratkaisu toimisi hyvin ilman Capacitoria myös työpöytäympäristössä, kun taas cross-platform -kehykset, kuten Flutter ja React Native, tarjoaisivat yhdessä apissa iPhone- ja Android-yhteensopivuuden, mutta eivät kunnollista työpöytäsoveltuvuutta.

[Pave]

Mikään ei poista sitä faktaa, että kaikki testaus joudutaan joka tapauksessa tekemään kolmessa eri ympäristössä (iOS, Android ja webbi) ja se, jos mikä on aikaavievää. On yleinen harhaluulo, että useamman koodikannan ylläpito automaattisesti kuluttaisi enemmän resursseja. Se riippuu. Jos tavoitteena on oikeasti pitkäikäinen softaprojekti, niin silloin kannattaa valita ne ohjelmistokehykset, jotka ovat tarkoitettu kyseisille alustoille. Eikä tehdä mitään "järkevää kompromissia".

Historiallisesti tilanne on tiedetty, mutta cross-platform-ratkaisuihin on yleensä päädytty, koska tiimistä on löytynyt vain webbikoodareita. Sitten kaikki on jouduttu kirjoittamaan muutaman vuoden päästä uudestaan, kun se "järkevä kompromissi" on paljastunut vähemmän järkeväksi. Tekoäly on myös muuttanut hyvin lyhyessä ajassa tilanteen siihen, että niitä kompromissiratkaisuja on yhä vaikeampi perustella, koska koodin määrä tai osaamisen taso ei ole enää suurin pullonkaula.

Itse juuri olen tehnyt eräästä vanhasta iOS-sovelluksestani natiivin Android-version ennätyslyhyessä ajassa tekoälyn avustamana. Lopputuloksena minulla on kaksi koodikantaa, joita on helppo ja mukava ylläpitää yhden ison sillisalaatin sijasta. Ja jos teen muutoksia toiseen, niin testauskin on nopeampaa, koska voin olla varma, että Android-koodiin tehdyt muutokset eivät aiheuta yllättäviä bugeja iOS-versiossa tai toisinpäin.
IOS-versio on myös optimoitu hyvin iPadOS ja MacOS-ympäristöihin ja tarjoaa monia natiivispesifisiä mukavuuksia kuten lukitusnäytön widgetit. Ei tulisi pieneen mieleenkään tehdä samaa millään kompromissityökaluilla.

Suoraan sanottuna tuntuu todella murheelliselta katsoa uudenTiiran meininkiä. Kentältä olen kuullut kommentteja, että ei monikaan halua sitä käyttää. En ihmettele, eikä sen tulevaisuus näytä kovin valoisalta tällä hetkellä.

[jtp]

Hyviä pointteja kokeneelta tekijältä.

UusiTiiran ehkä tärkein luvattu tuleva uusi piirre on täysi offline-tuki erämaassa liikkumista varten. Sellaista on vaikeampi saada pomminvarmaksi pelkillä websovelluksilla kuin natiivi- tai Capacitor-apilla. On kehittäjille varmasti ikävä lukea palautetta siitä, että selain hävitti käyttäjän kolmen vuorokauden havainnot ennen palvelimelle synkronointia.

Joka tapauksessa BirdLifen täytyy tehdä yksi työpöytäselaimessa toimiva versio. Nykyisillä tekniikoilla siitä saadaan samalla vaivalla responsiivinen layout myös kännykkään, ja Capacitor-kehyksen avulla sovellus pääsisi vähällä koodaamisella tarvittaessa käsiksi myös niihin natiivipalveluihin, joihin pelkkä selain ei yllä. Jos rahaa riittää, voitaisiin myöhemmin tehdä lisäksi erilliset natiivit sovellukset, jotka vaatisivat paljon enemmän lisäkoodia.

[Pave]

Jep, työpöytäversio tarvitaan. Toivotaan parasta, että edes siitä saadaan mahdollisimman toimiva.