Category Archives: Ulkoasu

Windows Phone -sovelluskehitys Androidin ja iPhonen rinnalla

Windows Phonen astuminen iOS:n ja Androidin rinnalle on saanut aikaan hieman hämmennystä joidenkin loppukäyttäjien ja sovellusten tilaajienkin mielissä. Siinä missä iOS (iPhone/iPad), Android ja jopa poistuva Symbian muistuttavat toisiaan yleisasultaan – kukin tietenkin erottautuen omilla pienillä eroavaisuuksillaan – Windows Phone on tietoisesti suuntautunut erilleen muista omalla Metro-suunnittelukielellään.

Ohje: maassa maan tavalla

Suunnitellessa uutta sovellusta mille tahansa alustalle, yleispätevänä ohjenuorana voitaneen antaa:

Kunkin tyyppisen mobiililaitteen käyttäjä haluaa systemaattisen käyttäjäkokemuksen ja käyttöjärjestelmälle tunnusomaisen sekä varsin yhdenmukaisen ulkoasun sovelluksille. Sovelluksen käyttöönotto on tällöin mahdollisimman luontevaa eikä vaadi syvällistä perehdytystä.

Tämä halu kumpuaa usein niin käyttäjien puolelta kuin myös käyttöjärjestelmien toimittajilta! Jotkut palvelujen kehittävät mieltävät ajattelevansa käyttäjän parasta pyrkimällä mahdollisimman yhdenmukaiseen käyttöliittymään laitteen käyttöjärjestelmästä riippumatta, mutta päätyvät tekemään käyttäjälle karhunpalveluksen. On poikkeustilanne, että ihmiset käyttävät samaa sovellusta eri käyttöjärjestelmillä, mutta varmaa, että he käyttävät sitä muiden saman käyttöjärjestelmän sovellusten lomassa.

Suunniteltaessa sovellusta usealle alustalle täysin samaa konseptia ei siis voi aina käyttää. Vaikka iPhone ja Android-sovellukset voivat muistuttaa toisiaan hämmentävän paljon, niillä on eronsa. WP:llä erot ovat muihin alustoihin verrattuna huomattavat.

Esimerkki

Alla käytännön vertailuesimerkki IMDB-sovelluksesta Applen iPhonelle ja Windows Phonelle.

Kuva 1. iPhone versio IMDB:n sovelluksesta.

Kuva 2. WP-versio IMDB-sovelluksesta.

Edellä esitetyt kuvat osoittavat selvästi, että iPhonen käyttäjät eivät pitäisi WP:n tyylisestä sovelluksesta puhelimessaan (mikäli se edes pääsisi Applen App Storeen), eivätkä vastaavasti Windows Phone -käyttäjät halua iPhone/Android-tyylistä sovellusta laitteilleen. Toisilleen vieraat esitystavat vaativat sovelluksen arkkitehdilta jo konseptin varhaisessa vaiheessa ydinidean hahmottamiskykyä ja näkemystä mitä kukin loppukäyttäjä haluaa siltä.

Microsoftin sivuilta löytyy (englanniksi) esimerkkejä erilaisista sovellustyypeistä Windows Phonella.

Päätelmä

Metro-tyyliohjeita noudattavat Windows Phone -sovellukset ovat niin toimintalogiikaltaan kuin ulkoasultaan selvästi erilaisia kuin iOS/Android-taustaiset sovellukset, vaikka tarjottava toiminnallisuus olisi sama.

Windows Phonen tarjoaman visuaalisesti rikkaan Panorama-näkymän avulla yritysten brändäys ja yleensäkin halutut teemat sovelluksissa voidaan saada muita alustoja vahvemmin esille (kuva 2). Tämä toki vaatii ylimääräisen graafisen aineiston luomista.

Vaikka Windows Phonella vältetään käyttöliittymäelementtien ylimääräisiä koristeita, kuten liukuvärejä, tekstuureita, varjostuksia ja kiiltoefektejä, sisältö pyritään vastaavasti tuomaan esiin niin, että lopputulos voi hyvin olla kauniimpi kuin muilla alustoilla.

 

 

Apuohjelmia iOS-designereille

Xcode on asennettu, mitä nyt? Tässä kokoelma apuohjelmia ja muita resursseja, jotka helpottavat iOS-sovellusten kehitystä ja erityisesti käyttöliittymäsuunnittelua.

Templaattikokoelmat

Omnigraffle on suosikkityökaluni rautalankojen laatimiseen. Da5id:n kokoelma on paras tietämäni iOS-templaatti OmniGrafflelle.

