J2ME MIDLET PELISOVELLUKSEN SUUNNITTELU JA TOTEUTUS NOKIAN 7210 PUHELIMEEN

T a m p e r e e n A m m a t t i k o r k e a k o u l u L i i k e t a l o u s Tutkintotyöraportti J2ME MIDLET PELISOVELLUKSEN SUUNNITTELU JA TOTEUTUS NOKIAN 7210 PUHELIMEEN Satu Pietarinen

2 Tekijä(t): Koulutusohjelma(t): Tutkintotyön nimi: Satu Pietarinen Tietojenkäsittely J2ME MIDlet pelisovelluksen suunnittelu ja toteutus Nokian 7210 puhelimeen Title in English: Designing and producing the J2ME MIDlet game application for the Nokia 7210 mobile phone Työn valmistumiskuukausi ja -vuosi: tammikuu 2004 Työn ohjaaja: Paula Hietala Sivumäärä: 56 TIIVISTELMÄ J2ME on alustariippumaton ohjelmistoympäristö matkapuhelinten ja kämmentietokoneiden sovellusten kehittämistä varten. Sen avulla on mahdollista tehdä Java-kielisiä MIDlet-sovelluksia, jotka toimivat useiden eri valmistajien laitteissa. Sovellukset ovat ladattavissa päätelaitteelle Internet-verkosta tai pöytätietokoneelta. Tutkintotyö on Nokian keväällä 2003 julkaiseman MIDlet-sovelluskilpailun määrittelyn mukaan tehty pelisovellus Nokian 7210 -puhelimeen. Työn tavoitteena oli suunnitella ja toteuttaa päätelaitteella toimiva pelisovellus. Sovelluksen sisällön suunnittelussa noudatettiin pelisuunnittelun yleisiä ohjeita. Sovelluksen ulkoasun suunnittelun tavoitteena oli tehdä mobiililaitteen pienikokoiselle näytölle soveltuvaa grafiikkaa. Sovelluksesta tehtiin helppokäyttöinen ja sen käyttöliittymästä yhtenevä muiden päätelaitteen pelisovellusten kanssa. Työn toteutuksen aikana pelin toiminnallisuutta testattiin emulaattorissa ja päätelaitteella. Testaus osoittautui erittäin tärkeäksi osaksi työtä. Tutkintotyön kirjallisessa osuudessa käsitellään J2ME-arkkitehtuuria ja sen erityispiirteitä, MIDletsovelluksen sisältöä ja käytännön ohjelmointia. Kartoitusosio sisältää käyttäjän tarpeiden kartoittamisen sekä sovelluksen suunnittelulle ja toteutukselle asetettujen rajoitusten tarkastelua. Suunnitteluvaiheessa esitellään sovelluksen sisältöä, rakennetta, toiminnallisuutta, visuaalista ilmettä ja suunnittelun ongelmia. Sovelluksen toteutusosassa esitellään käytännön peliohjelmointia ja sovelluksen teossa esiintyneitä ongelmia. Pelisovellus on tutkintotyön liitteenä levykkeellä ja se on asennettavissa päätelaitteelle JAD-tiedostona. Avainsanat: J2ME MIDlet Java Ohjelmointi Pelisovellus

3 Sisällysluettelo 1 Johdanto...5 2 J2ME (Java TM 2, Micro Edition)...6 2.1 J2ME:n historia...6 2.2 J2ME:n arkkitehtuuri...7 2.3 Virtuaalikone...9 2.3.1 KVM (KiloByte Virtual Machine)...9 2.3.2 KVM:n rajoitukset...9 2.3.3 KVM ja luokkien tarkistus...10 2.3.4 Tietoturva...10 2.4 J2ME konfiguraatiot...10 2.4.1 Connected Device Configuration (CDC)...10 2.4.2 Connected Limited Device Configuration (CLDC)...11 2.4.3 CLDC kirjastot...11 2.4.4 Kansainvälisyys...13 2.4.5 Generic Connection Framework (GCF)...13...14 Kuvio 4 Esimerkki Connector-luokan käytöstä (Kontio 2002: 44)...14 2.5 Profiili...15 2.5.1 Mobile Information Device Profile (MIDP)...15 2.5.2 Record Management System ( RMS )...16 2.5.3 MIDP -käyttöliittymäluokat...18 3 MIDlet...19 3.1 MIDletin elinkaari ja metodit...19 3.2 MIDletin luominen...20 3.3 MIDlet ja Applet...23 4 Kartoitus...24 4.1 Käyttäjän tarpeet...24 4.2 Tekniset rajoitteet suunnittelulle ja toteutukselle...25 5 Pelisuunnittelu...27 5.1 Pelin sisältö...27 5.2 Pelin rakenne...28 5.3 Sovelluksen visuaalinen ilme...29 5.4 Suunnittelun ongelmat...30 6 Sovelluksen toteutus...31 6.1 Toiminnallisuuden kuvaus...31 6.2 Sovelluksen käyttöliittymä...31 6.2.1 Screen...32 6.2.2 Display...32 6.2.3 Form...33 6.2.4 Menu -valikot ja käskyt...34 6.2.5 Image...35 6.2.6 Double Buffering...35 6.2.7 Canvas...36 6.3 Spritet...39 6.3.1 Animointi...40 6.3.2 PNG (Picture Network Graphic)...41 6.3.3 Spriten piirto...41 6.3.4 Törmäystarkistus...42 6.4 Optimointi...42 6.5 Monisäikeinen pelin ohjelmointi...43 6.5.1 Thread-luokan metodit...44 6.5.2 Runnable-rajapinta...47 6.5.3 Säikeiden prioriteetit...48 6.5.4 Säikeen tilat...48 6.5.5 Synkronointi...49 6.5.6 wait() ja notify() -metodit...49 6.5.7 Timer...50 6.6 Ongelmat sovellusta tehtäessä...50 6.7 Testaus...51

