• Portfolion etusivulle
• OLO-sessiot
• Esseet- ja käsitekartat
• Ohjelmointitehtävät
• Ohjelmointiprojekti
• Jälkisanat

• Projektin aihe-ehdotus
• Projektisuunnitelma
• Projektin loppuraportti
• Lähdekoodi
• JavaDoc-dokumentaatio
• Projektin luokkahierarkia

• 1. Kalenteri-ohjelman kuvaus
• 1.1 Kalenterin toiminnallisuus
• 1.2 Käyttöliittymän kuvaus
• 1.2.1 Kalenterinäkymät
• 1.2.2 Merkinnät ja käyttöliittymä
• 2. Kalenterin tekninen toteutus
• 2.1 Toteutusympäristö ja käytetyt ohjelmointivälineet
• 2.2 Teknisen toteutuksen pääpiirteet
• 2.2.1 Merkintojen hallinnointi ja luominen
• 2.2.2 Päivä- ja viikkonäkymien toteutus
• 2.3 Ongelmat, puutteet ja kehitysideat
• 2.3.1 Merkinnän keston esittäminen
• 2.3.2 Tooltip-tekstit taulukoille
• 2.3.3 Ohjeistus
• 2.3.4 Muita huomioita
• 2.3.3 Ohjeistus
• 3. Kokemukset projektista
• 3.1 Suunnittelu vastaan lopullinen toteutus
• 3.2 Bugit ja minä
• 3.3 Työskentely
• 4. Yhteenveto
• 5. Kalenteri-sovelluksen koodi

1. Kalenteri-ohjelman kuvaus

Kalenteri-sovelluksen tarkoituksena on säilyttää käyttäjän lisäämiä merkintöjä sekä tarjota käyttäjälleen mahdollisuuden selata kalenteria päivä-, viikko- ja vuosinäkyminä. Kalenterin sisältämät merkinnät voi tallentaa ja sovelluksen avatessaan ottaa taas uudelleen käyttöön.

Merkinnät sisältävät luonnollisesti ajankohdan ja viestin. Merkinnän voi asettaa tärkeäksi, jolloin käyttäjälle tarjotaan mahdollisuus hakea listaksi kaikki tärkeäksi merkitsemänsä merkinnät. Merkintöjä voi hakea myös tekstin osalla, jos on päässyt unohtumaan, minne merkintänsä on sijoittanut. Merkinnälle voi myös asettaa keston, jos se on tarpeen muistaa, mutta keston tarkastelu ei onnistu perinteisen käsikalenterin tapaan. Merkinnän keston toteutuksen kanssa oli hieman ongelmia, josta lisää ongelmat kohdassa.

1.1 Kalenterin toiminnallisuus

Kalenterin toiminnallisuudessa voidaan eriyttää kaksi eri kokonaisuutta: kalenterin näkymien rakentaminen ja merkintöjen kanssa toimiminen. Toiminnallisuus perustuu hyvin pitkälti käyttäjän käyttöliittymän kanssa toimimiseen, joten paremman kuvan kalenterin toiminnallisuudesta saa seuraavasta luvusta.

Kalenteri-sovelluksen sisäisistä toiminnallisuuksista voin listata muutamia: kalenterin sisältämien merkintöjen tallennus tiedostoon ja luku tiedostosta, merkintöjen teksti- ja tärkeys-hakualgoritmit, uuden merkinnän luominen ja uusien kalenterinäkymien luominen.

1.2 Käyttöliittymän kuvaus

Kalenteri-sovelluksen peruskäyttöliittymä rakentuu valikoista sekä ikkunan keskellä olevasta kalenterinäkymästä. Käyttöliittymän avulla navigoidaan näkymästä toiseen ja hallinnoidaan merkintöjä. Käyttöliittymän teknistä toteutusta käsitellään tarkemmin seuraavassa osiossa. Nyt keskityn esittelemään kalenterin käyttäjälle tarjoamat mahdollisuudet.

