Sijaintipalvelut iOS-applikaatioissa 2 – Geokoodaus

Edellinen kirjoitukseni oli pintaraapaisu iOS SDK:n CoreLocation-kirjastoon. Kävin läpi kuinka laitteen sijainti saatiin haettua CLLocationManager-luokan avulla leveys- ja pituuspiirin koordinaatit sisältävän CLLocation-olion muodossa. Kuitenkaan pelkät koordinaatit eivät sellaisenaan ole kovin kiinnostavaa tai hyödynnettävää tietoa ja sen takia  koordinaatteihin liittyy usein kysymyksiä kuten “missä tämä paikka on?” ja “mitä täällä paikassa on?”. Vastauksen näihin tarjoaa geokoodaus.

Geokoodaus on osoitteen muuttamista koordinaateiksi, ja käänteinen geokoodaus koordinaattien muuttamista osoitteeksi. CoreLocation tarjoaa kummankin palvelun CLGeocoder-luokassa. Geokoodauksen käyttö ei edellytä paikkatietojen käytön hyväksyntää käyttäjältä. Luokka sisältää kolme metodia geokoodaukseen ja yhden metodin käänteiseen geokoodaukseen.

  • geocodeAddressString:completionHandler: Ottaa parametrinä vapaamuotoisen osoitteen, esimerkiksi “Urho Kekkosen katu 5, 00100 Helsinki”
  • geocodeAddressString:inRegion:completionHandler: Tekee samaa kuin edellinen, mutta toisena parametrina voi antaa aluetta kuvaavan CLRegion-olion jonka sisällä olevia kohteita suositaan tuloksia järjestellessä.
  • geocodeAddressDictionary:completionHandler: Parametrina annetaan NSDictionary johon voi määritellä tarkemmin haettavan alueen esim. kaupungin tai maan perusteella. Esimerkiksi parametrinä annettu NSDictionary @{(id)kABPersonAddressCityKey : @”St. Petersburg”, (id)kABPersonAddressCountryKey : @”United States”} palauttaisi Floridassa olevan St. Petersburgin kaupungin. Dictionaryn kABPersonAddressCountryKey-avaimen arvon ollessa @”Russia“, palauttaa geokoodaaja itänaapurin entistä pääkaupunkia kuvaavan vastauksen.
  • reverseGeocodeLocation:completionHandler: palauttaa listan koordinaatteja vastaavia CLPlacemark-olioita. Parametrina metodi ottaa CLLocation-olion. CLLocation-olion voi luoda ja alustaa CLLocation-oliolla.
Kaikilla neljällä metodilla on samanlainen completion handler. Se sisältää listan CLPlacemark-olioita (joita normaalisti on yksi kappale listassa) ja NSError-olion. CLGeocoding-oliolla on myös metodit isGeocoding ja cancelGeocode. Geokoodauksen kumoaminen saa aikaan kCLErrorGeocodeCanceled-tyyppisen virheilmoituksen.

Mitä täällä on?
CLPlacemark on luokka paikkatietojen esitystä varten. Oliosta löytyy alueesta riippuen mm. seuraavia tietoja:
  • paikan koordinaatit (CLLocation-olion muodossa)
  • Listan alueen maamerkeistä (esim. Golden Gate -silta San Franciscossa), listana NSString-olioita
  • paikan osoitetiodot Address Book -yhteensopivina avain-arvopareina
  • paikan nimi
  • kaupunki ja kaupunginosa
  • mahdollistet läänit ja maakunnat joiden osa paikka on
  • maa, johon paikka kuuluu, sekä maakoodi
  • vesistö tai valtameri jossa paikka sijaitsee

 Vaihtoehto Applen geokoodauspalvelulle
Applen tarjoaman geokoodauspalvelun lisäksi Googlella on Geokoodaus-API. Googlen paikkatietokanta on epäilemättä paljon kattavampi ja tarkempi kuin Applen oma, mutta Applen valmiit CLGeocoding-luokat tarjoavat hyvin nopean tavan muuttaa koordinaatteja informaatioksi ja toisin päin. Yleensä Applen palvelu riittää katuosoitteiden ja kaupunkien nimien muuttamisen koordinaateiksi ja toisin päin. Googlen palvelussa kehittäjä joutuisi itse parsimaan JSON- tai XML-muotoisen vastauksen itse. Mielestäni Applen geokoodauspalvelun suurin puute on maamerkkien, kauppojen, ravintoloiden yms. kiinnostavien kohteiden täydellinen puute. Siitä huolimatta CLGeocoder on riittänyt useimpiin kehittämiini applikaatioihin.

Sijaintipalvelut iOS-applikaatioissa

Nykyaikaisista älypuhelimista ja tableteista löytyy välineet käyttäjän sijainnin selvittämiseen. Sijaintia voi käyttää mobiiliapplikaatioissa monella tavalla: käyttäjälle voidaan esimerkiksi tarjota lähiympäristöön liittyvää tietoa – esimerkiksi paikallisuutisia, tai käyttäjää voi muistuttaa hänen saapuessaan tärkeään paikkaan. Liikuntasuorituksia kirjaava applikaatio voi muodostaa juoksureitistä kartan tallennettujen GPS-päivitysten perusteella.
iOS SDK tarjoaa monipuolisen paikannuskirjaston nimeltään CoreLocation. Kirjasto toimii rajapintana koodin ja mobiililaitteen fyysisten mittalaitteiden välillä mahdollistaen mm. seuraavat asiat:
  • laitteen sijainnin paikantaminen, parhaimmillaan alle kymmenen metrin tarkkuudella
  • viestittäminen laitteen sijainnin muuttumisesta
  • määritellyille alueille liikkumisen tarkkailu
  • sijainnin tarkkailu ja siitä tiedottaminen applikaation ollessa taustalla
  • applikaation käynnistäminen sijainnin muuttuessa merkittävästi
Paikannuksen musta laatikko
Mobiililaitteet hoitavat laitteen paikannuksen monella tavalla: GPS-paikantimella, Wifi-tukiasemien avulla ja kolmiomittaamalla puhelinmastoja. CoreLocation valitsee automaattisesti sopivimman paikannusmenetelmän, ja tarvittaessa yhdistelmää useasta menetelmästä. Syy automaattiseen paikannusmenetelmän valintaan on laitteen virrankulutuksen minimointi ja paikannusnopeuden maksimointi.
Vaikka paikannusmenetelmän valinnan läpinäkymättömyys kuulostaa kehittämistä rajoittavalta, helpottaa se kehittäjän työtä. Käytännössä kehittäjän tarvitsee valita haluttu sijainnin tarkkuus ja kirjasto hoitaa kaiken muun.
Paikannusprosessi tapahtuu kahden luokan avulla jotka ovat CLLocationManager ja CLLocation.
  • CLLocationManager paikantaa sijiannin ja lähettää tietoa sijainnin muutoksista CLLocationManagerDelegate-protokollan kautta päivityksiä kuuntelevalle delegaatille. Kaikki paikannukseen liittyvät muutettavat asetukset löytyy tästä luokasta
  • CLLocation kuvaa yhtä paikkatietopäivitystä. Olio sisältää aikaleiman, koordinaatit ja päivityksen tarkkuuden metreinä. Mukana on myös tieto liikkeen suunnasta ja nopeudesta.
