Tag Archives: iOS

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.

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.

 

 

Manuaalinen muistinhallinta “for dummies” iOS-alustalla osa 2

Edellisessä osassa esiteltiin tapa yksinkertaistaa muistinhallintaa tekemällä luokkamuuttujista propertyja. Tällä kertaa syvennytään hieman siihen miten ja milloin Objective-C kutsuu retain ja release metodeja objekteille. Lopuksi vielä muutama huomautus objektien säilömisestä kokoelmien sisällä.

Alla olevassa EsimerkkiYksi.h tiedostossa on esitelty muuttuja minunTeksti, josta on tehty property. Objective-C luo propertyille automaagisesti mutator-metodit eli metodit joilla muuttujan sisältöä voidaan helposti manipuloida.

EsimerkkiYksi.h

@interface EsimerkkiYksi : NSObject {
  NSString *minunTeksti;
}

@property(nonatomic,retain) NSString *minunTeksti;

-(void)esimerkkiMetodi;

@end

Alla olevassa Esimerkki.m tiedostossa on havainnollistettu miten minunTeksti objektia voidaan käsitellä gettereilla ja settereilla.

EsimerkkiYksi.m

@implementation EsimerkkiYksi
@synthesize minunTeksti;

-(void)esimerkkiMetodi {
   //Asettaa minunTeksti muuttujaan tekstin "Mun teksti!"
   self.minunTeksti = [NSString stringWithString: @"Mun teksti!"];

   //Tekee saman asian eri syntaksilla.
   [self setMinunTeksti: [NSString stringWithString: @"Mun teksti!"]];

   NSLog(@"Teksti: %@", minunTeksti);

   NSString *toinenTeksti;

   //Asettaa toinenTeksti muuttujan viittaamaan minunTeksti muuttujaan.
   toinenTeksti = self.minunTeksti;
   NSLog(@"Toinen teksti: %@", toinenTeksti);

   //Sama asia eri syntaksilla.
   toinenTeksti = [self minunTeksti];
   NSLog(@"Toinen teksti: %@", toinenTeksti);
}

@end

Ohjelmoija voi myös korvata muuttujiensa mutator-metodit haluamillaan. Yläpuolella olevaan EsimerkkiYksi luokan tapauksessa metodit voisi kirjoittaa auki seuraavanlaisesti:

-(NSString*)minunTeksti {
   return minunTeksti;
}

-(void)setMinunTeksti:(NSString*)uusiTeksti {
   //Nostaa uusiTeksti muuttujan retainCounttia yhdellä. "Ottaa vastuun objektista"
   [uusiTeksti retain];

   //Vapauttaa minunTeksti muuttujan.
   [minunTeksti release];

   //Asettaa minunTeksti muuttujan.
   minunTeksti = uusiTeksti;
}

Jos kyseiset metodit sisällytetään luokkaan niitä kutsutaan aina, kun minunTeksti muuttujaa pyydetään tai asetetaan self notaation kautta. Mahdollisia ongelmatilanteita syntyy jos setterin sisällä kutsutaan retain ja release metodeja väärissä järjestyksissä. Toinen asia mikä pitää muistaa luodessa omia mutator-metodeja on se, ettei niiden sisällä pidä koskaan käyttää self notaatiota.

Alla esimerkki tilanteesta, jossa ohjelma menee loputtomaan looppiin, koska ohjelmoija käyttää getter-metodin sisällä self notaatiota. Jos olet epävarma on parasta olla muokkaamatta propertyille luotuja mutator-metodeja.

//EI NÄIN!!!!
-(NSString*)minunTeksti {
   return self.minunTeksti;
}

Tapauksissa, joissa objekteja säilötään esimerkiksi NSArray tai NSDictionary kokoelmien sisällä on huomioitavaa, että sisään syötettäville objekteille kutsutaan automaattisesti retain metodia. Muistivuotojen välttämiseksi kokoelmiin tulee syöttää vain autoreleasettuja objekteja, ellei objektin oleteta säilyvän kokoelman tuhoutumisen jälkeen. Alla esimerkki kokoelmien käytöstä.

-(void)populoiArray {
   //EI NÄIN!!!
   NSString *testi = [[NSString alloc] initWithString: @"Testi teksti!"];
   self.testiArray = [NSArray arrayWithObject: testi];

   //testi muuttuja ei ole autoreleasettu. Muistivuoto syntyy, kun testArray tuhotaan.
}