Kalenteri-sovelluksen avaaminen tapahtuu komentoriviltä, mutta käyttöliittymä tarjoaa mahdollisuuden avata merkintöjä sisältäviä tiedostoja sekä vastaavasti tyhjän kalenterin. Käyttäjä voi tallentaa merkintänsä koska vain käytön aikana. Lopettaessaan sovellusta valikon kautta, käyttäjältä varmistetaan, mitä hän merkinnöilleen haluaa tehdä eli tallennetaanko ne vai jätetäänkö tallentamatta. Näin pyritään varmistamaan, etteivät merkinnät katoa. Pieniä ongelmia tässä kuitenkin on, sillä JFrame-ikkunaa sulkiessa sulje-painikkeesta oikeasta yläkulmasta, ei tätä kyselyä tapahdu ja riski menettää merkintöjä on siis olemassa, jos tallennusta ei ole tehty itse.

1.2.1 Kalenterinäkymät

Käynnistyessään kalenteri aukeaa kyseisen päivän päivänäkymään. Samalla konstruktoidaan valmiiksi kyseisen viikon ja vuoden näkymät. Päivä- ja viikkonäkymässä käytetään päivien esittämiseen taulukkoa, jossa kyseisen päivän merkinnät ovat järjestyksessä. Viikkonäkymässä näitä taulukoita on seitsemän vierekkäin. Vuosinäkymässä on 12 kuukausitaulukkoa, jotka vastaavat tavallista seinäkalenteria.

Päivä- ja viikkonäkymässä voidaan edetä ja palata päiviä/viikkoja edellinen ja seuraava painikkeilla. Lisäksi kaikissa näkymissä voidaan ajankohtaa muuttaa JSpinnerillä. Käyttäjän muuttaessa ajankohtaa kalenteri luo aina uuden näkymän ja asettaa sen esille. Näkymästä toiseen voi siirtyä painikkeiden ja valikon kautta. Viikko- ja vuosinäkymästä pääsee suoraan päivämäärää klikkaamalla kyseiseen päivänäkymään. Reaaliaikaiseen päivämärään pääsee palaamaan kätevästi siirry-valikon kautta, jos on navigoinnissaan ajautunut jonnekin kauas tulevaisuuteen. Valikosta voi valita siirtyvänsä nykyiseen päivään, viikkoon tai vuoteen.

1.2.2 Merkinnät ja käyttöliittymä

Merkintöjen lisääminen käyttöliittymän kautta on mielestäni varsin kätevää. Merkinnät-valikosta merkinnän voi lisätä lomakkeella, jossa kysytään ajankohtaa, tekstiä, kestoa ja tärkeyttä. Merkintä lisätään ajankohdan paikalle edellyttäen, että siinä ei ole jo merkintää. Merkintöjä voi lisätä, muuttaa ja poistaa suoraan päivä- ja viikkonäkymästä. JTable:n ja AbstractTableModel:n avulla rakennetut näkymät mahdollistavat sisällön muokkaamisen koodaajan antamien valmiuksien mukaan. Tekstiä, minuutteja ja tärkeyttä voi muokata suoraan klikkaamalla kyseistä kohtaa. Tekstin pyyhkiminen pois poistaa koko merkinnän merkintöjenhallinnasta. Itse asiassa kyseinen tapa on ainut mahdollisuus poistaa yksittäisiä merkintöjä. Valikossa tarjotaan mahdollisuus poistaa kaikki kalenterin sisältämät merkinnät, mikä tarkoittaa käytännössä uuden tyhjän kalenterisovelluksen avaamista. Katsoin, että yksittäisten merkintöjen poistaminen lomakkeen tms. avulla ei ollut tarpeellista. Kehitysideana toki mahdollinen.

Merkintöjä voidaan hakea tekstin ja tärkeyden perusteella. Haut löytyvät merkinnät-valikosta. Hakutuloksena syntyneestä listasta käyttäjä voi valita jonkun merkinnän ja siirtyä tarkastelemaan sitä päivänäkymän kautta. Merkinnän sisältämät tiedot saa avattua lomakkeeksi päivänäkymän klikkaamalla tunnit sarakkeetta kyseisen merkinnän kohdalta.

2. Kalenterin tekninen toteutus

