Mobiilisovelluksen suunnittelu kehitystiimin näkökulmasta

Mobiilisovelluksen suunnittelu kehitystiimin näkökulmasta

En ole aikaisemmin törmännyt suomalaiseen blogikirjoitukseen, joka kertoisi, mitä kysymyksiä ja teknisiä haasteita on tullut matkan varrella vastaan, kun mobiilisovellusta on lähdetty suunnittelemaan ja kehittämään. Tässä on ehkä ensimmäinen sellainen, CC0-lisenssillä varustettuna, aidosti avointa, lähdekoodilisenssiä mukaillen.

Tämä blogi käsittelee teknologiaa innostuneille kehittäjille. Seuraava teksti voi olla mielenkiintoista luettavaa jos olette jo itse pohtineet mobiilisovelluksen toteutusta tai olette jo sellaisen kehittäneet, muussa tapauksessa tämän blogin loppuosa voi mennä tekniseksi jargoniksi.

”App” on muuten sanana ihan mielenkiintoinen. Suora käännös tarkoittaa applikaatiota, mutta lyhenne ”App” ei tarkoita ihan mitä tahansa vanhaa applikaatiota, vaan yleensä applikaatiota joka toimii tableteissa tai mobiililaitteissa. Eli puhutaan nykyaikaisista applikaatioista, joita käytetään vaikkapa Surface, iPad tai Android-laitteella.

Helpot päätökset

Kun keräännyimme suunnittelupöydän ääreen, niin ainoastaan nimi oli valmiiksi mietittynä – ”FieldSales App”. Appi on siis suunnattu kenttämyyntiä harjoittaville organisaatioille, jotka toimivat erityisesti vähittäiskaupan parissa.

Ensin helpot päätökset: koska Fenixillä olemme kaikki Microsoft Dynamics CRM-osaajia, ei varmasti lukijalle tule yllätyksenä, että asiakashallinnan sovellukseksi valikoitui Microsoft Dynamics CRM (On-Premise ja Online). Olimme kaikki yksimielisiä siitä, että rakennamme mobiilisovelluksen helppokäyttöiseksi, FMCG-alaa tukevaksi appiksi, jota voidaan jatkossa vapaasti räätälöidä asiakkaalle sopivaksi. Markkinoilla oli myös valmiita CRM-mobiiliratkaisuja, joita oli mahdollista jälkikäteen kustomoida, mutta totesimme että ratkaisut sisälsivät aina puutteita:

  • Ei loppuun asti viety ratkaisu, perusominaisuuksissa puutteita.
  • Rajoittuneet kustomointimahdollisuudet.
  • Omituinen tai heikosti toimiva käyttöliittymä.
  • Ongelmia sisäänkirjautumisessa (IFD-teknologia).
  • Ei takeita että ratkaisu toimii tulevissa CRM-versioissa.

Päätimme rakentaa FieldSales -mobiilisovelluksen, jonka voisimme räätälöidä asiakkaalle sopivaksi. Tarpeelliset asiakaskohtaiset toiminnallisuudet voitaisiin toteuttaa, sisäänkirjautumiseen liittyviä ongelmia ei enää tulisi eteen emmekä olisi riippuvaisia kolmannen osapuolen sovelluspäivityksistä. Sivutuotteena appin rakentaminen pitkästä puusta toisi taloon myös paljon uutta teknologiaosaamista laajemmalla skaalalla.

Ideointi lähti liikkeelle

Scrum-tehtävätaulussa (kiitos 3M ja Post-it), toiveiden tynnyrissämme oli ominaisuuksia, joita halusimme appin tukevan. Eli kaikenlaista löytyi, mutta yksi ominaisuus nousi yli kaiken muun – offline-toiminnallisuus. Nettiyhteyteen ei vielä nykypäivänäkään voi aina luottaa, ja kun yhteys vaipuu alle 3G:n, voi kenttämyyjä omalla asiakaskäynnillään huoletta unohtaa netin käytön.

Lappujen joukosta toiseksi tärkeimmäksi valikoitui teknologian valinta sekä mitä päätelaitteita lähdetään tukemaan. Siis mitä päätelaitteita tukisimme?

Pöytäkoneet & läppärit, tabletit, älypuhelimet?

Pöytäkoneille halusimme tuen, vaikkei varsinaista hevikäyttöä näiden kautta tulisikaan tapahtumaan. Tabletit oli ehdoton vaatimus, olihan sovelluksen nimessä jo sana ”App” joka viittaa vahvasti tablettikäyttöön, ja kenttämyyjällä on tietysti aina asiakaskäynnillään tabletti mukanaan. Älypuhelintuki? Ei ehdoton tarve, kenties myöhemmin. Näyttö ja muistikapasiteetti olivat rajoittava tekijä.