Tuotantokelpoista jälkeä tarvittaessa Teehan & Lax:n Photoshop-kokoelma on mainio. Kannattaa malttaa nähdä sen verran vaivaa, että tekee 1x-grafiikat sille tarkoitetun tyylipohjan avulla, niin kuvat pysyvät mahdollisimman tarkkoina.

Liveview (ilmainen)

Liveview näyttää iPhone tai iPadin ruudulla valitun alueen tietokoneen työpöydältä. Tämä on hyödyllistä, jos haluaa tarkistaa, miltä grafiikat näyttävät retina-näytöllä ja että tekstit ovat varmasti luettavissa.

Sovelluksen avulla voi toteuttaa myös yksinkertaisen wizard of oz -demon operoimalla näkymiä tietokoneelta ja antamalla puhelimen käyttäjän käteen.

iExplorer (ilmainen)

 iOS-laitteissa ei ole tiedostojenhallintaa. Joskus on kuitenkin hyödyllistä nähdä, mitä tiedostoja minnekin kertyy. iExplorer on Mac-ohjelma, jolla pääsee selaamaan puhelimensa tiedostorakennetta.

xScope (29,99 $)

xScope tarjoaa vastaavan toiminnallisuuden kuin Liveview. Lisäksi sen avulla voi mittailla eri elementtien kokoja tietokoneen näytöltä ja lisätä apuviivoja. Tuleepa mukana virtuaalinen viivoitinkin. Apuviivoista on apua esim. Xcodessa, jonka omat viivat toimivat vähän kankeasti.

Ostin sovelluksen aikoinaan alennusmyynistä. Täysi hinta on hieman tyyris. Jos tarvitset vain viivoitinta, katso Free Ruler. Se on ilmainen, mutta toimii vähän bugisesti uusilla käyttöjärjestelmillä.

Mittaamisesta puheen ollen: itse käytän jatkuvasti kuvakaappausnäppäinkomentoa eri asioiden koon mittaamiseen. Painamalla komento + shift + 4 voi ottaa kuvakaappauksen halutusta näytön alueesta. Ominaisuutta voi käyttää myös elementtien kokojen selvittämiseen – ja kun painaa esciä ennen kuin päästää hiireen irti, säästää maailman turhalta kuvaruutukaappaukselta.

Hex color picker (ilmainen)

 Kuvakaapparin lisäksi Mac OS X:ssä on mainio pipettityökalu värien poimimiseen. Sen käyttöliittymä on peruja Next-ajoilta, ja pelkään pahoin, että moni ei edes tiedä sen olemassaolosta. Suurennuslasia klikkaamalla voi valita haluamansa värin kuin Photoshopin pipetillä. Ja mikä parasta, tämä toimii myös ohjelmien välillä.

Kätevää on myös siirtää värejä sovellusten välillä raahaamalla värin valitsimen alalaitaan.

Mac OS X:n värivalitsinta voi tehostaa asentamalla Hex color picker -laajennuksen. Sen avulla saa näkyviin suoraan värin heksa-arvon, mikä on hyödyksi myös web-suunnittelussa.

Skitch (ilmainen)

 Vakavamielisempään kuvakaappausten ottamiseen kannattaa hankkia Skitch. Se on yksi ohjelmista, joita ei voi suositella kylliksi. Kuvakaappausten ottamisen lisäksi Skitchillä voi tehdä niihin kätevästi merkintöjä: tekstiä, nuolia, vapaita tuherruksia. Paras puoli on kuvien jakaminen. Jos kuvan raahaa pois Skitchistä, siitä luodaan automaattisesti tiedosto kovalevylle ilman että kuvaa joutuisi itse erikseen tallentamaan.

Jos haluaa vaikkapa lisätä Jiraan kuvakaappauksen löytämästään bugista, ei tarvitse ensin tallentaa tiedostoa ennen kuvan lataamista selaimeen ja sitten etsiä uudelleen avaa-dialogissa, vaan riittää, että raahaa sen selaimeen suoraan Skitchistä. Kuvien lataaminen kaikkien nähtäville skitch.comiin käy sekin yhdellä klikkauksella.

Screenshot Journal (1,59 €)

Tietokoneen lisäksi kuvakaappauksia tulee helposti ottaneeksi valtavat määrät puhelimelta. Valitettavasti Apple on katsonut viisaaksi näyttää kuvakaappaukset samassa läjässä puhelimella otettujen valokuvien kanssa. Apuun tulee Screenshot Journal, joka poimii kuvakaappaukset erilleen kuvavirrasta ja tarjoaa keinoja kuvien hallintaan.