-(void)populoiToinenArray {
   //NÄIN
   NSString *testi = [NSString stringWithString: @"Testi teksti!"];
   self.testiArray = [NSArray arrayWithObject: testi];

   //testi muuttuja on autoreleasettu, testiArray ottaa sen haltuun ja vapauttaa sen, kun testArray tuhotaan.
}

Aloittelijan opas säikeisiin (threads) iOS-alustalla

Välillä iOS-ohjelmoinnissa törmää tilanteisiin, joissa ohjelman täytyy suorittaa paljon asioita ennekuin jokin tieto voidaan näyttää käyttäjälle. Nämä asiat voivat olla esimerkiksi XML-tiedoston parsiminen, viestit palvelimelle tai raskaat laskentarutiinit. Käyttäjän näkökulmasta on tärkeää, ettei käyttöliittymä jäädy missään vaiheessa siitä huolimatta, kuinka paljon ohjelma käsittelee tietoa. Jos ohjelma suorittaa kaiken yhdessä säikeessä voi käyttökokemus jäädä heikoksi. Tämän takia useat ohjelmointikielet Objective-C mukaan lukien tarjoavat mahdollisuuden suorittaa asioita samanaikaisesti säikeissä.

Säikeet eli threadit saattavat alussa kuulostaa monimutkaisilta. Objective-C:ssä threadien käyttö on onneksi hyvin yksinkertaista. Helpoin tapa tehdä ohjelmatasi monisäikeinen on käyttää NSObject luokan mukana tulevaa performSelectorInBackground:withObject: metodia. Se mahdollistaa minkä tahansa metodin suorittamista taustalla ilman, että käyttöliittymä jäätyy metodin suorituksen ajaksi.

Alla on yksinkertaistettu esimerkki luokasta, joka suorittaa taustalla paljon laskentaa.

MinunLaskuri.h

@interface MinunLaskuri : NSObject {
  //Tyhjä
}

-(void)laskeMiljoonaan;

@end

MinunLaskuri.m

@implementation MinunLaskuri

-(id)init {
  if ( (self = [super init]) ) {
    [self performSelectorInBackground: @selector(laskeMiljoonaan) withObject: nil];
  }
  return self;
}

-(void)laskeMiljoonaan {
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

  for (int i = 0; i < 1000000; i++) {
    NSString *teksti = [NSString stringWithFormat: @"numero on %i", i];
    NSLog(@"Laskurin %@", teksti);
  }

  [pool release];
}

@end

Alla oleva rivi luo uuden taustasäikeen ja suorittaa luokan metodin nimeltä laskeMiljoonaan kyseisessä säikeessä jäädyttämättä käyttöliittymää. Metodille annetaan
tässä tapauksessa parametriksi nil, koska se ei ota vastaan mitään parametreja.
[self performSelectorInBackground: @selector(laskeMiljoonaan) withObject: nil];

Seuraavat tärkeät huomioitavat ovat rivit:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[pool release];

Muistinhallinnan kannalta on tärkeää, että jokaisessa ohjelman säikeessä on ainakin yksi NSAutoreleasePool-objekti, joka ottaa vastaan autoreleasetut objektit vapauttaen ne automaattisesti muistista. Kun kirjoittaa metodia, joka suoritetaan taustasäikeessä kannattaa lisätä heti alkuun ja loppuun kyseiset rivit. Tämän jälkeen voi rauhassa koodailla metodin sisälle mitä haluaa. Yläpuolella olevassa esimerkkitapauksessa metodi laskee miljoonaan ja printtaa konsoliin jokaisen numeron.

Lisää tietoa säikeistä löytyy Applen sivuilta

Manuaalinen muistinhallinta “for dummies” iOS-alustalla – Osa 1

Manuaalinen muistinhallinta voi tuntua alussa haastavalta aloittelevalle ohjelmoijalle. Useissa ohjelmointikielissä vastuu muistinhallinnasta on siirretty garbage collectorille, joka hoitaa muistinhallintaa automaattisesti. Apple lisäsi iOS 5.0 version myötä alustalleen ARC:n (Automatic Reference Counting), joka estää tehokkaasti mm. muistivuotoja ja olioiden vapauttamisesta johtuvia kaatumisia. ARC ei tuo Objective-C:lle garbage collectoria vaan se lisää olioille tarvittavat retain ja release kutsut ennen ohjelman kääntämistä. Xcode 4.2 tarjoaa työkalun, jolla olemassa olevia projekteja voi konvertoida ARC-yhteensopiviksi. ARC:n voi myös kytkeä pois päältä tiedostokohtaisesti.