Kertakäyttöinen vai jatkuva paikannus?
Moni applikaatio tarvitsee sijaintitietoa vain kerran, esimerkiksi käynnistyessään. Yleensä kerran haettu paikkatieto riittää useimpiin tarpeisin. Silloin on järkevää että CLLocationManager hakee käyttäjän sijaintia vain kun paikkatietoa ei ole haettu, tai viimeisin paikkatietopäivitys on liian vanha tai epätarkka. Yleensä applikaatioihin riittää yksi jaettu CLLocationManager-olio jonka location-propertyä muu applikaatio käyttää. Jaettu CLLocationManager laitetaan silloin hakemaan käyttäjän sijaintia, ja haku päätetään kun tarpeeksi tarkka sijainti on löydetty. Tämän jälkeen jaetussa CLLocationManager-oliossa on tallessa viimeisin haettu sijainti tallennettuna location-propertyyn josta sijaintia tarvitsevat applikaation osat sitä voivat kysyä. On syytä tarkastaa location-propertyn aikaleima, sillä applikaation käynnistyessä tai palatessa taustalta viimeisin sijaintipäivitys voi olla liian vanha kertomaan käyttäjän nykyisen sijainnin.

Paikannus applikaation ollessa taustalla
Sijainnin paikantamista voi jättää päälle kun applikaatio siirtyy taustalle ajoon. Paikannusmenetelmiä on kolme erilaista:
  1. startUpdatingLocation – jatkuva ja tarkka sijainnin päivitys
  2. startMonitoringSignificantLocationChanges – epätarkka ja harvoin päivittyvä sijainnin seuraaminen
  3. startMonitoringForRegion: – tarkkailee liikkuuko laite määritellyn alueen sisälle tai pois alueelta. Alueita voi olla seurannassa yhtäaikaisesti 20 kappaletta.

Kolmesta edellämainitusta menetelmästä ensimmäinen on tarkin, ja sen ollessa käynnissä applikaatio pysyy koko ajan taustalla ajossa. Tämä on paras vaihtoehto jos paikannusta käyttää esimerkiksi liikuntasovellukseen tai reittioppaaseen. Haittapuolena on jatkuva akun kuluminen.

Kaksi jälkimmäistä seurantatapaa kuluttaa vähemmän akkua kuin ensimmäinen, eikä applikaatio jää päälle taustalle. Nämä menetelmät kuitenkin käynnistävät applikaation, ja sijaintipaikannus pysyy päällä vaikka laitteen sammuttaisi ja käynnistäisi uudestaan.

Sijaintipalveluiden käyttö taustalla XCode-projektiss
a
  1. lisää CoreLocation.framework projektiin.
  2. Ota käyttöön Background modes Capabilities-näkymästä. Se löytyy projektin targetista.
  3. Valitse Location updates. Applikaatio saa nyt päivityksiä sijainnista ollessaan taustalla.
CoreLocationin haasteet ja ongelmat
Laitteen sijainnin hakeminen yksittäistä käyttökertaa varten ei ole niin suoraviivaista kuin se voisi olla. Sijainti toimitetaan asynkronisesti CLLocationManagerDelegate-protokollan kautta asynkronisesti. Ei siis ole olemassa suoraa myLocation = getLocation() -tyylistä tapaa hakea sijaintia. Helpoin tapa hakea laitteen sijainti kerra on kutsua CLLocationManager-luokan startUpdatingLocation-metodia. Kutsu käynnistää paikannuksen, ja lähettää normaalisti 3-4 locationManager:didUpdateLocations: -kutsua delegaatille sijainnin päivittymisestä. Paikannus kannattaa lopettaa silloin kun kutsujen mukana tulevien CLLocation-olioiden horizontalAccuracy-attribuutti on tarpeeksi pieni, eli paikannettu sijainti on riittävän tarkka applikaation tarpeisiin.
Haettavan sijainnin halutun tarkkuuden voi määritellä CLLocationManager-olioon, desiredAccuracy-propertyyn. Halutulla sijainnin tarkkuudella on suuri merkitys paikannuksen nopeuteen ja laitteen virran kulutukseen, joten on suositeltavaa että haettavan sijainnin tarkkuus on niin pieni kuin se on välttämätöntä applikaatiolle. Esimerkiksi paikallissäätä tai paikallisuutisia näyttävä applikaatio voi hyvin käyttää kCLLocationAccuracyThreeKilometers-tarkkuutta, kun taas juoksureittiä tallentava applikaatio vaatii tarkimman mahdollisen tarkkuuden, eli kCLLocationAccuracyBest-tarkkuuden.

Lopuksi
Tämä kirjoitus esitteli pintapuolisesti CoreLocation-kirjaston mahdollisuuksia. Moni mielenkiintoinen ja hyödyllinen kirjaston osa, kuten iBeacon-majakat ja CLGeocoder-geokoodauspalvelu, jäivät tässä kirjoituksessa esittelemättä.

Sijaintipalveluiden hyödyntäminen tekee applikaatiosta tilannetietoisen, mutta sijaintipalveluita käyttäessä pitää punnita sijainnista saadut hyödyt ja nopeammin tyhjenevän akun haitat tarkkaan.

OUYA, Android-konsoli

Kesälomalta paluu sorvin ääreen voi olla raskasta tai hauskaa… Kesälomalla hankittujen lelujen kanssa siitä onneksi saa hauskaa.

OUYA on Kickstarter-rahoituksen avulla luotu Android 4.1 -konsoli, jossa pyörivät kaikki normaalit Android-applikaatiot ilman suurempaa vaivaa. Konsoliin saa helposti ladattua SDK:n, jonka avulla ohjainta voi käyttää applikaatioissaan, mutta hiirellä ja näppäimistölläkin voi konsolia suoraan käyttää.

OUYA ei ole kovin tehokas konsoli eikä pelitarjonta ole vielä kovin laaja, tätä artikkelia kirjoitettaessa vain 384 peliä, mutta 99$ hintansa puolesta se on hyvä hankinta arcade pelien pelaamiseen olohuoneen sohvalla kavereiden kanssa.