Kalenterin toteutus tapahtuu 13 luokan avulla, joista 9 liittyy käyttöliittymään ja 4 kalenterin käynnistämiseen ja merkintöjen hallintaan.

Gregoriaaninen kalenteri oli koko projektin pohjana. Java Api:n tarjoama valmis GregorianCalendar-luokka vapautti keskittymään käyttöliittymään ja merkintöjen hallinnointiin, sillä luokan käyttö, sitten kun sen oppi, oli erittäin kätevää. Muutamalla metodikutsulla pystyi konstruktoimaan päivänäkymän ilman, että tarvitsi paljon miettiä esimerkiksi mikä viikonpäivä 23. tammikuuta on. GregorianCalendar-luokka tietää kaiken tarpeellisen. Tarvitsi vain osata kysellä oikeita asioita.

Käyttöliittymässä käytetään paljon tavallisia komponentteja, kuten JButtoneita, JLabeleitä ja valikkoja. Sen lisäksi sain opetella käyttämään harjoituksissa vieraiksi jääneitä komponentteja, kuten JSpinneriä ja JTablea yhdessä AbstractTableModelin kanssa. JTablen väitetään olevan Swingin vaikeimpia komponentteja, siksi olenkin varsin ylpeä siitä kuinka helposti loppujen lopuksi opin sen perusominaisuudet sekä AbstractTableModelin idean.

Työ lähti kuitenkin liikkeelle Merkinta- ja MerkintojenHallinta-luokista. Jo suunnittelu vaiheessa sain palautetta, että myös jonkun näköisen päivä-luokan käyttämistä kannattaa miettiä. Totesinkin, että se oli viisasta. Merkintöjä hallinnoidaan loppujen lopuksi näiden kolmen luokan avulla. Kalenterin käynnistävässä luokassa, Kalenterissa, luodaan uusi MerkintojenHallinta-olio sekä käyttöliittymä eli KalenteriK-olio. Tämän jälkeen kalenteri on valmis käyttöön.

2.1 Toteutusympäristö ja käytetyt ohjelmointivälineet

Kalenterin toteuttaminen tapahtui perinteisellä tekstieditorilla XEmacsilla. Pääosin koodasin työtä kotona, mutta osallistuin myös kahteen järjestettyyn projektiharjoitukseen. Apuna työskentelyssä oli tietenkin Sunin Java API:n dokumentaatio. Suurimman merkityksen projektilleni antoi Java API:n valmis GregorianCalendar-luokka, joka antoi minulle valmiina koodina kaiken päivämääriin ja sitä kautta kalenteriin tarvittavat tiedot. Sen käyttö ei aivan heti avautunut kunnolla, mutta pieni vihje kokeneemmalta koodaajalta ratkaisi koko ongelman ja sen jälkeen käyttö olikin varsin helppoa.

GregorianCalendar-luokan lisäksi tarvitsin dokumentaatiosta Javax Swingiin liittyviä luokkia. JTableen perehdyin Java Tutoriaalin kautta, koska pelkkä dokumentaatio ei antanut tarpeeksi hyvää kuvaa JTablen käytöstä. Yhdyn väitteeseen java-koodaaja ei tule toimeen ilman API:n apua pätee aivan varmasti. Oikeastaan nyt vasta opin kunnolla käyttämään API:a huolimatta pieniä lukuvaikeuksia.

Java Apin ja Tutoriaalin lisäksi apunani oli Mika Vesterholmin ja Jorma Kyppön Java-ohjelmointi -kirja. Siitä on koko kurssin ajan ollut paljon hyötyä ja tukea.

2.2 Kalenterin toteutuksen pääpiirteet

Oheisen linkin taakse on koottu kalenteri-sovellukseen liittyvät kaikki 13 luokkaa ja niiden suhteet luokkakaavioksi. Luokkakaavioon on koottu attribuutit ja metodit lukuun ottamatta KalenteriK-luokan attribuutteja, joita on noin 50 kpl. Niiden luetteleminen ei olisi ollut millään lailla järkevää. Kyseiset attribuutit ovat Javax Swingin peruskomponentteja, kuten JMenuItem, JMenuBar, JLabel, JButton jne. Toivottavasti luokkakaavion antaa hyvän kokonaiskuvan kalenteri-sovelluksesta ja sen sisäisestä toiminnasta.

