Studio 1 -kurssin itsenäisen ohjelmointiprojektin loppuraportti. Kirjoittanut Pekka Ryynänen.
Projektini aihe-ehdotuksen ja projektisuunnitelman lukeneet tuntevat alkuperäiset aikeeni tämän ohjelman suhteen. Tässä dokumentissa kerron, millaisen selaimen oikein sain aikaiseksi. Sovelluksella on hyvä olla nimi; minä kutsun omaani nimellä Azure.
Sisältö:
Ohjelman kuvaus
- Yleiskuvaus
- Selaimen toiminnallisuus
- Käyttöliittymä
Teknisen toteutuksen kuvaus
- Yleistä
- Teknisen toteutuksen pääpiirteet
Kokemukset projektista
- Projektipäiväkirja
Yhteenveto
Selain on työkalu erilaisilla koodikielillä - erityisesti HTML-kielellä - kuvattujen dokumenttien katseluun siten, että sivuilla näkyvät tyylitelty teksti, grafiikat yms. Ajattele tuntemiasi suosittuja selaimia (Opera, Mozilla, Internet Explorer). Azure on kuin jonkin näistä raakaversio. Sillä voi surffata internetissä ja yksinkertaiset asiat näkyvät sivuilla oikein. Monimutkaisemmat rakenteet ja erilaiset objektit kuten javascript toistuvat todennäköisesti väärin tai eivät ollenkaan. Siitä huolimatta niitä sisältävät sivut voivat olla (ja hyvin tehtyjen sivujen pitäisikin olla) lukukelpoiset. Omien sivujen katselu Azurella, jossa muotoilusta huolehtii puutteellinen HTML 3.2 -tuki, voi antaa hyödyllisiä vinkkejä siitä, mitä ongelmia sivuilla on nykyselainten vanhemmilla versioilla, joita miljoonat ihmiset maailmassa yhä käyttävät.
Nettisivuille siirtyminen onnistuu kahdella tapaa: syöttämällä sivun URL-osoite osoitekenttään tai klikkaamalla linkkiä. Myös käytettävällä tietokoneella olevia tiedostoja voidaan avata ja tarkasteltujen sivujen koodi tallettaa sisältöineen kovalevylle. Sivuhistoria pitää kirjaa katselluista sivuista, jotta niille on helppo palata myöhemmin. Sivuhistoriassa voi liikkua edestakaisin, ja mikäli käyttäjä päättää lähteä välillä uusille urille, vaikuttaa historia siltä kuin harhapoluilla ei olisi kesken kaiken käytykään.
Suurin osa työstä Azuren parissa kului käyttöliittymän tekemiseen. Olenkin aika tyytyväinen sen toimivuuteen. Sivuja voi ladata uudestaan, Back- ja Forward-napit ovat painettavissa vain kun sivuhistoriassa on jotain minne liikkua, alapalkki kertoo linkin kohteen kun hiiren kursori on sellaisen päällä ja sivun hakemisesta kertova statusteksti vaihtuu säännöllisesti kun sisältöä ladataan. Kovalevyn sisältöä voi selata sivuja avattaessa ja talletettaessa html-tiedostoihin rajoittuen, ruutuun mahtumattomia sivuja tarkastellaan rullaamalla ja tooltipit ovat käytössä. Ulkoasu on huoliteltu, komponenteissa on käytössä samat värisävyt kuin tässä dokumentissa. Työkalupalkin näppäimet on saatu käyttöön Sunin Java look and feel Graphics Repository -sivuilta. Osoitekenttään syötetystä URL:sta voi halutessaan jättää http://-alkutunnuksen pois. Mikäli käyttäjä yrittää surffata osoitteeseen, jota ei ole tai johon ei saada yhteyttä, ohjataan hänet "Invalid or broken URL"-sivulle.
Azure on kehitetty kotikoneella Windows XP -työympäristössä, pääasiallisena työkaluna oli XEmacs. Javasta käytössä olivat J2SE:n 1.4.2-luokkakirjastot. Käytin myös vähän Sunin omaa NetBeans IDE -työkalua. Testasin ohjelman toimivuuden myöhemmin Tietotekniikka-talon Solaris-koneilla ja Linuxissa. Olioiden nimet, dokumentaatio ja kommentit ovat englanniksi.
Selaimessa on neljä luokkaa, jotka kuvaan seuraavaksi lyhyesti ennen Poseidon-ohjelmalla laaditun UML-kaavion näyttämistä. Tarkempaa tietoa haluaville suosittelen JavaDoc-dokumentaatioon perehtymistä.
Azure.java on sovelluksen tärkein luokka. Se tuo yhteen kaikki muut ja toimii käyttöliittymän tapahtumien kuuntelijana. Sen yhteydessä luodaan menu ja työkalupalkki. Azure käynnistetään tästä luokasta.
PageBrowser.java on se osa selaimen ikkunasta, johon sivu ladataan näkyviin. Lataus tapahtuu mahdollisimman pitkälle käyttöliittymäsäikeeseen nähden erillisessä säikeessä, jota PageBrowser-luokka myös kuvaa.
AddressBar.java sisältää osoitekentän ja pyörittää erillisenä säikeenä statustekstiä.
PageHistory.java on ainut puhdas ei-käyttöliittymäluokka. Se pitää listaa selatusta sivuhistoriasta ja käyttäjän kulloisestakin sijainnista historian sisällä.
Näiden lisäksi palautin työssäni myös viidennen luokan AzureXHTMLHandler.java, joka näyttää kuinka lähestyin XHTML-koodin parsettamista ja sen myötä muotoilua näkyville. Valitettavasti nykyisellään Azure nojaa Java APIssa valmiina olleeseen (puutteelliseen) HTML 3.2 -tukeen. Projektisuunnitelmassa mainitsemistani tavoista laatia oma nettisivujen näyttämistä säätelevä ratkaisu osoittautui uuden XHTMLEditorKitin laatiminen laajuudeltaan mahdottomaksi tutustuttuani selaimen nyt käyttämän HTMLEditorKitin lähdekoodiin. Myöskään AzureXHTMLHandler-luokan tyylinen XML-pohjainen käsittely ei lopulta vastannut tarpeitani, eikä aikaa lopulta enää ollut kirjoittaa kolmatta vaihtoehtoa toimivaksi tyhjästä. Mainitsen myöhemmin mitä olisin tehnyt.
Projektini tärkein tietorakenne on sivuhistorian mallinnus. PageHistory-luokka on mielestäni selkeä ja toimiva. Se perustuu linkitettyyn listaan URL-osoitteita ja nykysijainnin kertovaan lukuun. Historian käsittelyyn käytettävien metodien huolellinen kirjoittaminen oli avain sen toimivuuteen. Mainittavia algoritmeja ei tällaisessa työssä tarvittu. Säikeiden käyttö oli oleellista että käyttöliittymä pysyy vastaanottavaisena sivujen lataamisen aikana.
Tein ajoittain muistiinpanoja projektipäiväkirjaan.
Ohjelmointiprojektini aihevalinta, selain, oli kunnianhimoinen ja vaativa. Jos nyt voisin puhua itselleni muutaman kuukauden päähän menneisyyteen, kehottaisin valitsemaan jotain simppelimpää. Tämä oli kyllä mielenkiintoista ja tarjosi paljon opittavaa, mutta huomauttaisin (edelleen itselleni) ettei tällaisen kurssin lopettavan työn tarvitsisi välttämättä opettaa niin paljoa uutta. Käytössä ollut aika ei myöskään tehnyt aiheelle oikeutta. Mikäli olisin saanut itseni vaihtamaan aihetta, olisin kyllä kehottanut kokeilemaan tätä omalla ajalla toiste juuri mielenkiintoisuuden ja oppimisen takia.
Osa huonosti riittäneestä toteutusajasta menee sen piikkiin, että sairastuin ennen joulua enkä saanut tuolloin paljoakaan aikaan projektin eteen. No, huono säkä, eipä sille mitään voi. Tiedän toisten toteuttaneen minulla myöhemmin jäljellä olleessa ajassa laajempiakin projekteja. Suurin osa ajastani kului uuden opettelemiseen. Vaikka sanoisin käyttäneeni viimeisen viikon aikana päivittäin vain reilut kuusi kunnollista työtuntia projektiin, tuntui siltä että elin ja hengitin sitä. Se pyöri päässä aina tehdessäni jotain muuta, yrittäessäni ruveta nukkumaan ja herätessäni aamuisin. Ei välttämättä hyväksi jaksamiselle. Projektityön palautettuani olen kuitenkin huomannut iloisena miettiväni, että minkähänlaisen simppelin pelin koodaisin omaksi ilokseni.
Ei ole yllättävää, että projektini olisi hyötynyt huolellisemmasta suunnittelusta etukäteen. Tämä on varmaan aika yleinen piirre. Luokkarakenteesta sain hyvin pitäneen käsityksen jo varhain, mutta aikomani keinot koodin muotoiluun sivuksi eivät olleetkaan toteutuskelpoisia. Sikäli huvittavaa, että olin mielestäni suunnitteluvaiheessa hyvällä pohjalla kun minulla oli vaihtoehtoisia etenemisreittejä projektilleni. HTML/XHTML-koodin käsittelyyn olisi pitänyt paneutua varhaisemmassa vaiheessa, vaikka en pidäkään huonona ajatustani saada ensin jotain näkymään selaimessa ja sitten vasta koittaa muotoilla sitä. Jos tekisin samaa työtä uudestaan, kirjoittaisin oman parserin joka pistäisi käyttiksen mallintamaan yksinkertaiset asiat sopivilla Swing-komponenteilla ja jättäisi monimutkaiset pois pilaamasta sivujen luettavuutta. Karua, mutta toimisi tiettyyn pisteeseen.
Käyttämäni opiskelulähteet olivat lähes yksinomaan englanniksi, ja ohjelmakoodi näyttää mielestäni paremmalta englanninkielisillä asioiden nimillä. Työn tekeminen englanniksi oli siten luontevaa, mietin oikeastaan vasta uuden vuoden aikoihin olisiko pitänyt sittenkin käyttää suomea, että olisi voinut kirjoittaa helpommin ymmärrettävää dokumentaatiota.
Säikeiden käytössä oli jonkin verran ongelmia johtuen yhteydestä Swingiin ja sen tapahtuma- ja kuuntelusäikeeseen. En ole vieläkään ihan varma, johtuvatko eräät poikkeukset konflikteista säikeiden välillä vaiko HTMLEditorKitin huonosta HTML-tuesta (tai huonosti kirjoitetuista nettisivuista). Tämän ja aiemmin selittämäni sivujen muotoiluongelman ohella en kohdannut suuria vaikeuksia.
Työskentelystä opin pari hyödyllistä seikkaa:
- On hyvä olla joku henkilö, jonka kanssa voi puhua projektista aina kun tuntuu siltä. Kaikupohjana toimiminen riittää, hyvät ehdotukset ovat tietysti vielä tervetulleempia. On erittäin hienoa, jos tuo henkilö on itse opetellut Java-ohjelmointia. Minä olen tyttöystävälleni velkaa paljon kärsivällistä kuuntelua. Vaikka hän ei ollut itse ohjelmoinut mitään tämmöistä, oli hänellä kuitenkin pari yleishyvää huomiota jaettavaksi koodista.
- Yritin ottaa oppia parista avoimen lähdekoodin selaamisesta. En suosittele uppoutumista paljoa Java Tutorialin esimerkkejä monimutkaisempaan koodiin (tai mihinkään missä on lukuisia toisiinsa nojaavia luokkia). Minulle ei ollut kokemuksesta hyötyä, koska tutkimani selaimet olivat niin paljon kehittyneempiä kuin oma viritelmäni. Resurssien puolesta niiden esimerkin noudattaminen ei tullut kysymykseen.
- Työskentelyyn omistettuina päivinä kannattaa nousta ajoissa. Uskon saaneeni aamun tunteina yleensä enemmän aikaan kuin iltapäivisin samassa ajassa. Tämän rytmin noudattaminen oma-aloitteisesti oli minulle hyvin epätavallista, koska pidän lomalla luonnollisina lepotunteina aikaa varhaisesta aamusta keskipäivään.
Sanoisin ehtineeni käyttää projektiin noin 60-70 työtuntia. Koodaamisen osuus tästä on minun työssäni huomattavan pieni, ehkä vain puolet. Muu aika meni suunnittelussa, ongelmien märehtimisessä ja ennen kaikkea uuden opettelussa. Tuota viimeistä olen painottanut varmasti jo liiankin monta kertaa. Miksi? Koska en ole vieläkään löytänyt ainuttakaan lähdettä, joka pyrkisi opettamaan nettisivujen muotoilua varten kaipaamiani asioita. Parsettaminen osoittautui sinällään vielä kovin riittämättömäksi. Tämä opetuslähteiden puute oli suuri järkytys sen jälkeen, kun oli kurssilla tottunut löytämään kaikki kaipaamansa asiat kirjoista ja/tai tutoriaaleista. Valitkaa ihmiset aiheenne huolella, kun on kyse tulosvastuullisesta projektista.
Palautettuani työni jäi minulle sellainen olo, että siitä jäi puuttumaan jotain. Onttouden tunne tulee siitä kelvottomasta mutta vaikeasti karistettavasta mielikuvasta, että käyttöliittymäohjelmointi on jotenkin ala-arvoista "oikeaan ohjelmointiin" (jonkinlainen hämärä sekoitus algoritmeja ja tietorakenteita) verrattuna. Jos minun pitäisi arvostella työtäni selaimena, pärjäisi se varsin heikosti. Vertailu niinikään "oikeisiin" selaimiin on tietysti epäreilu, mutta sellainen mielipaha minulle jäi kun en tehnytkään jotain loisteliasta.
Muistaen projektiarvostelun enemmän syntyneen koodin ja ajatustyön laatua painottavat kriteerit, olen toisaalta melkein tyytyväinen. Uskon koodini rakenteineen olevan kelvollista. Sen volyymi ei ole toivomaani luokkaa, mutta voinen antaa itselleni jotain sen sairauden takia anteeksikin. Vaikkei minulle olekaan jäänyt projektista yksipuolisen positiivinen olo, toivon että se todetaan kelvolliseksi.
Tilaisuus oppia, sen minä sain. Javan 1.4-version myötä tullut XML:n prosessointi JAXP:n (Java Api for XML Processing) muodossa, EditorKit-luokkien toiminta, käyttöliittymäohjelmointi, säieprobleemat eritoten käyttöliittymän yhteydessä. Projektityöskentelystä saatuja kokemuksia kannattaa myös ehdottomasti hyödyntää jatkossa. Suunnittelu, ajankäytön miettiminen, asioihin huolellisesti tutustuminen. Toivottavasti löydän tänä keväänä aikaa tehdä jotain simppeliä ihan vaan itseäni varten, ehkä peliapplettina: ajatus, jonka työnsin pois päästäni miettiessäni alun perin aihetta, koska minulle oli ammatti-ihminen huomauttanut erittäin osuvasti joka oksalla istuvista Java-koodareista, jotka kaikki haluavat tehdä pieniä pelejä. Itsenäinen ohjelmointiprojekti vaativasta aiheesta oli sen verran karaiseva kokemus, että sen jälkeen moinen löysäily on hetken aikaa sallittua.