Yrityksille OUYA tarjoaa halvan ja helpon ratkaisun tarjota interaktiivista sisältöä asiakasnäyttöihin. Valmiin applikaation kääntäminen ja asentaminen OUYA:lle on hyvin helppoa. Kehittäminen OUYA-konsolille ei ole yhtään sen vaikeampaa kuin mille tahansa muulle Android-laitteelle. Toki pieniä muutoksia joudutaan tekemään käyttöliittymään, jotta normaalisti kosketusnäytölle tarkoitettua applikaatiota voi käyttää peliohjaimella tai hiirellä. Kosketusnäytön korvaaminen hiirellä tai muulla ohjaimella johtaa helposti hyvin heikkoon käyttökokemukseen.

 

Asentaaksesi minkä tahansa applikaation OUYA:lle pitää sinun voida ladata applikaation .apk-tiedosto Internetistä. Mene OUYA:n kotinäkymän MAKE-valikkoon ja sisäänrakennetulla Internet-selaimella lataa APK-tiedosto. Tämän jälkeen palaa päävalikkoon, mene MANAGE-valikkoon, valitse SYSTEM ja siellä valitse ADVANCED. Tämä on jokaiselle Android-käyttäjälle tuttu asetukset-valikko Androidissa. Mene listassa alaspäin ja valitse Storage, jonka sisällä valitse Download. Täältä löydät juuri lataamasi APK-paketin ja asentaminen onnistuu ohjaimen O-napilla. Tämän jälkeen applikaatio löytyy samasta MAKE-valikosta kuin OUYA:n Internet-selain.

Samaan MAKE-valikkoon tulevat myös applikaatiot, jotka itse kehität ja asennat tietokoneen ADB:n avulla microUSB:n kautta.

Kehittäminen OUYA:lla

Kaikki OUYA-konsolit toimivat applikaatioiden kehittämiseen ilman maksuja tai muutoksia konsoliin. Jotta saat OUYA:n toimimaan normaalissa Android-kehitysympäristössäsi Macilla sinun täytyy vain lisätä kolmannen osapuolen USB Hex ID (0x2836) adb_usb.ini -tiedostoon .android-hakemistossa ja käynnistää ADB uudelleen. Tarkemmat ohjeet myös Windows-koneille on katsottavissa videona OUYA developers -sivustolta. Tämän jälkeen OUYA-konsolisi näkyy Eclipsessä ja ADB:ssä samalla tavalla kuin mikä tahansa muu Android-laite.

Seuraavaksi lataa OUYA Development kit (ODK) osoitteesta https://devs.ouya.tv/developers/odk, kopioi libs\-hakemistosta ouya-sdk.jar ja lisää se omaan Android-projektiisi. Tämän jälkeen ohjaimen komennot saa kiinni oman Activity -luokkasi onKeyDown() ja onGenericMotionEvent() -metodeista.

Tein tätä artikkelia varten yksinkertaisen applikaation, joka käyttää ODK:ta siirtelemään ImageView:tä FrameLayoutin sisällä.

Ota ohjain käyttöön Activity-luokan onCreate()-metodissa:

@Override
protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);
	OuyaController.init(this);
}

Tunnista ohjaimen komennot:

@Override
public boolean onKeyDown(final int keyCode, KeyEvent event) {
	switch (keyCode) {
		case OuyaController.BUTTON_O:
			Log.d(TAG, "OUYA button O");
			break;
		case OuyaController.BUTTON_U:
			Log.d(TAG, "OUYA button U");
			break;
		case OuyaController.BUTTON_Y:
			Log.d(TAG, "OUYA button Y");
			break;
		case OuyaController.BUTTON_A:
			Log.d(TAG, "OUYA button A");
			break;
	}
	return true;
}
@Override
public boolean onGenericMotionEvent(final MotionEvent event) {
// Joystick
	if ((event.getSource() & InputDevice.SOURCE_CLASS_JOYSTICK) != 0) {
		float LS_X = event.getAxisValue(OuyaController.AXIS_LS_X);
		float LS_Y = event.getAxisValue(OuyaController.AXIS_LS_Y);
	}
	return true;
}

Tämän jälkeen voit tehdä ohjaimen antamilla komennoilla mitä itse haluat.
Koko koodin ja Eclipse projektin saat ladattua Githubista:
https://github.com/Androidkehitys/OUYA

Onnea pelikehitykseen! Palataan leikkimään telkkujen kanssa, kun Cromecast saapuu postissa.

Windows Phone 8 ja parantunut HTML5-tuki

Windows Phone 7 -käyttöjärjestelmän yhtenä huonoimmista puolista on pidetty sen surkeaa selainta – Internet Explorer 9 -selaimen mobiiliversion tuki HTML5- ja CSS3-teknologioille oli aivan surkea. Myös suorituskyky vähänkin edistyneimmillä verkkosivuilla oli huono ja buginen. Windows Phone 8 käyttöjärjestelmä toi tähän selvän parannuksen, ja sen Internet Explorer 10 -selain tukee uusia web-teknologioita huomattavasti paremmin. Tämä tekee web-teknologioista yhä houkuttelevamman palveluntarjoajien näkökulmasta.

Parempi suorituskyky, sulavammat animaatiot, …

Mobiili IE9:n suurimmat ongelmat liittyivät toimimattomiin animaatioihin, mahdottomuteen rekisteröidä kosketus- ja raahaustapahtumia, puutteeliseen ja bugiseen CSS-tukeen sekä fiksatun positioinnin puuttumiseen. Näistä seurasi se, että mobiiliweb-sovellukset toimivat IE9:ssa parhaimmillaankin vain keskinkertaisesti. Tämän vuoksi esimerkiksi yksi mobiilimaailman tunnetuimmista ja vanhimmista frameworkeista, Sencha Touch, ei tue Windows Phone 7 -käyttöjärjestelmää lainkaan. jQuery Mobile -sovellukset ovat sentään funktionaalisia, mutta ne eivät toimi läheskään niin hyvin kuin Android- ja iOS-alustoilla.

Windows Phone 8 toi näihin edellä mainittuihin asioihin huomattavia parannuksia. CSS3-animaatiot toimivat – ja vieläpä erittäin hyvin. Esimerkiksi keskihintainen Nokia Lumia 620 -puhelin suoriutuu niistä erinomaisesti. Toinen huomattava parannus on elementtien positiointi pysyvästi sivun ylä- ja alaosaan CSS:n position:fixed; -määrittelyllä. Se toimii jopa paremmin kuin monissa iOS- ja Android-laitteissa. CSS3-tuesta myös mm. 3D-transformaatiot, geolokaatio ja fonttimäärittelyt ovat tuettuja.