Seuraavissa kappaleissa käsittelen tärkeitä teknisiä kokonaisuuksia kalenterin toiminnassa. Merkityksen niille antavat varmasti minun omat kokemukseni. Tavallaan ne ovat rajapyykkejä, jotka saavat kalenterin tietyt osat toimimaan. Siis tekevät Kalenteristani kalenterin.

2.2.1 Merkintojen hallinnointi ja luominen

Merkintojen hallinnointiin osallistuu siis kolme luokkaa. Varsinainen Merkintä-luokka sisältää merkinnän tiedot, kuten tekstin, ajankohdan jne. sekä niihin liittyvät metodit. Aina kun uusi merkintä tehdään, lomakkeella tai klikkaamalla taulukkoa näkymässä, luodaan uusi Merkinta-olio. Jos kyseiselle ajankohdalle ei ole jo toista oliota, sijoitetaan se merkintöjen hallintaan. Kohdassa Päivä- ja viikkonäkymän toteutus käsitellään tarkemmin merkintöjen tietojen muokkaamista ja luomista suoraan JTablen avulla.

Paiva-oliolla on yhtä päivää esittävä taulukko, johon mahtuu 24 merkintää, 2 kullekin tunnille. Tämä oli selkeä ratkaisu, joka helpotti huomattavasti AbstractTableModelin käyttöä ja syntyi vasta siinä vaiheessa, kun PaivaNakymaTaulukko-luokkaa tehtiin. Suunnitelman mukainen järjestyksessä ollut TreeSet-kokoelma ei ollutkaan kätevä, kun sieltä pitikin saada mikä tahansa merkintä ulos tuntien ja minuuttien perusteella eikä kaikkia merkintöjä järjestyksessä niin kuin olin suunnitellut. Joka tapauksessa ajattelin, että yhden päivän sisältämien merkintöjen määrän täytyy olla rajattu, jotta taulukot eivät pursuisi liitoksistaan. Vasta nyt tajuan, että rajoitushan pitää tosiaan tehdä jo kokoelman määrittelyvaiheessa. Eli suunnitelmassa oli pieni bugi tässä kohtaa, mutta kokonaisuus ja JTable käyttö ei ollut vielä hallussa siinä vaiheessa.

Paiva-olio luodaan, jos kyseiselle päivälle on yksikin merkintä, muuten ei. MerkintojenHallinta kokoaa kaikki päivät HashMapiin. Se sisältää myös metodit merkintöjen lisäämiseksi ja poistamiseksi sekä kalenterin merkintöjen tiedostoon kirjoittamista ja lukemista varten.

2.2.2 Päivä- ja viikkonäkymän toteutus

Päivänäkymä koostuu erilaisista navigointi elementeistä sekä varsinaista päivää esittävästä taulukosta, joka on toteutettu JTable:n avulla. Viikkonäkymässä näitä taulukoita on sijoitettu seitsemän vierekkäin lähtien liikkeelle maanantaita kuvaavasta taulukosta. Päivä- ja viikkonäkymän luominen perustuu, sille parametrina annetun Gregoriaanisen kalenterin päivämäärään. Päivänäkymä tehdään juuri kyseisestä päivästä. Viikkonäkymässä sen sijaan päivämäärähän voi kuvata mitä tahansa viikon päivistä. Halusin, että viikon esittäminen aloitetaan aina maanantaista, joten kalenterin päivämäärä asetetaan aina vastaamaan kyseisen viikon maanantaita ja muut päivät konstruktoidaan sen avulla. Kyseinen algoritmi löytyy viikkonäkymän konstruktorista.(linkki)