Jos et kuitenkaan pysty tai halua käyttää projektissasi ARC:tä voit noudattaa muutamaa ohjenuoraa, jotka estävät turhia muistivuotoja ja kaatumisia.

Luokkamuuttujat.

Kun luot uuden luokkamuuttujan voit yksinkertaistaa muistinhallinnan tekemällä siitä propertyn ja asettamalle propertylle retain parametrin. Heti tämän jälkeen kannattaa lisätä luokan dealloc metodin sisälle kutsun, jolla vapautetaan muuttuja. Sen jälkeen voit unohtaa muistinhallinnan kyseisen muuttujan osalta.

On vain yksi asia mikä pitää muistaa. Aina kun asetat muuttujaan tietoa käytä self notaatiota ja vain autoreleasettuja olioita. Käyttämällä self notaatiota autoreleasetulle objektille kutsutaan samalla retain metodia, koska propertyyn oli asetettu retain parametri. Kun ottaa tavaksi luoda luokan metodien sisällä vain autoreleasattuja objekteja välttyy monilta ikäviltä muistivuodoilta. Tällöin ohjelmoijan ei täydy koskaan kutsua manuaalisesti olioiden retain ja release metodeja, koska kaikki tarvittava on hoidettu propertyn esittelyssä ja luokan dealloc metodissa.

Alla havainnollistava esimerkki aiheesta.

EsimerkkiYksi.h

@interface EsimerkkiYksi : NSObject {
  NSString *muuttujaYksi;
}

@property (nonatomic,retain) NSString *muuttujaYksi;

-(void)minunMetodi;

EsimerkkiYksi.m

@implementation
@synthesize muuttujaYksi;

-(void)minunMetodi {
  self.muuttujaYksi = [NSString stringWithString: @”Testi teksti”];
}

-(void)dealloc {
  [muuttujaYksi release];
  [super dealloc];
}
@end

Lisää tietoa muistinhallinnasta iOS-alustalla löytyy Applen sivuilta

iOS 4.3, Xcode 4 ja iPad 2.

Apple on julkaissut kasan uusia tuotteita ja työkaluja sovelluskehittäjien iloksi.

iOS-sovelluskehittäjille karkkia.

iOS 4.3

iOS-käyttöjärjestelmän 4.3 versio tuli iTunesin kautta ladattavaksi tänään. Päivityksen luvataan nostavan Safarin suorituskykyä ja se tuo myös Oma yhteyspiste-ominaisuus iPhone 4:lle. Oma yhteyspiste-ominaisuudella voit jakaa iPhone 4:sen 3g-yhteyden muille laitteille langattomasti. Ominaisuus toimii vain, jos operaattori on sen sallinut, eli Suomessa ainakin Elisan ja Soneran liittymillä.

Päivitys on saatavissa seuraaville laitteille: iPhone 3GS, iPhone 4, iPod touch 3 gen, iPod touch 4 gen, iPad ja iPad 2.

Lue lisää Apple:n sivuilta : iOS 4.3 -ohjelmistopäivitys

XCode 4

iOS-sovelluskehittäjien työkalu XCode 4 on saannut pitkään odotetun kasvojenkohotuksen ja tukun kaivattuja parannuksia. XCode 4:sta kirjoitamme tulevaisuudessa varmaan lisää, kunhan pääsemme tekemään sillä enemmän töitä.

Lue lisää XCode:sta : What’s new in Xcode 4

iPad 2

Appel julkisti iPad 2 – tablettinsa viime viikolla ja julkaisee sen huomenna Yhdysvalloissa. Suomessa iPad 2 tulee kauppoihin 25 maaliskuuta, noin neljä kuukautta iPad 1:sen jälkeen. Tämä luo sovelluskehittäjille Suomessa erikoisen tilanteen, kun voidaan olettaa, että iPad 2 saa huomattavasti isomman markkinaosuuden kuin muualla maailmassa.

Palaan iPad 2:seen tarkemmin, kunhan saan sellaisen hyppysiini. Sillä aikaa voit lukea mitä mieltä Engadget on Applen uutukaisesta.