jQuery Mobile toimii aiempaa huomattavasti paremmin, ja myös Sencha Touchista on tullut version 2.2, jolla tuotetut sovellukset toimivat hyvin myös Windows 8 -käyttöjärjestelmässä. Lisätietoja Windows Phone 8:n CSS3- ja HTML5-tuesta löytyy Windows Phone Dev Centerista.

Suurin ongelma Windows 8 -selaimessa tuntuu sen sijaan olevan interaktio raahattavien objektien kanssa. Verkkosivut kyllä ottavat kosketuksia vastaan, mutta ainakin jQuery Mobilen slider-komponentti toimii tahmeasti. Loppujen lopuksi Windows Phone 8 on web-kehittäjille erittäin tervetullut päivitys, joka mahdollistaa sovellusten kehityksen myös yrityspuhelimena suosituille Windows Phone -puhelimille.

Harmittavasti Windows Phone 7 -laitteita ei pysty päivittämään Windows Phone 8 -käyttöjärjestelmään, vaan WP8-laitekanta vahvistuu vain sillä että kuluttajat ostavat uusia WP8-puhelimia. Tästä johtuen WP8-markkinaosuus on vielä suhteellisen pieni, mutta vahvistuu tukevasti päivä päivältä.

Nokia tekee Suomessa Windows Phonesta suositun

Nokia on ollut perinteisesti vahvoilla Suomen markkinoilla, ja tekee Suomen markkinasta kansainvälisesti poikkeuksellisen käyttöjärjestelmien näkökulmasta. StatCounterin tilastojen perusteella (kuvat alla) Windows Phone -käyttöjärjestelmän markkinaosuus oli toukokuussa 2013 13.66%, kun Androidin luku oli 24.75% ja iOSin 23.71%. Suomen suosituin käyttöjärjestelmä on hieman yllättäen S40, joka toimii Nokian budjettipuhelinten käyttöjärjestelmänä ja on haukannut peräti 34.18% markkinaosuuden. Ero maailmanlaajuisiin tilastoihin on huomattava, Windows Phonen maailmanlaajuisen markkinaosuusuuden ollessa ainoastaan 1.33%.

Android ja iOS hallitsevat maailmanlaajuisia markkinoita. Windows Phone mahtuu juuri ja juuri kahdeksan käytetyimmän alustan joukkoon.
Suomessa Nokian puhelimissa käytetyt järjestelmät nousevat iOSin ja Androidin rinnalle merkittäviksi käyttöjärjestelmiksi

Nokian ja Windows Phonen asema Suomessa tekee palvelujen alustan valinnasta normaalia haastavampaa. Siinä missä Yhdysvalloissa sovelluksen tekeminen Androidille ja iOSille riittää kattamaan 95% markkinoista, Suomessa samanlaisen (älypuhelinten) markkinaosuuden kattaminen natiivisovelluksilla vaatii huomattavasti useamman alustan tukemista. Tämä korostuu yrityksille suunnattujen palvelujen suunnittelussa, sillä Nokian puhelimet ovat erityisen suosittuja juuri työsuhdepuhelimina.

Porttautuva koodi mobiilissa

“Write once, run anywhere” oli Javan silver bullet -mantra aikanaan. Eli kirjoitat koodin kerran, käännät sen kerran ja ajat missä vaan tuetussa ympäristössä ilman että ohjelmasi tarvitsee liiemmin tietää ajonaikaisesti mikä käyttöjärjestelmä / rauta ympäristössä on käytössä. No, vaikkei tuohon ole vieläkään – 18 vuotta myöhemmin – ole ihan päästy, on Javan ja vaikkapa Pythonin kaltaisten tulkattujen/scriptauskielten kanssa useimmiten paljon helpompaa elää monialustaympäristössä kuin natiivikoodin. Mutta entä jos halutaankin kehittää natiivisovellus jossa uudelleenkäytetään mahdollisimman suuri osa koodista sen sijaan että N alustaa varten tehdään N toteutusta? Vaikka nykyisten mobiililaitteiden rautaspeksejä (kotitehtävä: montako 25MHz i386 CPU:ta tarvitaan tuottamaan Samsung Galaxy S4:n CPU-teho?) ihmetellessä ei parhaalla omallatunnollakaan voi sanoa resurssien puutteen pakottavan natiivikoodiin, on sen käyttö esim. Android-alustallakin perusteltua sovelluksissa joiden on puristettava se viimeinenkin pisara suorituskykyä irti laitteesta.

Luonnollisesti kaikenlaisiin sovellustyyppeihin porttautuvaa koodia on turha yrittää ujuttaa; jos sovellus on 80%:sti käyttöliittymää eikä ole tarjolla/ei haluta käyttää kaikilla kohdealustoilla toimivaa porttautuvaa UI-kirjastoa, ei kannata väkisin lyödä päätään seinään vaan kirjoittaa toteutukset kiltisti alustan natiivi-API:a käyttäen – tai valita teknologiaksi HTML5 joka sopii webmäisiin lomakesovelluksiin kuin nyrkki silmään. Ym. UI-kirjastoa käyttämällä saatetaan myös – sen toteutuksesta toki riippuen – menettää alustan oma look-and-feel. Ihan hihasta ravistettuna porttautuvan arkkitehtuurin puolesta / vastaan listat voisivat näyttää vaikkapa tältä:

Vastaan:

  • Väkisin yritetty porttautuvuus tekee arkkitehtuurista kömpelön ja lisää turhaa kompleksisuutta
  • Alustan natiiveja ominaisuuksia saatetaan menettää (hyvässä ja pahassa)
  • Käytettäväksi valittu yhteinen ohjelmointikieli ei välttämättä ole tuttu kaikille projektin jäsenille

Puolesta:

  • Koodin joutuu kirjoittamaan vain kerran eli kehityskustannus pienenee
  • Bugit joutuu korjaamaan vain kerran
  • Koodipohjasta tulee merkittävästi pienempi jolloin sen ylläpidettävyys paranee ja siihen on nopeampaa perehdyttää uusia tekijöitä
  • Ohjelmiston luonteen salliessa paljon koodia kierrättävä arkkitehtuuri on hyvin elegantti

Esimerkkiprojekti: MMark13 – mobiilia suorituskykytestausta