6.8 Sovelluksen lataaminen päätelaitteelle...52 7 Havaintoja...53 8 Johtopäätöksiä...54 Liitteet...57 Liite 1: Sanasto...57 API (Application Programming Interface) kokoelma luokkia joita voidaan sovelluksessa käyttää. Yhdessä ne muodostavat kirjaston, jota kutsutaan API- rajapinnaksi...57 CLDC (Connected Limited Device Configuration) on J2ME-konfiguraatio. CLDC määrittelee Java-kielen, Java virtuaalikoneen (KVM), rajapinnat (API:t) syöttö- ja tulostustoimintojen suorittamiseen, perus verkkotuen (GCF) ja tietoturvan...57 J2ME (Java 2, Micro Edition) on kokoelma määrityksiä ja teknologioita jotka tukevat Java-kieltä. J2ME kattaa laajan valikoiman laitteita kämmentietokoneista auton navigaatio järjestelmiin. J2ME jaetaan konfiguraatioihin ja profiileihin, jotka määrittelevät Java ympäristön tietyn tyyppiselle laitteelle....57 MIDlet on Java-kielinen MIDP-sovellus joka toimii päätelaitteella....57 MIDlet Suite (eli JAR) sisältää useamman MIDlet-sovelluksen pakattuna yhteen JAR-tiedostoon. Päätelaitteella voi olla useita JAR-paketteja...57 4

5 1 Johdanto Tutkintotyö on Nokian keväällä 2003 julkaiseman sovelluskilpailun määrittelyjen mukaan tehty Java-kielinen (MIDlet) pelisovellus Nokian 7210 puhelimeen, joka tukee Java 2 Micro Edition (J2ME) -teknologiaa. Sovellus sai Nokian määritysten mukaan olla kooltaan enintään 64 kilotavua. Pelin grafiikan tuli soveltua käytettäväksi päätelaitteen 128x128 pikselin näytöllä ja päätelaite käyttää KVM-virtuaalikonetta, MIDP 1.0 -profiilia ja CLDC 1.0 -konfiguraatiota. Tutkintotyön tavoitteena oli tehdä päätelaitteessa toimiva MIDlet pelisovellus ja selvittää, miten MIDlet-ohjelmointi eroaa pöytäkoneelle tehdyn pelisovelluksen ohjelmoinnista. Työssä esitellään J2MEteknologiaa ja käytännön peliohjelmointia. Työn on tarkoitus olla käytännön apuna uusille MIDlet-ohjelmoijille ja tuoda esiin niitä asioita, joihin tulisi kiinnittää huomiota matkapuhelinten pelisovelluksia kehitettäessä. Tutkintotyö on tehty sovelluskehittäjän näkökulmasta. Tutkintotyönä tehty sovellus on toimintapeli nimeltä SpaceBall ja se on tehty laitesuuntautuneille käyttäjille, joille on tärkeää, että puhelimessa on mahdollisimman paljon erilaisia ominaisuuksia kuten esim. pelejä. Se soveltuu pelattavaksi kaiken ikäisille henkilöille ja molemmille sukupuolille. Pelin toteutus on tehty englannin kielellä. Sovelluksen peli-idea ja käyttöliittymä ovat yksinkertaiset ja helppokäyttöiset. Pelin toimintaidea perustuu puhelimen näppäimistöltä tapahtuvaan käsi - silmä koordinaatiokykyyn. Sovellus on testattu toimivaksi pöytäkoneella Nokian 6310i MIDP SDK Beta 0.9 -emulaattorissa ja Nokian 7210 puhelimessa. Tutkintoyö aloitettiin tutustumalla matkapuhelimissa pelattaviin peleihin, J2ME MIDlet ohjelmointia käsittelevään kirjallisuuteen ja Borlandin JBuilder-ohjelmaan, johon on liitetty Nokia Developer's Suite kehitysympäristö. Tutkintotyössä perehdytään ensin J2ME teknologiaan ja sen arkkitehtuuriin. Tämän jälkeen tutkintotyössä käsitellään tutkintotyönä tehdyn pelisovelluksen suunnittelun ja toteutuksen eri vaiheita, sekä ohjelmointitekniikoita.

6 2 J2ME (Java TM 2, Micro Edition) 2.1 J2ME:n historia Ensimmäisissä matkapuhelimissa oli mukana ohjelmisto, jota käyttäjä ei itse pystynyt muokkaamaan. Matkapuhelimien ohjelmat eivät olleet yhteensopivia muiden laitevalmistajien kanssa, eivätkä käyttäjän siirrettävissä tai päivitettävissä kuten tietokoneissa. Kun haluttiin käyttöön uusi sovellus, oli ostettava kokonaan uusi laite. Matkapuhelinten laitevalmistajat ja Sun Microsystems olivat samaa mieltä siitä, että alustasta riippumaton Java-ohjelmointikieli mahdollistaisi samojen ohjelmien käyttämisen eri valmistajien laitteissa. Matkapuhelimet asettivat kuitenkin vähäisten resurssiensa takia omat vaatimuksensa ja niihin täytyi suunnitella aivan uusi Java-ympäristö. Sunin ensimmäinen ratkaisu oli kehittää sen aikaisesta (1997) alustasta Java AE:sta (Java Application Environment) kolme uutta teknologiaa käytettäviksi erilaisissa laitteissa. Nämä teknologiat olivat Personal Java AE, Embedded Java AE sekä Java Card. Jokaiselle laitekategorialle tehtiin sopiva virtuaalikone ja rajoitettiin mukana tulevien luokkakirjastojen määrää. Näiden teknologioiden ongelmana kuitenkin oli, että ne eivät mainittavasti tukeneet ohjelmistojen siirrettävyyttä eri laitevalmistajien laitteiden välillä (Sun 1998). Vuonna 1998 Sun julkisti Java 2:n ja kehitysympäristöt jaettiin kuvan (Kuvio 1) mukaisesti kolmeen erilaiseen kokonaisuuteen niiden käyttötarkoituksen mukaan. Nämä Java alustat ovat: J2EE (Java 2 Enterprise Edition), J2SE (Java 2 Standard Edition) ja J2ME (Java 2 Platform, Micro Edition). (Muchow 2002.) Server Workstation, Laptop Communicator, Net TV Pager, SmartPhone Smartcard PDA J2EE J2SE CDC J2ME CLDC Java Language HotSpot JVM CVM KVM CardVM Kuvio 1 Java arkkitehtuuri ja kohde alustat (Kontio 2002: 4)