Jos tykkää nahkaefekteistä ja tikkauksista, sovellukseen kannattaa tutustua jo niiden vuoksi. Ovat keskimääräistä hienommat.

Kuvansiirtäjä

Mac OS X:n mukana tuleva kuvansiirtäjä ei ole tainnut saada ainuttakaan päivitystä sitten ensimmäisen Mac OS X -version, ja käyttöliittymä on muutamilta osin rasittava. Jos puhelimelta haluaa noutaa kuvakaappauksia, se on kuitenkin kevyempi vaihtoehto kuin iPhoto. Jos tiedät Kuvansiirtäjää paremman vaihtoehdon, kerro toki kommenteissa!

iOS-Simulator Cropper (ilmainen)

Laitteella kuvakaappauksien ottaminen on kaikesta huolimatta vähän jähmeää. Käyttöohjeita, promokuvia yms. varten on usein kätevämpää  ottaa kuvakaappaukset suoraan Xcoden Simulator-ohjelmasta. iOS-Simulator Cropper ottaa kuvakaappauksen pelkästään simulaattorissa pyörivästä ohjelmasta, nimeää sen halutulla tavalla ja lisää haluttaessa kuvan ympärille iPhone-kuoret kiiltoineen kaikkineen.

Myös status barin poistaminen kuvan ylälaidasta onnistuu helposti, jos vaikka haluaa lisätä kuvakaappaukset App Storeen Applen ohjeiden mukaan ilman palkkia.

iPhone Configuration Utility (ilmainen)

Sovellusten ja provisiointiprofiilien asentaminen onnistuu periaatteessa iTunesilla, mutta sillä on paha tapa synkronoida valtavia datamassoja joka välissä heti kun se löytää koneeseen kytketyn puhelimen. Kätevämpi työkalu on Applen tarjoama iPhone Configuration Utilyty. Sen avulla voi mm. asentaa .IPA-muotoisia sovelluksia laitteelleen, kun sellainen tarve tulee. Saatavilla myös Windowsille.

Quicklook plugin for provisioning profile files (ilmainen)

Provisiointiprofiilien kanssa tappelu on iOS-kehityksessä väistämättä vastaantuleva hupi. Tuskaa vähentää, jos voi kätevästi varmistua, että sovelluksen pitäisi teoriassa asentua halutulle laitteelle. Tämä kätevä lisäpalikka antaa Finderille kyvyn näyttää suoraan, mitkä testilaitteet sovelluksen provisiointiprofiiliin on lisätty.

UDID (ilmainen)

Jotta voisi varmistua, että oma puhelin on tuettu, pitäisi tietää puhelimen UDID-koodi. Sen saa selvitettyä iTunesilla, mutta Apple on tehnyt sen siinä määrin hankalaksi, että on usein helpompaa neuvoa ihmisiä asentamaan puhelimeen sovellus tätä varten. UDID on yksi näistä. Parempiakin saattaa olla.

Picturesque (11,99 €)

Törmäsin Picturesquehun vasta, mutta se näyttää lupaavalta. iPhone-sovelluksia tykätään usein esitellä heijastuksin je perspektiivitempuin kuorrutettuina. Picturesque tekee nämä yleisimmät efektit helposti ja antaa tallentaa kuvat myös läpinäkyvällä taustalla. Kätevä, jos kaipaat vapautusta Photoshopista.

 

Mobiiliselaimen tunnistaminen CSS:llä

Selainten tunnistaminen tulee monesti kuvioihin silloin, kun joko sivun tyylejä, logiikkaa tai sisältöä muokataan sopimaan erikokoisille näytöille tai mobiiliselaimelle. Tähän on olemassa monenlaisia tekniikoita, ja tässä blogipostauksessa esittelen tavan tehdä tämä CSS-sääntöjen avustuksella.

Media Queryn käyttö

CSS:ssä pystyy määrittämään CSS-tyylien säännöt sen perusteella, minkä levyinen ikkuna tai laite on.Tämä onnistuu CSS:n media query -ominaisuuden avulla alla kerrotulla tavalla. Parametreina voidaan käyttää esimerkiksi laitteen leveyttä ja korkeutta sekä pikselitiheyttä.

1. CSS-tyylitiedoston aktivoiminen headissa ehtojen perusteella

<link rel="stylesheet" media="screen and (min-device-width: 320px) and (min-device-pixel-ratio:2)" href="retina-styles.css"/>

2. CSS-säännön aktivointi ehtojen perusteella

@media screen and (min-device-width: 320px) and (max-device-width: 480px) and (min-device-pixel-ratio:2) and (-webkit-min-device-pixel-ratio:2) and (-moz-min-device-pixel-ratio:2) {
display:block;
}