Käytän esimerkkinä kuluneen vuoden aikana hiljalleen syntynyttä harrasteprojektiani MMark13, joka – hyvin tiivistetysti – on mobiililaitteiden CPU/GPU suorituskyvyn mittaamiseen tarkoitettu työkalu. Vastaavalla idealla (joskin merkittävästi isommalla tiimillä & budjetilla :)) rakennettu sovellus löytyy Desktop-puolelta, monelle tuttu suomalaista tekoa oleva Futuremark:in 3DMark. Ja ei, en ole suoraan rinnastamassa harrastelijatuotostani PC-maailman (Ja Futuremark:han puuhaa parasta aikaa myös mobiilibenchmarkingia, Androidille se jo ilmestyikin! -toim.) uraauurtavaan tuotteeseen.. no joka tapauksessa, projekti lähti liikkeelle halusta hioa/päivittää OpenGL ES 2.0 taitoja ja havaittuani ettei tuossa vaiheessa (alkuvuosi 2012) juuri vastaavia sovelluksia ollut tarjolla (paitsi kaupallinen ja maksullinen GLBenchmark 2.5 – joskin tuolloin vain iOS:lle), valitsin kyseisen sovellusalueen jo siksikin että porttautuvan arkkitehtuurin hyväksikäyttäminen laajalti tarjosi ainutlaatuisen edun: kun jokaisella alustalla ajettava koodi on 100% sama niiltä osin jotka grafiikan piirtoon / mittauksiin vaikuttavat, voidaan tuloksia verrata 1:1 toisiinsa alustojen välillä ilman että tarvitsee napista Javan tehottomuudesta Androidilla.

 

MMark13 koodin rakenne

 

Koodin uudelleenkäytön suunnittelussa on hyvä lähteä liikkeelle siitä että kartoittaa tarkasti kohdealustansa ja niiden tarjoamat asiat ja sitten hahmottelee niiden pohjalta suurimman yhteisen nimittäjän. Valitsin kohdealustoikseni iOS (Applen laitteet) ja Qt (Android, kaikki merkittävät desktop-käyttöjärjestelmät, Meego, Blackberry10, Symbian, Sailfish OS, Ubuntu Phone, luultavasti myös Tizen ja Firefox OS). Kun alustat ovat tiedossa, aloittaa voi vaikka ohjelmointikielestä; se on valinta jota alemmalle tasolle ei juuri pääse. C olisi aina varma valinta, mutta puhtaalla C:llä syntyy tulosta kovin hitaasti ja dynaamisten tietorakenteiden / merkkijonojen / jne käsittely on melko kömpelöä. Valitsinkin siksi pykälää korkeamman abstraktiotason eli C++:n. Ohjelmointikielen version valintaan kannattaa paneutua myös hetken eikä sännätä käyttämään heti uusinta; itse en uskaltanut vielä tähän projektiin valita tuoreinta C++11 versiota vaikka se oliskin tarjonnut muutamat elämää helpottavat asiat kuten “auto” tyypin muuttujille, sisäänrakennetun säiekirjaston ja paljon muuta. Sittemmin olen perehtynyt tarkemmin C++11 feature support matriisiin merkittävillä kääntäjillä (GCC, clang, MSVC++) ja vaikuttaa että aika on kypsä sen käyttöönotolle.

Ohjelmointikielen valinnan jälkeen seuraava looginen askel on kartoittaa APIen/ulkoisten kirjastojen tarve ja koettaa vaikkapa proof-of-concept -hengessä varmistaa että kirjastovalinnat täyttävät tarpeet. MMark13 -projektissa tarvitsin säikeistystä, joten käytin hyväkseni tietoa että kaikki kohdealustani ovat UNIX-perillisiä ja siten tarjoavat POSIX threads (pthreads) paketit. Tarvittiin myös JSON kirjastoa; pienellä googlauksella löysin “jsoncpp” paketin jonka koodi/dokumentaatio oli poikkeuksellisen laadukkaan oloista ja joka istui suoraan tarpeisiini. Kenties tuosta löydöksestä riemuitessani kirjoitin seuraavan askeleen eli tuloslaskelma-JSON lähetyksen palvelimelle abstraktion läpi siten että kirjoitin alustoille omat toteutuksensa sen sijaan että olisin käyttänyt ilmiselvää ratkaisua libcurlia. Tajusin mokani vasta projektin loppumetreillä enkä rupea yleensä korjaamaan jotain joka toimii, joten saivat jäädä. Lisäksi otin mukaan simppelin C++ MD5-toteutuksen. Halusin toteuttaa softani käyttöliittymän alustariippumattomasti siten että se käyttäytyy kaikilla laitteilla samalla tavalla ja myös näyttää samalta. Etsinkin melko laajalti OpenGL-pohjaista Widget-kirjastoa mutta löytämäni paketit olivat joko aivan järjettömiä bloatteja tai sitten erittäin huonolaatuisen näköistä koodia (usein molempia) että päädyin kirjoittamaan hyvin lightweight toteutuksen aivan alusta erään intensiivisen viikonlopun aikana. Eli ainakin yksi pyörä tuli keksittyä uusiksi – toisaalta aikaa ei tuohon uponnut paljoa, lopputulos miellyttää silmää, homma oli erittäin hauskaa ja lisäksi vieläpä opin paljon.

Lisäksi tarvittiin seuraavat asiat alustariippuvasti: softan bootstrapping, softa/hardisinformaation penkomista laitteelta, joitain sekalaisia pikkujuttuja sekä resurssifilejen lukeminen systeemistä – tähän olisi voinut käyttää ihan fread():ia mutta halusin toisaalta käyttää Qt:n mainiota resource systeemiä jonka kanssa tuo taas ei toimi. Alla muutama konkreettinen koodiesimerkki alustariippuvasta koodin jaosta:

CommonFunctionsQT.cpp:

std::string RandomUuid()
{
    // .mid(1,36) strips the curly braces added by toString(), duh
    return std::string(QUuid::createUuid().toString().mid(1,36).toUtf8());
}

CommonFunctionsIOS.cpp:

std::string RandomUuid()
{
    CFUUIDRef theUUID = CFUUIDCreate(NULL);
    CFStringRef cfuuid = CFUUIDCreateString(NULL, theUUID);
    CFRelease(theUUID);
    NSString* uuid = (NSString*)cfuuid;
    [uuid autorelease];

    return std::string([uuid UTF8String]);
}