Kun JTable:a käytetään yhdessä AbstractTableModelista perityn luokan kanssa, kalenterissa PaivaNakymaTaulukko-luokka, muodostuu kokonaisuus, jossa JTable tarjoaa ulkoiset raamit ja esitysasun taulukolle ja AbstractTableModel välittää taulukolle sen sisältämät tiedot. AbstractTableModelin avulla päivä- ja viikkonäkymän perustana oleviin päivää kuvaaviin taulukoihin pystyttiin merkintöjenhallinnasta poimimaan merkintään liittyvät tiedot. AbstracTableModel sisältää tavallaan viittauksen siitä, mistä jonkun solun tieto pitää kaivaa esille sekä mistä sarakeotsikot rakennetaan, mikä on sarakkeen luokka ja mitä sarakkeita voi muuttaa. Samalla se huolehtii muutetun arvon sijoittamisesta oikealle paikalleen. Kalenterissa tämä tarkoitti käytännössä sitä, että merkinnän teksi-, minuutit- tai tärkeysmuuttujan arvoa muutettiin.

2.3 Ongelmat, puutteet ja kehitysideat

Kalenterin koodaamisen aikana syntyi muutamia ongelmia, jotka johtivat joko toteutuksen viivästymiseen taikka lopullisen ohjelman puutteisiin. Lisäksi käsittelen vielä muutamia toteutuksen kehitysideoita, jotka päätin jo lähtiessä tehdä tämän tasoiseen projektiin paremmin soveltuvalla tavalla.

2.3.1 Merkinnän keston esittäminen

PaivaNakymaTaulukko-luokan metodit olivat mielestäni kalenterin kannalta tärkeä juttu. Ne toimivat hyvin ja mahdollistavat järkevän tiedon säilytysmenetelmän. Muutamia puutteita JTable:n kanssa kuitenkin ilmeni. Merkintöjen keston toteuttaminen ei onnistunutkaan suunnitellulla tavalla. Samalla kariutui myös idea, erilaisista merkinnöistä tyyliin työskentely-, vapaa-aika-, kokous-merkinnät. Minun kyvyt ja ideat eivät riittäneet saamaan selville, miten JTablessa pystyy värittämään haluamansa solut, jollakin tietyllä värillä. Ideana oli kuvata merkinnän kesto väritettyinä soluina ja eri merkintätyypeillä olisi ollut eri värikoodit. Etsin tietoa asiasta niin API-dokumentaation uumenista ja internetistä yleisesti. Lopputuloksena oli, että moni muukin oli törmännyt kyseiseen ongelmaan, mutta ratkaisua ei tuntunut löytyvän.

Yritin miettiä myös muita tapoja ilmaista merkinnän kestoa, kuten nuolta kuvaavan kuvan sijoittaminen omaksi sarakkeekseen. Sekään ei toiminut, sillä ilmeisesti JTable:n soluun ei voi sijoittaa mitään kuvaa ilmaisevaa komponenttiä. Ilmeisesti tuo merkinnän konstruktointi abstract-table modelin avulla ei olisi ollut aivan niin yksinkertaista kuin tavallisten merkinnän tietojen poimiminen merkintöjenhallinnasta. Harmi, että merkintöjen kesto on havaittavissa nyt ainoastaan lomakkeen kautta. Lomake aukeaa taulukon tunnit saraketta klikkaamalla kyseisen merkinnän kohdalta. Se ei kuitenkaan oikein aja asiaansa. Suunnitelmassa tämä oli selkeästi painotettu tärkeäksi asiaksi, joten epäonnistuminen jäi mieleen. Mielestäni tämä oli ainut ns. vakava puute. Muut kehityskohteet tuovat lisää toiminnallisuutta.

2.3.2 Tooltip-tekstit taulukoille

Pääsin jo varsin pitkälle tooltip-tekstien esittämisessä, mutta joku pieni ongelma siinä ilmeni. Kalenteri olisi tarvinnut selitystekstin mm. tärkeys sarakkeelle, johon ei ollut asianmukaista sijoittaa koko tärkeys-sanaa otsakkeeksi. Sen lisäksi muutakin ohjeistusta olisi ollut varsin kätevä sijoittaa tooltip-tekstiin. Kuten miten sarakkeen tietoja muokataan, mitä tekstin pyyhkimisestä tapahtuu jne. Jopa merkinnän keston olisi mielestäni voinut ilmaista paljon nopeammin tooltip-tekstinä kuin JDialogin perivänä lomakkeena.