3. CSS-tiedoston sisällyttäminen toiseen CSS-tiedostoon

@import url(styles-retina-iphone.css) screen and (min-device-width: 320px) and (max-device-width: 480px) and (min-device-pixel-ratio:2) and (-webkit-min-device-pixel-ratio:2) and (-moz-min-device-pixel-ratio:2)

Mobiilikehityksen kannalta tärkeimpiä parametrejä ovat:
min-device-width ja max-device-width, jotka rajoittavat tyylin käyttöä tietyn levyisille näytöille. Näillä saadaan sivuston tyylit mukautumaan mobiilinäytölle.

min-device-pixel-ratio tarkoittaa näytön “pikselitiheyttä”. Tyypillisen tietokoneen näytön ja peruspuhelimen arvo on 1, mutta esimerkiksi iPhone 4:llä ja iPhone 4S:llä tämä arvo on 2. Selitys tälle on ns. retina-näytössä: näytön koko on iPhone 3G:ssä ja iPhone 4:ssä on sama, mutta näytön leveys ja korkeus on kaksinkertainen. Tällöin sivustolla olevat kuvat näkyvät iPhone 4:n tarkemmalla näytöllä pikselöityneenä ja epätarkkoina, sillä käytetyn grafiikan resoluutio on liian pieni. Tämän säännön avulla voidaankin saada käyttöön tarkemmat grafiikat siihen pystyville näytöille.

@media handheld on kiinnostava parametri, mutta sen selaintuki on valitettavan rajallinen. Esimerkiksi Safari jättää tämän parametrin kokonaan huomiotta, joten parametri ei tunnista iPhonea. Tätä parametria en siis suosittele käytettävän.

orientation tarkoittaa puhelimen asentoa, eli onko puhelin vaaka- vai pystysuunnassa. orientation:landscape tarkoittaa että puhelinta pidetään vaakasuunnassa, kun taas orientation:portrait tarkoittaa pystysuuntaa.

Media query CSS3:n tuoma uusi ominaisuus, joka on jo kuitenkin nykyään erittäin laajasti tuettu. Ajantasaisen listan tuetuista selaimista löydät caniuse.com-sivustolta.

Media Queryt Qvikin kotisivuilla

Qvikin kotisivuilla on käytetty media queryjä sovittamaan sivuston ulkoasu näytön koon mukaiseksi. Sivustolla käytetään kolmea eri moodia: täysileveä, portrait ja mobiili. Täysileveässä moodissa käytettävät tyylit määritellään niin, että sen leveys on vähintään 1024 pikseliä:


@media screen and (min-device-width:1024px) {
...
}

Tällä leveydellä sivun kokonaisleveys on 1000 pikseliä. Yksi sivuston käyttöliittymäelementeistä on neljän, kiinteän leveyden laatikon ‘gridi’ joka näyttää kokoleveällä näytöllä tältä:

Jos tämä osuus näytettäisiin tällaisenaan pienemmällä näytöllä, boksit joko leikkaantuisivat, tai niitä joutuisi skrollaamaan ja zoomaamaan. Esimerkiksi tableteille (kuten iPad pystymoodissa, jonka leveys 768px) on tässä tapauksessa käytännöllistä esittää tämä gridi eri tavalla. Tyylitiedostossa nämä tyylit määritellään seuraavasti:


@media screen and (min-device-width:321) and (max-device-width:999) {

}

Tällä tavalla määritellyt tyylitiedostot näkyvät esimerkiksi iPhonen vaakatilassa ja iPadin pystytilassa. Alla kuvankaappaus Qvikin kotisivuilla:

Laatikot on asetettu 2×2 gridiin, jolloin ne ovat luettavia. Koska laatikoiden tarkoitus on tässä tapauksessa pysyä tasalevyisenä, niin ne eivät vie enää koko ruutua tilaa. On kuitenkin täysin mahdollista tehdä niin, että kaksi laatikkoa veisivät aina sen 50% ikkunan leveydestä. Tällöin niiden leveys määritellään CSS:ssä prosenttilukuna sen containerista.

Qvikin sivut on tehty myös näyttämään käytännölliseltä myös mobiililaitteella, eli 320px tai kapeammilla näytöillä:

Lisätietoa media queryjen käytöstä löytyy englanniksi W3C:n sivuilta.

Mitä voimme oppia Facebook-sovelluksen kotinäkymän kehityksestä?

Applen tarjoama standardiratkaisu iPhone-sovelluksen osiosta toiseen liikkumiseen on enimmillään viisipaikkainen tab bar. Jos on tarvetta useammalle osiolle, viimeiseksi valinnaksi voidaan laittaa kolme pistettä, ja sijoittaa tämän taakse listamuodossa lisäkohteita.