Kurkistetaan vielä korkealla tasolla ohjelmiston toimintaa ja sitä miten alustariippuva ja porttautuva osa koodia pelaavat yhteen. iOS-buildissa tarvittava wrapperkoodi on luonnollisesti Objective-C(++):aa; kokemus osoitti ettei sen ja C++ -maailman sekoittaminen keskenään ole triviaalia tai kovin eleganttia, ja kehotankin eristämään kyseisen rajapinnan mahdollisimman pienelle alalle. Käytännössä toimiva pattern on antaa Objective-C++ koodille yksisuuntainen has-a -patternin mukainen suhde porttautuvaan C++ koodiin ja rakentaa iOS-specific toteutus C++ luokalle joka hoitaa callbackien tarvitseman alustariippuvan koodin. Qt maailma on natiivisti C++:aa, joten siellä ei tarvittu taikatemppuja. Ohjelman toimintalogiikka pääpiirteittäin:

  1. Alustariippuvainen osa ottaa vastaan inputit, muuttaa niiden datatyypit alustariippumattomaan muotoon ja välittää ne eteenpäin allaolevalle porttautuvalle osalle. Käytännössä inputit ovat:
    • Redraw timer. iOS:ssa CADisplayLink, Qt:ssä QTimer.
    • Käyttäjän kosketukset. iOS:ssa UITouch*, Qt:ssa QTouchEvent.
  2. Alustariippumaton osa päivittää tilan / menussa ollessa UI:n tilan touchien / kuluneen ajan avulla
  3. Uuden tilan perusteella piirretään uusi frame sekä mm. aloitetaan fysiikkalaskenta seuraavaa framea varten
  4. Tarvittaessa kutsutaan abstraktoituja callbackeja kun tarvitaan alustariippuvaa toiminnallisuutta; esimerkiksi kun ladataan testin vaatimia tekstuureita levyltä tai halutaan lähettää tulokset serverille

Jollekulle on saattanut tätä lukiessa tulla mieleen että mitenkäs se Windows Phone sitten? WP8 pois jättämiseen kohdealustojen joukosta on oikeastaan vain yksi syy – OpenGL APIn puute. Vaikka ymmärtääkseni WP8 hardis on OpenGL ES 2.0 yhteensopivaa, Microsoft ei tapansa mukaan tarjoa standardia rajapintaa vaan pakottaa kehittäjät porttaamaan koodinsa Direct3D:lle. Ja koska softani tärkeimpiä ominaisuuksia on olla suoraan vertailukelpoinen ympäristöjen välillä, ei tuo oikein ollut optio. Jos Googlen ANGLE projektista tulee ikina luotettava port WP:lle *tai* jostain taivaasta putoaa OpenGL ajuri, teen ilomielin myös WP-buildin. Tämän vuoden aikana on tarkoitus suoltaa ulos buildit ainakin Blackberry10:lle, Sailfish OS:lle sekä Ubuntu Phonelle riippuen siitä saadaanko moisia laitteita käsiimme.

Hyvää kevättä kaikille!

Linkkejä

Lisää luettavaa:

Push-viestit ja push-palvelin – mitä ne ovat?

Viimeisen kahden vuoden aikana push-viestien osuus mobiiliviestinnässä on kasvanut räjähdysmäisesti uusien älykkäämpien palvelujen myötä. Seuraavassa pyrimme avaamaan mitä push-viestit ovat sekä niiden hyötyjä ja mahdollisuuksia. Tulemme julkaisemaan myöhemmin myös push-viestintäteknologiaa ja -arkkitehtuuria tarkemmin käsittelevän artikkelin.

Push-viestejä voitaisiin kuvata esimerkiksi seuraavalla virkkeellä:

Push-viestit ovat viestejä, jotka laitteeseen saapuessaan lähes poikkeuksetta herättävät käyttäjän huomion. Käyttäjä voi viestin otsikosta riippuen joko unohtaa sen tai perehtyä siihen ja saada mahdollisesti lisää tietoa asiasta.

Kuvauksen mukaisesti push-viestejä voitaisiin verrata tekstiviesteihin, sillä lisäyksellä, että ne aina liittyvät puhelimelle ladattuun sovellukseen.

Mainonnan ja markkinoinnin näkökulmasta push-viestit eroavat merkittävästi tekstiviesteistä tai muista digitaalisista viestintämuodoista. Digitaalinen mainonta tekstiviestien avulla saattaa monien mielestä olla tunkeilevaa ja sähköpostin välityksellä tapahtuvana persoonatonta sekä harvoin tunteita herättävää. Push-viestit sen sijaan saapuvat aina käyttäjän sallimana, näkyvät reaaliaikaisesti laitteessa ja voivat sisältää monipuolista interaktiivista sisältöä.

Henkilökohtainen merkityksellisyys

Yksilön profilointi on perinteisessä mainonnassa usein pulmallista ja sen toteutus sekä järkevästi että käytännöllisesti on hankalaa, sillä käyttäjien taustat pitää kartoittaa ja sen perusteella jakaa käyttäjät lokeroihin. Käyttäjien profiilitietojen muuttuminen puolestaan ei välttämättä koskaan saavuta palveluiden tarjoaa. Tällainen tilanne saattaa olla kaikille vahingollista. Mainostaja tekee turhaa työtä ja tuhlaa resurssejaan. Viestin saajan osalta roskaviestinnäksi muuttuneen yhteydenottojen käsittely voidaan kokea jopa ärsyttäväksi, mikä saattaa herättää negatiivisia tunteita palvelun tarjoajaa kohtaan.

Push-viestien vastaanottamisen sallimisen mahdollisuus mobiilisovelluksessa estää turhien viestien saapumisen loppukäyttäjille. Viestien lähettämisen salliminen myös ennakoi vastaanottavampaa suhtautumista asiasisältöön. Mobiilisovellus, joka on yhteydessä push-palveluun, voi kerätä ja pitää ajantasalla käyttäjien palvelutietoja, listaa kiinnostuksen kohteista ja sekä esimerkiksi paikkatietoja – käyttäjän sen salliessa. Erityisesti paikkatietojen hyväksikäyttö on vielä vähän käytetty “se suuri” mahdollisuus; paikkatietoisuus yhdistettynä käyttäjien kiinnostuksien kohteisiin tuo merkityksellisyyttä ja korostaa palvelun tarjoajan kunnioitusta yksilöä kohtaan.

Push-viestit saavuttavat kohdeyleisön välittömästi

Ihmisillä on nykyään hyvin usein monia sähköpostitilejä: todennäköisesti tietty tili varattuna henkilökohtaiseen viestintään ja jokin toinen tai toiset tilit yleisempään viestintään, kuten rekisteröitymisiin ja muihin harvemmin käytettyihin palveluihin. Viestin ja loppukäyttäjän kohtaaminen saattaa tapahtua vasta päivien tai viikkojen kuluttua itse lähetystapahtumasta, koska käyttäjät eivät välttämättä seuraa aktiivisesti kaikkia tilejään.