2.3.3 Ohjeistus

Varsin pian käyttöliittymän kehittyessä ja laajentuessa mieleeni tuli puute, joka käyttöliittymään myös jäi. Jonkin näköinen kalenteri-sovelluksen käyttöohje, olisi ollut paikallaan. Jos ajatellaan projektia hyvin suunniteltuna ohjelmana, pienoisprototyyppinä jostakin hienosta ja virallisesta oikeasti käytettävästä tuotteesta, olisi siihen tietenkin kuulunut myös hyvä ohjeistus.

Ajan puutteen vuoksi ohjetta en kuitenkaan laatinut. Päätin työtä tehdessä, että jos saan toteutettua merkinnöille eri tyypit, on pakko tehdä jonkun näköinen info-laatikko. Kalenteri jäi kuitenkin varsin perustoimintojen varaan, joten luultavasti ne selviävät vähänkin tietokoneohjelmia käyttäneille ilman varsinaista ohjetta. Ohjeen käytännön toteutus olisi ollut pitkälti kirjoittamista eikä siksi varmaankaan niin oleellista tämän ohjelmointiprojektissa.

2.3.4 Muita huomioita

GregorianCalendar-luokan käyttäessä saattaa ilmetä ongelmia, jos kalenteria selaa paljon taaksepäin. Luokan toteutuksessa on joku tietty rajapäivä, jolloin ongelmia saattaa esiintyä. En ole tätä asiaa omassa kalenterissani huomioinut mitenkään. Asiaa voisi ajatella vaikka siltä kannalta, että kalenteria käytetään tulevaisuuteen suuntautuvassa suunnittelussa menneen sijasta. Asia olisi luultavasti vaatinut syvempää perehtymistä asiaan, mitä ei tämän projektin puitteissa ollut mahdollista tehdä.

Jo projektia suunnitellessani päätin toteuttaa merkintöjen tallentamisen kurssilla opetellun tiedostoon tallennuksen tapaan. Tiedostin jo kuitenkin silloin, ettei se välttämättä ole paras mahdollinen tapa säilyttää merkintöjä tallessa. Esiin tuli ideoita esimerkiksi tietokannasta, mikä soveltuisi ilmeisesti paremmin suuren tietomäärän säilyttämiseen. Jos kalenterini otetaan ihan oikeasti käyttöön voi tiedostoon tallennuksessa ilmetä hitautta, sillä tiedoston koko kasvaa tietenkin merkintöjen määrän kasvaessa. Tämän kurssin sisältöön ei kuitenkaan kuulunut tietokantojen hallinta, joten sivuutan idean mainitsemalla siitä tässä raportissa.

3. Kokemukset projektista

3.1 Suunnittelu vastaan lopullinen toteutus

Ensiksi haluan hieman hehkuttaa. Mielestäni suunnitelmani onnistui pääpiirteissään erittäin hyvin. Olin perehtynyt juuri tarpeeksi asioihin, jottei minun tarvinnut tehdä paljonkaan muutoksia luokkajakoon ja luokkien sisältämiin metodeihin. Koodauksen aikana syntyi toki paljon lisää metodeja siitä, mitä olin suunnitteluvaiheessa osannut listata, mutta ne toimivat ns. apumetodeina.

Suurin ero suunnitelmassa käytännön toteutukseen syntyi aikataulussa. Suunnittelu vaiheessa kuvittelin aloittavani projektin heti kun suunnitelmat oli tehty. Toisin kuitenkin kävi. Projekti pääsi käyntiin vasta tenttikauden loputtua, jolloin joulukiireet pukkasivat jo pahasti päälle. Käytännössä projektin loppurutistus oli 5 päivää 10-12 tuntia päivässä. Tämän aiheutti oikeastaan vasta tammikuun puolella selvinnyt käyttöongelma Gregoriaanisen kalenterin yhteydessä. En päässyt projektissani etenemään, kun en saanut jo tehtyä osuutta testattua ja toimimaan.