Apple tulee omissa sovelluksissaan toimeen tällä ratkaisulla, mutta usein on tarvetta toteuttaa navigaatio jotenkin muuten. Tärkeitä kohteita saattaa olla enemmän kuin viisi tai näytön pinta-ala haluttaisiin tehokkaammin käyttöön, eikä näytön alalaitaa raaskita varata navigointipalkille.

Facebookin iPhone-sovellus käytti alkuaikoinaan myös tätä ratkaisua. Ohessa kuvakaappaus versiosta 2.0 (cnet.com).

Kuvassa pistää erityisesti silmään vaikeakäyttöinen vieritettävä navigointipalkki välilehtirakenteen alapuolella. Muistan, ettei sen kanssa ollut mukava näpertää. Tab bar, välilehdet, vieritettävä palkki – on siinä hierarkiaa kerrakseen! Ei ihme, että Facebook päätti panna navigaation uusiksi sovelluksen 3.0-versiossa.

Versiossa 3.0 esiteltiin sittemmin varsin laajasti käytetty kotinäkymäpatterni, jossa päänavigaatio on koko ruudun kokoinen. Skaalautuminen hoidetaan samaan tapaan kuin iPhonen kotinäytöllä, näyttö kerrallaan vaakasuunnassa vierittämällä. (kuva Ars Technica)

Etuna on, että kohteita mahtuu näkyviin enemmän kuin tab bariin ja näkymästä saadaan visuaalisempi. Valikko ei myöskään haaskaa tilaa muilta näkymiltä. Haittapuolena on, että valikko täytyy avata erillisellä painalluksella.

Päädyimme vastaavaan ratkaisuun viime kesänä myös Taloussanomien iPhone-version kanssa. Ensin toteutetussa iPad-versiossa tärkeimmät osiot olivat mahtuneet näkyviin vaakasuuntaiseen palkkiin, mutta puhelimen ruudulla olisi tullut ahdasta emmekä halunneet tuoda ylimääräistä palkkia pystysuuntaista tilaa viemään, joten toteutimme kotinäkymäratkaisun.

Facebookiin tapaan sovellus aukeaa ensisijaisesti tärkeimpään uutisnäkymään, ja kotinäkymään pääsee erikseen painamalla. Käytimme painikkeen symbolina Facebookista poiketen talon kuvaa, sillä Facebookin käyttämä kuva toi liikaa mieleen list/grid-painikkeen.

Pian saimme huomata, että ratkaisu oli juuri mennyt muodista. Facebookin nykyinen versio toi mukanaan uuden version kotinäkymästä. Se ei enää olekaan erillinen koko ruudun näkymä, vaan näytön reunasta aukeava osittain valitun näkymän alle peittoon jäävä lista. Vierityssuunnaksi on valittu jälleen Applen standardin more-näkymän tapaan pystysuunta.

Jos vanha kotinappi näytti grid-valinnalta, uusi näyttää vastaavasti list-napilta…

Raa’asti painallusten määrällä analysoiden tämä lähestymistapa ei ole sen tehokkaampi kuin aiempi koko ruudun kotinäkymä. Yhtä lailla se vaatii yhden painalluksen aueatakseen ja samaan tapaan se estää nykyisen näkymän käytön valikon ollessa auki. Henkinen etäisyys osittain nykyisen näytön takaa aukeavaan valikkoon sen sijaan tuntuu lyhyemmältä.

Valikon vaikutelma ei ole yhtä visuaalinen kuin koko ruudun kotinäkymän ja mikä yllättävintä, listaan ei mahdu sen enempää kohteitatakaan. Aiempaan kotinäkymään mahtuu hakuluukku ja yhdeksän kohdetta. Uudessa listassa on hakuluukun lisäksi vain kahdeksan kohdetta.

Niin tai näin, uusi patterni on jo osoittautunut suosituksi. Google on ottanut sen käyttöönsa iPhonen Gmail-sovelluksessa oleellisella parannuksella: valikon saa näkyviin ja piiloon valikkonapin lisäksi sormella pyyhkäisemällä.

Viimeiseen asti hiotusta käyttöliittymästään tunnettu oman elämänsä facebook Path on toteuttanut kenties hienoimman version tästä lähestymistavasta. Valikko aukeaa Gmailin tapaan pyyhkäisyeleellä, mutta toimii huomattavasti pehmeämmin joustopomppuineen kaikkineen. Vastaavasti osiosta toiseen siirryttäessä se animoituu hetkeksi pois näkyvistä ja palaa takasin niin, että näkymä on jo valmiiksi piirretty.