7 J2SE tunnettiin aiemmin pelkkänä Javana. Se on suunniteltu työasemien sovellusten kehittämiseen ja se sisältää kaikki perus Java-luokat. J2EE on näistä kolmesta kehitysympäristöstä laajin. Se on kehitetty palvelimille ja yritysten kokonaisvaltaisten palvelujen tietojenkäsittelyyn. Näitä palveluja ovat mm. online-kaupankäynti, asiakashallinta- ja kirjanpito-järjestelmät. J2EE sisältää myös sisäänrakennetun tuen servlet-, JSP- ja XML-ohjelmoinnille. J2ME on modulaarinen Java-ympäristö, joka on suunniteltu laitteille, joiden käytössä on vähän muistia, pieni prosessori ja pienikokoinen näyttö kuten esim. kämmentietokoneet ja matkapuhelimet (Muchow 2002). Kuviosta 1 näkyy myös, että J2EE:tä käytetään palvelimien toimintojen kehittämiseen, kun taas J2SE ja J2ME on suunniteltu kehittämään yksittäisiä sovelluksia tai ratkaisuja, jotka käyttävät J2EE-teknologialla tehtyjä palvelin-sovelluksia (Kontio 2002: 4). 2.2 J2ME:n arkkitehtuuri J2ME jakaa laitteet eri ryhmiin horisontaalisesti laitteistoresurssien mukaan, sekä vertikaalisesti niiden käyttötarkoitusten mukaan. Samassa vertikaalisessa ryhmässä olevilla laitteilla voi kuitenkin olla erikokoiset laitteistoresurssit, jolloin ne eivät kuulu samaan horisontaaliseen ryhmään. J2ME:n päämääränä on tukea jo markkinoilla olevia laitteita siten, että jokaisen laitteen Java-ympäristö sisältäisi vain ne ominaisuudet, joita kyseisellä laitteella tarvitaan. Tästä syystä J2ME:stä ei ole olemassa vain yhtä toteutusta. J2ME on Java-ympäristö, joka kootaan osista laitteen ominaisuuksien ja käyttötarkoituksen mukaan. Näitä osia ovat konfiguraatiot ja profiilit, jotka perustuvat edellä kuvattuun laitteiden luokitteluun. (Kontio 2002: 5.) J2ME-konfiguraatio määrittelee virtuaalikoneen, joka toimii kuvan (Kuvio 2) mukaisesti laitteiston varusohjelmakerroksen päällä. Konfiguraatio määrittää myös joukon luokkakirjastoja, jotka sisältävät vain kaikki tarpeelliset ja olennaiset luokat. J2ME-konfiguraatioita on kaksi (Sun 2000a): Connected Device Configuration (CDC) ja Connected Limited Device Configuration (CLDC).

8 Sama konfiguraatio voi kattaa käyttötarkoitukseltaan aivan erityyppisiä laitteita, kuten esim. matkapuhelimia ja pesukoneita. Ei ole tarkoituksenmukaista, että pesukoneen ohjelmia käytettäisiin matkapuhelimessa tai toisinpäin. Koska konfiguraatio ei huomioi erilaisten laitteiden erikoistarpeita, tätä tarkoitusta varten on kehitetty profiilit. Profiilit määritellään aina tietyn konfiguraation päälle ja ne laajentavat konfiguraation luomaa Java-ympäristöä. (Sun 2000a.) Sovelluskerros (Midlet) Profiilikerros (MIDP) Konfiguraatiokerros (CLDC) Virtuaalikonekerros (KVM) Laitteiston varusohjelmistokerros Kuvio 2 J2ME arkkitehtuuri (Mahmoud 2002: 4) Profiilit määritellään aina JCP:n (Java Community Process) kautta yhdessä Sun:in, sekä laitevalmistajien kanssa (Sun 2001a). Profiili määrittelee rajapinnat ja luokkakirjastot, joita tarvitaan hyödyntämään kaikki kyseisen laitteen tarjoamat ominaisuudet (Sun 2000b). Profiili mahdollistaa myös ohjelmien siirrettävyyden laitteesta toiseen. Ohjelma luodaan profiilin päälle ja se käyttää vain ja ainoastaan tämän profiilin tarjoamia rajapintoja. Ohjelma toimii kaikissa laitteissa joissa kyseinen profiili on toteutettu. Profiilien lisäksi laitevalmistajalla on mahdollisuus luoda omia rajapintoja. Niiden avulla ohjelmoija pääsee käsiksi laitteen ominaisuuksiin, joita yksikään konfiguraatio tai profiili ei tue. Tämänkaltaisten rajapintojen käyttö tosin vaikeuttaa ohjelman siirrettävyyttä toisiin laitteisiin. (Sun 2002a.) Matkapuhelinten käyttämälle CLDC-konfiguraatiolle on tällä hetkellä määritelty ainoastaan yksi profiili: MIDP (Mobile Information Device Profile). MIDP-määritys antaa laite- ja ohjelmistovalmistajille varsin vapaat kädet tehdä minimivaatimukset täyttävä toteutus. Päätelaitteelta täytyy löytyä vähintään: verkkoyhteys, tietueille perustuva tallennusjärjestelmä ja lcdui (liquid crystal display user interface) -määritystä noudattava käyttöliittymä (Muchow 2002).