Lue lisää Applen-sivuilta : iPad 2

Näin aloitat iOS-kehityksen

Tämän artikkelin tarkoituksena on esitellä iOS-kehittämiseen liittyviä perusasioita ja työkaluja pintapuolisesti. Seuraavissa artikeleissa käydään läpi ympäristöä ja työkaluja ja kielen syntaksia syvemmin esimerkkien avulla.

Miksi kehittää ohjelmia iOS-alustalle?

  • Hyvät kehitystyökalut. Xcode ja Interface Builder
  • Vain kaksi erilaista laitetta huomioitavana. Toisin kuin muilla alustoilla, on iOS-alustalla vain kaksi eri huomioitavaa laitetyyppiä: iPhone ja iPad.
  • Ohjelmien julkaisukanava. App Store on tällä hetkellä maailman suurin mobiiliohjelmien kauppa.
  • Hyvät valmiit UI-komponentit. Hyvältä näyttävien ja toimivien käyttöliittymien teko on helppoa. Valmiiden UI-komponenttien muokkaaminen ei olekaan sitten ihan niin helppoa…
  • Hyvin dokumentoitu ympäristö. Apple on kirjoittanut kattavan dokumentaation iOS-ympäristön rajapinnoista ja luokista.

Tekniset vaatimukset

iOS-ohjelmien kehityksen aloittaminen on vaivatonta ja osittain ilmaista. Osittain ilmaista siksi, että kehitystyökalut on ilmaisia, mutta ilman $99/vuosi maksavaa kehittäjälisenssiä ohjelmia ei voi ajaa laitteella, eikä julkaista App Storessa. Lisäksi aivan kaikki Applen tekemät esimerkit ja oppaat eivät ole esillä muille kuin maksaneille. Ilmaiseksi pääsee kuitenkin lukemaan suurta määrää oppaita ja itse tekemiä ohjelmia voi ajaa simulaattorissa, joten perusteita opetellessa ei tarvitse, eikä välttämättä kannata maksaa mitään.

iOS-kehittämisen aloittamiseen tarvitaan vain kolme asiaa: uudehko Mac-tietokone, Xcode-kehitysympäristö ja iOS SDK.

Ohjelmat kehitetään pääasiassa Mac-tietokoneilla. Ainoa laitteistovaatimus on OS X Snow Leopard -käyttöjärjestelmä, eli versio 10.6, joka on tullut uusien Mac-koneiden mukana vuoden 2009 puolivälistä lähtien.

Pääasiallinen kehitysympäristö on Xcode. Toki ohjelmakoodin kirjoittamiseen voi käyttää jotain muutakin editoria, mutta alussa ei kannata ampua itseään jalkaan, vaan käyttää Xcodea, kunnes koodaaminen alkaa sujua. Xcode on ilmainen, ja ladattavissa iOS Dev Centeristä. Dev Centeristä lataaminen vaatii rekisteröitymisen Apple-kehittäjäksi, mutta se ei onneksi tarkoita sielunsa myymistä Stevelle, eikä maksa mitään. Dev Center sisältää valtavan määrän dokumentaatiota, esimerkkejä ja ohjeita iOS-kehitykseen.

Tällä hetkellä uusin Xcoden uusin versio on 3.2.5 ja iOS SDK:n on 4.2. Molemmat saa ladattua yhtenä pakettina täältä (paketin koko on n. 3,52 GB).

Xcoden projektinäkymä.

Millä kielellä?

iOS-ohjelmat kehitetään pääasiassa Objective-C -kielellä. Se on laajennus C-kieleen ja tuo mukanaan mm. oliomallin, ollen kuitenkin täysin yhteensopiva C:n kanssa. Apple hyväksyy App Storeen vain Objective-C:llä, C:llä ja C++:lla kirjoitettuja ohjelmia, joten muita kieliä ei ohjelmien kehityksessä voi käyttää.

Simulaattorilla vai oikealla laitteella?

Helpoin ja ilmainen tapa tutustua Objective-C -kieleen ja Cocoa Touchiin, on ajaa ohjelmia simulaattorilla. Simulaattori näyttää iPhone- ja iPad-ohjelmat sellaisena kuin ne näkyisivät itse laitteellakin. Huomaa, että simulaattorissa ei toimi ominaisuudet jotka käyttävät kiihtyvyyssensorin lukemia ja GPS-paikanninta ja kompassia käyttävät ominaisuudet eivät toimi simulaattorissa.