Animaatiot Androidissa

Helppo tapa tehdä applikaatiostasi hienompi on lisätä animaatioita. Käymme tässä läpi yksinkertaisia animaatioita ja niiden käyttämistä applikaatiossasi. Tässä esimerkissä keskitymme elementtien sijainnin muuttamiseen animaatioilla.

Animaatioita voi tehdä kahdella tavalla. Joko suoraan koodissa, tai määritellä erikseen xml:ssä. Jos animaatiossa ei tarvitse laskea suoritusaikana mitään tulisi ne tehdä xml:ssä, että koodi on selkeämpää.

Voit ladata esimerkin lähdekoodin täältä.

Animaatio koodissa

Animaation luominen koodissa on hyvin suoraviivaista. Uusi animaatio olio luodaan halutunlaisesta animaatiotyypistä. Tässä tapauksessa:

TranslateAnimation (int fromXType, float fromXValue,
                    int toXType, float toXValue,
                    int fromYType, float fromYValue,
                    int toYType, float toYValue)

Type attribuutit kertovat onko animoitava matka absoluuttinen vai suhteellinen. Suhteellinen matka voi riippua joko itse animoitavasta näkymästä, tai sen vanhemmasta:

Animation.ABSOLUTE
Animation.RELATIVE_TO_SELF
Animation.RELATIVE_TO_PARENT

Koodissa olen käyttänyt absoluuttista siirtymätyyppiä, sillä haluan animoida valikon liikkumisen vain piiloon jäävältä osiolta, jonka olen asettanut 100dp:ksi. Huomaa että koodissa täytyy ottaa huomioon dp:t, eli näytön tiheydestä riippumattomat pikselit. Näytön tiheyden saat:

float scale = getResources().getDisplayMetrics().density;

Koska absoluuttisia siirtoja ei voi ilmoittaa dp:nä on annetut dp:t kerrottava näytön tiheydellä, jotta saat dp:n arvon pikseleinä.

Animaatiolle tulee asettaa kesto, minkä aikana animaatio suoriutuu loppuun. Kesto annetaan millisekuntteina.

animation.setDuration(500);

Animaation loputtua liikutettu näkymä ei suoraan jää sille asetettuun paikkaan, vaan sen paikka täytyy asettaa koodissa ja vasta, kun animaatio on päättynyt. Muuten kuva hyppää asettamaasi paikkaan suoraan.

Huomaa:

Huomaa, että animaatio lähtee aina animoidun näkymän sen hetkisestä asemasta. Aseman pystyy muuttamaan myös automaattisesti:

animation.setFillEnabled(true);
animation.setFillAfter(true);

Tätä tapaa voi käyttää sekä koodissa, että xml:ssä, mutta jos kuvasi reagoi painalluksiin sen oikea paikka on edelleen siellä, missä se on xml layoutissa asetettu. Eli kuvan tai napin paikka on oikeasti eri, kuin missä se näyttäisi olevan. Tästä syystä tätä tapaa ei voi käyttää tässä esimerkissä. Jos esimerkiksi valikossa olisi nappula se kyllä tulisi näkyviin, mutta sen painalluksen tunnistava osuus olisi edelleen näytön ulkopuolella, eikä nappulaa näin voisi painaa.

Lopuksi animaatio käynnistetään sille näkymälle, mitä halutaan liikuttaa:

slider.startAnimation(animation);

Animaatio XML:ssä

Animaatioiden määrittäminen XML:ssä on melko suoraviivaista. Tarvittavat ohjeet ja listat mahdollisista elementeistä löytyvät Googlen Android developer-sivustolta.

Animaatiot tallennetaan applikaatiosi resurssi kansioon res/anim/animaation_nimi.xml. Animaatio voi sisältää useita animaatioita, kuten liikkumista ja koon muutosta. Nämä animaatiot tulee asettaa <set>-elementin sisälle. Jos animaatiosi koostuu vain yhdestä osasta ei <set>-elementin käyttäminen ole pakollista. Yllä olevasta linkistä löytyy mahdolliset animaatiotyypit ja niiden parametrit.

Tähän esimerkkiin tein yksinkertaisen siirtymisanimaation, missä kuva tulee näytön vasemmasta laidasta sisään. Animaatiolle on asetettu kesto, lähtöpaikka ja lopullinen paikka. Tässä tapauksessa kuva on koko näytön kokoinen ja aloittaa -100%:sta ja siirtyy normaaliin paikkaansa. X-akselin negatiiviset arvot ovat ruudun vasemmalla puolella ja positiiviset oikealla puolella.

