• Ei tuloksia

Alustariippumaton Qt-sovellus ja REST-rajapinta

N/A
N/A
Info
Lataa
Protected

Academic year: 2022

Jaa "Alustariippumaton Qt-sovellus ja REST-rajapinta"

Copied!
54
0
0

Kokoteksti

(1)

Jani Palo-oja

ALUSTARIIPPUMATON QT-SOVELLUS JA REST-RAJAPINTA

(2)

ALUSTARIIPPUMATON QT-SOVELLUS JA REST-RAJAPINTA

Jani Palo-oja Opinnäytetyö Syksy 2020

Tietotekniikan tutkinto-ohjelma Oulun ammattikorkeakoulu

(3)

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

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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ä.

(9)

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ä.

(10)

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.)

(11)

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).

(12)

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.)

(13)

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

(14)

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.)

(15)

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).

(16)

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ä

(17)

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

(18)

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).

(19)

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).

(20)

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.

(21)

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).

(22)

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).

(23)

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ää

(24)

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).

(25)

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.)

(26)

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).

(27)

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).

(28)

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

(29)

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.

(30)

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

(31)

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ä.

(32)

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

(33)

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.

(34)

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.

(35)

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-

(36)

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-

(37)

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)

(38)

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.)

(39)

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.)

(40)

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ä.

(41)

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.)

(42)

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).

(43)

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.)

(44)

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

(45)

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

(46)

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ä.

(47)

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.

(48)

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

(49)

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.

(50)

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.

(51)

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.

(52)

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.

(53)

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.

(54)

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.

Viittaukset

LIITTYVÄT TIEDOSTOT

Meaneffectsofsilageadditivetreatment(formicacid(FA)applicationrates0,2,4and6ltMean effects of silage additive treatment (formic acid (FA) application rates 0, 2, 4 and 6 l

–  Suljettu (Apple App Store, DRM-suojattu sisältö) –  Hybridejä (Maksullinen

Kun saaren korkeimmalla kohdalla sijaitseva avara huvilarakennus oli hel- posti seiniä puhkomalla ja ovia siirte- lemällä saatettu siihen kuntoon, että seura voi sinne

19 mm thick wood-fibre panel fronts with low formaldehyde emission CLASS E0, covered on 2 sides with melamine sheets [HRM], edge on 4 sides in 8/10 thick abs.. The external surface

Ensi vuoden Liittoneuvoston kokous olisi myös tarkoitus pitää Islannissa, mutta Islannin edustuksen puuttuessa kokous ei voinut suoraan päättää asiasta!. Suurimpia asioita

Ja mikä ettei, kyllähän Vellamossa toimivien museoiden, Suomen merimuseon ja Kymenlaakson museon tilat ovat sekä arkkitehtoniselta ilmeeltään, että vaikuttavuudeltaan

Musiikkikasvatuksen kirkkomuskarit alle kou- luikäisille sekä kirkkomusikanttitoiminta 6-vuo- tiaista ylöspäin ovat tuoneet musiikin iloa niin seurakuntalaisten perheisiin

Asiaa ei yksinkertaista sekään seikka, että yksikkömme on asiassa mukana monessa eri roolissa: kaivauksilla työskentelevä Museoviraston palkkaama henkilökunta on pääasiassa