9 2.3 Virtuaalikone 2.3.1 KVM (KiloByte Virtual Machine) J2ME tarvitsee sovellusten suorittamiseen Java-alustan eli virtuaalikoneen. Matkapuhelimissa käytettävä virtuaalikone on nimeltään KVM (KiloByte Virtual Machine). Se on pienikokoinen ja helposti siirrettävä virtuaalikone (Kontio 2002: 29). Siitä on jätetty pois joitakin muiden virtuaalikoneiden ominaisuuksia, joiden ei ole katsottu olevan tarpeellisia kohdelaitteissa. Näin virtuaalikonetta tukevan luokkakirjaston joukkoa on saatu pienennettyä, joka puolestaan mahdollistaa virtuaalikoneen päälle sijoittuvan konfiguraation (CLDC) toimimisen pienemmässä tilassa (Sun 2000a). KVM on kirjoitettu C-kielellä, joten se on helposti siirrettävissä erilaisille alustoille, joille löytyy C-kielinen kääntäjä. KVM voi ladata luokkia luokka hakemistosta tai JAR (Java Archive) -tiedostoista (Mahmoud 2002: 22). 2.3.2 KVM:n rajoitukset KVM-virtuaalikoneesta on olemassa useita eri versioita. Kun KVMvirtuaalikone toimii CLDC-konfiguraation kanssa on siitä poistettu ominaisuuksia, jotka ovat joko liian kalliita toteuttaa tai joiden olemassaolo toisi tietoturva-ongelmia (Mahmoud 2002: 21): CLDC:tä käyttävillä laitteistolla ei ole tukea liukuluvuille. CLDC perustaisissa sovelluksissa ei siis voida käyttää liukulukuja, kuten float tai double. CLDC ja MIDP sisältävät tuen säikeille, koska suurin osa MIDPsovelluksista perustuu säikeille. Ne eivät kuitenkaan tue säie ryhmiä tai ns. demoni säikeitä (daemon threads). CLDC rajapinta ei sisällä Object.finalize()-metodia, eli resursseja ei voida sulkea ennen kuin olio on kerätty roskiin. Ajonaikaisille virheille CLDC määrittelee vain kolme virheluokkaa: java.lang.error, java.lang.outofmemoryerror ja java.lang.virtualmachineerror. Ei-ajonaikaiset virheet käsitellään laitteesta riippuen joko sulkemalla sovellus, tai uudelleen käynnistämällä laite. KVM ei sisällä JNI:tä (Java Native Interface), koska se veisi liikaa muistia kohdelaitteessa ja toisi lisäksi tietoturva ongelmia. Tämä aiheuttaa sen, ettei sovelluksia ohjelmoitaessa voida käyttää mitään natiivirajapinnan kuvakkeita, tai esim. puhelimen soittoääniä. Java-virtuaalikoneessa, joka tukee CLDC:tä, täytyy olla sisäänrakennettu luokkalataaja, jota ei voi tietoturvan takia

ylikirjoittaa tai korvata käyttäjän toimesta. Sovellus ei voi vaikuttaa siihen kuinka luokat ladataan, koska luokkalataajan voi määritellä ja tuottaa vain ajonaikainen järjestelmä. 10 2.3.3 KVM ja luokkien tarkistus J2SE:n Java-virtuaalikoneessa on luokkatarkistaja, joka on vastuussa ajonaikana virheellisten luokkien hylkäämisestä. Tämä tarkistus on aikaa vievää ja siihen tarvitaan 35-110 kilotavua ajonaikasta muistia. KVM:n muistin koko on 50-80 kilotavua. Rajoitetun muistin takia KVM:n suunnittelijat päättivät siirtää suurimman osan tarkistuksesta päätelaitteen sijaan palvelin-koneelle, josta sovellus ladataan. Tätä toisella laitteella tapahtuvaa tarkistusta kutsutaan esitarkistukseksi (preverification). Esitarkistuksen tuloksena saadut luokka-tiedostot sisältävät ylimääräistä tietoa varmistamassa, että ajonaikainen tarkistaja voi suorittaa työnsä minimaalisella muistilla ja mahdollisimman nopeasti. (Mahmoud 2002: 22.) 2.3.4 Tietoturva CLDC tietoturva on tiukempi kuin J2SE:ssä. Tämä tietoturvamalli on jakautunut kahteen alueeseen: virtuaalikonetason ja sovellustason tietoturvaan. Virtuaalikonetasolla edellisessä luvussa kuvattu esitarkistus varmistaa, ettei luokan tavukoodi sisällä viittauksia virheellisiin muistipaikkoihin, eikä sovellus pysty vahingoittamaan laitetta, jolla ne toimivat. Sovellustasolla KVM sisältää yksinkertaisen ns. hiekkalaatikko tietoturvamallin, jossa sovellus toimii suljetussa ympäristössä. Tällöin sovellus voi kutsua vain laitteen tukemia luokkia. (Mahmoud 2002: 23.) 2.4 J2ME konfiguraatiot 2.4.1 Connected Device Configuration (CDC) CDC-konfiguraatio on tarkoitettu lähinnä seuraavan sukupolven laitteisiin, joissa on paljon laitteistoresursseja ja monipuoliset hallintalaitteet. Tällaisia laitteita ovat mm. television digitaalivastaanottimet, Internet televisiot, kehittyneemmät kommunikointivälineet sekä autojen viihde- ja navigointi-järjestelmät. (Sun 2001b.)

