Jani Palo-oja
ALUSTARIIPPUMATON QT-SOVELLUS JA REST-RAJAPINTA
ALUSTARIIPPUMATON QT-SOVELLUS JA REST-RAJAPINTA
Jani Palo-oja Opinnäytetyö Syksy 2020
Tietotekniikan tutkinto-ohjelma Oulun ammattikorkeakoulu
TIIVISTELMÄ
Oulun ammattikorkeakoulu
Tietotekniikan tutkinto-ohjelma, ohjelmistokehityksen suuntautumisvaihtoehto
Tekijä: Jani Palo-oja
Opinnäytetyön nimi: Alustariippumaton Qt-sovellus ja REST-rajapinta Työn ohjaaja: Eino Niemi
Työn valmistumislukukausi ja -vuosi: Syksy 2020 Sivumäärä: 54
Tämän opinnäytetyön päätavoitteena oli suunnitella ja toteuttaa alustariippuma- ton mobiilisovellus kuntosaliharjoittelun tueksi. Toinen tavoite oli toteuttaa REST-arkkitehtuuria noudattava rajapinta mobiilisovelluksen ja MySQL-tieto- kantapalvelimen välille.
Sovelluksen suunnittelu alkoi käyttötapausten määrittelyllä ja käyttöliittymäsuun- nittelulla, jossa käytettiin Figma-suunnitteluohjelmaa. Sovellus toteutettiin käyt- täen Qt 5.15 -ohjelmistokehystä. Käyttöliittymä ohjelmoitiin QML-kielellä ja toi- minnallisuus C++-kielellä. Rajapinta ohjelmoitiin PHP:llä ja se palauttaa ja vas- taanottaa kaiken informaation JSON-muodossa. Tietokantakyselyt toteutettiin SQL-kyselykielellä. Ohjelmoinnissa käytettiin Qt Creator -ohjelmointiympäristöä.
Opinnäytetyön lopputuloksena syntyi Android- ja iOS-alustoilla toimiva mobiili- sovellus, jolla käyttäjä voi luoda itselleen treeniohjelmia ja pitää kirjaa käyttämis- tään painoista ja toistomääristä. Kaikki treeneistä kirjattu tieto tallennetaan tieto- kantapalvelimelle. Sovelluksen tarkoituksena on korvata paperinen treenipäivä- kirja.
Asiasanat: Qt, Qt Quick, QML, Android, iOS, mobiilisovellus, REST
ABSTRACT
Oulu University of Applied Sciences
Degree programme in Information Technology, option of Software Development
Author: Jani Palo-oja
Title of thesis: Qt Based Cross-Platform Mobile Application and REST API Supervisor: Eino Niemi
Term and year when the thesis was submitted: Fall 2020 Pages: 54
The main goal of this thesis was to develop cross-platform mobile application which can be used to replace the traditional workout log diary. Second goal was to implement REST API between the mobile application and MySQL database.
The application was implemented by using the Qt framework version 5.15. QML was used for the user interface and the business logic was implemented by using C++. Qt Creator IDE was used for all the development work.
REST API was built by using PHP and it handles all the HTTP requests sent by the application and it responses in JSON format.
The result of the thesis was a mobile application that runs on both Android and iOS platforms.
Keywords: Qt, Qt Quick, QML, Android, iOS, mobile application, REST
SISÄLLYS
TIIVISTELMÄ 3
ABSTRACT 4
SISÄLLYS 5
SANASTO 7
1 JOHDANTO 9
2 ALUSTARIIPPUMATTOMUUS 10
2.1 Määritelmä 10
2.2 Hyvät puolet 10
2.3 Huonot puolet 10
3 MOBIILIKÄYTTÖJÄRJESTELMÄT 11
3.1 Android 11
3.2 iOS 13
4 SOVELLUSKEHITYS QT-OHJELMISTOKEHYKSELLÄ 16
4.1 Qt 16
4.2 Qt Creator 17
4.3 Tuetut mobiilialustat 17
4.3.1 Android 17
4.3.2 iOS 18
4.4 Kehitysympäristön konfigurointi 18
4.4.1 Konfigurointi Android-alustalle 19
4.4.2 Konfigurointi iOS-alustalle 20
4.5 QML 21
4.6 Signal & Slot 24
4.7 Property-järjestelmä 25
4.8 Qt-moduulit 26
5 MOBIILISOVELLUS 30
5.1 Suunnittelu 30
5.1.1 MVC-malli 31
5.2 Käyttötapaukset ja sovelluksen ulkoasu 33
5.2.1 Rekisteröityminen ja kirjautuminen 33
5.2.2 Treeniohjelman luominen ja treenin suorittaminen 33
5.2.3 Treenihistorian selaaminen 35
5.2.4 Liikekirjaston selaaminen 36
5.3 OAuth 2.0 36
6 REST-RAJAPINTA 38
6.1 REST-arkkitehtuuri 38
6.1.1 Asiakas-palvelin-vaatimus 39
6.1.2 Tilattomuus 39
6.1.3 Välimuisti 39
6.1.4 Yhdenmukainen rajapinta 40
6.1.5 Kerroksittainen järjestelmä 40
6.1.6 Ladattava koodi 40
6.2 HTTP-protokolla 41
6.2.1 Metodit 41
6.2.2 HTTPS 42
6.3 JSON Web Token 42
7 TIETOKANTA 44
7.1 MySQL 44
7.2 SQL-kyselykieli 44
7.3 MySQL Workbench 44
7.4 Tietokannan suunnittelu 45
7.4.1 Käsiteanalyysi ja ER-kaavio 45
7.4.2 Tietokohteet ja kohdetyypit 46
7.4.3 Attribuutit 46
7.4.4 Tietokohteiden väliset yhteydet 47
8 YHTEENVETO 49
LÄHTEET 50
SANASTO
Android Googlen kehittämä käyttöjärjestelmä mobiililaitteille Android NDK Android Native Development Kit, joka mahdollista
Android-sovelluksen toteutuksen C- ja C++-kielillä Android SDK Android Software Development Kit on Android-sovellus-
kehityspaketti
API Application Programming Interface, eli ohjelmointiraja- pinta, jonka kautta eri ohjelmat tai ohjelman osat voivat keskustella keskenään
Asynkroninen Ei-reaaliaikainen kommunikointitapa, jossa kommuni- koinnin osapuolet eivät ole ajallisesti toisistaan riippuvai- sia
C++ Ohjelmointikieli, joka on kehitetty C-kielestä
GPL GNU General Public Licence on vapaiden ohjelmistojen julkaisemiseen tarkoitettu lisenssi. Antaa kenelle ta- hansa oikeuden käyttää, kopioida, muuttaa ja jakaa edelleen ohjelmia tai niiden lähdekoodia
Gradle Moderni koonti- ja projektinhallintatyökalu, jota käyte- tään Android-projekteissa
HTTP Hypertext Transfer Protocol on protokolla, jota selaimet ja web-palvelimet käyttävät tiedonsiirtoon
iOS Applen kehittämä käyttöjärjestelmä mobiililaitteille Java Ohjelmointikieli, jota käytetään mm. Android-ohjelmoin-
nissa
JavaScript Web-ympäristössä käytettävä ohjelmointikieli, jonka pääasiallinen tarkoitus on lisätä web-sivuille dynaamista toiminnallisuutta
JNI Java Native Interface, eli rajapinta, jonka kautta Androi- din Java-kielen metodeja voidaan kutsua käyttämällä C- tai C++-kieltä
JWT JSON Web Token on menetelmä käyttöoikeustietueiden hallinnoimiseen eri ohjelmistojen välillä
MySQL Maailman suosituin avoimen lähdekoodin tietokantaoh- jelmisto
Natiivisovellus Tarkoittaa mobiilialustan omalla kehitysympäristöllä ja ohjelmointikielellä toteutettua sovellusta.
OpenGL Open Graphics Library, avoin grafiikkakirjasto
PHP Ohjelmointikieli, jota käytetään erityisesti web-palve- linympäristössä
QML Qt Modeling Language on Qt-käyttöliittymien ohjelmoin- tikieli
Qt Alustariippumaton ohjelmistojen ja käyttöliittymien kehi- tykseen tarkoitettu ohjelmistokehys (lausutaan ”cute”) SQL Structured Query Language, eli jäsennetty kyselykieli,
jota käytetään tietokantahakuihin esimerkiksi MySQL- tietokantojen kanssa
SSL Secure Sockets Layer, kahdesta avaimesta koostuva tiedonsalausmenetelmä.
1 JOHDANTO
Nykyään älypuhelimet ovat iso osa ihmisten jokapäiväistä elämää ja niiden määrä on kasvanut räjähdysmäisesti siitä, kun Apple julkaisi ensimmäisen iPho- nen vuonna 2007. Älypuhelimet ovat nykyään mukana työelämässä, opiskelussa ja myös harrastuksissa.
Markkinoilla olevat älypuhelimet voidaan jakaa kahteen eri ryhmään niiden käyt- töjärjestelmien perusteella, koska niiden markkinaosuudet ovat niin suuria.
Vuonna 2020 Android-käyttöjärjestelmän markkinaosuuden arvioidaan olevan noin 73 % kaikista käytössä olevista älypuhelimista ja Applen iOS-käyttöjärjestel- män osuudeksi arvioidaan 26,5 %. Näiden kahden käyttöjärjestelmän arvioitu markkinaosuus on siis 99,5 % kaikista käytössä olevista älypuhelimista vuonna 2020. (1.)
Tämän opinnäytetyön päätavoitteena on suunnitella ja toteuttaa alustariippuma- ton mobiilisovellus kuntosaliharjoittelun tueksi Android- ja iOS-käyttöjärjestelmille käyttäen Qt-ohjelmistokehyksen versiota 5.15. Sovellus toteutetaan käyttäen pääasiassa C++-, JavaScript ja QML-ohjelmointikieliä. Työssä esitellään myös muita työssä käytettyjä tekniikoita ja työkaluja.
Sovelluksella käyttäjä voi luoda itselleen treeniohjelmia ja pitää kirjaa käyttämis- tään painoista ja toistomääristä. Sovelluksen tarkoituksena on korvata paperinen treenipäiväkirja ja tarjota muita hyödyllisiä ominaisuuksia harjoittelun tueksi ja ke- hityksen seurantaan. Kaikki käyttäjän sovellukseen kirjaamat tiedot tallennetaan MySQL-tietokantaan.
Opinnäytetyön toisena päätavoitteena on toteuttaa REST-arkkitehtuuria noudat- tava rajapinta mobiilisovelluksen ja MySQL-tietokantapalvelimen välille. Raja- pinta toteutetaan käyttäen PHP-ohjelmointikieltä ja se palauttaa sekä vastaanot- taa kaiken informaation JSON-muodossa. MySQL-tietokannan suunnittelu ja to- teutus on myös osa tätä opinnäytetyötä.
2 ALUSTARIIPPUMATTOMUUS
2.1 Määritelmä
Alustariippumattomuudella tarkoitetaan sovellusta tai ohjelmaa, jonka toteutuk- sessa on käytetty mahdollisimman vähän tai ei ollenkaan sellaisia ominaisuuksia, jotka ovat sidottuja johonkin tiettyyn laitteistoalustaan, käyttöjärjestelmään tai oh- jelmointikieleen. Se ei kuitenkaan tarkoita sitä, että alustariippumaton ohjelma tai sovellus toimisi kaikilla mahdollisilla käyttöjärjestelmillä. (2.)
Alustariippumattoman ohjelmoinnin tavoite on, että sovellusta ei tarvitse kirjoittaa jokaiselle alustalle erikseen, vaan sama lähdekoodi voidaan kääntää useille eri käyttöjärjestelmille sellaisenaan tai tekemällä vain pieniä muutoksia lähdekoo- diin.
2.2 Hyvät puolet
Yhden alustariippumattoman sovelluksen kehittäminen on nopeampaa kuin na- tiivisovelluksen kehittäminen monelle alustalle erikseen. Nopean kehityksen ja alustoille yhteisen ohjelmakoodin ansiosta alustariippumattoman sovelluksen ke- hitys on yleensä myös edullisempaa kuin natiivisovelluksen. Sovelluksen ylläpi- täminen, päivittäminen ja jatkokehitys helpottuu, kun käytössä on vain yksi ohjel- makoodi. Sovellus saadaan tarvittaessa nopeasti jakeluun suurelle yleisölle. (3.) 2.3 Huonot puolet
Natiivisovellusten tarjoamien ominaisuuksien puute saattaa tuottaa vaikeuksia kehitystyöhön tai se voi jopa estää kokonaan joidenkin ominaisuuksien toteutta- misen. Natiivisovellukselle tyypillisiä ominaisuuksia ovat laitteen sensoreihin ja tiedostorakenteeseen liittyvät toiminnallisuudet, joihin ei välttämättä ole pääsyä käytettäessä alustariippumatonta ohjelmakoodia. Jotkin suorituskykyä vaativat graafiset toteutukset ovat raskaampia käytettäessä alustariippumatonta toteu- tusta. Uusien alustakohtaisten ominaisuuksien tuominen alustariippumattomaan sovellukseen on hitaampaa kuin natiivisovelluksiin. (3.)
3 MOBIILIKÄYTTÖJÄRJESTELMÄT
3.1 Android
Android on älypuhelimille, tablettitietokoneille, älytelevisioille, älykelloille ja nyky- ään myös ajoneuvoille suunniteltu käyttöjärjestelmä. Ensisijaisesti se on tarkoi- tettu kosketusnäytöllisiin mobiililaitteisiin. (4.)
Androidin kehitystyön on alun perin aloittanut Android Inc. -niminen yritys, jonka Google osti vuonna 2005. Ensimmäinen versio Androidista julkaistiin vuonna 2008. Nykyisin Androidin kehitystyöstä vastaa Googlen lisäksi OHA eli Open Handset Alliance, joka koostuu 84 laitteisto- ja ohjelmistovalmistajasta sekä tele- operaattorista. Tunnetuimpia OHA:n jäsenyrityksiä ovat Googlen lisäksi mm.
Samsung, LG, Sony, Intel, Motorola, HTC, Dell, Nvidia ja Qualcomm. (5.)
Android-versiosta 1.5 lähtien julkaisut ja päivitykset on nimetty aakkosjärjestyk- sessä jonkin jälkiruokaherkun mukaan, mutta Android 10:n kohdalla tästä luovut- tiin. Uusimmat versiot 10 ja 11 tunnetaan vain nimillä Android 10 ja Android 11.
Syynä on se, että Q-kirjaimella alkavan jälkiruokaherkun nimen keksiminen on vaikeaa ja herkkujen nimet ovat aiheuttaneet myös epäselvyyksiä ja väärinkäsi- tyksiä eri versioiden välillä. (6.)
Android on suurimmaksi osaksi avoimen lähdekoodin ohjelmisto, jonka arkkiteh- tuuri koostuu viidestä eri kerroksesta muunnellun Linux-ytimen päällä (kuva 1).
KUVA 1. Android-käyttöjärjestelmän arkkitehtuuri (7)
Sovelluskerros
Ylimmällä kerroksella ovat valmiit Android-sovellukset, kuten esimerkiksi kalen- teri, sähköposti ja internet-selain. Sovelluskerrokselle asettuvat valmiiden sovel- lusten lisäksi myös sovelluskehittäjien kirjoittamat sovellukset. (7.)
Java-rajapintakehys
Neljännellä kerroksella ylhäältä alaspäin on Java-rajapintakehys (Java API Fra- mework), joka toimii rajapintana sovelluskerroksen ja Android Runtime -kerrok- sen sekä Androidin alkuperäisten C- ja C++-kirjastojen välillä (7).
Alkuperäiset C- ja C++-kirjastot
Monet Android-järjestelmän komponentit, kuten ART (Android Runtime) ja HAL (Hardware Abstraction Layer) on kirjoitettu natiivikoodilla, ja ne vaativat toimiak- seen C- ja C++-kielisiä kirjastoja. Java-rajapintakehyksen kautta myös sovelluk- set voivat käyttää näitä kirjastoja ja niiden toiminnallisuuksia. (7.)
Android Runtime -kerros
Sovellusten varsinainen suoritus tapahtuu tässä kerroksessa Androidin arkkiteh- tuuria. ART (Android Runtime) on korvannut aiemmin käytetyn Dalvik-virtuaaliko- neen Android-versiosta 5.0 alkaen. ART kääntää sovellukset natiiville konekie- lelle ja kaikki sovellukset ajetaan omana prosessinaan omassa ART-instans- sissa. ART käyttää ennen ajoa tehtävää kääntämistä toisin kuin aiemmin käy- tössä ollut Dalvik, joka käytti ajon aikaista kääntämistä. ART on optimoinut myös Android-järjestelmän muistinhallintaa eli roskienkeruuta. Sovellusten, jotka toimi- vat hyvin ART-ympäristössä, pitäisi toimia hyvin myös vanhemmassa Dalvik-ym- päristössä, mutta ei välttämättä toisin päin. (7.)
Abstraktiokerros
Abstraktiokerros koostuu laitteistoa hallitsevista kirjastomoduuleista, jotka luovat rajapinnan fyysisille laitekomponenteille, joita voidaan käyttää ylemmästä Java- rajapintakehyskerroksesta. Kun sovellus haluaa käyttää jotain tiettyä laitteen komponenttia, kuten esimerkiksi GPS, Bluetooth tai kamera, niin järjestelmä lataa juuri tämän komponentin kirjastomoduulin. (7.)
3.2 iOS
iOS on Applen kehittämä käyttöjärjestelmä, joka pohjautuu Darwin BSD -käyttö- järjestelmän XNU-ytimeen. Se on käytössä kaikissa Applen mobiililaitteissa ja on
tarkoitettu käytettäväksi ensisijaisesti kosketusnäytöltä. Apple on julkaissut iOS- käyttöjärjestelmän ensimmäisen version vuonna 2007 ja sen alkuperäinen nimi oli OS X ennen vuotta 2010, jolloin nimi muutetiin iOS:ksi. Viimeisin vakaa versio on iOS 14 ja se on julkaistu vuonna 2020. Käyttöjärjestelmän kehityksestä vastaa Apple ja sen lähdekoodi on pääosin suljettua. (8.)
iOS-käyttöjärjestelmän arkkitehtuuri on kerrostettu, kuten Android-käyttöjärjestel- mänkin. Käyttöjärjestelmän arkkitehtuuri koostuu neljästä eri kerroksesta XNU- ytimen päällä (kuva 2).
KUVA 2. iOS-käyttöjärjestelmän arkkitehtuuri (9)
Cocoa Touch -kerros
Arkkitehtuurin ylin kerros vastaa käyttöjärjestelmän ja sovellusten käyttöliitty- mästä ja yleisimmistä toiminnallisuuksista, kuten esimerkiksi kosketusnäytön syötteiden vastaanottamisesta. Kerroksen vastuulla on myös kamera ja push-il- moitusten näyttäminen näytöllä. Kerros sisältää myös UIKit-rajapinnan, joka si- sältää kaikki käyttöliittymäelementit. (10.)
Media Services -kerros
Kerros sisältää nimensä mukaisesti kuva-, video- ja ääniteknologiat. Kerros mah- dollistaa kuvan, videon ja äänen tallentamisen ja selaamisen laitteella sekä myös kuvien ja videoiden katselun internet-yhteyden yli. Se tukee myös alemman tason grafiikkarajapintoja ja -teknologioita, kuten OpenGL ES, joka on tarkoitettu edis- tyneen 3D-grafiikan renderointiin. (10.)
Core Services -kerros
Kerros sisältää pääsyn käyttöjärjestelmän ydinpalveluihin, kuten osoitekirjaan, kalenteriin, paikannuspalveluihin ja verkkotoimintoihin. Kerroksen avulla tietoa voidaan tallentaa laitteen SQLite-tietokantaan tai Applen iCloud-pilvipalveluun.
Kerroksesta löytyy myös Unicode-kirjaimiston tuki. (10.) Core OS -kerros
Alimpana iOS-käyttöjärjestelmän arkkitehtuurissa on Core OS -kerros, joka sisäl- tää alimman tason rajapintoja esimerkiksi verkkoyhteyksiin, muistinhallintaan, tal- lennusjärjestelmän loogisiin levyosioihin ja muihin XNU-ytimen toimintoihin (10).
4 SOVELLUSKEHITYS QT-OHJELMISTOKEHYKSELLÄ
4.1 Qt
Qt on alustariippumaton ohjelmistokehys työpöytä- ja mobiilisovellusten sekä su- latettujen ohjelmistojen kehitykseen. Tuettuja alustoja ovat mm. Windows, macOS, Linux, Android, iOS, BlackBerry, QNX ja Sailfish OS. Qt on vapaa ja avoimen lähdekoodin ohjelmisto ja se on saatavilla GPL- ja LGPL-lisensseillä. Qt Company myy Qt-ohjelmistokehystä myös kaupallisella lisenssillä. (11.)
Qt-ohjelmistokehys sisältää luokkia ja moduuleita erilaisten tietoliikenne- ja kom- munikaatioprotokollien toteutukseen sekä anturitiedon käsittelyyn sulautetuissa- ja mobiililaitteissa. Qt sisältää myös Qt Quick -käyttöliittymäkirjaston, jonka avulla voidaan tehdä näyttäviä ja nykyaikaisia käyttöliittymiä. Qt-ohjelmistokehykseen kuuluu myös monia tietorakenneluokkia, joiden avulla voidaan tallettaa ja esittää tietoa. (12.) Tarjolla on myös paljon kolmansien osapuolten tarjoamia kirjastoja, joita löytyy esimerkiksi osoitteesta https://inqlude.org/.
Qt:n kehitystyö on aloitettu jo 1990-luvulla ja sen ensimmäinen julkinen versio julkaistiin vuonna 1995 sekä avoimella että kaupallisella lisenssillä. Kehitystyön aloittivat norjalaiset ohjelmoijat Eirik Chambe-Eng ja Haavard Nord ja heidän sil- loin omistansa yritys nimeltä Trolltech. Qt ja Trolltech ovat kokeneet historiansa aikana useita yritysostoja ja se on ollut myös matkapuhelinvalmistaja Nokian omistuksessa vuosina 2008–2012. Vuonna 2012 Qt siirtyi ohjelmistoyhtiö Digia Oyj:n omistukseen. Nykyään Trolltech tunnetaan myös nimellä The Qt Company, joka oli Digia Oyj:n kokonaan omistama tytäryhtiö, johon kaikki Qt-liiketoiminta siirrettiin vuonna 2014. Vuonna 2016 Digia jakautui Digiaksi ja Qt Groupiksi, joka on Helsingin pörssiin listattu yhtiö. Qt Group käyttää edelleen myös The Qt Com- pany nimeä. (11.)
The Qt Companyn lisäksi Qt:n kehitystyöstä vastaa nykyisin myös The Qt Pro- ject niminen yhteisö, joka koostuu useista yrityksistä ja yksityishenkilöistä ympäri maailmaa. The Qt Project -yhteisöön ovat vapaita liittymään kaikki halukkaat ja he voivat osallistua kehitystyöhön mm. kirjoittamalla ohjelmakoodia, ylläpitämällä
projektin dokumentteja, raportoimalla Qt:n ohjelmakoodista löytyneistä ohjelmis- tovioista tai ihan vain auttamalla muita kehittäjiä vastaamalla heidän kysymyk- siinsä Qt-aiheisella keskustelufoorumilla. (11.)
4.2 Qt Creator
Qt Creator (kuva 3) on Qt:n oma kehitysympäristö. Siitä löytyvät kaikki nykyaikai- sen kehitysympäristön ominaisuudet, kuten koodin syntaksin korostus, automaat- tinen sanojen täydennys, virheenjäljitin (debugger), kääntäjä ja tuki useimmille versionhallintajärjestelmille. Qt Creatoria voidaan käyttää kaikilla yleisimmillä työ- pöytäkäyttöjärjestelmillä, kuten Windows, macOS ja Linux. Siitä löytyy myös graafisten käyttöliittymien suunnitteluun tarkoitettu Qt Designer, jonka avulla käyttöliittymien luominen onnistuu jopa ilman ohjelmointitaitoja. (13.)
KUVA 3. Qt Creator -kehitysympäristö
4.3 Tuetut mobiilialustat 4.3.1 Android
Qt:lla on mahdollista toteuttaa sovelluksia Android-laitteille, joiden käyttöjärjestel- män versio on Android Lollipop 5.0 (API 21) tai uudempi. Tuetut prosessoriarkki- tehtuurit ovat armv7a, x86, arm64-v8 ja x86_64. Android-laitteissa toimivat kaikki muut Qt-moduulit paitsi Qt WebEngine, Qt Serial Port, Qt Virtual Keyboard ja
muille käyttöjärjestelmille suunnatut moduulit. Qt-sovelluksia Android-alustalle voidaan kehittää ja kääntää Windows-, macOS-, ja Linux-laitteilla. (14.)
4.3.2 iOS
Qt:lla on mahdollista toteuttaa sovelluksia iOS-laitteille, joiden käyttöjärjestelmän versio on iOS 12 tai iOS 13. Vuoden 2020 lopulla julkaistava Qt 6.0 tukee myös Applen iOS 14 -käyttöjärjestelmää. Tuettu prosessoriarkkitehtuuri iOS-laitteille on armv8 (arm64). Qt-sovelluksia iOS-alustalle voidaan kehittää Windows-, macOS- ja Linux-laitteilla, mutta kääntäminen puhelimeen on mahdollista vain macOS- laitteella, koska kääntämiseen tarvittavaa Applen Xcode-ohjelmointiympäristö on saatavilla vain macOS-laitteille. Vaadittu Xcode-ohjelmointiympäristön versio Qt- sovelluksille on Xcode 11. (15.)
4.4 Kehitysympäristön konfigurointi
Kaikki tarvittavat komponentit on oltava asennettuina ennen Qt-sovellusprojektin perustamista. Jos Qt-ohjelmistokehys on jo asennettuna, mutta vaadittavat käyt- töjärjestelmäkohtaiset komponentit puuttuvat, voidaan ne asentaa käyttämällä Qt:n mukana tulevaa Qt Maintenance Tool -ohjelmaa (kuva 4).
4.4.1 Konfigurointi Android-alustalle
Qt-sovellusprojektin perustaminen Android-käyttöjärjestelmää varten vaati joitain esivalmisteluita, ennen kuin varsinainen kehitystyö voi alkaa.
Jotta Java-ohjelmointikielen käyttäminen projektissa olisi mahdollista, tarvitaan JDK eli Java SE Development Kit. JDK sisältää Java-virtuaalikoneen, joka pystyy suorittamaan tavukoodiksi käännetyn Java-ohjelman. Mikäli kehitystyö tehdään Linux-koneella, niin vaihtoehtoisesti voidaan käyttää myös OpenJDK:n versiota 6 tai 8. Uudemmat OpenJDK:n versiot voivat aiheuttaa ongelmia Android SDK:n komentorivityökalujen kanssa. (16.)
Android-pakettitiedostojen (APK) ja Android-sovellusnipun (AAB) luomista varten tarvitaan Gradle-koontityökalua. Googlen sovelluskauppa käyttää APK- ja AAB- tiedostoja sovelluspaketin optimoimiseen kullekin laitekokoonpanolle erikseen, jolloin käyttäjän laitteeseen ladataan vain tarvittavat koodit ja resurssit sovelluk- sen suorittamiseksi. Käyttäjän ei tarvitse ottaa sovellusta ladatessaan huomioon esimerkiksi hänen laitteensa käyttämää suoritinarkkitehtuuria, vaan Googlen so- velluskauppa osaa optimoida sovelluksen juuri hänen laitteelleen sopivaksi. (17.) Android Software Development Kit eli SDK sisältää työkaluja, kuten Android Na- tive Development Kit (NDK), joiden avulla voidaan käyttää C- ja C++-kieliä Androidissa ja sitä kautta päästä käsiksi Android-laitteen fyysisiin laitekom- ponentteihin, kuten esimerkiksi sensoreihin (18).
Qt Creator asentaa kaikki Android-kehitystyössä vaaditut paketit ja työkalut auto- maattisesti versiosta 4.12 lähtien (16). Laitekohtaiset komponentit voidaan tarkis- taa ja myös asentaa manuaalisesti Qt Creatorin laiteasetuksista (kuva 5).
KUVA 5. Qt Creatorin laitekohtaiset asetukset
4.4.2 Konfigurointi iOS-alustalle
Kehitysympäristön konfigurointi iOS-kehitystä varten on hieman suoraviivaisempi kuin konfigurointi Android-kehitystä varten, eikä se vaadi juurikaan muutoksia lai- tekohtaisiin asetuksiin.
Ennen Qt-ohjelmistokehyksen ja Qt Creator -ohjelmointiympäristön asentamista on suositeltavaa asentaa Xcode-ohjelmointiympäristö. Apple suosittelee käyttä- mään aina viimeisintä versiota Xcode-ohjelmointiympäristöstä, jos tarkoituksena on ladata kehitettävä sovellus Applen App Store -sovelluskauppaan. iOS:n versi- oita 12 ja 13 varten käytössä on oltava Xcode-ohjelmointiympäristön versio 11 ja iOS 14:n kehitys vaatii Xcode-version 12. Tämä tarkoittaa käytännössä myös sitä, että kehittäjällä on oltava käytössä myös viimeisin versio macOS-käyttöjär- jestelmästä laitteessa, jolla kehitystyötä tehdään. (15.)
Qt:n ja Xcoden asentamisen jälkeen kehittäjä voi aloittaa iOS-sovellusten kehit- tämisen ja ajaa niitä Mac-tietokoneellaan Qt Creatorin kautta tai iOS-simulaatto- rissa, joka tulee Xcode-ohjelmointiympäristön mukana.
Applen vaatimuksiin kuuluu, että kehittäjän on rekisteröidyttävä Applen kehittäjä- ohjelmaan, jotta omia sovelluksia voidaan ajaa iOS-laitteissa. Sovelluksen julkai- seminen Applen App Store -sovelluskaupassa ei myöskään ole mahdollista, en- nen kuin käyttäjä on rekisteröitynyt iOS-kehittäjäksi. (15.)
4.5 QML
Qt Modeling Language eli QML on kosketusnäytöltä käytettävien graafisten käyt- töliittymien rakentamiseen suunniteltu deklaratiivinen kieli, joka tunnettiin aiem- min myös nimellä Qt Declarative. Sen helposti luettava syntaksi muistuttaa JSON-kieltä, jossa objektit muodostavat puumallin. QML-koodin sekaan voidaan kirjoittaa myös JavaScript-koodia (kuva 6). Koska QML pohjautuu JavaScript-kie- leen, se suoritetaan ajon aikaisesti JavaScript-moottorin päällä, eikä sitä tarvitse kääntää ennen ohjelman suorittamista. JavaScript-koodia voidaan kirjoittaa suo- raan qml-tiedostoon tai erilliseen JavaScript-tiedostoon. (19.)
KUVA 6. QML-tiedostoon määriteltyjä JavaScript-funktioita
QML sisältää runsaasti valmiita visuaalisia elementtejä, joiden avulla näyttävien käyttöliittymien toteuttaminen on helppoa ja nopeaa. Alkeellisin käyttöliittymäele- mentti on Qt Quick -moduulin tarjoama suorakulmio (Rectangle), jota käyttämällä näytölle voidaan piirtää erivärisiä neliöitä, suorakulmioita ja myös ympyröitä. (20.) Rectangle-elementistä voidaan tehdä myös painonappi lisäämällä siihen MouseArea-elementti, joka sisältää onClicked-tapahtumankäsittelijän (kuva 7).
KUVA 7. Rectangle-elementistä tehty painonappi
Monimutkaisempia muotoja voidaan piirtää näytölle käyttämällä Canvas-ele- menttiä, johon on mahdollista piirtää käyttämällä JavaScript-kieltä (20).
Omien kustomoitujen käyttöliittymäkomponenttien rakentaminen qml-kielellä on helppoa. Käyttöliittymäkomponenttien rakentaminen tapahtuu luomalla uusi qml- tiedosto, johon komponentin koodi kirjoitetaan (kuva 8).
KUVA 8. LoadingIndicator-komponentin koodi
Tiedoston nimeksi kannattaa valita komponenttia hyvin kuvaava nimi, kuten esi- merkiksi LoadingIndicator.qml. Komponentti voidaan liittää osaksi muuta käyttö- liittymää käyttämällä qml-koodissa tiedoston nimeä, jossa komponentti sijaitsee (kuva 9).
KUVA 9. LoadingIndicator-komponentin käyttö osana muuta käyttöliittymää
Uudelleen käytettäviä käyttöliittymäkomponentteja kannattaa luoda kaikista sel- laisista käyttöliittymäelementeistä, joita käytetään useassa eri näkymässä. Tämä helpottaa komponentteihin kohdistuvien muutosten tekemistä, koska tällöin kom- ponentin koodia voidaan muuttaa muokkaamalla vain yhtä qml-tiedostoa.
4.6 Signal & Slot
Signaalit ja slotit ovat keskeisessä roolissa Qt-ohjelmoinnissa. Signal-slot-meka- nismin avulla QObject-luokasta johdetut oliot voivat välittää toisilleen tietoa ja rea- goida tapahtumiin. Signaalin mukana kulkeva tieto voi olla jokin yksittäinen muut- tuja, lista, taulukko tai olio. Luokkien tai niistä johdettujen olioiden ei tarvitse olla tietoisia toisistaan, vaan luokkien signaalit ja slotit yhdistetään toisiinsa QObject- luokan connect-metodilla (kuva 10). Connect-metodi ottaa parametrina signaalin lähettäjäolion, lähetetyn signaalin parametreineen, vastaanottajaolion sekä vas- taanottajaolion slotin. (21.)
KUVA 10. Connect-metodilla yhdistetty signaali ja slotti
Signaali lähetetään yleensä, kun jokin asia tapahtuu. Signaali voidaan lähettää esimerkiksi, kun internet-yhteyden yli ladattu data on valmis tai kun jonkin muut- tujan arvo muuttuu. Signaali voidaan lähettää emit-komennolla (kuva 11).
Slotit ovat rakenteeltaan tavallisia metodeja eli jäsenfunktioita (member function).
Ne voivat olla virtuaalisia ja ne voidaan ylikirjoittaa aliluokassa ja niitä voidaan käyttää ihan kuten tavallisia metodeja. (21.) Slotin sijaan signaaliin voidaan kyt- keä myös lambda-lausekkeita (kuva 12).
KUVA 12. granted-nimiseen signaaliin kytketty lambda-lauseke
4.7 Property-järjestelmä
Property on kuin tavallinen muuttuja, jolle voidaan asettaa luku- ja kirjoitusmetodit arvon lukemista ja asettamista varten. Propertyn tietotyyppi voi olla mikä tahansa tyyppi, jota QVariant-luokka tukee. Tavallisesta C++-muuttujasta sen erottaa se, että sitä voidaan käyttää myös QML-koodissa. (22.)
Property voidaan määrittää vain luokassa, joka on periytetty QObject-luokasta.
Propertyyn kytketään NOTIFY-avainsanalla signaali, joka lähetetään, kun proper- tyn arvo muuttuu. Property määritetään C++-koodissa käyttämällä Q_PRO- PERTY-makroa (kuva 13). (22.)
KUVA 13. WorkoutRoutineModel-luokka, joka sisältää useita propertyjä
4.8 Qt-moduulit
Qt sisältää kymmeniä eri moduuleja, joista sovelluskehittäjä voi valita oman so- vellusprojektin kannalta tärkeät moduulit.
Käytettävät moduulit sisällytetään projektiin lisäämällä ne Qt:n pro-päätteiseen projektitiedostoon ja lähdekooditiedostoon tai suoraan QML-tiedoston alkuun (kuva 14).
KUVA 14. Qt-moduulien lisäys qml-tiedoston alussa
Tärkein moduuli on Qt Core -moduuli, jonka sisältämiä luokkia kaikki muut mo- duulit käyttävät. Qt Core -moduuliin kuuluu mm. QObject-luokka, jonka kaikki Qt- luokat perivät. (23.)
Seuraavissa luvuissa on esitelty joitain tässä työssä käytettyjä Qt-moduuleja.
Qt Quick
Qt Quick -moduuli sisältää kaikki perusasiat, jotta Qt-sovellukseen voidaan luoda moderni käyttöliittymä käyttämällä qml-kieltä. Se tarjoaa alustan (canvas), johon koko sovelluksen käyttöliittymä piirretään. Se sisältää myös kaiken tarpeellisen visuaalisten käyttöliittymäkomponenttien animointiin, käyttäjäsyötteiden vastaan- ottamiseen ja se mahdollistaa myös tietomallien (data model) ja näkymien luomi- sen. (24.)
Qt Network
Qt Network -moduuli tarjoaa nimensä mukaisesti erilaisia kommunikaatioproto- kolla toteutuksia ja rajapintoja. Se mahdollistaa mm. datan lähettämisen ja vas- taanottamisen HTTP-protokollan avulla (25). Tässä työssä kaikki sovelluksen te- kemät rajapintakyselyt toteutettiin käyttämällä Qt Network -moduulin luokkia (kuva 15).
Kaikki rajapintakyselyt tehtiin käyttäen QNetworkAccessManager-luokan in- stanssia, joka kommunikoi rajapinnan kanssa asynkronisesti eli ei-reaaliaikai- sesti, jolloin osapuolet eivät ole ajallisesti toisistaan riippuvaisia. Asynkroninen kommunikointi HTTP-protokollan yli ei vaikuta sovelluksen käyttöliittymän käytet- tävyyteen, koska se tapahtuu omassa säikeessä.
KUVA 15. Treenihistorian noutaminen päivämäärän mukaan
Qt Android Extras
Qt Android Extras -moduuli sisältää luokkia, jotka mahdollistavat pääsyn joihinkin Androidin natiiviominaisuuksiin. Moduuli sisältää myös QAndroidJniObject-luo- kan, joka mahdollistaa Java-muuttujien ja -funktioiden käytön suoraan C++-koo- dista JNI-rajapinnan kautta (Java Native Interface). (26.)
Qt Charts
Qt Charts -moduuli tarjoaa nimensä mukaisesti helposti käytettäviä kuvaajia da- tan visualisointiin.
Jotta Qt Charts -moduulin kuvaajia voidaan käyttää Qt Quick -projektissa, täytyy projektin main.cpp-tiedostoa hieman muokata. Qt Quick -projekteissa oletuksena käytettävä QGuiApplication-luokan instanssi täytyy korvata QApplication-luokan instanssilla (kuva 16), koska Qt Charts -moduuli on riippuvainen Qt:n Graphics
KUVA 16. QGuiApplication-luokka korvattu QApplication-luokalla
Qt Network Authorization
Moduuli tarjoaa rajapinnan OAuth 2.0 -protokollan toteutukseen, jonka avulla käyttäjä voi kirjautua sovellukseen esimerkiksi käyttämällä omaa Google- tai Fa- cebook-tiliään ilman, että sovelluksen täytyy tietää käyttäjän käyttäjätunnusta tai salasanaa (28). OAuth 2.0 -protokollaan tutustutaan tarkemmin luvussa 5.3.
5 MOBIILISOVELLUS
5.1 Suunnittelu
Sovellus pyrittiin suunnittelemaan MVC-mallin mukaisesti siten, että käyttöliit- tymä, toiminnallisuus ja tietorakenteet olisivat erillään toisistaan.
Ennen varsinaisen ohjelmointityön aloittamista suunniteltiin myös sovelluksen ul- koasu, sitä koskevat vaatimukset sekä toteutettavat käyttötapaukset (kuva 17).
Vastaavien kuntosalisovellusten sekavat käyttöliittymät johtivat osaltaan tämän opinnäytetyöidean syntymiseen ja aiheen valintaan, joten käyttöliittymästä halut- tiin tehdä mahdollisimman selkeä ja helppokäyttöinen. Ulkoasun suunnittelussa käytettiin Figma-suunnitteluohjelmaa, joka osoittautui erittäin hyväksi työkaluksi.
KUVA 17. Sovelluksen käyttötapauskaavio
5.1.1 MVC-malli
MVC (Model View Controller) on ohjelmistoarkkitehtuuri ja -suunnittelumalli, joka jakaa sovelluksen kolmeen nimensä mukaiseen kategoriaan. MVC-arkkitehtuuri erottaa sovelluksessa esitettävän tiedon, graafisen käyttöliittymän ja niitä käsitte- levän logiikan toisistaan, minkä ansiosta sovelluksen kehitys ja ylläpito yksinker- taistuvat. (29.)
Kaikki sovelluksen näkymissä näytettävä data tulee model-luokista, joita voidaan manipuloida controller-luokkien kautta. Jokainen model- ja controller-luokka on vastuussa vain omasta toiminnallisuudestaan ja ne pyrittiin suunnittelemaan niin, että niiden keskinäinen riippuvuus olisi mahdollisimman vähäistä.
MVC-arkkitehtuurimallia noudatettiin työssä niin järjestelmäarkkitehtuuritasolla kuin myös sovelluksen sisällä (kuva 18).
KUVA 18. Järjestelmäarkkitehtuuri
Malli
Malli (Model) sisältää jonkin tietokokonaisuuden, kuten esimerkiksi käyttäjän koko treenihistoria tai yksittäisen treeniohjelman liikkeet sekä sarja- ja toistomää- rät. Malli voi olla tietokannan taulu, rajapinnan palauttama JSON-muotoinen data, treeniohjelman tiedot sisältävä C++-luokka tai kaikki nämä yhdessä.
Näkymä
Näkymä (View) -kategoriaan kuuluu sovelluksen graafinen käyttöliittymä ja sen kaikki yksittäiset näkymät, esimerkiksi lomakenäkymä, johon käyttäjä kirjaa jokai- sen suoritetun liikkeen toistomäärät ja käytetyn painon. Näkymät eivät ole tiukasti sidottuja sovelluksen toiminnallisuuteen. Sovelluksen käyttöliittymä voidaan vaih- taa kokonaan uuteen ilman, että sovelluksen toiminnallisuuksiin täytyy tehdä juu- rikaan muutoksia.
Käsittelijä
Käsittelijä (Controller) vastaanottaa käyttäjältä tulevat syötteet sekä käskyt ja muuttaa näkymää ja mallia niiden perusteella. Käsittelijä hoitaa esimerkiksi kaikki sovelluksen rajapintakyselyt sekä jotkin näkymien ja ponnahdusikkunoiden la- tauspyynnöt. Käsittelijä vastaanottaa rajapinnan palauttaman JSON-muotoisen datan, jonka se parsii sellaiseen muotoon, että datasta voidaan tehdä jonkin mo- del-luokan tietokokonaisuus. (Kuva 19.)
KUVA 19. Kirjautumista kuvaava sovelluksen ja rajapinnan välinen viestiyhteys- kaavio
5.2 Käyttötapaukset ja sovelluksen ulkoasu
Alla on esitelty sovelluksen käyttötapauksia sekä niihin liittyviä toiminnallisuuksia ja näkymiä, jotka sovellukseen toteutettiin.
5.2.1 Rekisteröityminen ja kirjautuminen
Sovelluksen käyttäminen ei ole mahdollista ilman kirjautumista. Ennen kirjautu- mista käyttäjän on luotava sovellukseen uusi käyttäjätili. Uuden käyttäjätilin luo- minen onnistuu sovelluksessa olevan rekisteröitymislomakkeen kautta.
Käyttäjä voi kirjautua sovellukseen käyttämällä jotain sosiaalisen median käyttä- jätiliään. Myös perinteinen kirjautuminen sähköpostiosoitteella ja salasanalla on mahdollista. Mikäli kirjautuminen tai uuden käyttäjätilin luominen epäonnistuu, käyttäjälle näytetään virheilmoitus ponnahdusikkunassa. (Kuva 20.)
KUVA 20. Sovelluksen kirjautumis- ja rekisteröitymisnäkymä
5.2.2 Treeniohjelman luominen ja treenin suorittaminen
Sovelluksella käyttäjä voi luoda itselleen uusia treeniohjelmia. Treeniohjelmiin käyttäjä valitsee suoritettavat liikkeet sovelluksen liikekirjastosta ja määrittää toisto- ja sarjamäärät.
Sovelluksella luotujen treeniohjelmien muokkaaminen on mahdollista. Käyttäjä voi nimetä treeniohjelman uudelleen sekä lisätä tai poistaa liikkeitä. Myös tree- niohjelmien poistaminen kokonaan on mahdollista. (Kuva 21.)
KUVA 21. Yksittäisen treeniohjelman hallintanäkymä
Kun käyttäjä on luonut itselleen ensimmäisen treeniohjelman, hän voi alkaa suo- rittamaan ensimmäistä treeniään. Käyttäjä kirjaa sovellukseen jokaisessa tree- niohjelman liikkeessä käyttämänsä painon ja toistomäärät. Toistojen ja käytetyn painon lisäksi myös käyttäjän treeniin käyttämä aika tallennetaan.
Sovellus laskee käyttäjälle treeninaikaisten liikesarjojen kokonaiskuorman prog- ression edelliseen sarjaan verrattuna ja esittää sen käyttäjälle prosenttilukuna lo- makenäkymän oikeassa laidassa (kuva 22). Sovellus laskee sarjan kokonais- kuorman kertomalla suoritetut toistomäärät käytetyllä harjoituspainolla.
KUVA 22. Lomakenäkymä, johon käyttäjä kirjaa tiedot suoritettavasta treenistä
5.2.3 Treenihistorian selaaminen
Treenihistoriaa on mahdollista selata päivämäärän mukaan. Käyttäjä voi seurata sovelluksen kautta myös käytettyjä toisto ja sarja määriä sekä käytettyjä harjoi- tuspainoja liikekohtaisesti. (Kuva 23.)
KUVA 23. Päivämäärän mukaan haetun yksittäisen treenin tiedot ja liikekohtai-
5.2.4 Liikekirjaston selaaminen
Sovelluksessa on myös kattava liikekirjasto, jota käyttäjä voi vapaasti selata (kuva 24). Treeniohjelmia rakentaessaan käyttäjä valitsee suoritettavat liikkeet sovelluksen liikekirjastosta.
KUVA 24. Liikekirjastonäkymä
5.3 OAuth 2.0
OAuth 2.0 on laajasti käytössä oleva autorisointiprotokolla, joka käyttää TLS-sa- lausprotokollaa viestien salaamiseksi. OAuth 2.0 -protokollan avulla käyttäjä voi valtuuttaa sovelluksen käyttämään jollain resurssipalvelimella sijaitsevia resurs- seja ilman, että sovelluksen täytyy tietää käyttäjän käyttäjätunnusta tai salasanaa (kuva 25). Resurssipalvelin voi olla esimerkiksi Facebookin ylläpitämä palvelin ja resurssit käyttäjän sähköpostiosoite, kaverilista ja profiilikuva. OAuth 2.0 -autori- sointiprotokollaa käyttävät muun muassa sellaiset suuryhtiöt, kuin Google, Face- book, Apple, Spotify ja Microsoft. (30.)
Sovelluksen käyttäjälle OAuth 2.0 -autorisointiprotokollan hyöty on se, että käyt- täjä voi luoda käyttäjätilin tai kirjautua sovellukseen käyttämällä esimerkiksi Google- tai Facebook-tiliään. Tämä helpottaa ja nopeuttaa sovelluksen käyttöön-
ottoa, koska käyttäjän ei tarvitse enää syöttää sähköpostiosoitettaan ja salasa- naansa, kuten perinteisesti on ollut tapana. Tunnistautumiseen käytettyyn käyt- täjätiliin täytyy olla liitetty sähköpostiosoite, jotta käyttäjä voidaan kirjata sisään sovellukseen tunnistautumisen jälkeen.
KUVA 25. Tunnistautumisprosessin kulku (31)
6 REST-RAJAPINTA
Rajapinta yhdistää sovelluksen ja palvelimella sijaitsevan tietokannan. Käyttäjä tekee sovelluksessa rajapintakyselyjä, joiden perusteella rajapinta tekee tieto- kantakyselyjä käyttäen SQL-kyselykieltä. Onnistuneen tietokantakyselyn jälkeen rapapinta palauttaa haetun informaation JSON-muodossa takaisin sovellukselle, jossa se visualisoidaan ja esitetään käyttäjälle (kuva 26).
KUVA 26. Rajapinnan palauttamat yksittäisen treenin tiedot JSON-muodossa
6.1 REST-arkkitehtuuri
REST eli Representational State Transfer on arkkitehtuurimalli sovellusten väli- seen kommunikointiin. Sovellukset voivavat olla asiakas- ja palvelinsovelluksia (client-server). REST-arkkitehtuurimallia käytetään yleisimmin HTTP-protokollan kanssa, mutta sitä ei kuitenkaan ole sidottu mihinkään tiettyyn tiedonsiirtoproto- kollaan. Se on yleisimmin käytetty rajapintamalli internetin välityksellä kommuni- koiville laitteille ja sovelluksille. REST-arkkitehtuurin hyötynä on se, että sillä on universaalit arkkitehtuuriset vaatimukset, joka mahdollistaa usean ohjelmointikie- len käyttämisen saman REST-rajapinnan kanssa. (32.)
Kuten mille tahansa muullekin arkkitehtuurityylille, myös REST-arkkitehtuurille on määritelty omat ohjaavat vaatimukset. REST-arkkitehtuurilla on viisi pakollista vaatimusta ja yksi vapaaehtoinen vaatimus. Mitä tahansa web-rajapintaa voidaan kutsua REST-rajapinnaksi, mikäli kaikki viisi sille asetettua pakollista vaatimusta täyttyvät. (32.)
6.1.1 Asiakas-palvelin-vaatimus
Asiakas-palvelin-vaatimuksen tarkoitus on jakaa toiminnallisuus kahteen osa- alueeseen. Yleensä toiminnallisuus jaetaan esimerkiksi siten, että asiakas huo- lehtii käyttöliittymästä ja palvelin tiedon tallennuksesta. (32.)
Tässä työssä asiakas-palvelin-vaatimus toteutettiin siten, että kehitetty mobiiliso- vellus toimii asiakkaana ja tietokantapalvelin huolehtii tiedon tallentamisesta.
6.1.2 Tilattomuus
Jokaisen rajapintakutsun täytyy sisältää kaikki tarvittava informaatio kyseisen kutsun suorittamiseksi. Palvelimen täytyy käsitellä jokainen asiakkaan, eli tässä tapauksessa sovelluksen tekemä rajapintakutsu yksittäisenä täysin uutena kut- suna. Palvelimelle ei tallenneta kutsujen suorittamiseen tarvittavia muuttuvia tie- toja, kutsujen välisiä tiloja tai istuntoja. (32.)
Tilattomuusvaatimus toteutettiin siten, että käyttäjää yksilöiviä tietoja ei tallenneta palvelimen istuntoihin. Sovellus lähettää jokaisen rajapintakutsun yhteydessä käyttöoikeustunnuksen (access token), jonka perusteella rajapinta tietää onko ky- seisellä käyttäjällä oikeus sen tarjoamiin palveluihin ja resursseihin.
6.1.3 Välimuisti
Välimuistivaatimus edellyttää, että palvelimen palauttaman informaation mukana on oltava tieto siitä, voidaanko informaatio tallentaa asiakkaan välimuistiin. Asi- akkaan ei tarvitse toistaa samoja rajapintakutsuja, jos välimuistiin tallentaminen on sallittu, vaan se voi hakea tarvitsemansa informaation omasta välimuististaan.
(32.)
Tämä vaatimus toteutettiin tässä työssä siten, että sovellukseen ohjelmoitiin eri- laisia model-luokkia, joiden avulla rajapinnan palauttama informaatio tallenne- taan väliaikaisesti puhelimen muistiin.
6.1.4 Yhdenmukainen rajapinta
Yhdenmukainen rajapinta järjestelmän komponenttien välillä yksinkertaistaa jär- jestelmän kokonaisarkkitehtuuria ja parantaa komponenttien välisen kanssakäy- misen näkyvyyttä. Varsinainen sovelluksen toteutus voidaan pitää kokonaan eril- lään tarjottavasta rajapinnasta, mikä mahdollistaa sovelluksen jatkuvan kehityk- sen. (32.)
REST tarkentaa yhdenmukaisen rajapinnan vaatimusta vielä neljällä lisävaati- muksella. Kaksi ensimmäistä vaatimusta käsittelevät resurssien tunnistamista ja manipulointia. Kolmas vaatimus edellyttää itseselitteisiä viestejä ja neljäs puoles- taan hypermedian käyttöä sovelluksen tilakoneena. (32.)
6.1.5 Kerroksittainen järjestelmä
Kerrosrakenteinen järjestelmä mahdollistaa arkkitehtuurin koostamisen erillisistä komponenteista. Järjestelmän erilliset komponentit keskustelevat vain niiden vä- littömässä läheisyydessä olevien kerrosten kanssa. Tämä tarkoittaa käytännössä sitä, että komponentti, joka on vastuussa rajapinnan palauttamasta tiedosta, ei ole kiinnostunut siitä, millä tavalla sen palauttama tieto visualisoidaan sovelluk- sessa. (32.)
6.1.6 Ladattava koodi
REST-arkkitehtuurimallin viimeinen vaatimus on vapaaehtoinen ja se koskee va- linnaista koodin lataamista. Tämä antaa palvelimelle mahdollisuuden laajentaa asiakassovelluksen toiminnallisuutta lähettämällä vastauksen mukana koodia, joka voidaan suorittaa asiakassovelluksessa. (32.)
Tätä vaatimusta ei toteutettu tässä työssä.
6.2 HTTP-protokolla
HTTP (Hypertext Transfer Protocol) on yksi internetin keskeisimmistä tiedonsiir- toprotokollista. Sen tyypillisin käyttötapaus on HTML-sivujen välittäminen palve- limelta internet-selaimelle, mutta sen avulla voidaan välittää melkein mitä dataa tahansa, kuten esimerkiksi tekstiä, videoita ja kuvia (kuva 27).
KUVA 27. HTTP-protokollan avulla voidaan välittää monenlaista dataa (33) Myös HTTP-protokolla noudattaa REST-arkkitehtuurityyliä. Se toteuttaa yhden- mukaisen tilattoman rajapinnan määrittelemällä tarkan rakenteen ja syntaksin viestille, jonka avulla resurssien esityksiä kuljetetaan asiakkaan ja palvelimen vä- lillä. (34.)
6.2.1 Metodit
HTTP määrittelee joukon metodeja, joiden avulla asiakkaan ja palvelimen välinen viestintä tapahtuu. Yleisimmät käytössä olevat metodit ovat POST, GET, PUT ja DELETE. POST lähettää dataa palvelimelle, GET hakee dataa palvelimelta, PUT päivittää palvelimella sijaitsevaa dataa ja DELETE poistaa sitä. Muita vähemmän yleisiä metodeja ovat OPTIONS, HEAD, TRACE ja CONNECT. (35.)
6.2.2 HTTPS
REST-rajapinnan kommunikaatiossa käytetään pelkän HTTP-protokollan sijaan HTTPS-protokollaa, joka on HTTP-tiedonsiirtoprotokollan ja TLS-salausprotokol- lan yhdistelmä. TLS on salausmenetelmä, jossa data kryptataan eli salataan ja salauksen purkamiseen tarvittavat salausavaimet jaetaan vain asiakaslaitteen ja palvelimen välillä. Näin HTTP-protokollan yli lähetettyyn dataan ei pääse käsiksi ulkopuolisia. Kommunikaation ulkopuolinen osapuoli ei voi muuttaa internet-yh- teyden yli lähetettyjen viestien sisältöä tai saada niitä luettavassa muodossa it- selleen. TLS on paranneltu versio vanhentuneesta SSL-salausmenetelmästä.
(36.)
Tässä työssä toteutettu rajapinta sijaitsee palvelimella, johon on ohjattu app- päätteinen verkkotunnus. App-päätteiseen verkkotunnukseen ei ole mahdollista muodostaa ollenkaan suojaamatonta HTTP-yhteyttä. Salatun HTTPS-yhteyden muodostamiseksi palvelimelle täytyi myös asentaa SSL-sertifikaatti, joka sisältää julkisen ja yksityisen salausavaimen. Sertifikaatti uusitaan vuosittain.
SSL-sertifikaatin salausavaimet ovat pitkiä salattuja merkkijonoja, joita käytetään HTTPS-yhteyden yli lähetettyjen tietojen salaamiseen ja salauksen purkamiseen.
Julkisella avaimella salatut tiedot voidaan purkaa vain yksityisellä avaimella ja päinvastoin. (37.)
6.3 JSON Web Token
JSON Web Token (JWT) on avoimen standardin (RCF 7519) menetelmä käyttö- oikeustunnusten esittämiseen kahden osapuolen välillä. JWT-käyttöoikeustun- nuksen (access token) muoto perustuu JSON-formaattiin. Sen yleisin käyttötar- koitus on käyttäjän varmentaminen. Palvelin tai rajapinta luo käyttäjälle JWT- käyttöoikeustunnuksen onnistuneen kirjautumisen yhteydessä, jonka avulla pal- velin pystyy varmistamaan, että käyttäjällä on oikeus sen palvelimelta pyytämiin resursseihin. (38.)
JWT on merkkijono, joka koostuu kolmesta pisteellä erotetusta osasta: otsikko (header), sisältö (payload) ja allekirjoitus (signature) (kuva 28).
KUVA 28. Kolmeen osaan purettu JSON Web Token (38)
Ensimmäinen osa eli otsikko sisältää tiedon siitä, minkä tyyppisestä käyttöoikeus- tunnuksesta on kyse ja miten sen sisältämän allekirjoituksen salaus on toteutettu.
Toinen osa voi sisältää esimerkiksi palvelimen palauttamat käyttäjätiedot, jotka voidaan tallentaa sovellukseen ja käyttää tulevissa rajapintakutsuissa. Merkkijo- non viimeinen osa sisältää palvelimella määritellyn salasanan salatun allekirjoi- tuksen luomista varten. Allekirjoitus salataan käyttäen valittua algoritmia ja se koostuu käytännössä kaikista merkkijonon kolmesta osasta. Allekirjoituksella var- mistetaan, että lähetetty käyttöoikeustunnus ei ole muuttunut matkalla ja että ra- japintakutsun suorittava käyttäjä on juuri se, joka hän väittää olevansa. Käyttäjän oikeus palvelimella sijaitseviin resursseihin mitätöityy, jos yksikin merkki JWT- merkkijonossa muuttuu sen luomisen jälkeen. (38.)
7 TIETOKANTA
7.1 MySQL
MySQL on maailman suosituin avoimen lähdekoodin tietokantaohjelmisto, jonka kehityksestä ja jakelusta vastaa Oracle Corporation. Sen vahvuuksia ovat mm.
korkea suorituskyky, luotettavuus, skaalautuvuus ja helppokäyttöisyys. (39.) MySQL on relaatiotietokantaohjelmisto eli tietokanta varastoi kaikki taulut sekä niiden sarakkeet ja rivit ja käsittelee niitä yhtenä kokonaisuutena. Relaatiotieto- kannassa taulujen välille luodaan yhteyksiä käyttämällä taulujen viite- ja vieras- avaimia. (39.)
7.2 SQL-kyselykieli
MySQL käyttää tietokantakyselyissä standardoitua SQL-kyselykieltä. SQL on ly- henne sanoista Structured Query Language. Kieli on kehitetty alun perin 1970- luvulla IBM:n tutkimuslaboratoriossa DB2- ja System R -tietokantajärjestelmiä varten. SQL on standardi, kun käsitellään tietoja relaatiotietokannasta. Se ei ole rakenteellinen kieli, joten se määrittelee vain, miten ja mitä tietoja käsitellään, ei niinkään miten käsittelytoiminto tapahtuu (kuva 29). Kaikki keskeiset relaatiotie- tokantoja hyväkseen käyttävät tietokantajärjestelmät tukevat sitä jollain tapaa.
(40.)
KUVA 29. SQL-lause, jolla haetaan kaikki aloittelijoille sopivat selkälihasliikkeet
7.3 MySQL Workbench
Opinnäytetyössä toteutettu tietokanta suunniteltiin käyttäen MySQL Workbench -ohjelmaa, joka on visuaalinen tietokantojen suunnittelu- kehitys- ja ylläpitotyö- kalu. Se mahdollistaa visuaalisen tietokantamallin muuntamisen toimivaksi MySQL-tietokannaksi ja jo olemassa olevan tietokannan muuntamisen takaisin
visuaaliseksi tietokantamalliksi. Ohjelma on saatavilla Windows-, Linux- ja ma- cOS-käyttöjärjestelmille GNU General Public -lisenssillä. (41.)
7.4 Tietokannan suunnittelu 7.4.1 Käsiteanalyysi ja ER-kaavio
Tietokantasuunnittelu aloitetaan tekemällä tietokokoelman käsiteanalyysi (con- ceptual data modeling). Tietokannan tai minkä tahansa tietokokoelman käsite- analyysissä määritellään, mitä tietoa tietokokoelmaan sisältyy. Tarkoituksena on siis määritellä kaikki tietokantaan tallennettava tieto ja niiden väliset yhteydet.
Tietokantasuunnittelussa käsitteellä tarkoitetaan yhtä tietokohdetta (entity) eli jo- tain tunnistettavissa olevaa asiaa tai tapahtumaa (esim. treenaajan suorittamaa lihaskuntoharjoitusta). (42.)
Käsiteanalyysissä keskeisiksi käsitteiksi muodostuivat sovelluksen käyttäjä (tree- naaja), aktivoitu lihasryhmä, suoritettu lihaskuntoharjoitus, käytetty treenioh- jelma, suoritettu treeniliike ja suoritettu liikesarja, joka sisältää käytetyn painon ja toistomäärän.
Käsiteanalyysin tuloksena syntyi käsitemalli, joka kuvaa käsitteiden välisiä suh- teita ja niiden attribuutteja graafisena ER-kaaviona (kuva 30). ER-kaavio voidaan esittää myös yksinkertaisemmin käyttämällä UML-mallinnuskieltä.
KUVA 30. Tietokannan ER-kaavio
7.4.2 Tietokohteet ja kohdetyypit
ER-kaaviossa määritellään tietokohteet kohdetyyppien (entity type) perusteella.
Kaaviossa ei siis kuvata yksittäisiä tietokohteita, kuten esimerkiksi jotain tiettyä käyttäjää tai yksittäistä kuntosaliohjelmaa.
Kohdetyyppi voi olla mikä tahansa konkreettinen tai abstrakti asia, johon liittyy jotain sellaista tietoa, jota halutaan tallentaa tietokantaan. Tietokannan taulut ovat kohdetyyppejä, joiden sisältämät rivit ovat tietokohteita. (43.) Esimerkiksi treeni- liike on kohdetyyppi, jonka tietokohteita voivat olla tietyt treeniliikkeet, kuten penk- kipunnerrus tai jalkakyykky.
Kohdetyypit voivat olla riippumattomia tai alisteisia eli riippuvaisia. Alisteisen koh- detyypin kaikki tietokohteet ovat koko olemassaolonsa ajan kytkettyinä alistavaan kohteeseen. Alistajan kautta tunnistettavaa tietokohdetta kutsutaan tunnisteriip- puvaksi ja yhteyttä tunnistettavaksi yhteydeksi (Identifying relationship). (44.) Esi- merkiksi yksittäistä treenikertaa ei voi olla olemassa ilman, että se on kytketty johonkin treenaajaan. Tunnistettavaa yhteyttä kuvataan ER-kaaviossa yhtenäi- sellä viivalla.
Riippumaton tietokohde voi olla olemassa ilman, että sitä on kytketty toiseen tie- tokannassa sijaitsevaan tietokohteeseen. Riippumattomien tietokohteiden välistä yhteyttä sanotaan ei-tunnistettavaksi yhteydeksi (Non-identifying relationship).
(44.) Esimerkiksi treeniliikkeen ja treeniohjelman välillä on ei-tunnistettava yh- teys, eli treeniliike voi olla olemassa ilman, että sitä on käytetty yhdessäkään treeniohjelmassa. Ei-tunnistettavaa yhteyttä kuvataan ER-kaaviossa katkovii- valla.
7.4.3 Attribuutit
Yksittäisiin tietokohteisiin liittyy tietoja, joita tietokantaan halutaan tallentaa. Täl- laisia tietoja kuvataan kohdetyyppeihin liittyvillä attribuuteilla. Esimerkiksi liike- sarja kohdetyypin attribuutteja ovat suoritettu treeniliike, käytetty paino ja toisto- määrä.
7.4.4 Tietokohteiden väliset yhteydet
Tietokohteiden välillä on yhteyksiä (relationship), joiden kautta ne liittyvät loogi- sesti toisiinsa. Tällaiset tietokohteet ovat aina jollain tavoin riippuvaisia toisistaan.
Yhteyksien selvittäminen auttaa vähentämään ylimääräistä ja kaksinkertaista tie- toa tietokannassa.
Tietokohteiden väliset yhteydet voidaan jakaa kolmeen eri luokkaan: yhden suhde yhteen, yhden suhde moneen ja monen suhde moneen. (45.)
Yhden suhde yhteen
Kahden tietotyypin välillä on yhden suhde yhteen -yhteys, jos ensimmäisen tieto- tyypin yksittäinen tietokohde liittyy vain yhteen toisen tietotyypin tietokohteeseen ja toisen tietotyypin tietokohde liittyy vain yhteen ensimmäisen tietotyypin tieto- kohteeseen. Yhden suhde yhteen -yhteydet ovat harvinaisia, koska usein näissä tapauksissa tiedot voidaan tallentaa yhteen tauluun. (45.)
Tässä työssä yhden suhde yhteen yhteys luotiin users- ja credentials-taulujen välille, eli yhdellä käyttäjällä voi olla vain yhdet käyttäjätunnukset ja käyttäjätun- nukset voivat olla vain yhden käyttäjän käyttäjätunnukset. Tällä haluttiin varmis- taa se, että käyttäjätietoja haettaessa tietokannasta ei vahingossakaan palauteta käyttäjän salasanaa. Credentials-tauluun luodaan yhteys vain kirjautumisen yh- teydessä, eikä sen jälkeen ole enää tarpeen tehdä kyselyjä kyseisestä taulusta.
Yhden suhde moneen
Yhden suhde moneen on tietotyyppien yleisin yhteystyyppi. Tietotyyppien välille syntyy yhden suhde moneen -yhteys, jos ensimmäisen tietotyypin yksittäinen tie- tokohde liittyy yhteen tai useampaan toisen tietotyypin tietokohteeseen ja toisen tietotyypin tietokohde liittyy vain yhteen ensimmäisen tietotyypin tietokohteeseen.
(45.)
Kuvassa 31 on esimerkki yhden suhde moneen -yhteydestä. Yhdellä käyttäjällä voi olla monta suoritettua kuntosalitreeniä, mutta yhdellä kuntosalitreenillä voi olla vain yksi suorittaja.
KUVA 31. Yhden suhde moneen -yhteys users- ja workouts-taulujen välillä
Monen suhde moneen
Monesta moneen -suhde syntyy, jos ensimmäisen tietotyypin yksittäinen tieto- kohde liittyy yhteen tai useampaan toisen tietotyypin tietokohteeseen ja toisen tietotyypin tietokohde liittyy yhteen tai useampaan ensimmäisen tietotyypin tieto- kohteeseen. Monesta moneen yhteys täytyy purkaa välitaulun avulla kahdeksi yhden suhde moneen -yhteydeksi (kuva 32). (45.)
KUVA 32. Treeniohjelman ja treeniliikkeen välinen monesta moneen -yhteys
8 YHTEENVETO
Opinnäytetyön tavoitteena oli suunnitella ja toteuttaa alustariippumaton mobiili- sovellus, joka voisi korvata kuntosaliharjoittelijan käyttämän paperisen treenipäi- väkirjan. Toisena päätavoitteena oli suunnitella ja toteuttaa REST-arkkitehtuuria noudattava rajapinta sovelluksen ja MySQL-tietokannan välille. Kaiken kaikkiaan työ onnistui hyvin ja lopputulos vastaa hyvin työn alussa määriteltyjä tavoitteita.
Suunnitelluista käyttötapauksista ainoastaan muiden käyttäjien seuraaminen so- velluksessa jäi toteuttamatta.
Mobiilisovelluksen toteutukseen valittu teknologia (Qt) osoittautui erittäin päte- väksi ja uskallan kyllä suositella sitä myös nykyaikaisten web-teknologioiden ti- lalle alustariippumattomien mobiilisovellusten kehitykseen. Erityisesti QML-kieli ja Qt Quick -käyttöliittymäkirjasto ansaitsevat kehuja. Miellyttävää Qt:n käytöstä teki myös se, että sovellusta ei tarvitse ajaa kehitysvaiheessa laite-emulaatto- rissa, kuten natiiveja mobiilisovelluksia. Toteutetun sovelluksen toiminnassa ei juurikaan ollut eroja Android- ja iOS-laitteiden välillä.
Suurempia ongelmia tai haasteita en opinnäytetyön edetessä kohdannut, mutta työ oli sen laajuuden vuoksi aika työläs ja päivät venyivät usein pitkiksi. Eniten päänvaivaa minulle aiheutti sovelluksen käyttöliittymä, johon en edelleenkään ole täysin tyytyväinen, mutta se ei haittaa, koska muuten sovellus toimii hienosti ja siihen on helppo toteuttaa vaikka kokonaan uusi käyttöliittymä. Työn aikana tör- mäsin Figma-suunnitteluohjelmaan, joka osoittautui erittäin päteväksi työkaluksi käyttöliittymäsuunnitteluun ja sen avulla pääsin etenemään sovelluksen ulkoasun suunnittelussa.
Työn teknisessä toteutuksessa pyrin keskittymään siihen, että koodi olisi laadu- kasta ja helposti ylläpidettävää. Tässä tavoitteessa pysyminen oli tärkeää, koska tarkoituksenani on julkaista sovellus Applen ja Googlen sovelluskaupoissa, mutta ennen julkaisua se vaatii vielä hieman jatkokehitystä ja testausta.
LÄHTEET
1. Mobile Operating System Market Share Worldwide - October 2020. StatCoun- ter. Saatavissa: https://gs.statcounter.com/os-market-share/mobile/world- wide. Hakupäivä 11.11.2020.
2. Cross-platform software. 2020. Wikipedia. Saatavissa: https://en.wikipe- dia.org/wiki/Cross-platform_software. Hakupäivä 7.10.2020.
3. Nitecki, Szymon 2019. Cross-Platform Mobile Apps Development – Pros and Cons. Netguru S.A. Saatavissa: https://www.netguru.com/blog/cross-plat- form-mobile-apps-development. Hakupäivä 9.10.2020.
4. What is Android. Android.com Saatavissa: https://www.android.com/what-is- android/. Hakupäivä 10.10.2020.
5. Callaham, John 2020. The history of Android: The evolution of the biggest mobile OS in the world. Android Authority. Saatavissa: https://www.androi- dauthority.com/history-android-os-name-789433/. Hakupäivä 16.11.2020.
6. Su, Jeb 2019. Android 10 Is Now The Official Name Of Google's Next Mobile Operating System, Dropping Dessert Names. Forbes Media LLC. Saatavissa:
https://www.forbes.com/sites/jeanbaptiste/2019/08/23/android-10-is-now- the-official-name-of-googles-next-mobile-operating-system-dropping-des- sert-names/?sh=5142afe4895e. Hakupäivä 14.10.2020.
7. Platform Architecture. 2020. Android Developers. Saatavissa: https://develo- per.android.com/guide/platform. Hakupäivä 14.10.2020.
8. iOS. 2020. Wikipedia. Saatavissa: https://en.wikipedia.org/wiki/IOS. Haku- päivä 18.10.2020.
9. Pandey, Renuka 2019. What should every iOS engineer know about the iOS architecture? Quora.com. Saatavissa: https://www.quora.com/What-should- every-iOS-engineer-know-about-the-iOS-architecture/answer/Renuka-Pan- dey. Hakupäivä 19.10.2020.
10. Naveen 2020. iOS Architecture. Intellipaat.com. Saatavissa: https://intelli- paat.com/blog/tutorial/ios-tutorial/ios-architecture/. Hakupäivä 19.10.2020.
11. About Qt. 2019. Qt Wiki. Saatavissa: https://wiki.qt.io/About_Qt. Hakupäivä 21.10.2020.
12. All Modules. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/qtmo- dules.html. Hakupäivä 21.10.2020.
13. Qt Creator. 2016. Qt Wiki. Saatavissa: https://wiki.qt.io/Qt_Creator. Haku- päivä 21.10.2020.
14. Qt for Android. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt- 5/android.html. Hakupäivä 22.10.2020.
15. Qt for iOS. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/ios.html.
Hakupäivä 22.10.2020.
16. Getting Started with Qt for Android. 2020. The Qt Company. Saatavissa:
https://doc.qt.io/qt-5/android-getting-started.html. Hakupäivä 22.10.2020.
17. About Android App Bundles. 2020. Android Developers. Saatavissa:
https://developer.android.com/guide/app-bundle. Hakupäivä 23.10.2020.
18. Get started with the NDK. 2020. Android Developers. Saatavissa: https://de- veloper.android.com/ndk/guides. Hakupäivä 23.10.2020.
19. QML Applications. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt- 5/qmlapplications.html. Hakupäivä 26.10.2020.
20. Use Case - Visual Elements In QML. 2020. The Qt Company. Saatavissa:
https://doc.qt.io/qt-5/qtquick-usecase-visual.html. Hakupäivä 27.10.2020.
21. Signals & Slots. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/sig- nalsandslots.html. Hakupäivä 27.10.2020.
22. The Property System. 2020. The Qt Company. Saatavissa:
https://doc.qt.io/qt-5/properties.html. Hakupäivä 27.10.2020.
23. Qt Core. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/qtcore-in- dex.html. Hakupäivä 28.10.2020.
24. Qt Quick. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/qtquick- index.html. Hakupäivä 29.10.2020.
25. Qt Network. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/qtnet- work-index.html. Hakupäivä 2.11.2020.
26. Qt Android Extras C++ Classes. 2020. The Qt Company. Saatavissa:
https://doc.qt.io/qt-5/qtandroidextras-module.html. Hakupäivä 2.11.2020.
27. Qt Charts. 2020. The Qt Company. Saatavissa: https://doc.qt.io/qt-5/qtcharts- index.html. Hakupäivä 2.11.2020.
28. Qt Network Authorization. 2020. The Qt Company. Saatavissa:
https://doc.qt.io/qt-5/qtnetworkauth-index.html. Hakupäivä 4.11.2020.
29. MVC Framework - Introduction. Tutorialspoint.com. Saatavissa:
https://www.tutorialspoint.com/mvc_framework/mvc_framework_introduc- tion.htm. Hakupäivä 7.11.2020.
30. OAuth. 2020. Wikipedia. Saatavissa: https://en.wikipedia.org/wiki/OAuth. Ha- kupäivä 9.11.2020.
31. Authorization Code Flow. Auth0. Saatavissa:
https://auth0.com/docs/flows/authorization-code-flow. Hakupäivä 14.11.2020.
32. What is REST. Restfulapi.net. Saatavissa: https://restfulapi.net/. Hakupäivä 14.11.2020.
33. An overview of HTTP. 2019. MDN web docs. Saatavissa: https://develo- per.mozilla.org/en-US/docs/Web/HTTP/Overview. Hakupäivä 16.11.2020.
34. HTTP. 2020. MDN web docs. Saatavissa: https://developer.mozilla.org/en- US/docs/Web/HTTP. Hakupäivä 16.11.2020.
35. HTTP request methods. 2020. MDN web docs. Saatavissa: https://develo- per.mozilla.org/en-US/docs/Web/HTTP/Methods. Hakupäivä 16.11.2020.
36. HTTPS. 2020. Wikipedia. Saatavissa: https://en.wikipedia.org/wiki/HTTPS.
Hakupäivä 16.11.2020.
37. What is an SSL certificate? Cloudflare Inc. Saatavissa:
https://www.cloudflare.com/learning/ssl/what-is-an-ssl-certificate/. Hakupäivä 17.11.2020.
38. Introduction to JSON Web Tokens. Auth0 Inc. Saatavissa: https://jwt.io/intro- duction/. Hakupäivä 19.11.2020.
39. What is MySQL? Oracle Corporation. Saatavissa:
https://dev.mysql.com/doc/refman/8.0/en/what-is-mysql.html. Hakupäivä 21.11.2020.
40. SQL. Koulutus- ja konsultointipalvelu KK Mediat. Saatavissa:
https://www.2kmediat.com/sql/alkeet.asp. Hakupäivä 21.11.2020.
41. MySQL Workbench. Oracle Corporation. Saatavissa:
https://www.mysql.com/products/workbench/. Hakupäivä 21.11.2020.
42. Laine, Harri 2005. Käsiteanalyysi. Helsingin yliopisto, Tietojenkäsittelytieteen laitos. Saatavissa: https://www.cs.helsinki.fi/u/laine/tkp/tietomallit/kasiteana- lyysi.html. Hakupäivä 23.11.2020.
43. Introduction of ER Model. 2019. GeeksforGeeks.org. Saatavissa:
https://www.geeksforgeeks.org/introduction-of-er-model/. Hakupäivä 24.11.2020.
44. What's the difference between identifying and non-identifying relationships?
2009. Stackoverflow.com. Saatavissa: https://stackoverflow.com/questi- ons/762937/whats-the-difference-between-identifying-and-non-identifying-re- lationships. Hakupäivä 26.11.2020.
45. The 3 Types of Relationships in Database Design. 2016. Database.guide Saatavissa: https://database.guide/the-3-types-of-relationships-in-database- design/. Hakupäivä 26.11.2020.