Push-viestit saavuttavat vastaanottajan viimeistään muutaman minuutin sisällä lähetyksestä. Käyttäjien voidaan olettaa saaneen ja huomioineen viestin lähes välittömästi, sillä puhelin värisee, soittaa mahdollisesti merkkiäänen ja ruudulla tapahtuu visuaalinen päivitys.

Pushin avulla sisältöä mobiiliviestintään

Niin massaviestit kuin käyttäjien profiloinnin kautta yksilöidyt viestit kannattaa muotoilla huolellisesti ja sisällyttää niihin jotain, joka oikeuttaa välittömän yhteydenoton käyttäjiin.

Pelkkä tekstitieto,esimerkiksi vaikkapa “Liikkeemme on auki tänäänkin klo 9-18” voi olla paikallaan sillöin tällöin muistuttamassa palvelun olemassaolosta. Suositeltavampaa olisi kuitenkin antaa käyttäjille arvokkaampaa informaatiota, jota epush-viestipalvelua käyttämättömät eivät tietäisi. Esimerkiksi “Muotisuunnittelijamme on tänään liikkeessämme klo 18 asti antamassa henkilökohtaisia vinkkejä. Skumppaa 50 ensimmäiselle!” -tyyppinen viesti tuo lisäarvoa viestiin ja on myös käyttäjille syy olla liittyneenä viestipalveluun. Varsinkin lyhytaikaiset kaikille tarjottavat tiedotteet ja edut houkuttelevat palvelusta kiinnostuneet liittymään palveluun saadakseen tiedon tapahtumista ensimmäisten joukossa.

Push-viestivaihtoehdot

Push-viestit ovat perusidealtaan samankaltaisia kaikissa laitteissa: viesti saapuu, se mahdollisesti avataan ja siihen sidottu mobiilisovellus käynnistyy ja näyttää lisätietoa asiasta.

Applen iOS-laitteilla push-viestit tulevat laitteen ruudulle ja käyttäjä voi reagoida siihen välittömästi tai palata asiaan myöhemmin uudelleen viestikeskuksen kautta. Näkyvän viestisisällön lisäksi viestiin liitetään usein myös käyttäjälle näkymätöntä tietoa, kuten mikä merkkiääni soitetaan viestin saapuessa tai mitä dataa palveluun halutaan välittää sisällönpäivittämisen mahdollistamiseksi.

Windows Phone -laitteille on tarjolla puolestaan usean tyyppisiä push-viestejä, joista perusvaihtoehto (“toast”) on samankaltaisin muiden alustojen push-viesteihin verrattuna. Windows Phone -laitteelle on mahdollisuus lähettää myös raw- ja tile-viestejä. Raw-viestit tarjoavat mahdollisuuden palvelulle syöttää tietoa (esimerkiksi kuponki) mobiilisovellukseen taustalla, ilman että sovelluksen pitää hakea tietoa erikseen.

Tile-viesteissä puolestaan palvelu voi syöttää sovellustiileen (vastaa muilla alustoilla suurin piirtein ikonia työpöydällä) taustakuvia, tekstejä ja numerotietoa. Tämän avulla voidaan toteuttaa esimerkiksi käyttäjän työpöydän uutissovelluksen ikonin sisällönmuutos tai vastaava tilapäivitys.

Android-laitteilla mahdollisuuksia on useita. Käytännössä kehittäjä voi päättää mitä tehdään push-viestin tullessa. Yleisin käytäntö kuitenkin on, että käyttäjälle näytetään notifikaatti, jonka hän voi avata silloin kun on siihen sopiva hetki. Voidaan kuitenkin tehdä monimutkaisempiakin toteutuksia — esimerkiksi käsketään laite lataamaan jokin iso tiedosto ja vasta sen jälkeen ilmoitetaan käyttäjälle notifikaatilla. Käyttäjälle ei ole pakko ilmoittaa push-viestistä mitään, vaan se voi pelkästään olla taustalla tapahtuvaa logiikkaa.

Toimintaympäristö

Push-viestipalvelun käynnistämisen jälkeineen tapahtuva viestien lähetys voi parhaimmillaan olla varsin yksinkertaista ja suoraviivaista. Palvelun tarjoaja luo uuden push-viestin syöttämällä lähettävässä palvelussa lomakkeeseen viestin tiedot. Lähetysnapin painamisen jälkeen tiedot siirtyvät push-viestipalvelimelle, joka lähettää viestin edelleen Applen, Googlen ja Microsoftin kautta mobiililaitteille. Edellä kuvattu toimintatapa vaatii kuitenkin sen, että palvelun kehittäjä on joko itse kehittänyt push-palvelimen viestien välittämiseen tai käyttää tarjolla olevia kaupallisia vaihtoehtoja.

Qvik on toteuttanut push-palvelimen ja tarjoaa sitä mielellään kaikkien asiakkaiden käyttöön. Jatkamme Push-teknologiasta ja viestintäarkkitehtuurista tarkemmin seuraavassa artikkelissa.

 

Kuva 1. Push -viestipalvelin lähettää viestit mobiilikäyttäjille

 

NPG Card julkaistu Windows Phone:lle

Night People Groupin suosittu jäsenkorttisovellus on saatavilla nyt myös Windows Phone -laitteisiin Windows Phone Store:sta!

Sovellusta käyttämällä voi saada jäsenille kohdistettuja etuja NPG:n yökerhoissa ja ravintoloissa. Edut näkyvät sovelluksessa uutisina ja sähköisinä etukuponkeina. Sovellus tarjoaa myös käytännön tietoja tulevista tilaisuuksista yhteystietoineen, paikkatiedot kartalla sekä virtuaalisen jäsenkortin oikeine nimineen ja voimassaoloaikoineen.

NPG Card pohjautuu Qvik Oy:n lanseeraamaan Qvik Card -white label -alustaan, joka voidaan räätälöidä persoonallisesti tilaajan tarpeiden ja brändin mukaiseksi.

Windows Phone:lle tehty Qvik Card eroaa vastaavista iOS- ja Android-sovelluksista huomattavasti ulkoasultaan ja käyttöliittymälogiikaltaan – säilyttäen kuitenkin alkuperäisen toiminnallisuuden.  iOS- ja Android -versioissa “ajankohtaista”, “kupongit”, “membertarjoukset”, “tapahtumat” ja “ravintolat” ovat erillisissä näkymissään, jotka haetaan erikseen Facebook-tyylisestä sivuvalikosta. Käyttäjä avaa ensin valikon ja valitsee sitten, mihin osioon haluaa siirtyä.