<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
   android:interpolator="@android:anim/decelerate_interpolator"
   android:duration="500"
   android:fromXDelta="-100%"
   android:toXDelta="0"
   android:fillEnabled="true"
   android:fillAfter="true"
   />

Animaatio ladataan koodissa:

Animation slideFromLeft = AnimationUtils.loadAnimation(this, R.anim.slide_in_from_left);

Muista asettaa animoitu näkymä näkyväksi, ennen kuin aloitat animaation, jos näkymän näkyvyys on poissa. Tai jos viet näkymää pois ruudulta aseta näkymä pois animaation jälkeen. Muuten animaatio aloitetaan samalla tavalla, kuin koodiesimerkissä.

Vinkki

Mukava tapa sulkea valikoita, jotka eivät peitä koko näyttöä on tehdä tyhjän osan peittävä näkymä, jota painamalla valikko menee kiinni. Tässä esimerkissä teemme slidecontainer:ssä FrameLayoutin nimeltä hider, joka tekee saman asian, kuin välilehden painaminen. Kun valikko on ylhäällä piilotamme hiderin, niin ettei sitä pysty painamaan. Tämä lisää valikon käytettävyyttä.

Valikot olisi myös hyvä toteuttaa omina aktiviteetteinään, mutta tässä esimerkissä näin ei voi tehdä, sillä valikon alareuna on osittain näkyvissä koko ajan. Aktiviteetti voi olla vain osittain toisen päällä, mutta alempaa aktiviteettiä ei voi käyttää.

Androidin resurssit, orientaatio ja kuvan tarkkuus

Mobiililaitteille koodatessa tarvitsee usein ottaa huomioon, että käyttäjä saattaa käyttää laitettaan muussakin, kuin pystysuunnassa. Ohjelmiston ulkonäköä eri asennoissa tulisi miettiä ja vain harvoin orientaation lukitseminen yhteen asentoon on toimiva ratkaisu.

Androidissa pystyy hyvin pienellä vaivalla tekemään uusia pohjia (layout) tai käyttämään eri kuvia riippuen laitteen orientaatiosta. Android ottaa nämä pohjat ja kuvat automaattisesti käyttöön orientaatiosta riippuen, jos ne on asetettu oikeisiin kansioihin ja nimetty oikein.

Projektin resurssien peruskansiot ovat drawable ja layout. Näihin kansioihin asetetut resurssit tulevat köyttöön näytön tarkkuudesta tai orientaatiosta riippumatta. Android kuitenkin hakee resursseja ensisijaisesti kansiosta, joka vastaa nöytön tarkkuutta ja/tai orientaatiota. Mikäli pohja main.xml löytyy kansiosta “layout-land” sekä “layout”, valitaan tiedosto “layout-land”-kansiosta, kun laitetta pidetään vaakatasossa ja layout-kansiosta muissa tapauksissa.

Uutta projektia luotaessa Eclipse ei luo kaikkia kansioita suoraan, vaan joudut itse lisäämään ne. Kansioiden nimissä on aina joko “drawable” tai “layout” alussa. Alun jälkeen voi kansioille antaa viivalla eroteltuna sääntöjä siitä millaisessa tilanteessa tämän kansion resursseja tulisi käyttää. Täydellinen lista käytettävissä olevista parametreista löytyy osoitteesta:
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources

Kuvien kanssa voi helposti tulla ongelmia, jos xml pohjat vaativat erilaisia kuvia eri orientaatioissa. Huono ratkaisu olisi tehdä uusi pohja haluttuun orientaatioon ja uudet kuvat, mitkä nimettäisiin jokainen yksilöllisesti. Xml:n osista, kuten kuvista on kuitenkin mahdollista tehdä uudet versiot samalla nimellä oikeisiin kansioihin. Näin Android osaa hakea oikean kuvaresurssin orientaatiosta tai resoluutiosta riippuen ilman xml-pohjan muuttamista.

Kuvien tarkkuuksien kanssa kannattaa olla varovainen. Mikäli Android löytää kuvan drawable-hdpi kansiosta, mutta ei drawable-mdpi kansiosta se automaattisesti skaalaa kuvan pienemmäksi. Tämä johtaa usein suttuisiin kuviin. Android 3.2 on tuonut lisää mahdollisuuksia näyttöjen koon ja tarkkuuden erittelyyn ja näihin perehdytään lähemmin erillisessä artikkelissa.