Seuraavaksi sovellusalustan valintaan, nykyaikaiset applikaatiot voidaan selkeästi jakaa kolmeen eri ryhmään.

Sovellusalustan valinta

Havaitsimme, että Web appeilla kaikkia laitteen toimintoja ei ole mahdollista hyödyntää samalla tavalla kuin natiivisovelluksilla koska Web appeille ei ole saatavilla yhteistä standardisoitua SDK-kehitystyökalua. Nettiselaimen tietoturva-asetukset voisi myös joutua säätämään laitekohtaisesti, tämä voisi olla ongelmallista useassa organisaatiossa. Havaitsimme myös lisähaasteita tiedostojärjestelmän lokaalioikeuksissa, jotka voisi koitua ongelmaksi median tallennuksessa, tuleva File API voisi toisaalta ratkaista tämän ongelman.

Punnittuamme eri vaihtoehtoja, joista kaikista löytyi hyviä sekä huonoja puolia, alkoi ratkaisu lopulta löytyä. Projektin aikataulu vahvisti jo etukäteen suunnitellun kompromissiratkaisun. Toteutamme natiiviapplikaation WinJS-kirjastolla, jolla mahdollistetaan tuki kaikille päätelaitteille, eli universaaleille Windows-applikaatioille (älypuhelimien käyttöliittymä pitäisi kuitenkin suunnitella erikseen). Tämä osoittautui toimivaksi ratkaisuksi. WinJS-kirjasto on HTML/Javascript-ohjelmointia ja tämä voidaan siirtää Apache Cordova-projektiin ja tätä kautta voidaan siirtyä hybridimalliin, tämä taas mahdollistaa natiivituen myös Android- ja Apple-laitteille. Javascriptin avoimuus ei ollut ongelma tietoturvan suhteen, koska mobiilisovellus oli alun perinkin tarkoitus jakaa SCCM tai pilvipohjaisen Intune -ratkaisujen kautta, eikä siis Storen kautta.

Kolmanneksi tärkeimmäksi ominaisuudeksi valikoitui kuvan ja videon ottaminen päätelaitteella ja median lähetys sisäverkkoon tai pilveen, esim. SharePointiin. Uskomatonta kyllä tämä ominaisuus on ollut monen mobiilikäyttäjän toiveena jo pitkään ja tähän ei ole ollut toimivaa ratkaisua tarjolla. Ei yhtään sellaista, jota voitaisiin kustomoida jälkikäteen ja hienosäätää loppukäyttäjälle sopivaksi. Eli päätimme toteuttaa myös tämän ominaisuuden tulevaan appiin.

Hyväksi havaitut kirjastot

WinJS on avoimen lähdekoodin Javascript-kirjasto, jonka Microsoft on kehittänyt. WinJS:n käyttöä edellyttää, että kehittäjä ymmärtää asynkronisen ja Promises Javascript-ohjelmoinnin käsitteet.

jQuery valittiin koska tämä oli tuttu kirjasto meidän kehittäjille. HTML5 ja ECMAScriptin huima kehitys on kuitenkin joiltain osin tehnyt jQuerysta tarpeettoman. Käytimme jQueryä mm. XML:n parserointiin.

Koska W3C ei enää tue WebSQL:n kehitystä, niin IndexedDB API oli helppo valinta offline-tietokannan objektikieleksi. IndexedDB:n kaveriksi valitsimme Dexie.js –kirjaston, joka on asynkroninen wrapperi ja joka ratkaisee natiivin IndexedDB:n ongelmat:

  • Virheenkäsittely
  • Heikosti laaditut kyselyt
  • Lähdekoodin monimutkaisuus

Dexie.js on helpottanut IndexedDB kyselyiden kirjoittamista ja siinä on yksinkertainen syntaksi. Kirjoittaisitko mieluummin näin…

…vai näin?

Kehitys loppuu tyytyväisyyteen?

Vai ruokkiiko kuitenkin tyytyväisyys kehitystä? Oli niin tai näin, meillä näyttäisi ainakin jälkimmäinen toimivan. Tällä hetkellä appiin on kehitetty kaikki projektin alussa suunnittelemamme toiminnallisuudet. Olemme onnistuneesti tuotteistaneet tuotekehityksen tulokset ja kehitystä jatketaan mielenkiintoisina asiakasprojekteina.

By |2017-08-31T15:43:16+00:0002.12.2015|Blogi|

About the Author:

Mika Suonvieri