Windows Phone -versio käyttää hyväkseen Panorama-näkymää, joka esittää kaikki edellä mainitut toiminnot rinnakkain. WP-lopputulos on grafiikkaintensitiivisempi ja kenties luonnollisempi käyttää kuin muut versiot. Pyyhkäisyliikkeiden pintaan nostattama sisältövirta auttaa isompien asiakokonaisuuksien välillä luovimista.

Sovellus on saanut myönteisen vastaanoton: artikkelia kirjoitettaessa enemmistö arvostelijoista antoi sille arvosanaksi 5 tähteä.

Windows Phone markkinaosuus kasvaa ripeästi

Nyt

Suomessa Elisan myydyin puhelin vuonna 2012 henkilöasiakkaiden kategoriassa oli Nokian Windows Phone Lumia 800 ja yrityspuolella se oli toisena. Myös Soneralla Lumia 800 oli myydyin puhelin vuonna 2012.

StatCounter ilmoittaa Windows Phonen osuuden olleen Suomessa n. 18% joulukuussa 2012, ja nyt tammikuun alussa 20.24%, joten kasvu näyttää jatkuvan vahvasti.

Syksyn Windows Phone 8 -julkistuksen ja sen myötä myyntiin tulleiden WP8-puhelimien myynti näyttää lähteneen hyvin liikkeelle useiden lähteiden mukaan. Vaikka WP-laitteiden markkinaosuus maailman laajuisesti oli muutama kuukausi sitten marginaalista, muutos tilanteeseen on odotettavissa: Microsoftin Steve Balmerin mukaan myynti oli marraskuussa nelinkertaista ja jouluviikolla viisinkertaista verrattuna vuotta aiempaan tilanteeseen.

Vahvistamattomien tietojen mukaan myynti Kiinassa ja USA:ssa on erittäin hyvää eritoten Nokian Lumia-malliston ansiosta. Palkittua Nokian Lumia 920-puhelinta on kehuttu maailman innovatiivisimmaksi ja laitteen kysyntä on ollut huikeaa muihin saman käyttöjärjestelmän laitteisiin verrattuna.

Tulevaisuus

Ennustaminen on hankalaa, kuten vaikkapa IDC:n ennusteet osoittavat. IDC:n ennustukset Windows Phonen kohdalla ovat heitelleet maailmanlaajuisesta 11.4%:n osuudesta aina 19 prosenttiin. Vertailun vuoksi sanottaneen, että Apple iPhonen markkinaosuus maailmassa lienee noin 15%.

Selvää on kuitenkin, että suomalaiset ovat ottaneet Windows Phonen ja Nokian omakseen sekä ostavat laitteita innokkaasti.

Kuva 1. StatCounter Q4/2012 – Suomi.

iPad Mini -arvostelu

Ensimmäinen iPad julkaistiin tammikuussa 2010. Aikaa on siis kulunut vasta vähän vajaat kolme vuotta, mutta julkaisusta alkaneen tablettivallankumouksen takia aika tuntuu huomattavasti pidemmältä ja paljon on vettä virrannut julkaisun jälkeen. Suurin muutos tablettimarkkinoilla iPadin julkaisun jälkeen ovat olleet halvat minitabletit Amazon Kindle Fire ja Google Nexus 7. Nyt Apple lähtee mukaan minitablettitaistoon ei-niin-halvalla iPad  Minillä.

Otin viikonlopun ajaksi testiin iPad Minin 16-gigaisen WiFi-version ja testasin, onko uutukaisesta mihin ja mihinkään.

Onko minun käteni todella iso, vai onko iPad Mini?

Ensi tuntuma

Ensi tuntuma iPad Miniin on melkein maaginen: se on kevyt, erittäin ohut ja tuntuma on “arvokas”. Samanlaista tunnetta ei välitä iPad Minin Android vastine Google Nexus 7, joka on pienestä koostaan huolimatta varsin pulska ja painava. Myös sen ulkokuori natisee kun laitetta käsittelee. Tuo arvokkuuden tuntuma on todennäköisesti syy, miksi Apple on hinnoitellut iPad Minin melkein 100 euroa kalliimmaksi kuin mitä Google on laittanut hintalapuksi Google Nexus 7:lle.

Kannettavuus on iPad Minissä huippuluokkaa: se sujahtaa talvitakin povitaskuun näppärästi, eikä sitä edes huomaa kantavansa mukanaan.

Näyttö

Retina iPadiin tottuneelle iPad Minin pienempi näytöntarkkuus on heti huomattavissa, ja teksti näyttää hiukan sumuiselta. Latasin iBooksista testin vuoksi pari kirjaa ja yhden sarjakuvan. Kirjoissa näyttö ei varsinaisesti haitannut, mutta sarjakuvissa tekstien näkemin vaati huomattavaa keskittymistä. Zoomailuun ei kuitenkaan tarvinnut turvautua. Verkkosivuilla huomasin zoomailevani huomattavasti enemmän kuin Retina iPadilla.

Käyttö

Kolmannen sukupolven Retina iPad (eli se ensimmäinen Retina), kärsii hiukan nopeusongelmista, johtuen näytön suuresta koosta. Nuo nopeusongelmat ovat poissa iPad Minissä: kuten myös samalla suunnilleen samalla raudalla toimivassa iPad 2:ssa, applikaatiot avautuvat sukkelaan ja isotkin pdf-tiedostot ovat selattavissa nopeasti iBooksissa.

Peleistä testasin Suomalaisen Remedyn Death Rally -peliä, jota olen aiemmin testannut iPhone 4:lla ja kaikilla aiemmilla iPadeilla. iPad Minillä pelattuna pelikokemus oli tähän astisista laitteita paras. Näyttö oli tarpeeksi iso, mutta laite on niin kevyt, että sitä jaksaa kannatella pidemmänkin aikaan. Voidaan siis sanoa, että homma pelittää.

Pähkinänkuoressa

Olin ennen testirupeaa hiukan skeptinen minitablettien tarpeellisuudesta, testi ei aivan kokonaan saannut mieltäni muutettua, mutta ei minitabletit aivan turhia ole. iPad Mini on rahansa arvoinen laite ja varsinkin sisäisellä verkkoyhteydellä varustettuna laite olisi varsin kätevä paljon tienpäällä oleville.

Retina iPadin omistajille iPad Mini ei tuota mainittavaa lisäarvoa, mutta esimerkiksi iPod Touch tai iPad 1 olisi jo varsin perusteltua korvata iPad Minillä. Muihin minitabletteihin verrattuna iPad Minin iso näyttö, mutta pieni koko antaa mielesätni sellaisia etuja, joista kannattaa maksaa muutama euro enemmän.

 

tarinoita mobiilikehityksen maailmasta.