Yksittäisistä teknisistä muutoksista merkittävin oli varmasti Päivä-luokan käytön varmistuminen ja sitten hieman myöhemmin TreeSet-toteutuksen vaihtuminen kooltaan rajoitetuksi taulukoksi.

Olin sisällyttänyt suunnitelmaani varsin paljon muutakin kuin mitä toteutui. Assarit osasivat onneksi suunnitellessa vakuuttaa minut keskittymään ensin peruskalenterin tekemiseen ja siirtymään vasta sitten extraominaisuuksiin. Jopa kalenterin perusominaisuudet piti laittaa tärkeysjärjestykseen mm. siten, että ensiksi tehdään päivä- ja viikkonäkymät ja vuosinäkymä konstruktoidaan vain jos on aikaa. No onneksi sain sen kuitenkin tehtyä. Olisi kalenteri ollut aika vajaa ilman sitä. Toteutuksesta pois jäivät jo aikaisemmin mainitsemat merkintöjen tyypitykset. Tyypityksiin olisi liittynyt myös tiettyjä ominaisuuksia, kuten matkalaskun kokoamista jne. Hakutoiminnot sain sentään jossain mittakaavassa toteutettua.

3.2 Bugit ja minä

Törmäsin toteutuksen aikana yhteen isoon ongelmaan. En osannut käyttää GregorianCalendar-luokkaa oikein. Hämäännyin sen sisältämistä runsaslukuisista attribuuteista niin pahoin, että ryhdyin käyttämään niitä ns. suoraan, enkä metodien kautta. Mikä sai aikaan sen, että tulostamani päivämäärät olivat aina 5.0.1. Esimerkiksi viikkonäkymässä kaikkien päivien kohdalla luki tuo kyseinen päivämäärä. Tuo kyseinen bugi pysyi kalenterissani useita viikkoja, koodailin vain eteenpäin toivoen, että jonain päivänä valkenisi, miksi Gregoriaaninen kalenteri ei toimi. Lopulta tarvitsin asian selvittämiseen ns. apusilmää, joka huomasi varsin nopeasti virheeni: en siis ollut käyttänyt metodia get(int Field) vaan käytin niitä kenttiä suoraan tyyliin kalenteri.MONTH.

Toinen hieman lyhyemmän aikaa kestänyt ongelma liittyi GregorianCalendar luokan käyttöön. Sama ongelma ilmeni useiden kenttien yhteydessä. GregorianCalendar-luokan kentät ovat int tyyppiä, mutta missään ei oikein kerrota selvästi, mitä arvoja kentät saavat. Toisinaan kenttien arvot alkoivat 0:sta, toisinaan 1:stä. Vaati pientä salapoliisin työtä ottaa selville, mitä numeroa mikäkin kentän arvo vastaa.

Nuo GregorianCalendar luokkiin liittyvät bugit ovat osaltaan omaa huolimattomuuttani osaltaan API:n puutteellisuutta. Vieläkään en oikein voi ymmärtää, miksi en huomannut tuota ensimmäistä virhettä. Mielestäni pientä kehityksen varaa olisi GregorianCalendar-luokan API dokumentaation selkeyttämisessä.

Muita isompia bugeja ei enää tule mieleen. Pääasiassa olen sellainen koodaaja, että noita kirjoitusvirheitä yms. syntyy varsin paljon ja sitten saan niitä metsästellä välillä kauankin ennen kuin huomaan missä virhe on. Siinä lienee itsellä kehittymisen varaa. Tarkkuutta koodauksessa vaaditaan paljon.

3.3 Työskentely

Työskentely oli tehokasta, silloin kun pääsin koneen ääreen ja aikaa koodaamiseen oikeasti oli. Asennoituminen siihen, että nyt on oikeasti koodattava, vei joulun alla aikansa. Halusin nimittäin viettää myös joulua ja joululomaakin. Loppujen lopuksi lomaa yritin viettää juuri ennen palautusta Pohjois-Karjalan reissulla, mutta eipä se loppujen lopuksi siltä paljon tuntunut, kun joka päivä piti kone avata ja vielä jotain viimeistellä.