Jos kuva on vain drawable-kansiossa sitä ei skaalata vaan näytetään sellaisenaan. Drawable-kansioon ei tulisi laittaa kuvia, vaan täällä on suositeltavaa pitää vain xml:llä luotuja bittikarttoja tai kuvaresursseja, joiden luomista käsittelen myöhemmässä artikkeliss

Mikäli samaa kuvaa käytetään eri näyttötarkkuuden laitteilla tulevat kuvat erittäin isoiksi huonoilla tarkkuuksilla tai erittäin pieniksi suurilla tarkkuuksilla. Tarkempi kuvaus kuvien tarkuuksien käytöstä löytyy:
http://developer.android.com/guide/practices/screens_support.html#density-independence

Omat layout elementit Androidissa

Android tarjoaa runsaan valikoiman erillaisia graafisia elementtejä. Usein tulee kuitenkin vastaan tilanne, jossa näiden valmiiden elementtien toiminnallisuus ei riitä. Java ja Android antavat kuitenkin tehokkaan ja hyvän tavan toteuttaa omia layout luokkia. Graafiset elementit periytyvät aina View tai ViewGroup luokista. Helpoin tapa aloittaa omien näkymien tekemisen on tekemällä yläluokka jo olemassa olevasta layout elementistä, jonka toiminnallisuus on mahdollisimman lähellä haluttua.

Oman näkymäluokan tekeminen antaa tarkan kontrolliin elementin ulkonäköön ja toiminnallisuuteen. Näkymäluokkia on myös mahdollisuus yhdistää ja näin sitoa useiden elementtien välinen toiminnallisuus yhteen. Esimerkiksi listan aktiivihakuun voi yhdistää tekstikentän ja listan samaan elementtin, näin ei aktiivihaun koodia tarvitse tuoda aktiviteetin muun toiminnallisuuden kanssa samaan paikkaan. Useita elementtejä yhdisteltäessä helpoin tapa on määritellä elementit erillisessä xml:ssä ja käyttää LayoutInflateriä luomaan näkymä.

Tässä esimerkissä luodaan aktiivihaun toiminnallisuus oman graafisen elementin sisään. Elementti sisältää EditText kentän ja ListViewn:



haku.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
     xmlns:android="http://schemas.android.com/apk/res/android"
     android:orientation="vertical"
     android:layout_width="fill_parent"
     android:layout_height="fill_parent">
     <EditText
          android:id="@+id/search_field"
          android:layout_height="wrap_content"
          android:layout_width="fill_parent"
          />
     <ListView
     android:id="@+id/search_list"
     android:layout_width="fill_parent"
     android:layout_height="fill_parent"
     />
</LinearLayout>

Aktiivihaku.java:

...
public class Aktiivihaku extends ViewGroup {

View view;

/**
* Luontimetodi aktiivihaku näkymälle. Luo näkymän haku.xml perusteella.
*
* @param context Näkymän yhteys ohjelman yleiseen informaatioon
* @param attrs xml:ssä määritellyt atribuutit
*/
public Aktiivihaku(Context context, AttributeSet attrs) {
super(context, attrs);

LayoutInflater inflater = (LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
view = inflater.inflate(R.layout.haku, this);

list = (ListView) view.findViewById(R.id.search_list);
sortField = (EditText) view.findViewById(R.id.search_field);

adapter = new ListAdapter(getContext(), 0, 0, COUNTRIES);
list.setAdapter(adapter);

sortField.addTextChangedListener(new TextWatcher() {

@Override
public void onTextChanged(CharSequence s, int start, int before, int count) {
}

@Override
public void beforeTextChanged(CharSequence s, int start, int count, int after) {
}

@Override
public void afterTextChanged(Editable s) {
     adapter.getFilter().filter(sortField.getText());
}
});

}

...

Yleisin käyttö omille näkymä luokille on yhden tai muutaman toiminnallisuuden muuttaminen, tämä onnistuu korvaamalla (override) olemassaolevan metodin samannimisellä metodilla, näin voi helposti esimerkiksi poistaa

Hyvä ohjelmointityyli Androidilla on myös pitää aktiviteettiluokan koodi mahdollisimman yksinkertaisena, eikä rasittaa sitä esimerkiksi omien kuuntelijoiden tekemisellä aktiviteettiluokassa ja antamalla niitä xml:ssä määritellyille elementeille.

Itse tehdyn layout elementin voi xml:ssä viitata paketin kokonimellä ja komponentin nimellä. Esimerkiksi fi.androidkehitys.aktiivihaku paketissa olevaan Aktiivihaku.java luokkaan viitataan XML:ssä seuraavasti:

<fi.androidkehitys.aktiivihaku.Aktiivihaku
      android:layout_width="fill_parent"
      android:layout_height="wrap_content"
      />