11 2.4.2 Connected Limited Device Configuration (CLDC) CLDC on konfiguraatio laitteille, joilla on rajoitetummat resurssit kuin CDC:tä käyttävillä. Tyypillisiä tämän kaltaisia laitteita ovat matkapuhelimet, PDA- ja hakulaitteet. Näille laitteille on ominaista, että niiden käyttömuistin koko on 160-512 kilotavua, näyttö on kooltaan pieni ja tehonlähteenä käytetään akkua (Muchow 2002). Laitteita valmistetaan markkinoille suuria määriä ja laitteistoresurssit on pidettävä pieninä, jotta laitekustannukset pysyisivät mahdollisimman alhaisina (Sun 2000b). CLDC:n tarkoituksena oli luoda Java-ympäristö, joka toteuttaa suurimman osan Java standardista, mutta tarvitsee toimiakseen mahdollisimman vähän muistia. CLDC määrittelee tällä hetkellä sitä käyttäville laitteille seuraavat toiminnallisuudet: Java-kieli, virtuaalikone, ydinkirjastot, rajapinnat erilaisten syöttö- ja tulostustoimintojen suorittamiseen, perus verkkotuki ja tietoturva (Mahmoud 2002: 20). CLDC-konfiguraation tärkeimpinä ominaisuuksina on pidetty langattomien verkkoyhteyksien tukemista ja dynaamista Java-ohjelmien latausta laitteille. Lisäksi CLDC mahdollistaa laitteille usean tyyppisten siirrettävien sovellusten rakentamisen. Tällaisia sovelluksia ovat mm. hyötyohjelmat ja verkkosovellukset (esim. uutisten luku ja sähköposti sovellukset). Yksi merkittävin ryhmä J2ME:lle koodattavista ohjelmista ovat pelit (Kontio 2002: 6). CLDC ei määrittele käyttöliittymää, sitä miten ohjelmat asennetaan, käynnistetään tai poistetaan laitteilta (ohjelmistojen elämänkaari). Se ei anna tukea eri hallintalaitteille (kosketusnäytöt ym.), eikä tapahtuman käsittelylle. Nämä ovat ominaisuuksia, joita toteuttavat CLDC:n päälle sijoittuvat profiilit (Sun 2000b). 2.4.3 CLDC kirjastot CLDC kirjaston ohjelmointirajapinnat (API) voidaan jaotella luokkiin, jotka ovat osajoukko J2SE API:sta ja luokkiin, jotka on kehitetty erityisesti CLDC:tä varten. J2SE rajapinnat vaativat noin 20 megatavua muistia, joka ylittää pienikokoisten laitteiden muistin kapasiteetin. Tästä syystä CLDC käyttää vain Taulukossa 1 lueteltuja luokkia, jotka periytyvät J2SE alustasta (Mahmoud 2002: 23). Matkapuhelinten virheenkäsittely ominaisuudet ovat rajoitetut ja ne reagoivat eri tavalla virhetilanteisiin: yksi laite antaa virheilmoituksen, kun taas toinen suorittaa automaattisen ohjelman keskeytyksen (Kontio 2002: 43). Kaikkien J2SE-alustasta perittyjen luokkien täytyy käyttää täsmälleen samoja poikkeuksia kuin alkuperäisten J2SE-luokkien, joten CLDC-konfiguraatiolle periytyvät myös Taulukossa 2 luetellut poikkeusja virheluokat.

Erityisesti CLDC:tä varten suunnitellut rajapinnat ovat: javax.microedition.io, joka määrittelee GCF (Generic Connection FrameWork) -tietoliikenne toteutuksen ja javax.microedition.lcdui, joka sisältää korkean tason käyttöliittymäluokat (Kontio 2002: 40). Taulukko 1 CLDC-konfiguraation perityt J2SE luokat 12 Paketti java.lang java.io java.util Luokka Boolean, Byte, Character, Class, Integer, Long, Math, Object, Runnable, Runtime, String, StringBuffer, System, Thread, Throwable ByteArrayInputStream, ByteArrayOutputStream, DataInput, DataInputStream, DataOutput, DataOutputStream, InputStream, InputStreamReader, OutputStream, OutputStreamWriter, PrintStream, Reader, Writer Calendar, Date, Enumeration Hashtable, Random, Stack Time, Vector PACKAGE CLASS Taulukko 2 CLDC-konfiguraation perityt J2SE poikkeus- ja virheluokat Ta Paketti Luokka java.lang java.io java.util ArithmetricException, ArrayIndexOutOfBoundsException, ArrayStoreException, ClassCastException, ClassNotFoundException, Error, Exception, IllegalAccessException, IllegalArgumentException, IllegalMonitorStateException, IllegalThreadStateException, IndexOutOfBoundsException, InstantiationException, InterruptedException, OutOfMemoryException, NegativeArraySizeException. NumberFormatException, NullPointerException, RuntimeException, SecurityException, StringIndexOutOfBoundsException, VirtualMachineError EOFException, IOException, InterruptedIOException, UnsupprotedEncodingException, UTFDataFormatException EmptyStackException, NoSuchElementException