Simulaattorin käyttäminen sopii hyvin iOS-ohjelmoinin opetteluun; se käynnistyy nopeasti ja toimii nopeasti. Valmiin ohjelman lopullinen testaaminen on kuitenkin syytä suorittaa oikealla laitteella, sillä ohjelma saattaa käyttäytyä hieman eri tavalla kuin simulaattorissa. Fyysisen laitteen käyttäminen kehittämisessä edellyttää iOS Developer Program -jäsenyyttä, joka maksaa $99 vuodessa. Jäsenyys mahdollistaa ohjelmien julkaisun App Storessa. Lisää tietoja iOS Developer Programista saa täältä.

Xcoden perusteet

Seuraavassa ohjeessa luodaan tyhjä Xcode-projekti ja ajetaan se simulaattorissa.

  1. Rekisteröidy Apple-kehittäjäksi osoitteessa http://developer.apple.com/devcenter/ios/ Oikeasta yläkulmasta löytyy linkki rekisteröitymiseen.
  2. Lataa uusin Xcode ja iOS SDK samalta sivulta rekisteröitymisen ja kirjautumisen jälkeen. Paketti on ylin linkki, jossa lukee “Xcode 3.2.5 and iOS SDK 4.2″ 
  3. Käy kahvilla 3,5 gigan paketin latautuessa.
  4. Käynnistä Xcode. Edessäsi pitäisi näkyä Xcoden käynnistysikkuna.
  5. Luo uusi projekti valitsemalla “Create a new Xcode project” Xcoden käynnistysikkunan vasemmalta puolelta.
  6. Valitse projektiksi iPhone-ohjelma valitsemalla vasemmalta palstalta, iOS-kohdan alta “Application”, ja oikealla näkyvältä alueelta “View-based Application”.
  7. Tallenna projekti haluamallasi nimellä.
  8. Nyt sinulla on edessäsi projekti joka sisältää iPhone-ohjelman rungon. Ohjelman voi käynnistää, mutta se piirtää ruudulle vain harmaan kuvan.
  9. Käynnistä ohjelma painamalla projekti-ikkunan yläpalkista vasaran ja vihreän play-painikkeen näköistä kuvaketta, jossa lukee “Build and Run” , tai valitsemalla ohjelman ylävalikosta Run -> Run.
  10. Simulaattorin pitäisi käynnistyä ja näyttää harmaata kuvaa.

Esimerkkiohjelma ajossa iPhone-simulaattorissa.

Seuraavassa artikkelissa kerromme iOS-ohjelmien toimintaperiaatteesta ja laitamme simulaattorin näyttämään jotain hienompaa kuin harmaan ruudun!

Yhteenveto kehittämiseen tarvittavista asioista

  1. Mac-tietokone jossa on OS X Snow Leopard (10.6)
  2. Rekisteröityminen Apple-kehittäjäksi
  3. XCode ja iOS SDK
  4. Mielenkiintoa opetella Objective-C:n syntaksi (se ei ole ollenkaan niin vaikeaa miltä se näyttää ;))

Linkkejä

  1. iOS Dev Center
  2. iOS Developer Program

iPhone-kehityksestä suomeksi

iPhone ja iPad ovat nyt kovassa huudossa. Päivittäin voimme lukea lehtijuttuja, kuinka suomalaisen Rovion Angry Birds valloittaa maailmaa, kuinka Helsingin Sanomat on julkaissut iPad-sovelluksensa tai kuinka Vanjoki hyppäsi Apple-kelkkaan.

Näiden tarinoiden taustalla on satojen tuntien iOS-kehitystyö, joiden tarinat ovat vielä jäännet suomeksi kertomatta.

iPhone-kehitys

Tämän blogin tarkoituksena on kertoa kaikille kiinnostuneille iOS-sovelluskehityksestä, siinä käytettävistä työkaluista, jipoista ja tärkeimmistä alaan liittyvistä uutisista.

Blogin kirjoittajina toimii Qvik Oy:n työntekijät, joilta löytyy kokemusta kymmenistä iOS-sovellutuksista ja yleisesti mobiilikehityksestä. Pyöritämme myös Android-kehityksestä kertovaa blogia osoitteessa androidkehitys.fi.