Kokonaisuudessaan minusta tuntuu siltä, ettei koodaukseni ollut kuitenkaan koneen ääressä kokoajan istumista. Joulun välipäivät hujahtivat muissa jutuissa niin, että jouduin tosiaan koodaamaan melkein viikon putkeen 10-12 tuntia päivässä. Kun aloitin tuon rupeaman, minulla oli merkintöjen hallinnointiin liittyvät luokat melkein valmiina ja käyttöliittymässä raamit. Siitä se ohjelma sitten sai muotonsa varsin nopeasti, kun sain yllä esitellyn bugin selvitettyä.

Kokonaisuudessaan resursseja kului ehkä kuitenkin vajaat 100 tuntia.

4. Yhteenveto

Kalenteri-sovelluksestani tuli lopulta hyvä peruskalenteri. Se sisältää kaikki kalenteriin liittyvät perustoiminnot, sillä voi havainnoida vuoden kulumista erilaisissa näkymissä sekä lisätä omia merkintöjä haluamiinsa ajankohtiin tietyin reunaehdoin, kuten rajattu merkintöjen määrä/päivä. Kalenterin merkinnät voi tallentaa ja ladata taas tiedostosta takaisin käyttöönsä. Etuna on esimerkiksi se, että samalla koneella voi samaa kalenteria käyttää useampi henkilö, kun jokainen tallentaa omat merkintänsä eri tiedostoihin.

Ne toiminnot, jotka sain toteutettua toimivat omassa testauksessani hyvin ja olen erittäin tyytyväinen. Opin mielestäni ymmärtämään tiedostoon tallennuksen ja lukemisen sekä käyttöliittymän siihen liittyvät käytännöt hyvin, kuten FileChooserin käytön. Olin oikein tyytyväinen osuuden toimiessa. Myös näkymien toimivuus oli hyvää. Pientä kehittelyä niissä voisi olla, kuten mihin päivänäkymään siirrytään, tietyn viikkonäkymän ollessa avoinna jne. Suurimmat onnistumisen tunteet koin JTable ja AbstractTableModelin kanssa. Merkinnät menivät tosiaan oikeille paikoilleen ilman suurta taistelua. Toteutustapa tuntui aluksi niin abstraktilta.

Tietenkin minua jäi harmittamaan merkintöjen keston kuvaamisen epäonnistuminen. Se vaikeuttaa kalenterin mielekästä käyttöä arkipäivässä. Kuitenkin niin kuin edellä sanoin se, minkä toteutus onnistui, toimii hyvin. Mielestäni kalenterista tuli tästä puutteesta huolimatta hyvä.

Projektia suunnitellessa tavoitteena oli tehdä jotain oikeasti käytännöllistä. Suunnittelussa korostin monta kertaa käytettävyys näkökulmaa. Pientä hiomista kalenteri tarvitsisi, jotta se olisi oikeasti hyödynnettävissä esimerkiksi yrityksessä jossa työskentelen. Muutamia lisäominaisuuksia lisäämällä sekä jo suunnitellun toteuttamalla kalenterista voisi tulla ihan käyttökelpoinen pienyrityksen käyttöön. Matkalaskun lasku- ja projektin ajankäytönseurausominaisuudet antaisivat siihen yrityslähtöistä näkökulmaa. Seuraavan kurssin yhteydessä sitten. Tätä miettiessä opin, että java-ohjelma ei ole koskaan valmis. Aina on jotain miten sitä voidaan kehittää ja parantaa, jos ei muuta niin ulkoasun muokkausta.

Päällimmäiseksi projektityöskentelyssä jäi mieleen prosessi. Se miten lähdetään liikkeelle suunnittelemalla. Toteutetaan itse ohjelmaa, joka kehittyy työn ohessa. Aivan lopuksi analysoidaan, mitä saatiin aikaan ja vastaako se asetettuja tavoitteita. Tämä projekti oli ensimmäinen, jossa oikeasti ymmärsin näiden vaiheiden merkityksen. Erittäin opettavaista.

5. Kalenteri-sovelluksen koodi