13 2.4.4 Kansainvälisyys Laitteissa, jotka käyttävät CLDC:tä tulisi huomioida kansainvälisyys. Sovelluksen tulee varautua eri kieliversioille, fonteille jne. Käytännössä tämä tarkoittaa sitä, että sovelluksen ohjelmakoodiin ei tulisi kirjoittaa suoraan esim. käyttäjälle ohjelman aikana ilmestyviä ilmoituksia koskien käytettävää kieltä. Kielivalintojen tulisi tapahtua käyttäjän toimesta ikonien tai valikon kautta. CLDC:lle kansainvälistäminen tarkoittaa, että järjestelmän tulee tukea Unicode-merkkijärjestelmää, johon on olemassa tuki InputStreamReader ja OutputStreamWriter luokissa. (Kontio 2002: 43-44). 2.4.5 Generic Connection Framework (GCF) CLDC:n verkkoyhteyksien muodostaminen perustuu Generic Connection Framework (GCF) -kehykseen. Tässä kehyksessä kaikki verkkoyhteydet muodostetaan Connector-luokan open(string)-metodin avulla (Kontio 2002: 44). Verkkoyhteyden tieto siirretään yksinkertaisena merkkijonona ja yhteyden tyyppiä on helppo vaihtaa tarvittaessa. Näin sovelluksen koodi pysyy samana, riippumatta siitä mitä protokollaa käytetään (Mahmoud 2002: 27). Metodia open(string) käytetään kuvan (Kuvio 3) esimerkkien mukaisesti seuraavalla syntaksilla: Connector.open("protokolla:osoite;parametrit"); Connector.open( http://www.abslue.com ); Connector.open( socket://127.0.0.1:8080 ); Connector.open( datagram://127.0.0.1:8090 ); Connector.open( comm.:0;baudrate=9600 ); Connector.open( file://j2me.doc ); //HTTP //socket //datagrammi //sarjaportti //tiedosto Kuvio 3 Esimerkkejä protokollien käytöstä (Kontio 2002: 44) Connector-luokkaa käytetään kuvan (Kuvio 4) mukaisesti. Metodin open(string) epäonnistuminen laukaisee IOException-poikkeuksen ja avatut yhteydet suljetaan finally-lohkossa.

14 Connection c = null; try{ c = Connector.open( http://www.webpage.com ); } catch (IOException io{} //yhteys suljetaan finally{ try{ if (c!=null) c.close(); } catch (IOException io){} } Kuvio 4 Esimerkki Connector-luokan käytöstä (Kontio 2002: 44) Connector-luokan lisäksi GCF sisältää kuvassa (Kuvio 5) näkyvät erikoistuneet rajapinnat. Connection rajapinta sisältää vain kaksi metodia: open() ja close(). Rajapinnat perivät niiden yläpuolella olevien rajapintojen metodit. Connection StreamConnectionNotifier InputConnection OutputConnection DatagramConnection StreamConnection ContentConnection Kuvio5 Generic Connection Framework -rajapinnat (Kontio 2002: 45) InputConnection-rajapinnan metodeilla avataan tietoa lukemista varten, OutputConnection-metodeilla tietoa kirjoitetaan ja StreamConnectionmetodi käyttää edellä mainittuja metodeja perimällä ne. StreamConnectionNotifier-rajapinnan metodit odottavat ensin yhteyden saamista, jonka jälkeen ne palauttavat StreamConnection-rajapinnan. ContentConnection-rajapinta käsittelee yhteyden metatietoja ja DataGramConnection-rajapinta lähettää, tai vastaanottaa datagrammeja. (Kontio 2002: 45.)

15 CLDC ei sisällä tapaa toteuttaa mitään verkkoyhteyteen tarvittavaa protokollaa, vaan se on jätetty profiilin tehtäväksi. MIDP-profiili lisää HttpConnection-rajapinnan, joka mahdollistaa HTTP-yhteyden. MIDPprofiili voi myös tukea socket-kantoja tai datagrammeja (Internet verkon paketti). Näitä käytettäessä on kuitenkin muistettava, että sovellus ei välttämättä toimi kaikissa päätelaitteissa, tai kaikissa verkoissa. (Kontio 2002: 44.) 2.5 Profiili 2.5.1 Mobile Information Device Profile (MIDP) J2ME:tä varten on kehitetty Mobile Information Device -profiili (MIDP), jonka ensisijaisena tehtävänä on määritellä rajapinta ohjelmistokehittäjiä varten. MIDP sijoittuu päätelaitteelle kuvan (Kuvio 6) mukaisesti. MIDP-sovellusta kutsutaan nimellä MIDlet. Sovellukset voivat olla yksittäisiä MIDlettejä tai ns. MIDlet Suite, joka sisältää useamman MIDlet-sovelluksen pakattuna yhteen JAR-tiedostoon. Päätelaitteella voi olla useita JAR-paketteja, mutta tietyn sovelluksen kaikkien luokkien on oltava samassa paketissa (Kontio 2002: 47). Kuvio 6 MIDP arkkitehtuuri (Mahmoud 2003) MIDP:tä käyttävien laitteiden resursseja rajoittavat: laskentateho, muistin määrä, verkkoyhteyden nopeus ja laatu, sekä näytön koko. MIDP Specification 1.0 -määrityksessä on sitä käyttäville laitteille asetettu minimirajat. Laitteiden näyttöjen tulee täyttää seuraavat vaatimukset: näytön koon on oltava vähintään 96x54 pikseliä, värimäärän kuvauksen tulee olla vähintään 1-bittinen (musta-valkoinen), pikselin muodon on oltava 1:1 ja lisäksi laitteessa tulee olla yhden/kahden käden näppäimistö, tai kosketusnäyttö. Laitteissa tulee olla 128 kilotavua pysyvää muistia MIDP-komponenteille, 8 kilotavua pysyvää muistia ohjelmien

16 tallentamaa tietoa varten ja 32 kilotavua muistia Javan ajonaikaiseen käyttöön. Lisäksi laitteissa tulee olla langaton kaksisuuntainen verkkoyhteys ja rajoitettu kaistanleveys. (Fox & Verhovsek 2002: 171-172.) MIDP sisältää kaikki CLDC:n käyttämät luokat ja lisäksi MIDP-profiilia varten määriteltyjä kirjastoja. Yksi tärkeimmistä kirjastoista on javax.microedition.midlet. Se sisältää MIDlet luokan, joka on kaikkien MIDlettien perusta. Muita tärkeitä kirjastoja ovat: javax.microedition.lcdui, jossa ovat käyttöliittymäluokat, javax.microedition.rms, joka sisältää tietueille perustuvan tallennusjärjestelmän (RMS eli Record Management System) ja javax.microedition.io, jota tarvitaan verkkoliikennettä varten (Kontio 2002: 55). MIDP ei määrittele sovelluksen liitäntää laitteeseen, päästä päähän tietosuojamallia, systeemitason tai laitteen alkuperäisen valmistajan (OEM, Original Equipment Manufacturer) määrittelemiä tarpeita sovellukselle, eikä mitään tiettyä toteutusta. 2.5.2 Record Management System ( RMS ) MIDP-profiilissa on huomioitu sovellukset, jotka tarvitsevat tiedoille katoamatonta muistia. MIDP määrittelee yksinkertaisen tietueille perustuvan RMS (Record Management System) -tallennusjärjestelmän. Sen luokat ja rajapinnat sijaitsevat javax.microedition.rms-paketissa. Käytännössä RMS-tietokanta on tiedosto, joka koostuu tietueista. Pääsy tietokantaan on vain samaan JAR-pakkaukseen kuuluvilla MIDleteillä. (Kontio 2002: 137.) RMS:n tieto on tavutaulukko, jonka koko voi vaihdella tietueittain. RMS ei rajoita sitä, millaista tietoa tietueisiin tallennetaan. Jokaiselle tietueelle määritellään yksilöllinen tunniste (recordid), joka on voimassa koko tietovaraston elinajan. Tietueita lisättäessä samaa tunnistetta ei käytetä uudelleen, joten yksittäisiä tietueita on helppo jäljittää. Tunnisteen avulla tietueita voidaan muuttaa ja poistaa. Tunnisteiden tietotyyppi on Integer ja ensimmäisen luotavan tietueen arvo on yksi. Tietueita lisättäessä, tunnisteen arvoa kasvatetaan ykkösellä (Mahmoud 2000). Tietovarasto luodaan, suljetaan ja poistetaan RecordStore-luokan metodeilla. Uuden tietovaraston luonti ja jo olemassa olevan tietovaraston avaus tehdään kuvan (Kuvio 7) mukaisesti openrecorstore()-metodilla, jolle välitetään kaksi parametria (String, boolean) (Kontio 2002:138). Ensimmäinen parametri kertoo luotavan, tai avattavan tietovaraston nimen. Nimi saa sisältää enintään 32 merkkiä. Toisen parametrin true-arvolla pyydetään metodia luomaan uusi tietovarasto, jos sitä ei ensimmäisen parametrin nimellä ole olemassa.

17 Avattaessa jo olemassa olevaa tietovarastoa, parametrin arvoksi asetetaan false. Tällöin on käytettävissä myös poikkeusten käsittely -luokka RecordStoreNotFoundExeption (Kontio 2002: 143). Tietovarasto suljetaan metodilla closerecordstore(). Tätä metodia käytettäessä on huomattava, että sitä on kutsuttava yhtä monta kertaa kuin metodia jolla tietovarasto avattiin. Muutoin tietovarasto jää avoimeksi (Mahmoud 2000). RecordStore rs = RecordStore.openRecordStore("nimi", false); byte[] tietue; //tallennettava tieto tavukoodeina int recordid; try { //tallennetaan tietue tietovarastoon recordid = rs.addrecord(tietue, 0, tietue.length); //haetaan tietue esille tietovarastosta tietue = rs.getrecord(recordid); //muutetaan tietuetta //kirjoitetaan tietue takaisin tietovarastoon rs.setrecord(recordid, tietue, 0, tietue.length), } catch (Exception e) { //käsitellään mahdolliset poikkeukset } Kuvio 7 Tietueiden käsittely RMS-tietovarastossa Tietuejoukon käsittelyä varten määritellään RecordStore-luokassa neljä perusmetodia: addrecord(), getrecord(), setrecord() ja deleterecord(). Tallentaminen suoritetaan koko tietue kerrallaan tavukoodina addrecord()-metodilla. Metodi palauttaa luodun tietueen tunnisteen. Tieto haetaan esille tallennusjärjestelmästä getrecord()-metodilla, jolle välitetään parametrina halutun tietueen tunniste. Metodilla setrecord() voidaan korvata jo olemassa oleva tietue uudella. (Kontio 2002: 137.) RMS-tallennusjärjestelmässä ei ole mahdollista muuttaa vain tietueen tiettyä osaa (Mahmoud 2000). Tietuetta muutetaan lukemalla ensin koko tietue tietovarastosta, jonka jälkeen tehdään muutokset ja lopuksi tietue kirjoitetaan tallennusjärjestelmään vanhan tietueen päälle setrecord()-

18 metodilla kuvan (Kuvio 7) mukaisesti. 2.5.3 MIDP -käyttöliittymäluokat MIDP-sovellusten käyttöliittymävaatimukset poikkeavat pöytätietokoneista, koska matkapuhelimilla ei ole vastaavia syöttölaitteita ja niiden näyttöjen koko on pienempi. MIDP ei käytä AWT:tä (Abstract Windowing Toolkit) graafisten käyttöliittymien luonnissa, koska se on liian raskas. Lisäksi AWT on suunniteltu käytettäväksi osoitinlaitteen kanssa ja sellainen on vain harvoilla MIDP-päätelaitteilla (Kontio 2002: 47). MIDP:n mukana tulee oma grafiikkarajapinta, joka on jaettu korkean tason (high-level) ja matalan tason (low-level) rajapintoihin. Korkean tason rajapinta on suunniteltu liike-elämän sovelluksia varten, joiden asiakasohjelmia ajetaan MID (Mobile Information Device) -laitteissa. Sovelluksen logiikka, tietokannat ja palvelut sijaitsevat palvelimilla ja MIDP-laitteella on vain kevyt asiakas-sovellus (Kontio 2002: 47). Näissä sovelluksissa tärkeintä on siirrettävyys. Korkean tason komponenttien ulkonäkö on kiinteä, eikä ohjelmoija voi siihen vaikuttaa. Ohjelmalla ei myöskään ole tarkkaa tietämystä laitteen hallinta- tai syöttölaitteista. Korkean tason käyttöliittymä-komponentteja toteuttavat luokat periytyvät luokasta javax.microedition.lcdui.screen. Matalan tason (low-level) grafiikkarajapinta on tarkoitettu sovelluksille, joissa tarvitaan graafisten elementtien tarkkaa sijoittelua ja ohjausta näytöllä. Pelit ovat tyypillisiä sovelluksia, jotka käyttävät matalan tason käyttöliittymäkomponentteja (Riggs, Taivalsaari ja VandenBrink 2001). Pienen näytön koon vuoksi puhelinlaitteilta puuttuvat myös pöytäkoneille ominaiset ikkunointijärjestelmät. MIDP-profiilin käyttöliittymärajapinnan keskeisin luokka on Screen, joka kapseloi 1 ja järjestää graafiset komponentit, sekä kohdistaa käyttäjän syötteet laitteiston avulla. Screen-luokan ilmentymästä käytetään nimitystä näkymä. MIDP-sovellus voi koostua useista näkymistä, mutta vain yksi näkymä voi olla kerrallaan aktiivisena päätelaitteen näytöllä. Näkymät tulisi toteuttaa siten, että näkymä on mahdollisimman yksinkertainen ja sisältää graafisia komponentteja vain sen verran kuin tehtävän suorittaminen vaatii (Mahmoud 2001). MIDP-käyttöliittymä API määrittelee neljä erilaista näkymätyyppiä: tekstiruutu-, lista, -viesti- ja valikkonäkymät. Nämä luokat totutetaan kuvan (Kuvio 8) mukaisesti Screen-luokasta perityistä luokissa: TextBox, List, Alert ja Form. 1 Oliotekniikan tukema tietojen määrittelytapa, jossa osaa tiedoista pääsee käyttämään vain olioiden avulla.

19 Kuvio 8 MIDP käyttöliittymäluokat (Kontio 2002: 58) 3 MIDlet 3.1 MIDletin elinkaari ja metodit MIDlet on Java-kielellä tehty MIDP-sovellus. MIDlet suoritetaan Javavirtuaalikoneen alaisuudessa päätelaitteella. Kannettavilla päätelaitteilla ei ole komentokuorta, jolla käyttäjä voi ohjata ohjelman suoritusta kuten pöytätietokoneissa. MIDlet-sovellusten ohjaus tapahtuu päätelaitteelle sijoitetun AMS (Application Management Software) -ohjelmiston avulla. Se ohjaa koko MIDletin elinkaaren toiminnot. AMS toimii samalla tasolla kuin laitteen muutkin varusohjelmistot ja se tekee yhteistyötä Java-virtuaalikoneen kanssa. (Kontio 2002: 157.) Kaikki MIDletit periytyvät kantaluokasta MIDlet, joka sijaitsee javax.microedition.midlet-paketissa. MIDlettien kantaluokka määrittelee kolme metodia, joiden avulla toteutetaan MIDletin elinkaaren aikaiset tilasiirtymiset. Nämä metodit ovat: startapp(), pauseapp() ja destroyapp(boolean), jotka täytyy ylikirjoittaa jokaisessa MIDletissä (Kontio 2002: 48). MIDlet voi itse pyytää tilasiirtymistä seuraavien metodien avulla: resumerequest(), notifypaused() tai notifydestroyed(). Kuvassa (Kuvio 9) näkyvät MIDletin mahdolliset tilat ja tilasiirtymiset.

20 Constructor Paused ResumeRequest() startapp() pauseapp() notifypaused() Active DestroyApp() notifydestroyed() DestroyApp() Destroyed Kuvio 9 MIDletin tilat ja sallitut tilasiirtymiset (Kontio 2002: 48) 3.2 MIDletin luominen MIDletin luominen sisältää viisi vaihetta (Kontio 2002: 51): MIDletin ohjelmakoodin kirjoitus, kääntäminen, esitarkistus, pakkaus JAR- ja JAD-tiedostoiksi. Tutkintotyössä käytetty Nokian Developers Suite antaa ohjelmointia varten kuvan (Kuvio10) mukaisen MIDlet rungon. Jokaisen MIDletin täytyy periytyä MIDlet luokasta. Valmiiseen runkoon on lisätty myös javax.microedition.lcdui-paketti, joka sisältää MIDP:n käyttämät käyttöliittymäluokat (Kontio 2002: 50). Kuvan (Kuvio 10) esimerkin SpaceBall-luokka toteuttaa CommandListener-rajapinnan, joka seuraa korkean tason käyttöliittymäluokkien tapahtumia. CommandListener rajapinta määrittää vain commandaction(command, Displayable) metodin (Kontio 2002: 50).