Upload
tuukka-tallgren
View
47
Download
2
Embed Size (px)
Citation preview
360 asteen palaute -sovelluksen toteuttaminen FeedbackDialog
Oy:lle
Tuukka Tallgren
Opinnäytetyö
Tietojenkäsittelyn koulutusohjelma
2014
Tiivistelmä
27.2.2014 Tietojenkäsittelyn koulutusohjelma
Tekijä tai tekijät Tuukka Tallgren
Ryhmätunnus tai aloitusvuosi 2011
Raportin nimi 360 asteen palaute -sovelluksen toteuttaminen FeedbackDialog Oy:lle
Sivu- ja lii-tesivumäärä 36 + 2
Opettajat tai ohjaajat Sirpa Marttila
Opinnäytetyön tavoitteena oli tehdä iPhonelle sovellus, jolla pystyy vastaamaan 360 asteen palautteeseen. 360 asteen palautteessa arvioitava henkilö arvioi omaa työsuori-tustaan täyttämällä kyselyn ja vastaajaryhmät kuten esimies, kollegat ja asiakkaat arvioi-vat arvioitavan henkilön työsuoritusta. Tällä tavalla saadaan muodostettua kokonaisval-tainen 360 asteen kuva henkilön suoriutumisesta. Sovelluksen tärkeimpiä toteutettavia ominaisuuksia olivat kyselyyn vastaaminen, kyse-lyn lähettäminen muille henkilöille vastattavaksi ja raportin katselu tuloksista. Lisäksi toteutettavana oli käyttäjätilin luonti, kysymysten selaaminen etukäteen, omien tietojen muokkaus ja lokalisointi neljälle eri kielelle. Sovellus toteutettiin annettujen vaatimusten perusteella Applen kehittämällä Xcode kehitysympäristöllä käyttämällä Objective-C ohjelmointikieltä. Sovelluksen laittaminen App Storeen ja rajapinnan toteuttaminen rajattiin opinnäyte-työn ulkopuolelle. Feedback Dialog vastasi rajapinnan toteuttamisesta, sovellus ainoas-taan käytti rajapinnan tarjoamia palveluita. Opinnäytetyöprosessi aloitettiin lokakuussa 2013 ja saatiin päätökseen helmikuussa 2014. Tavoitellut ominaisuudet saatiin tehtyä valmiiksi, ainoastaan raportointiominai-suudesta jäi puuttumaan pdf-raportin haku. Tämän lisäksi jatkokehitettäväksi jäi sovel-luksen käyttöliittymän viimeistely.
Asiasanat iPhone, iOS, henkilöarviointi, itsearviointi
Abstract 27.2.2014 Degree programme in Business Information Technology
Authors Tuukka Tallgren
Group or year of entry 2011
The title of thesis 360 degree feedback application for FeedbackDialog Oy
Number of report pages and attachment pages 36 + 2
Advisor(s) Sirpa Marttila
The goal of this thesis was to make an iPhone app for the so called 360-degree feed-back. In the 360-degree feedback, the person who is being evaluated for his/her work performance fills out a questionnaire and different respondent groups, such as, superi-ors, colleagues and customers fill out the same questionnaire in order to evaluate the work performance of the person who is being evaluated. This way it is possible to get a full 360-degree view of a person’s performance. The key features of the application were filling out the questionnaire, sending the ques-tionnaire to respondents and being able to view a report of the results. Also, creating a user account, being able to browse the questions beforehand, editing the user account information and localizing the application to four languages had to be done. The appli-cation was made with Objective-C using the Xcode IDE developed by Apple. Submitting the application to App Store and the server-side interface were excluded from this thesis. Feedback Dialog Oy developed the interface: the application only used services offered by it. This thesis project was started in October 2013 and finished in February 2014. All the features except fetching the pdf-report of the results were completed. The application’s user interface also needs further development.
Key words iPhone, iOS, self-evaluation
Sisällys
1 Johdanto ................................................................................................................................ 1
1.1 Opinnäytetyön tavoite ja rajaus ................................................................................. 1
2 360 asteen palaute työsuorituksen arvioinnissa ................................................................ 2
2.1 360 asteen palautteen taustaa ..................................................................................... 2
2.2 360 asteen palaute suunnittelu ................................................................................... 3
3 iPhone-kehitys ja sovelluksen käyttämät tekniikat ........................................................... 5
3.1 Objective-C .................................................................................................................. 5
3.2 Xcode ............................................................................................................................ 7
3.3 Interface Builder ja Storyboard ................................................................................. 8
3.4 Käyttöliittymäkomponentit ja ikonit......................................................................... 8
3.5 REST ........................................................................................................................... 12
3.6 JSON ........................................................................................................................... 16
4 Toteutus ............................................................................................................................... 19
4.1 Yleiskuvaus sovelluksen ominaisuuksista ja käytetyt tekniikat ............................ 19
4.2 Aloitusnäkymä ........................................................................................................... 19
4.3 Käyttäjän rekisteröityminen ..................................................................................... 21
4.4 Omien tietojen muuttaminen .................................................................................. 22
4.5 Kyselyyn vastaaminen ............................................................................................... 23
4.6 Kyselyn lähettäminen kontakteille .......................................................................... 25
4.7 Raportin katselu ......................................................................................................... 29
4.8 Monikielisyys .............................................................................................................. 31
5 Yhteenveto .......................................................................................................................... 32
5.1 Johtopäätökset ja tulokset ........................................................................................ 32
5.2 Projektin analyysi ja opinnäytetyön aikataulutus ................................................... 32
5.3 Oman oppimisen arviointi ....................................................................................... 33
5.4 Jatkokehitys ................................................................................................................ 34
Lähteet ...................................................................................................................................... 35
Liitteet ....................................................................................................................................... 37
Liite 1. Keskeiset käsitteet ................................................................................................. 37
1
1 Johdanto
Monissa suurissa yrityksissä käytetään vuosittain esimiesten työsuoritukseen arviointi-
prosessia nimeltä 360 asteen palaute. 360 asteen palautteessa esimiehet arvioivat omaa
työsuoritustaan ja esimiehen kanssa tekemisissä olevat ryhmät arvioivat esimiehen työ-
suoritusta. Esimiestä arvioivia ryhmiä ovat alaisten lisäksi esimerkiksi asiakkaat, kolle-
gat, oma esimies ja ystävät. Tuloksista voidaan kerätä historiatietoa ja vertailla vuosien
välillä miten henkilön taidot ovat kehittyneet.
Mobiilisovellusten käyttäminen yritysmaailmassa on nousussa oleva trendi. Feedback-
Dialog haluaa vastata tähän tarpeeseen ja tämä on ollut lähtökohtana opinnäytetyön
teon aloittamiselle. Sovellus tullaan toteuttamaan iPhonelle, koska Applen App Store
on suosittu kauppapaikka sovelluksille.
1.1 Opinnäytetyön tavoite ja rajaus
Opinnäytetyön tavoitteena on tehdä iPhone-sovellus, jolla esimies pystyy vastaamaan
360 asteen palautteessa käytettävään kyselyyn. Sovelluksen pääasiallisena käyttäjäryh-
mänä pidetään siis juuri esimiesasemassa olevia henkilöitä. Sovelluksesta on tarkoitus
tehdä monikielisyyttä tukeva, jolloin käyttäjiä voisi löytyä Saksasta, Ruotsista ja Hollan-
nista. Potentiaalisia asiakkaita on paljon, koska kyselyitä täytetään suuremmissa yrityk-
sissä vuosittain. Hieman yllättäen Applen App Storesta ei löydy kuin yksi 360-sovellus,
joten ohjelman teolle on perusteltu tarve.
Sovelluksen kehittäminen on aloitettu marraskuussa 2013 ja se on tarkoitus saada ladat-
tavaksi App Storeen keväällä 2014. Opinnäytetyön tavoitteena on saada sovellus siinä
määrin valmiiseen kuntoon, että toimeksiantajan on mahdollista laittaa se ladattavaksi
App Storeen.
Palvelinpään rajapinta on tehty toimeksiantajan toimesta. Tässä opinnäytetyössä tehtävä
sovellus ainoastaan kutsuu rajapintaa ja käyttää sen tarjoamia palveluita. Sovellus on
määritetty toimimaan ainoastaan iOS7:lla, vanhempia iOS-versioita ei tueta. Sovelluk-
sen laittaminen App Storeen rajataan opinnäytetyön ulkopuolelle.
2
2 360 asteen palaute työsuorituksen arvioinnissa
2.1 360 asteen palautteen taustaa
360 asteen palaute mittaa yksilön käytöstä ja osaamista ryhmän toiminnassa ja sen ta-
voitteiden saavuttamisessa. Prosessissa on mukana itse arvioitava henkilö ja sen lisäksi
esimies, tiimin jäsenet, henkilökunta, sisäiset ja ulkoiset asiakkaat, ystävät ja perhe voi-
vat ottaa osaa henkilön arviointiin. Tarkoituksena on muodostaa mahdollisimman ko-
konaisvaltainen kuva arvioitavasta henkilöstä. Prosessi ei ole nopea, tutkimukseen tar-
koitettua dataa kerätään systemaattisesti kyselyjen tai haastattelujen kautta. (Ward
1997, 4-5.)
Palautteen saaminen on tärkeä osa henkilön kehittymisen ja kasvun suhteen. Kun ym-
märtää itseään ja minkälainen vaikutus omilla toimillaan on muihin ihmisiin, saa henki-
lö oikeanlaisen kuvan vaikutuksestaan ympärillä oleviin ihmisiin ja se auttaa häntä suo-
riutumaan paremmin. (Maylett 2009, 52.) Arvioitavan henkilön kannalta on tärkeää,
että hän vastaa itse kyselyyn. Näin voidaan selvittää miten henkilön omat näkemykset
itsestään ja vastaajien näkemys arvioitavana olevasta henkilöstä kohtaavat (Ward 1997,
8).
Henkilön arvioinnin jättäminen pelkästään oman esimiehen arvion varaan huomattiin
olevan liian suppea tapa, jotta pystyttäisiin muodostamaan kunnollinen kuva henkilön
osaamisesta. Monen eri vastaajan antama palaute koettiin saavan aikaan tarkemman ja
kokonaisvaltaisemman kuvan henkilön osaamisesta ja suoriutumisesta. Tällä pystytään
paremmin perustelemaan henkilön palkitsemista, koska voidaan osoittaa, että suoriu-
tuminen on monen eri ryhmän mielestä ollut hyvää. (Maylett 2009, 53.)
Erityisen tärkeää on käyttää 360 asteen palautetta silloin kun esimies ei ole suoraan te-
kemisissä alaisen kanssa tai kun hän alainen viettää suurimman osan ajastaan muitten
henkilöiden seurassa. Kun tutkimusta otetaan käyttöön saattaa esiintyä jonkun verran
vastarintaa, mutta kun henkilöt ymmärtävät, että monesta eri suunnasta tuleva arviointi
on parempaa, niin yleensä se koetaan ymmärrettävämmäksi. Kääntöpuolena on kuiten-
kin se jos 360 asteen palautteella vaikutetaan henkilön palkkaan, bonuksiin tai muihin
3
työsuhteen liittyviin asioihin, henkilöstö ei välttämättä anna realistisia vastauksia, jos
sillä tiedetään olevan suora vaikutus kyseisiin asioihin. (Maylett 2009, 54.)
2.2 360 asteen palaute suunnittelu
Tutkimuksen valmistelu on erittäin monivaiheinen prosessi ja tutkimusta suunniteltaes-
sa tarvitsee tehdä tarkkoja päätöksiä kyselyn toteuttamisella. Kysymyksiä, joita tutki-
musta suunniteltaessa täytyy ottaa huomioon on esimerkiksi se, että voidaanko kysely
täyttää vain englanniksi ja kuinka johtamismallit toimivat eri kulttuureissa, kuinka mon-
ta vastaajaa per vastaajaryhmä tarvitaan, kuinka luotettavaa data on, minkä tyyliset ky-
symykset ovat soveliaita, kuinka monta vastaajaa tutkimukseen otetaan, ovatko vastaa-
jat luotettavia. (Bracken &Rose 2011, 185.)
Bracken & Rose (2011, 185) ovat määritelleet seuraavat neljä asiaa tärkeimmiksi jos
kyselyllä halutaan saada todellista kehittymistä ja muutosta organisaatiossa: relevantti
sisältö, luotettava data, vastuuvelvollisuus ja organisaation laajuinen osallistuminen tut-
kimukseen. Relevanttiin sisältöön liittyy se, että kysely räätälöidään kunkin yrityksen
strategian ja tarpeiden mukaan. Data tulee monen henkilön käytettäväksi ja sen tarvit-
see olla luotettavalla tavalla tuotettua. Luotettavuus syntyy esimerkiksi seuraavien seik-
kojen avulla: vastaajia on valittu riittävä määrä, vastaajat pystyvät oikeasti havainnoi-
maan arvioitavan henkilön toimia eli he ovat olleet tekemisissä hänen kanssaan, kyse-
lyä ei ole tehty hämmentämään vastaajaa sekavilla kysymyksillä ja valittu arviointiasteik-
ko on selkeä. (Bracken & Rose 2011, 185-187.)
On tärkeää, että kyselyn täyttämisellä on jonkinlaisia jälkiseuraamuksia. Sillä osoitetaan
vastaajille, että kyselyyn osallistumisella on käytännön merkitystä ja vastaajat saavat tar-
kemman kuvan siitä mihin tutkimus oikeasti vaikuttaa. Jos esimerkiksi kyselyyn osallis-
tujalle luvataan bonus, jos hän toteuttaa vuoden parin sisällä 360 asteen palautteesta
ilmenneet kehityskohdat on siinä hyvä motivaatiotekijä tutkimuksen suorittamiseen.
(Bracken & Rose 2011, 188.)
Yrityksen esimiesten ja johtajien osallistuminen tutkimukseen on tärkeää, jotta alaiset
näkevät esimiesten olevan sitoutuneita tutkimuksen tekoon. Heikkojen johtajien tun-
4
nistaminen on helpompaa ja pystytään alkaa keräämään historiatietoa organisaation
henkilöiden suoriutumisesta.
Koko organisaation käsittävä 360 asteen palaute on voimakas väline, jolla voidaan
kommunikoida muutosta ja saada aikaan uudistuksia yrityksessä. (Bracken & Rose
2011, 188.)
5
3 iPhone-kehitys ja sovelluksen käyttämät tekniikat
Kehittäminen iPhonelle on mahdollista ainoastaan Mac OS X 10.8 -käyttöjärjestelmää
(tai uudempaa) käyttävillä tietokoneilla. Kehitysympäristönä toimii Applen tekemä
Xcode. Xcoden mukana tulee iOS SDK, jolla sovelluksia rakennetaan. Lisäksi Xcodes-
sa on iOS-simulaattori, jolla ohjelmaa pystyy ajamaan. (Apple 2014.)
3.1 Objective-C
Objective-C on kieli, jota käytetään sovellusten tekemiseen Applen mobiilikäyttöjärjes-
telmälle nimeltä iOS. Objective-C:n kehitti alunperin Brian Cox 1980-luvulla. Kieli
pohjautuu C-kieleen, jonka päälle on tehty kerros olio-ohjelmointia varten. Apple osti
kielen lisenssin omistavan NextSoftwaren vuonna 1996 ja alkoi kehittää omaa sovellus-
kehitysympäristöään lisäämällä kielen ympärille Xcoden ja Interface Builderin, joilla
pystyi tekemään sovelluksia helpommin käyttäen hyödyksi. (Kochan 2012, 1.) Applen
iPhonessa käyttämä iOS-käyttöjärjestelmä on yksi versio Mac OS X-
käyttöjärjestelmästä (Kochan, 2012, 2).
Objective-C laajentaa C-kielen olio-ohjelmoinnin käsitteillä. Siihen sisältyy esimerkiksi
uusien luokkien määritteleminen, luokissa käytettävät metodit ja attribuutit sekä proto-
kollien käyttäminen. Objective-C on dynaaminen kieli. Sovelluksen toimintaan voidaan
helposti vaikuttaa, kun se on käynnissä eikä tarvitse asettaa liian suuria rajoitteita sille
mitä on tehty kun ohjelmaa alun perin käännetään. Tukea löytyy siis niin staattisesti
kuin dynaamisesti määritetyille muuttujille. Staattisesti tyypitetyssä muuttujassa tarvitsee
määritellä luokan nimi mitä käytetään, mutta jos ei tiedetä luokkaa ja halutaan määrittää
muuttuja dynaamisesti voidaan käyttää luokan tyyppinä ”id”-tä. (Apple 2013a.)
Objective-C:n luokat koostuvat kahdesta erillisestä osasta. Interface eli rajapinta (.h-
tiedosto) sisältää luokan sisältämän muuttujat ja määrittää luokan julkisen rajapinnan ja
implementaatiosta (.m-tiedosto) eli luokan toteuttavasta osasta. Rajapintaan julistetaan
luokan sisältämät muuttujat ja metodit. Rajanpintaluokkia kutsutaan yleisesti header-
tiedostoiksi. Implementaatio-luokkaan tarvitsee sisällyttää tieto siitä mitä headeria se
6
käyttää, joten ne tuodaan kirjoittamalla luokan ylälaitaan #import ja headerin nimi. Itse
koodi kirjoitetaan @implementation ja @end-avainsanojen väliin. (Apple 2013a.)
Taulukko 1 Objective-C:n tietotyypit (Nahavandipoor 2013, 4.)
Tyyppi Selitys
NSInteger kokonaisluku
CGFloat desimaaliluku
NSString/NSMutableString merkkijono
id mikä tahansa olio
NSDictionary/NSMutableDictionary Hash-taulu, johon voi tallentaa tietoa
avain/arvo periaattella. NSMutableDic-
tionaryn tietoja voi muuttaa jälkikäteen
NSArray/NSMutableArray Taulukko
Taulukossa 1 on esitetty osa Objective-C:n tietotyypeistä. Sovelluksissa käytettiin kaik-
kia näistä. Objective-C:n tietotyypeistä osa on primitiivejä ja osa luokkia. Esimerkiksi
NSInteger on primitiivi, mutta NSString (merkkijono) on luokka ja siitä tarvitsee tehdä
uusi instanssi. Objective-C:ssä käytetään C:n ja C++ tapaan pointereita, joten merkki-
jono ja muut luokat täytyy aina luoda käyttämällä edessä *-merkkiä. (Nahavandipoor
2013, 5.) Kuviosta 1 huomataan, että numero voidaan luoda ilman pointeria koska se
on primitiivi.
NSString *firstname = @"Tuukka";
NSInteger bestNumber=17;
Kuvio 1. Pointerin käyttö muuttujaa alustettaessa.
Objective-C:ssä normaali merkkijono (NSString) on muuttumaton. Sen sisältö siis luo-
daan, kun olio tehdään ensimmäisen kerran eikä sisältöä voi sen jälkeen enää muuttaa.
(Apple 2012.) Kuviossa 1 oleva ”firstname”-merkkijonon arvoa ei jälkeenpäin voi enää
muuttaa, vaan se on aina ”Tuukka”. Jos haluttaisiin tehdä merkkijono, jonka arvoa voi-
daan muuttaa jälkikäteen, täytyisi käyttää NSMutableStringiä. Samalla tavalla toimivat
NSArray ja NSDictionary: jos taulukon arvoja jälkikäteen halutaan muokata täytyy käyt-
7
tää Mutable-versioita. Sovelluksessa on käytetty esimerkiksi kysymysten esittämiseen
NSArray:ta, koska kysymykset eivät muutu vaan ne ovat aina samat. Kyselyn vastauksia
tallennettaessa käytetään NSMutableDictionarya, koska siihen lisätään vastauksia sitä
mukaan kuin käyttäjä vastaa kysymyksiin. Vastauksia voi vaihtaa jälkikäteen, joten jo
senkin takia NSMutableDictionary on tarpeellinen.
3.2 Xcode
Xcode on Applen kehittämä IDE, jolla pystytään kehittämään, testaamaan ja optimoi-
maan ohjelmia iPhonelle. Xcoden kautta sovellukset laitetaan niiden valmistuttua App
Storeen. Xcoden voi ladata ilmaiseksi Applen sivulta, eikä sen käyttö maksa mitään
(Apple 2013b).
Xcoden ulkoasu on jaettu lohkoihin (Kuvio 2). Projektin rakenne näkyy ikkunan va-
semmassa reunassa, keskellä on editori, johon kirjoitetaan tekstiä ja oikealla puolella on
valikko, josta määritetään erilaisten komponenttien asetuksia. Xcoden simulaattorilla
on mahdollista ajaa omia ohjelmia. Yläpalkin valikosta voi valita mitä alustaa simulaat-
tori simuloi. Vaihtoehtoina ovat eri iPhone ja iPad-mallit. Kun on ostanut kehittäjäli-
senssin aukeaa mahdollisuus ajaa ohjelmia omassa puhelimessaan.
Kuvio 2. Xcoden perusnäkymä
8
3.3 Interface Builder ja Storyboard
Interface Builderilla on graafinen työkalu ohjelman ulkoasun tekemiseen. Vaikka kaikki
on mahdollista määritellä koodin puolella, on ohjelman ulkoasun tekeminen käyttämäl-
lä Interface Builderia helpompaa, kun eri komponentteja pystyy helposti vetämään vali-
kosta puhelimen ruutua simuloivaan näkymään. Interface Builder piirtää komponenttia
liikuteltaessa viivoja, joilla on helppo asemoida komponentti suhteessa muihin näky-
mässä oleviin komponentteihin. Komponentin kokoa voi muuttaa venyttämällä sitä
reunoista.
Storyboard (Kuvio 3) helpottaa käyttöliittymän eri näkymien välisten siirtymien hah-
mottamista. Xcode luo automaattisesti projektille Storyboardin ja sovelluksen luonnin
yhteydessä täytyy erikseen määrittää, jos haluaa käyttää .nib-tiedostoja.
Kuvio 3. Storyboard
3.4 Käyttöliittymäkomponentit ja ikonit
Sovelluksessa eniten käytetyt käyttöliittymäkomponentit ovat UITableView, UITabBar,
UIButton ja UITextField. UITableView on taulukkonäkymä, johon voidaan listata tie-
toa riveihin ja osioihin jaoteltuna. UITableView:ssä olevia soluja ( UITableViewCellje)
voi koskettaa ja niihin voi liittää esimerkiksi siirtymän toiseen näkymään. UITable-
View:n tarkoituksena on esittää tietoa listamaisessa muodossa. Kuviossa 4 näkyy yh-
9
teystietojen lisäyksessä käytetty UITableView. Uudet henkilöt tulevat lisättyinä näkyviin
eri riveille.
Kuvio 4. UITableViewController listausnäkymä
Solujen tyypiksi voidaan määrittää joko static tai dynamic. Dynaamisesti luotuihin so-
luihin voidaan lisätä tietoa esimerkiksi taulukosta dynaamisesti ohjelman luonnin aika-
na. Staattisia soluja käytetään esimerkiksi valikkoja tehdessä Storyboardin kautta. Koska
valikko on aina sama, ei ole järkevää luoda sitä dynaamisesti. Kuvassa 4 on laitettu
UITableViewn tyyliksi grouped.
UINavigationBariin on navigoinnissa käytettävä palkki. Yleisin käyttötarkoitus sille on
”paluu”-toiminnon tekeminen, jolloin mennään takaisin edelliseen näkymään, mutta
siihen on mahdollista lisätä muitakin nappeja (UIButton). Koska ne ovat yläpalkissa
sanotaan niitä UIBarButtonItemeiksi. Niihin voidaan sitoa joku action tai siirtymä eri
ViewControlleriin. Kuviossa 5 on yläpalkissa takaisinpainike, edit-nappi ja lisäysnappi.
10
Kuvio 5. UITabBarController
UITabBarController (Kuvio 5) on välilehtiä hallitseva komponentti. Xcode tarjoaa
projektia luodessa mahdollisuuden tehdä ohjelma ns. välilehtisovelluksena. Xcode luo
valmiiksi Storyboardille UITabBarControllerin ja tekee siitä ohjelman aloitusnäkymän.
Storyboardilla on helppo lisätä uusia välilehtiä sovellukseen. Komponenttien joukosta
vedetään uusia ViewControllereita Storyboardille ja vedetään ctrl-näppäintä pohjassa
pitämällä viiva UITabBarControllerista ViewControlleriin, jonka halutaan tulevan väli-
lehdeksi. Maksimissaan välilehtiä voi olla viisi. Jos niitä on enemmän ryhmittää Xcode
viidennen välilehden uudeksi näkymäksi, johon on kerätty ylimääräiset välilehdet. Sto-
ryboardista pystyy määrittämään ikonin ja tekstin välilehden otsikoksi.
Kuvio 6. Rekisteröinnissä käytetyt komponentit UILabel ja UITextField
UILabel, UITextView ja UITextField liittyvät kaikki tekstin esittämiseen. UILabel ero-
aa muista siten, että siihen voidaan vain sijoittaa tekstiä. UITextView:n ja UITextFiel-
diin käyttäjä pystyy kirjoittamaan tekstiä. UITextView:n mahtuu enemmän kuin yksi
rivi tekstiä. Kummastakin pystyy poistamaan editointimahdollisuuden. Sovelluksessa on
käytetty UITextFieldiä niissä kentissä, joihin pystyy kirjoittamaan tekstiä. UIText-
View:llä on tehty tekstejä, jotka tarvitsevat useamman rivin tietoa kerralla.
11
Kuviossa 6 tekstit vasemmalla ovat UILabeleita ja harmaalla pohjalla näkyvät ovat UI-
TesxtFieldejä. Niihin pystyy laittamaan taustalle ehdotuksia mitä kenttään voisi kirjoit-
taa.
UIAlertView:tä käytetään ilmoittamaan virheistä tai jonkun asian onnistuneesta suorit-
tamisesta. Ilmoitus näkyy kuviossa 7 ruudun keskiosassa. Tässä tapauksessa on kyse
tiedonsiirrossa tapahtuneesta virheestä. Ikkunaan voi määrittää otsikon, tekstin ja siinä
käytettävät napit.
Kuvio 7. UIAlerView:n tekemä ilmoitus kun internetyhteyttä ei ole saatavilla
Sovelluksella täytyy olla viisi erikokoista ikonia, jotta se hyväksytään App Storeen. Iko-
nia käytetään iPhonen työpöydällä, App Storessa ohjelman ikonina ja koot ovat 58x58,
80x80 ja 120x120 pikseliä. Lisäksi tarvitsee olla Launch Image, joka näytetään kun oh-
jelma käynnistetään. Sen koko on 640x1136 iPhone 5:lle ja uudemmille, 640 x 960 iP-
hone 4:lle. App Storea varten tarvitsee lisäksi luoda yksi ikoni, jonka koko on 1024 x
1024. Kuvat suositellaan toimitettavan PNG-formaatissa. (Apple 2013c.)
12
UIActivityViewControllerilla (Kuvio 8) on mahdollista jakaa sisältöä sosiaalisen median
palveluihin kuten Twitteriin ja Facebookkiin, sekä lähettää jaettava sisältö eteenpäin
sähköpostilla tai tekstiviestinä. Jaettava sisältö voi sisältää tekstiä tai kuvia. Puhelimessa
täytyy kuitenkin olla kirjautuneena Facebookiin tai Twitteriin niiden integroitujen sovel-
lusten kautta. Tämä tarkoittaa siis sitä, että käyttäjä on laittanut käyttäjätunnuksensa ja
salasanansa puhelimen asetukset-sivun kautta.
Kuvio 8. UIActivityViewControllerin näkymä josta voi jakaa sisältöä sosiaaliseen
mediaan
3.5 REST
REST on alun perin Roy Fieldingin väitöskirjassaan kehittämä arkkitehtuurimalli web-
pohjaisten palveluiden kehittämiseen. REST ei ole tiukka standardi vaan enemmänkin
kokoelma parhaita käytäntöjä. (Friedrich 2013, 6.) On olemassa seuraavat rajoitteet,
jotka REST palvelun täytyisi toteuttaa:
- yhdenmukainen rajapinta
- tilaton
- välimuistia käyttävä
- asiakas/palvelin -malli
13
- kerroksittainen arkkitehtuuri
(Friedrich 2013, 6.)
Yhdenmukainen rajapinta tarkoittaa sitä, että palvelimella olevat resurssit voidaan tun-
nistaa URI-osoitteiden perusteella. Palvelin lähettää vastauksena ainoastaan esityksen
tietokannasta olevassa datasta. Se ei lähetä koko tietokantaa vaan kyseistä resurssia ku-
vaavan JSON tai XML-olion. Asiakkaan täytyy pystyä muuttamaan resurssin tilaa käyt-
tämällä näitä tarjottuja palveluita. (Friedrich 2013, 7.) REST on tilaton, koska jokaises-
sa pyynnössä on esitettynä tarpeelliset tiedot pyynnön suorittamiseen. Välimuistin käyt-
täminen tekee palvelun käytöstä nopeampaa ja paremmin skaalautuvaa. Asiakkaan
koodi erotetaan palvelimesta. Palvelin ei ole kiinnostunut mitä käyttöliittymässä tapah-
tuu tai mikä on sen tila. Kerroksittainen arkkitehtuuri tarkoittaa että asiakas ei välttä-
mättä tiedä onko se yhteydessä palvelimeen vai onko välissä jotain joka tekee turvalli-
seksi tai muuta. (Friedrich 2013, 8.)
REST-verbien luokitteluun liittyy käsite idempotenssi. Se tarkoittaa sitä, että jos operaa-
tio tehdään yhden tai useamman kerran on sillä täsmälleen sama lopputulos. Käsite on
helpointa ymmärtää matematiikan avulla: numeron kertominen nollalla on idempotent-
ti, koska se tuottaa saman lopputuloksen, kerrotaan numeron nollalla yhden kerran tai
sata kertaa. Lopputulos on aina 0. (Richardson & Ruby, 2007, 102.) Resurssiin suori-
tettava operaatio on siis idempotentti, jos yhden pyynnön tekemisellä on sama vaikutus
kuin jos tekisi pyynnön useamman kerran (Richardson & Ruby, 2007, 102-103).
Taulukko 2. REST-verbit taulukossa (Richardson & Ruby 2007, 97)
Verbi Selitys
POST Uuden resurssin luonti palvelimelle
GET Resurssin haku palvelimelta
PUT Resurssin tilan muuttaminen tai päivittä-
minen
DELETE Resurssin poisto
Url-osoitteet on tarkoitus pitää mahdollisimman yksinkertaisena ja luettavassa muodos-
sa. GET-pyyntöä (Taulukko 2) käytetään ainoastaan tietojen hakuun. Sitä ei ole tarkoi-
14
tus käyttää mihinkään muuhun, kuten uuden resurssin luontiin tai resurssin tietojen
päivittämiseen. GET-pyyntöä pidetään turvallisena operaationa. Sen voi tehdä yhden
tai kymmenen kertaa ja lopputulos on silti sama, muutosta tiedoissa ei tapahdu. Onnis-
tuneessa tapauksessa GET palauttaa http-statuskoodin 200, epäonnistuneessa joko 404
(ei löydy) tai 401 (tarvitsee autentikaation). (Friedrich 2013, 11.) Toteutettavassa sovel-
luksessa GET-verbiä käytetään esimerkiksi raportin hakuun.
PUT-verbillä suoritetaan resurssin tilan päivittäminen. Pyynnön mukana tulee uudel-
leen päivitetty data. Kyseessä on siis muokkauksissa käytettävä operaatio. PUT ei ole
turvallinen operaatio, koska se muuttaa palvelimella olevan resurssin tilaa, mutta se on
silti idempotentti. Jos tehdään sama PUT-pyyntö kaksi kertaa, on resurssin tila sama
toisella kerralla kuin ensimmäisen kerran jälkeen. (Friedrich 2013, 12.) Toteutettavassa
sovelluksessa PUT-verbiä käytetään käyttäjätilin tietojen muokkaamiseen.
POST-verbiä käytetään uuden resurssin luontiin. POST-pyyntö palauttaa http-
statuksen HTTP-statuksen 201. POST-pyyntö ei ole turvallinen eikä idempotentti. Se
tekee palvelimelle uuden resurssin ja kaksi peräkkäistä POST-pyyntöä saavat aikaan
sen, että kahdella eri resurssilla on samat tiedot. (Friedrich 2013, 12). Uutta resurssia
luotaessa voidaan tietyissä tapauksissa käyttää PUT-verbiä, jos asiakas tietää tulevan
resurssin id:n valmiiksi. Yleensä kuitenkin suositellaan käytettävän POST-verbiä luon-
nissa. (Friedrich 2013, 13.) Toteutettavassa sovelluksessa käyttäjätili luodaan POST-
verbillä.
DELETE-verbillä poistetaan palvelimelta resurssi. Operaatio palauttaa http-statuksen
200 eli OK. DELETE on idempotentti. Jos resurssi poistetaan ja kutsu tehdään uudel-
leen on lopputulos silti aina sama: resurssi on poistunut palvelimelta. (Friedrich 2013,
13.)
15
Kuvio 9. Käyttäjän tietojen haku
Kuviossa 9 on havainnollistettu käyttäjän tietojen haku palvelimelta. Puhelin lähettää
palvelimelle pyynnön 1, jonka http-metodi on tyyppiä GET. Sitä käytetään REST filo-
sofian mukaan resurssin tietojen hakuun. Url-osoite on muodossa
http://server.com/user/[id]. Tässä tapauksessa id:n kohdalle on laitettu arvo 5, kun
halutaan hakea käyttäjän tiedot, jolla luullaan olevan id arvolla 5. Tämän jälkeen palve-
limen tehtävänä on hakea tietokannasta kyseinen käyttäjä, jos se on mahdollista.
Jos käyttäjää ei löydy (pyyntö 2B) palauttaa palvelin HTTP-statuksen 404 , joka kertoo
puhelimelle ettei kyseistä käyttäjää ole olemassa (taulukko 3). Puhelin voi tehdä vir-
heilmoituksen. Kun käyttäjä löytyy, palauttaa palvelin HTTP-statuksen 200, joka tar-
koittaa että pyyntö on ollut onnistunut. Mukana tulee JSON-muodossa käyttäjän tiedot.
Puhelin voi tämän jälkeen esimerkiksi näyttää kyseiset tiedot näytöllä tai tallentaa ne
puhelimen muistiin.
16
Taulukko 3. HTTP-status koodit (W3)
Status Nimi Kuvaus
200 OK Pyyntö on suoritettu onnis-
tuneesti.
201 CREATED Pyyntö on suoritettu onnis-
tuneesti ja uusi resurssi on
luotu
401 UNAUTHORIZED Pyyntö tarvitsee autentikaa-
tion ja kirjautuminen on
ollut virheellinen
404 NOT FOUND Resurssia ei löydy
500 INTERNAL SERVER
ERROR
Palvelimella on tapahtunut
virhe joka estää pyynnön
suorittamisen
3.6 JSON
JSON:a käytetään kommunikointiin puhelimen ja palvelimen välillä. JSON tulee sa-
noista JavaScript Object Notation. Se on nykyään yleisimmin käytetty formaatti raja-
pinnoissa. Syy sen yleistymiseen XML:n ohi on, että se on paljon helpommin luettavis-
sa oleva formaatti niin ihmisen silmälle kuin koneellekin ja se on alustasta riippumaton
joten sen välityksellä voi kommunikoida monenlaiset eri sovellukset. (Wright 2013, 46.)
JSON:a käytetään paljon ulkoisissa palveluissa. koska sitä voidaan käyttää monen eri
domainin välillä. JSON on nopea ja kevyt ja sitä voi käyttää monen eri ohjelmointikie-
len kanssa. (Wright 2013, 96.) JSON-formaatissa on neljä mahdollista tietotyyppiä:
merkkijonot, numerot, boolean ja null). Tiedot voivat olla kahdessa eri muodossa, joko
oliona tai taulukkona. (IETF 2006.)
17
Oliot esitetään JSON-formaatissa kaarisulkeiden sisällä, jokainen attribuutti pilkulla
toisestaan erotettuina. Attribuutin nimi täytyy olla yksilöllinen ja sille löytyy kuvaava
arvo. Attribuutin nimen tarvitsee olla merkkijono eli string. Taulukot ovat hakasulkei-
den sisällä ja taulukon alkiot on eroteltuina pilkuilla toisistaan. Merkkijonot täytyy olla
lainausmerkkien sisällä, numerot ovat ilman lainausmerkkejä. (IETF 2006.)
{
”firstname”: ”Tuukka”,
”lastname”: ”Tallgren”,
”city”: ”Helsinki”
}
Kuvio 10. JSON-olio
Kuviossa 10 on esimerkkinä JSON-olio. Objective-C:ssä JSON tallennetaan yleensä
NSDictionary muodossa. Jos yllä oleva esimerkki olisi tallennettu NSDictionaryksi olisi
oliossa oleva etunimi mahdollista hakea kirjoittamalla contact[@”firstname”]. Tässä
tapauksessa ”firstname” on avain ja kyseinen komento palauttaisi arvon ”Tuukka”.
{
”contacts”: [ {
”firstname”: ”Tuukka”,
”lastname”: ”Tallgren”,
”city”: ”Helsinki”
},
{
”firstname”: ”Matti”,
”lastname”: ”Mattinen”,
”city”: ”Espoo”
}
]
}
Kuvio 11. JSON-taulukko
18
Kuviossa 11 on esitetty JSON-muotoinen taulukko ja ”contacts” avaimen sisällä on
kaksi alkiota. Taulukko täytyisi käydä läpi silmukalla. Silmukka ottaisi jokaisen alkion
omaksi oliokseen ja tästä oliosta saataisiin sitten haettua avaimella attribuutin arvo.
19
4 Toteutus
4.1 Yleiskuvaus sovelluksen ominaisuuksista ja käytetyt tekniikat
Työssä toteutettiin sovellus, jolla voidaan vastata 360 asteen kyselyyn. Käyttäjän on
mahdollista käyttäjätilin luotuaan ja sen varmistettuaan vastata kysymysryhmiin jaotel-
tuihin kysymyksiin. Kyselyn lopussa käyttäjän vastaukset lähetetään palvelimelle. Käyt-
täjä pystyy kutsumaan muita henkilöitä vastaamaan kyselyyn valitsemalla osoitekirjasta
henkilöitä, joille kysely lähetetään. Henkilöitä laitetaan eri rooleihin (kollegat, alaiset,
esimies, ystävät ja asiakkaat), jotta saadaan laaja käsitys arvioitavan henkilön osaamista.
Palvelin lähettää sähköpostiviestinä tai tekstiviestinä kutsun valituille yhteystiedoille.
Kun kyselyyn on tullut tarpeeksi vastauksia voi käyttäjä hakea palvelimelta raportin.
Raportissa on laskettuna eri roolien keskiarvotulokset. Käyttäjä voi tarkastella kysymyk-
siin tulleita vastauksia selaamalla niitä yksittäin. Raporttiin on toteutettu lisäksi listaus-
näkymä, josta pääsee suoraan tiettyyn kysymykseen. Käyttäjä voi katsella kenelle kysely
on lähetetty logi-sivun kautta. Kysymyksiä voidaan selata etukäteen info-sivulla olevas-
ta linkistä.
Sovelluksessa käytettävät tekniikat olivat vain Objective-C ja Xcode. Xcodesta käytet-
tiin uusinta saatavilla olevaa versiota, Xcode 5.0. Ulkopuolisia kirjastoja ei sovelluksessa
käytetty, koska toteuttavat asiat olivat suhteellisen yksinkertaisia ja Applen tarjoama
SDK sisälsi asiat, joilla sovelluksen pystyi toteuttamaan.
Sovellus kehitettiin MacBook Air (Late 2013) –tietokoneella ja käyttöjärjestelmänä oli
Mac OS X Mavericks. Käytetyistä käsitteistä löytyy selitykset Liitteestä 1.
4.2 Aloitusnäkymä
Sovellus avautuu näkymään, joka on kuviossa 12, kun käyttäjä on painanut FD360-
ikonia työpöydältään. Sovellus on toteutettu välilehtien avulla. Eri toiminnoille on omat
välilehtensä, ja niiden toimintaa ohjaa UITabBarController. Välilehdet ovat info-sivu,
kyselyyn vastaaminen, kyselyn lähettäminen kontakteille, raportti ja asetukset-sivu. Jo-
kaista välilehteä varten on tehty oma näkymä eli ViewController, joka ohjaa välilehdellä
20
tapahtuvaa toiminnallisuutta. Välilehtipalkki pysyy aina näkyvissä riippumatta siitä,
missä näkymässä käyttäjä on.
Aloitusnäkymässä on näkyvillä tuotteen logo, seliteteksti ja nappi, josta pääsee etukä-
teen selaamaan kysymyksiä. Kun käyttäjä painaa kysymysnapista, ohjautuu hän toiseen
ViewControlleriin. Kyseessä on niin sanottu ”push segue”, joiden avulla voidaan siirtyä
ViewControllereiden välillä. Käytännössä tämän siirtymän pystyy toteuttamaan Story-
boardin avulla. Napista on vedetty Storyboardissa viiva kysymyksiä käsittelevään
ViewControlleriin. Storyboard huomaa, että kyseessä on ”push”-siirtymä ja kun napista
painetaan näkymä vaihtuu.
Kuvio 12. Ohjelman aloitusnäkymä
Kysymykset on luokiteltu kuuteen eri luokkaan. Kysymykset näyttävä ViewController
on toteutettu käyttämällä UITableViewControlleria eli taulukkonäkymää. Storyboardis-
ta on valittu UITableView:n tyyliksi ”grouped”, jolloin kysymykset voidaan jakaa erilli-
siin lohkoihin kysymysryhmien mukaan. Lohkojen yläpuolelle on koodissa määritetty
headerit eli otsikot. Käyttäjä pystyy näin etukäteen näkemään minkälaisia kysymyksiä
kyselyssä kysytään.
21
Koska Storyboardissa oli määritelty edellisestä näkymästä push segue ja kysymys-
näkymä on laitettu NavigationControllerin alle, tekee Xcode automaattisesti navigointi-
palkkiin napin, josta pääsee takaisin sovelluksen aloitusnäkymään. Ei siis tarvitse erik-
seen määrittää nappia tai actionia, jolla pystyisi palaamaan edelliseen näkymään.
4.3 Käyttäjän rekisteröityminen
Käyttäjän tarvitsee luoda käyttäjätili, jos hän haluaa lähettää kyselyn eteenpäin. Tilin
luominen onnistuu asetuksista. Jos käyttäjätiliä ei luotaisi, ei pystytä varmistamaan sitä
kenen nimissä kyselyä tehdään. Sovellus lähettää varmistussähköpostin annettuun
osoitteeseen ennen kuin kyselyä pystyy lähettämään muille henkilöille.
Asetukset-välilehti on toteutettu UITableView:llä, mutta solujen tyypit ovat staattisia.
Tällöin ei näkymälle tarvitse määrittää cellForRowAtIndexPath ja muita UITableView
delegaten muuten vaatimia metodeita, koska solujen sisältö ei muutu, vaan ne tehdään
Storyboardin avulla. Storyboardissa on tehty soluun UILabel, jossa lukee kentän nimi ja
UITextFieldit joihin käyttäjä kirjoittaa nimensä ja sähköpostiosoitteensa.
Asetuksissa on kolme toimintoa: tilin luonti, uudelleen varmistuslinkin lähetys ja oman
tilin asetusten muuttaminen. Storyboardissa on määritetty jokaiselle solulle segue eli
siirtymä kyseisiin ViewControllereihin. Koska asetuksia ohjaava ViewController on
laitettu UINavigationControllerin alle tekee se automaattisesti alisivuille takaisin-
nappulat.
Rekisteröitymislomakkeessa on kentät etunimelle, sukunimelle ja sähköpostiosoitteelle.
Kun käyttäjä painaa ”Save”-napista sovellus ottaa kyseisistä kentistä tiedot. Koodissa
on täytynyt sitoa Storyboardissa luodut tekstikentät ja muuttujat toisiinsa, jotta arvoja
pystytään ottamaan käyttöliittymässä tulleista arvoista. Tämä onnistuu määrittelemällä
muuttujat IBOutlet-tyyppisiksi ja kytkemällä Storyboardissa tekstikentät kyseisiin muut-
tujiin. Storyboardin Assistant Editor –näkymästä voidaan yksinkertaisesti vetää viivat
koodissa määriteltyihin luokkien muuttujiin. Näin luodaan yhteys käyttöliittymän ja
koodin välille.
22
Kun ohjelma on saanut arvot, tekee se niistä NSDictionaryn ja muodostaa JSON:in,
joka lähetetään serverille. Vastauksena tulee joko http-status created, jolloin käyttäjätili
on hyväksytty tai HTTP-status 500, jos ei onnistu. Asynkronisen tiedonsiirron vaatimat
callback-metodit on toteutettu. Virheen tapahtuessa virheen käsittely tehdään didFail-
WithError-metodissa, onnistuneessa tapauksessa mennään didFinishDownloading-
metodiin. Jos tiedonsiirrossa tapahtuu virhe tai tiedot ovat virheellisiä, tulee virheilmoi-
tus, jossa kehotetaan kokeilemaan rekisteröitymistä myöhemmin uudelleen.
Onnistuneesta tilin luonnista tehdään UIAlertView:llä ilmoitus, jossa kehotetaan tarkis-
tamaan sähköposti, jossa on varmistuslinkki. Varmistuslinkki vie selaimeen ja tätä pai-
namalla tili aktivoituu. Kun käyttäjä painaa OK, ohjataan hänet NavigationControllerin
avulla takaisin asetukset-sivulle.
Vastauksena palvelimelta tullut käyttäjäolio tallennetaan puhelimen tietoihin käyttämäl-
lä NSUserDefaultsia. Muut ViewControllerit pystyvät näin tietämään, kuka käyttäjä on
kyseessä. Esimerkiksi yhteystietojen lähettämisessä ja raportin katselussa tarvitsee tietää
kuka käyttäjä on lähettämässä kyselyä ja kenen tuloksia katsellaan. Jos käyttäjätiliä ei ole
luotu eikä puhelimen muistista löydy käyttäjätunnusta ei kyseisiä ominaisuuksia pysty
käyttämään.
4.4 Omien tietojen muuttaminen
Käyttäjällä on mahdollisuus muuttaa omia tietojaan asetuksista. Muutettavia tietoja ovat
etunimi, sukunimi ja sähköpostiosoite. Muokkaussivulle ei pääse, jos puhelimen muis-
tista ei löydy tietoa käyttäjätilistä. Tieto tarkistetaan NSUserDefaultsista. Tilin puuttu-
misesta ilmoitetaan alert-ikkunalla ja kehotetaan luomaan tili. Kun tilin tiedot on saatu
haettua puhelimen muistista, voidaan tietoja alkaa muuttamaan. Käyttöliittymä on to-
teutettu UITableView:llä. Kun kenttiin on kirjoitettu arvot sovellus tarkistaa että ne
ovat hyväksyttäviä. Puuttuvista tiedoista ilmoitetaan virheilmoituksella. Kaikkien tieto-
jen ollessa oikein sovellus lähettää palvelimelle uudet tiedot tekemällä PUT-requestin.
23
Vastauksena tulleen JSON:n perusteella uudet tiedot päivitetään näytölle tai tehdään
virheilmoitus jossa kerrotaan että tiedot olivat väärin ja kehotetaan korjaamaan ne.
4.5 Kyselyyn vastaaminen
Kyselyyn vastatakseen käyttäjä valitsee välilehtipalkista ”Self evaluation” välilehden.
Välilehdellä on näkyvissä info-teksti, jossa kerrotaan miten kyselyyn vastaaminen toi-
mii. Alapuolella on nappula, jota painamalla kyselyyn vastaaminen lähtee käyntiin. Ky-
symysvaihtoehdot on toteutettu UITableView:lla. Vaihtoehtoja on viisi, ja ne ovat sa-
mat jokaiseen kysymykseen. Kerrallaan pystyy valitsemaan yhden vastauksen. Kun
käyttäjä on painanut jotain vastausvaihtoehdoista, tunnistaa UITableView sen didSe-
lectRowAtIndexPath-metodin avulla. Tähän metodiin perustuu suurin osa kyselyn lo-
giikasta. Vastausvaihtoehdoille löytyy aina vastaava rivi UITableViewsta. Käyttäjän
valitsema rivi tallennetaan taulukkoon, joka on tyyppiä NSMutableArrayhin. Taulukon
tarvitsee olla mutable, koska vastausvaihtoehtoa täytyy pystyä muuttamaan.
Kun käyttäjä on valinnut jonkun vaihtoehdon, siirtyy sovellus automaattisesti seuraa-
vaan kysymykseen (Kuvio 13). Kysymykset ovat tallennettuna NSDictionaryyn, josta
ne saadaan haettua avaimen avulla. Avaimena toimii tässä tapauksessa kysymyksen nu-
mero. Sovellus päivittää seuraavan kysymyksen kysymyksille varattuun tekstikenttään.
Kyselyn ylälaidassa on palkki, josta pystyy seuraamaan kyselyn etenemistä. Palkki on
toteutettu käyttämällä UIProgressViewta. Siihen pystyy visuaalisesti määrittämään mis-
sä kohtaa kysely on menossa. Kyselyssä on 50 kysymystä, joten sovellus tietää missä
kohtaa ollaan menossa, kun jaetaan kysymyksen indeksi kaikkien kysymysten määrällä.
Sovelluksessa on täytynyt ottaa huomioon, että palkkia päivitetään ainoastaan silloin,
kun käyttäjä vastaa kysymykseen, jossa ei jo ole vastausta.
Kun käyttäjä on vastannut ensimmäiseen kysymykseen aktivoituu previous-nappi.
Käyttäjällä on mahdollisuus selata omia vastauksiaan taaksepäin ja eteenpäin. Jo vastat-
tujen kysymysten valinta tapahtuu tekemällä checkmark riville. Checkmark näkyy Ku-
viossa 13 sinisellä ensimmäisessä solussa. Koko riviä ei voi Applen sääntöjen mukaan
24
valita. Kun käyttäjä vaihtaa vastaustaan, poistetaan ensin checkmark ja sitten laitetaan
uudelle riville. Edelliseen kysymykseen mentäessä sovellus ottaa NSMutableArraysta
löytyvän vastauksen arvon ja valitsee UITableViewsta sitä vastaavan rivin. Käyttäjällä
on mahdollisuus vaihtaa vastaustaan. Tällöin sovellus korvaa vastauksista löytyvän ar-
von käyttäjän uudella vastauksella. Next-nappia painettaessa sovellus valitsee seuraavan
vastauksen arvon. Nappiin on asetettu rajoite, että kysymyksissä pääsee eteenpäin aino-
astaan seuraavaan vastaamattomaan kysymykseen. Nappien asetuksista on otettu pois
valinta ”Highlighted adjusts image”, näin nappi ei välähdä kun sitä painetaan.
Kuvio 13. Kyselyyn vastaaminen käynnissä
Kaikkiin kysymyksiin vastattuaan käyttäjällä aukeaa näkymä, jossa on nappi, jota pai-
namalla vastaukset tallentuvat puhelimeen. Käyttäjällä on vielä mahdollisuus tarkastella
vastauksiaan navigoimalla ”previous” ja ”next”-napeilla. Koska kysymykset ja vastauk-
set ovat NSString muodossa eli merkkijonoja, saadaan ne helposti tallennettua NSU-
serDefaultsiin. Sinne tallennetaan vastuksia kerännyt NSMutableArray.
25
Kun vastaukset on tallennettu puhelimeen, lähettää sovellus ne eteenpäin palvelimelle.
Käyttäjän antamia vastauksia tarvitaan tulosten laskennassa. Edellytyksenä on, että
palvelimelta löytyy kyselylle luotu instanssi. Kyselyn alullepanija ja vastaajat tarvitsee
sitoa samaan instanssiin. Instanssi voidaan luoda kahdessa vaiheessa: joko kun käyttäjä
on vastannut kyselyyn tai kun hän on lähettämässä kyselyä eteenpäin vastaajille vastat-
tavaksi.
Koska käyttäjä voi milloin tahansa lopettaa ohjelman suorituksen tai sulkea sen mo-
niajovalikosta, täytyy jokaisen vastauksen jälkeen tallentaa käyttäjän vastaukset puheli-
meen. Ohjelma pysyy suspended-tilassa käyttöjärjestelmän määrittämän ajan, jonka
jälkeen se siirretään background-tilaan tai sen toiminta voidaan jopa lopettaa kokonaan
, jos on tarvetta muille resursseille (Harrison 2013). Sovellus tarkistaa viewDidLoad-
metodissa ,onko kyselyyn vastaaminen kesken hakemalla NSUserDefaultsista sinne
tallennetun taulukon käyttäjän antamista vastauksista. Sovellus katsoo taulukon pituu-
den perusteella monesko kysymys on menossa ja laittaa käyttäjän seuraavaan vastaa-
mattomaan kysymykseen.
4.6 Kyselyn lähettäminen kontakteille
Kysely on mahdollista lähettää eteenpäin puhelimen yhteystiedoista löytyvien henkilöi-
den vastattavaksi. Viestit lähettää FeedbackDialogin palvelin, jolloin käyttäjän puheli-
mella ei tule laskua. Palvelin lähettää joko tekstiviestin tai sähköpostin. Viesti, joka läh-
tee vastaajille sisältää info-tekstin ja linkin kyselyyn. Vastaajat vastaavat kyselyyn se-
laimessa. FeedbackDialog on hoitanut palvelinpäänohjelmoinnin ja selaimessa täytettä-
vän kyselyn toteuttamisen.
Käyttäjän on mahdollista lisätä henkilöitä viiteen eri roolilaatikkoon. Roolit ovat esi-
mies, alaiset, ystävät, kollegat ja asiakkaat. UITableViewssä näkyy rivejä, joista paina-
malla päästään eri roolien lisäysvalikkoon. Kun käyttäjä valitsee jonkun rivin, siirtyy hän
push seguen avulla seuraavaan näkymään. Seguen mukana menee tieto siitä mistä rooli-
laatikosta käyttäjä on painanut. Näin sovellus osaa lisätä henkilöitä oikeisiin laatikoihin.
Lisäyssivun ylälaidassa on nappi, jota painamalla saadaan valittua henkilöitä lisättäväksi.
26
Kun ohjelma käynnistetään ensimmäisen kerran kysyy ohjelma lupaa yhteystietojen
käyttämiseen. Se on iOS:n sisäänrakennettu ominaisuus: jos lupaa ei anneta ei henkilöi-
tä pystytä lisäämään.
Kun käyttäjä on antanut luvan yhteystietojen käyttämiseen voidaan henkilöitä alkaa
lisätä roolilaatikoihin. ABPeoplePickerNavigationControlleria käyttämällä henkilöiden
yhteystietoja voidaan siirtää puhelimen tietokannasta ohjelman käytettäväksi. Sovelluk-
sen täytyy erikseen määrittää mitä tietoja henkilöstä halutaan. Tässä tapauksessa yhteys-
tiedoista otetaan henkilön etunimi, sukunimi, sähköpostiosoite ja puhelinnumero. Tie-
dot tallennetaan NSMutableDictionaryyn, jonka sisällä on NSMutableArrayt eri rooleil-
le. Näin niitä pystytään käyttämään kahdesta eri paikasta. Singleton käyttää dis-
patch_once metodia, joka tarkoittaa sitä, että kyseinen NSDictionary alustetaan ainoas-
taan yhden ja ainoan kerran koko ohjelman suorituksen aikana (Nahavandipoor 2013,
373).
Kuvio 14. Kyselyn lähettäminen yhteystiedoille
27
Lisäysnäkymän ylävalikossa on Edit-nappi, jolla henkilöitä pystytään poistamaan listas-
ta. Kun haluaa palata päänäkymään, se onnistuu yläpalkista olevassa navigointinapista.
Koska lisätyt henkilöt ovat lisätty singletonissa olevaan NSMutableDictionary pystyy
päänäkymä näyttämään kuinka monta henkilöä laatikossa kyseisellä ajanhetkellä on.
Sovellus tarkistaa, ettei henkilöä ole lisätty samaan laatikkoon useampaa kertaa. On
mahdollista, että henkilö voi olla kahdessa eri laatikossa, mutta samassa roolissa ei voi
olla useampaa kertaa. Jokaisella henkilöllä on AddressBookissa yksilöllinen ABRecor-
dRef, jolta voi kysyä henkilön id:tä. Sovellus tallentaa id:n ja katsoo ettei useampaa ker-
taa tallennu sama id. Jos käyttäjä yrittää lisätä henkilöä joka on jo laatikossa mitään ei
tapahdu.
Lisätyistä henkilöistä näkyy ainoastaan yksi henkilö kerrallaan ja lukumäärä siitä kuinka
monta henkilöä laatikossa on. Tähän ratkaisuun on päädytty, koska vaakasuunnassa on
melko vähän tilaa eikä kaikkien henkilöiden luettelu ole näin mahdollista.
Koska käyttäjä voi lopettaa ohjelman suorituksen milloin tahansa, täytyy lisätyt henkilöt
tallentaa väliaikaisesti puhelimen muistiin. NSUserDefaultsiin on tallennettu NSDic-
tionary, jossa henkilöt ovat. Tallennus tehdään henkilöiden lisäämisen yhteydessä. So-
vellus tarkistaa viewDidLoad-metodissa löytyykö puhelimesta keskeneräistä kyselyä. Jos
löytyy niin henkilöiden tiedot laitetaan näkyviin. Ilman tätä tarkistusta kerran lisätyt
henkilöt häviäisivät, kun sovellus on ollut tarpeeksi kauan taustalla.
Kun käyttäjä on lisännyt haluamansa henkilöt laatikkoihin on hän valmis lähettämään
kyselyn eteenpäin. Sovelluksen käyttämän palvelinpään rajapinta on toteutettu REST-
palveluna.. Käyttäjän valitsemista yhteystiedoista muodostetaan tietojen lähetystä varten
JSON. Käyttäjän on tarvinnut ennen tietojen lähettämistä antaa nimensä ja sähköpos-
tiosoitteensa, jotta palvelin on pystynyt luomaan käyttäjälle käyttäjätilin. Tili täytyy var-
mistaa varmistussähköpostin avulla.
Käyttäjä painaa Send-ikonia, jolloin sovellus vielä kysyy käyttäjältä varmistusta. Varmis-
tus tehdään käyttämällä UIAlertView:tä, joka tekee hälytysikkunan. Ikkunassa on kaksi
nappia: OK ja cancel. Käyttäjän valitsema vaihtoehto saadaan toteuttamalla metodi
28
clickedButtonAtIndex. Napeille on annettu numeeriset arvot. OK-napin arvo on 1 ja
cancelin 0. Koska samassa näkymässä voi tulla useita hälytysikkunoita tämä erottelu ei
aina riitä. Alerteille voi antaa attribuutiksi tagin, jolloin pystyy tunnistamaan mikä alert
on ollut kyseessä.
Tietojen lähettäminen palvelimelle tehdään asynkronisesti NSURLConnectionin avulla.
NSURLConnectioniin liitetään NSMutableURLRequestin avulla palvelimen osoite ja
tarvittavat parametrit. Pyynnössä pystytään mm määrittämään headerit, http-metodit ja
kuinka kauan sovellus odottaa, että pyyntö on onnistunut. Jos tiedonsiirrossa tapahtuu
virheitä NSURLConnection kutsuu didFailWithError-metodia, johon on määritelty
mitä tapahtuu kun yhteys epäonnistuu. Lopulta, jos kaikki on mennyt hyvin, kutsutaan
connectionDidFinishLoading-metodia, jolla pystytään määrittämään mitä tapahtuu kun
yhteys on onnistuneesti saatu vietyä loppuun.
Tietojen lähettämisen jälkeen poistetaan puhelimen muistista keskeneräinen taulukko
henkilöistä. Vastauksena tulleiden http-headereiden ja JSONin avulla pystytään anta-
maan erilaisia virheilmoituksia tai reagoimaan onnistuneeseen pyyntöön.
Yläpalkissa olevaa info-ikonia painamalla, avautuu käyttäjälle pieni info-teksti. Se on
toteutettu asettamalla näkymä UITableView:n headeriin. Näkymässä on ”close”-
painike, jolla infotekstin saa pois näkyvistä.
Käyttäjän on mahdollista katsoa kenelle kysely on lähetetty painamalla yläpalkissa ole-
vaa logi-ikonia. Jos käyttäjä menee logi-sivulle, eikä kyselyä ole vielä lähetetty kenelle-
kään, tulee ilmoitus, jossa kerrotaan ettei kyselyä ole lähetetty vielä eteenpäin ja kehote-
taan tekemään se. Sovellus on tallentanut kyselyn lähetyksen yhteydessä puhelimen
muistiin NSUserDefaultsin taulukon, jossa on listattuna henkilöt, joille kutsu on lähe-
tetty. Tietoihin on tallennettu kellonaika ja päivämäärä, koska kutsu on lähetetty. Tämä
tehdään ainoastaan siinä tapauksessa, kun tietojen lähetys on tehty onnistuneesti. Kos-
ka tiedot on tallennettu puhelimen muistiin, pystyy kutsuja tarkastelemaan vaikka käyt-
täjällä ei olisi internet-yhteyttä saatavilla. Näin on aina saatavilla tieto siitä kenelle kutsu
on lähetetty. Sovellus hakee tiedot taulukosta ja laittaa ne käyttäjän näkyville..
29
4.7 Raportin katselu
Raportin saa haettua, kun on itse vastannut kyselyyn ja kutsutut henkilöt ovat vastan-
neet kyselyyn. Raportin katselussa käytetty pylväskaavio on toteutettu itse. Kaupallisia
vaihtoehtoja olisi ollut saatavilla, mutta ne olisivat olleet liian raskaita yksinkertaisen
kaavion tekemiselle. Palvelin on laskenut valmiiksi keskiarvot kunkin ryhmän tuloksille
ja kaikkien ryhmien keskiarvoille. Jokaiseen kysymykseen tulee siis viisi arvoa eri vastaa-
jaryhmiltä ja vastaajan itselleen antama arvosana.
Jokaisen kysymyksen tuloksia pääsee tarkastelemaan erikseen. Sivulla on kysymysteksti
ja sen alapuolella generoitu kaavio tuloksista. Kaavion vasemmalla puolella on luokitel-
tu roolit. Käyttäjän nimi on lihavoitu ja palkki on laitettu eri väriseksi, jotta se erottuu.
Palkit on toteutettu yksinkertaisesti tekemällä kuusi erillistä UIView:tä, joiden taustaksi
on laitettu yhden pikselin levyinen taustakuva. Palkin pituus on määritetty jakamalla
ryhmän tulos maksimiarvosanalla ja kertomalla tämä arvo palkin maksimipituudella.
Taustakuva on gradientti, joten se näyttää hieman tyylikkäämmältä. Kyselyn alullepani-
jan palkki on erivärinen kuin vastaajien jotta se erottuisi paremmin.
Tuloksia voi selata eteen- tai taaksepäin vetämällä sormea oikealle tai vasemmalle. Kos-
ketuksen tunnistus on tehty käyttämällä UISwipeGestureRecognizeria. Sen avulla on
hyvin yksinkertaista tunnistaa kosketus ja se mihin suuntaan se on tehty. Kumpaakin
suuntaa varten on tarvinnut tehdä oma tunnistaja. Attribuutiksi on määritetty, että toi-
nen tunnistaa kosketuksen oikealle ja toinen vasemmalle. Ensimmäisen kysymyksen
teksti ja tulokset on laitettu valmiiksi esille ja alustettu apumuuttuja, joka kertoo missä
kysymyksessä ollaan menossa. Kun käyttäjä vetää sormeaan vasemmalle huomaa kos-
ketuksen tunnistaja, että käyttäjä haluaa navigoida kysymyksiä eteenpäin.
Sivun vaihtoon on toteutettu siirtymä käyttämällä CATransitiotinia. Se hyödyntää Core
Animation –frameworkkia. Tarjolla on useita erilaisia animaatioita: sivun kääntö va-
semmalle/oikealle, genieEffect, rippleEffect, suckEffect.
Actionissa muutetaan apumuuttujan arvoa yhdellä suuremmaksi ja otetaan tätä vastaa-
vat tulokset taulukosta jossa on kaikki valmiiksi lasketut tulokset. Sovellus poistaa ensin
30
näkymästä kaikki alinäkymät ja sitten piirtää uudestaan tuloksia vastaavat alinäkymät.
Sormea oikealla vedettäessä toimitaan päinvastaisesti.
Ohjelmaan on tehty rajoitukset ettei kysymyksiä voi selata taaksepäin tai eteenpäin
enempää kuin taulukossa on arvoja. Ensimmäisen tai viimeisen kysymyksen kohdalla
tehty pyyhkäisy jättää käyttäjän siihen kysymykseen.
Kuvio 15. Raportin selaaminen
Tulokset on mahdollista jakaa sähköpostilla, tekstiviestillä, Facebookkiin tai Twitteriin.
Jakotoiminnallisuus on tehty UIActivityViewControllerilla. Yläpalkkiin on tehty share-
nappi, jota kutsuttaessa tehdään UIActivityViewController, johon pystyy määrittämään
mikä on jaettava sisältö. Tässä tapauksessa se on teksti, jossa lukee tulos. Aukeavasta
palkista pystyy valitsemaan esimerkiksi Facebookin, jolloin aukeaa Kuviossa 11 näkyvä
teksti.
Tulosten katseluun on tehty lisäksi näkymä, jossa jokaista kysymystä pääsee suoraan
tarkastelemaan. Yläpalkissa on nappi ”browse” jota painamalla aukeaa listamainen nä-
kymä kysymyksistä. Tämä on käytännössä sama näkymä kuin kysymysten katselu etukä-
teen info-sivulta. Ainoana eroavaisuutena on se, että kysymyksistä painettaessa ohjataan
31
käyttäjä suoraan kysymyksen tulokseen. Kysymykset on ryhmitelty eri ryhmiin ja kun
jostain taulukon solusta painetaan, tehdään push segue ViewControlleriin, jossa tulok-
set näytetään. Siirtymän mukana lähetetään tieto siitä mikä kysymys on ollut kyseessä.
Tässä tapauksessa koko kysymysteksti siirretään siirtymän mukana yksittäisen kysymyk-
sen tuloksen näyttävälle näkymälle. Näkymään on laitettu tekstikenttä johon suoraan
siirretään kysymyksen teksti. Tulokset katsotaan NSUserDefaultsista johon on tallen-
nettu arvot.
4.8 Monikielisyys
Sovellus tullaan toteuttamaan neljällä eri kielellä: suomeksi, englanniksi, saksaksi ja hol-
lanniksi. Xcodessa voidaan projektin asetuksista määrittää mitä kieliä sovellus tukee.
Kieliä lisätään yksitellen ja niille luodaan maakohtaiset tiedostot. Koska sekä Storybo-
ardissa, että koodin puolella voidaan asettaa teksteille arvoja tarvitaan kielitiedostoja
kaksi jokaiselle kielelle. Storyboardissa asetetuille teksteille on Main.storyboard ja koo-
dissa määritetyille teksteille Localizable.string –tiedosto. Tiedostoihin asetetaan aina
avaimeksi tietty koodi ja sitä vastaava arvo. Esimerkiksi ”Set”=”Asetukset” ja englan-
niksi ”Set”=”Settings”. Koodin puolella jokaista tekstiä kutsutaan NSLocalizedSt-
ring(@”Set”) ja näin näytöllä oleva teksti muuttuu automaattisesti käyttäjän laitteen
kielen perusteella. Käyttäjä voi vaihtaa kieltä vaikka ohjelma olisi käynnissä.
32
5 Yhteenveto
5.1 Johtopäätökset ja tulokset
Tavoitteena ollut 360 asteen palautteen toteuttava sovellus onnistui suurimmilta osin.
Sovelluksen tärkeimmät ominaisuudet kuten kyselyyn vastaaminen ja kyselyn lähettä-
minen eteenpäin yhteystiedoille saatiin toimimaan kokonaisuudessaan. Raporttiominai-
suus saatiin lähes täysin toteutettua. PDF-raportin haku jäi opinnäytetyön rajoitetun
tuntimäärän takia toteuttamatta. Sovellus kuitenkin hakee palvelimelta valmiiksi laske-
tut tulokset ja tekee niistä raportin. Tuloksia pystyy selaamaan ja on tehty oikopolku,
jolla voi mennä suoraan tiettyyn kysymykseen. Tuloksista voi jakaa linkin Facebookkiin
tai Twitteriin.
5.2 Projektin analyysi ja opinnäytetyön aikataulutus
Opinnäytetyön tekeminen aloitettiin lokakuussa 2013. Aloituskokous pidettiin 23.10. ja
tämän jälkeen työn tekeminen pääsi kunnolla alkamaan. Opinnäytetyölle oli varattu
aikaa 400h. Alkuperäinen päättymispäivä oli määritelty olemaan 15.2. Projekti pysyi
yllättävän hyvin aikataulussa ja projekti saatiin päätökseen 27.2. Tunnit menivät hieman
yli alkuperäisen rajan. Tehtyjä työtunteja tuli noin 430. Opinnäytetyön isoimmat tunti-
määrät ajoittuivat joulu- ja tammikuuhun, jolloin oli hyvä mahdollisuus saada projektia
paljon eteenpäin koulun kuukauden mittaisen joululoman aikana. Toimeksiantajan
kanssa projekti eteni hyvässä yhteistyössä.
Opinnäytetyö lähti liikkeelle Objective-C:n opettelulla. Ensiksi yritettiin muodostaa
jonkinlainen yleiskuva siitä miten sovelluksia voidaan rakentaa Objective-C:llä ja Xco-
della. Koska Xcodesta oli tullut juuri uusi versio ja iOS7 oli vasta tullut julkiseksi, oli
osittain vaikeaa päästä alkuun, kun suurin osa esimerkeistä oli vielä vanhemmille versi-
oille tehtyjä. Tietysti perusasiat eivät olleet miksikään muuttuneet, mutta esimerkiksi
Xcode näytti melko erilaiselta aiempiin versioihin ja uutta editoria opeteltaessa se vähän
vaikeutti kehitystä.
33
Sovelluksen luonti lähti käyntiin projektista, johon ensin tehtiin jokaiselle välilehdelle
oma näkymänsä. Ensimmäinen toteutettava ominaisuus oli kyselyyn vastaaminen ja
siinä käytettiin UITableViewControlleria jonka omaksuminen oli ensimmäinen askel
kohti onnistunutta sovellusta. Kun se oltiin saatu toimimaan siirryttiin vähitellen raja-
pinnan kanssa työskentelyyn. Rajapinnan kanssa töitä tehdessä pidettiin enemmän yh-
teyttä FeedbackDialogin suuntaan, koska he rakensivat rajapintaa samaan aikaan kun
ohjelma eteni. Ensin toteutettiin käyttäjätilin luontiin liittyvä toiminnallisuus. Seuraava-
na oli vuorossa yhteystietojen lähettäminen palvelimelle. Viimeisenä toteutettiin kaiken
yhteen kokoava raportti-ominaisuus. Siinä yhdistyvät sovelluksessa kyselyn täyttävän
henkilön itselleen antama arvosana ja vastaajaryhmien vastauksista lasketut tulokset.
Nämä kaikki sidotaan yhteen ja tuodaan näkyviin raportissa.
5.3 Oman oppimisen arviointi
Koska en ollut aiemmin tehnyt ohjelmia iPhonelle enkä osannut Objective-C:tä oli
alussa hieman vaikeaa hahmottaa mistä lähteä liikkeelle. Toimeksiantajan edustajalla ei
ollut kokemusta iPhone-kehityksestä, joten he eivät siinä pystyneet auttamaan. Käytän-
nössä kaikki tieto täytyi etsiä itse kirjoista tai nettiä selaamalla. Alussa tosin sain apua
kurssikaverilta, joka oli tehnyt fysiikkaan perustuvan pelin iPhonelle ja osasi auttaa
muutamissa perusasioissa. Alun vaikeuksien jälkeen kehittäminen lähti lopulta käyntiin
suuremmalla vauhdilla. UITableView:n toiminnan ymmärtäminen oli ratkaiseva askel
sovelluksen valmiiksi saamista. Melkein kaikki sovelluksessa käytettävät näkymät poh-
jautuivat UITableView:n käyttöön.
Rajapinnan suunnittelussa olin jonkin verran mukana toimeksiantajan edustajan kanssa.
He toteuttivat sen kokonaan, mutta ehdotin tiettyjä muutoksia siihen. Rajapinta ei ollut
valmiina, joten sitä tehtiin opinnäytetyön edetessä ja se ehkä vähän opinnäytetyön val-
mistumista. Kehittäjätunnuksia ei ollut alkuvaiheessa saatavilla, joten sovellusta pääsi
testaamaan puhelimessa vasta kehityksen loppuvaiheessa kun tunnukset vihdoin saatiin.
Sovellus kuitenkin näyttää simulaattorissa hieman erilaiselta kuin puhelimessa joten
esimerkiksi vasta kun puhelimesta tarkasteltiin välilehtien ikoneita huomattiin että ne
ovat aivan liian epätarkkoja puhelin Retina-näytölle. Simulaattorissa tämä ei tullut esille.
34
Kaiken kaikkiaan tuli opittua uusi kieli ja paljon käytännön asioita REST-rajapinnan
kanssa toiminnasta.
5.4 Jatkokehitys
Sovelluksen perusominaisuudet on saatu toteutettua, joten jatkokehitystä ajatellen ol-
laan hyvässä tilanteessa. Eniten jatkokehittämistä kaipaa ohjelman ulkoasu. Graafikon
tekemä suunnitelma tekisi sovelluksesta vetoavamman näköisen. Tällä hetkellä on to-
teutettu ainoastaan minimivaatimuksilla grafiikat. Jotta sovellusta voisi käyttää monelta
laitteelta, täytyisi rakentaa ominaisuus, jolla pystytään palauttamaan käyttäjätilin tiedot
toiseen laitteeseen. Käyttämällä iCloudia olisi mahdollista olla kirjautuneena monesta
laitteesta samaan aikaan. Käyttäjä ei kuitenkaan välttämättä salli sitä, jolloin täytyisi ke-
hittää lisäksi toiminnallisuus. jolla on mahdollista sovelluksen kautta pyytää käyttäjätilin
palauttamista. Tämä tarkoittaisi käytännössä näkymää, johon voi laittaa sähköpos-
tiosoitteensa ja sinne lähetettäisiin tunnuksen palauttava linkki.
Raporttiominaisuudesta jäi jatkokehitykseen pdf-raportin haku. Tarkoitus on, että pal-
velinpää generoi pdf-raportin tutkimuksen tuloksista ja puhelin saisi linkin, josta rapor-
tin voisi ladata. Tällöin itse raporttia ei tarvitse siirtää sovelluksen kautta puhelimeen,
joka olisi vähän monimutkaisempaa kuin pelkän linkin lataaminen ja avaaminen se-
laimessa. Toinen vaihtoehto on, että raportti lähetetään sähköpostilla käyttäjälle.
Ohjelmaan olisi mahdollista tehdä In App Purchase eli sovelluksen sisäinen osto. Ra-
porttiin liittyvät ominaisuudet voitaisiin laittaa maksun taakse. Sovelluksen perusomi-
naisuuksien oleminen ilmaisia saattaisi tuoda enemmän latauksia ohjelmalle. Sovelluk-
sen kaikki tiedot tallennetaan tällä hetkellä NSUserDefaultsiin, koska se vaikutti opin-
näytetyön alussa helpolta paikalta. Kuitenkin, jos tietomäärä kasvaa ja tarvitsee näyttää
monimutkaisempaa dataa olisi suositeltavampaa tallentaa tiedot käyttämällä CoreDataa
tai tietokantaa.
35
Lähteet
Apple 2012. Programming with Objective-C: Defining Classes. Luettavissa:
https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Progra
mmingWithObjecti-
veC/DefiningClasses/DefiningClasses.html#//apple_ref/doc/uid/TP40011210-
CH3-SW1 Luettu: 26.2.2014.
Apple 2013a. Write Objective-C Code. Luettavissa:
https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMap
OSX/books/WriteObjective-CCode/WriteObjective-CCode/WriteObjective-
CCode.html. Luettu: 14.1.2013.
Apple 2013b. Xcode Overview: About Xcode. Luettavissa:
https://developer.apple.com/library/ios/documentation/ToolsLanguages/Conceptua
l/Xcode_Overview/About_Xcode/about.html. Luettu 14.1.2013.
Apple 2013c. iOS Human Interface Guidelines: Icon and Image Sizes. Luettavissa:
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/
mobilehig/IconMatrix.html#//apple_ref/doc/uid/TP40006556-CH27-SW1 Luettu:
25.1.2014.
Apple 2014. Start Developing for iOS Apps Today. Luettavissa:
https://developer.apple.com/library/iOS/referencelibrary/GettingStarted/RoadMapi
OS/index.html Luettu 26.2.2014.
Fredrich, T. 2013. RESTful Services Best Practices. Pearson eCollege. Luettavissa:
https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20
Best%20Practices-v1_2.pdf Luettu: 25.2.2014.
Harrison, K. 2013. State Preservation and Restoration. Luettavissa:
http://useyourloaf.com/blog/2013/05/21/state-preservation-and-restoration.html
Luettu: 26.2.2014.
36
IETF 2006. The application/json Media Type for JavaScript Object Notation. Luetta-
vissa: https://www.ietf.org/rfc/rfc4627.txt Luettu: 25.2.2014.
Kochan, S. 2012. Programming in Objective-C. 4. Painos. Addison-Wesley Profes-
sional. Upper SaddleRiver.
Maylett, T. 2009. 360-Degree Feedback Revisited: The transition from Development to
Appraisal. Compensation & Benefits Review. Luettavissa:
http://cbr.sagepub.com/content/41/5/52 Luettu: 22.2.2014.
Nahavandipoor, V. 2013. iOS 7 Programming Cookbook. O’Reilly Media. Sebastopol.
Neuburg, M. 2013. Programming iOS7. 4. Painos. O’Reilly Media. Sebastopol.
Richardson, L & Ruby, S. 2007. RESTful Web Services. O’Reilly. Sebastopol.
W3. Hypertext Transfer Protocol -- HTTP/1.1- Status codes. Luettavissa: Lähde: W3
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Luettu: 4.2.2014.
Ward, P. 1997. 360-degree Feedback. Chartered Institute of Personnel and Develop-
ment. London.
Wright, T. 2013. Learning JavaScript: a hands-on guide to the fundamentals of modern
JavaScript. Pearson. Upper Saddle River.
37
Liitteet
Liite 1. Keskeiset käsitteet
App Store = Applen tekemä mobiilisovellusten kauppapaikka, josta sovelluksia voidaan
ladata ilmaiseksi tai maksua vastaan. Jotta sovellus saadaan hyväksyttyä App Storeen
tarvitsee sen noudattaa Applen määrittelemiä sääntöjä.
iOS = iPhonen käyttämä käyttöjärjestelmä
InterfaceBuilder = Xcodessa oleva työkalu, jolla pystyy tekemään käyttöliittymiä. Inter-
face Builderissa on valmiina komponentteja joita pystyy sijoittelemaan ruudulle.
NSMutableArray/NSArray = Taulukko. Mutable eroaa siten, että siihen lisättyä tietoa
voi jälkikäteen muuttaa.
NSMutableDictionary/NSDictionary = Kokoelma, johon voi lisätä tietoa avain/arvo-
periaatteella. Mutable eroaa siten, että siihen lisättyä tietoa voi jälkikäteen muuttaa.
NSString = merkkijono.
Objective-C = iOS-sovelluksissa käytettävä ohjelmointikieli.
Segue = Siirtymä eri näkymien välillä. Siirrytään esimerkiksi yhdestä ViewControllerista
toiseen.
Storyboard = Graafinen yleiskuva kaikista ohjelman näkymistä. Storyboardista näkee
eri näkymät ja niiden väliset suhteet.
UINavigationController = ohjaa siirtymiä näkymien välillä. Käytännössä tekee navi-
gointipalkin näkymän ylälaitaan, jolloin pystytään navigoimaan takaisinpäin.
38
UIAlertView = ilmoitusikkuna, joka tehdään kun halutaan kertoa että sovelluksessa on
tapahtunut jotain josta tarvitsee ilmoittaa. Esimerkiksi virheilmoitus kun internetyhteyt-
tä ei ole saatavilla
UITableView = Monikäyttöinen taulukkonäkymä. Taulukkonäkymän solussa voidaan
esittää esimerkiksi tekstiä tai kuvia.
ViewController = Ohjaa yhden näkymän toimintaa. Kaikki yhden näkymän toiminnal-
lisuus on yhden ViewControllerin takana.
Xcode = Applen tekemä kehitysympäristö, jolla pystyy hoitamaan koko sovelluksen
luonnin.