Toimintani on pienimuotoista ja harrastusluonteista, ja omalla taustallani jo App Storeen pääsy alle vuodessa on jo voitto sinänsä. Turha kuitenkaan kieltää, etteikö mahdolliset myyntiluvut kiinnostaisi myös – se Developer Programin kahdeksankymppiä olisi tietysti mukava tienata takaisin. Sweetest Kid on siinä mielessä mainio esimerkkitapaus, etten tehnyt sen suhteen minkäänlaista (tietoista) ennakkomarkkinointia – mainitsin toki useampaan kertaan tulossa olevasta applikaatiosta suosimillani foorumeilla ja sosiaalisessa mediassa, mutta lähinnä siksi että olin asiasta niin innoissani.

Ekojen päivien myynti – ei, nuo luvut eivät ole tuhansia

Ylläolevan kuvan perusteella lienee aika ilmeistä: jos tarkoituksenasi on oikeasti tienata jotain, ei kannata luottaa viidentoista minuutin kuuluisuuteesi (nerokkaan selvänäköinen ennustus Warholilta muuten) App Storen vastajulkaistujen listalla. Tuo ekan päivän “myyntiryntäys” koostuu omasta testiostostani, ja työkaverini sekä erään tuttavan ostoksesta. Seuraavilta päiviltä  kertyi yhteensä viisi latausta – viimeiset pari jopa aivan tuntemattomilta ihmisiltä, vau

Ihan näin helposti en kuitenkaan halunnut applikaationi jäävän unohduksiin, joten aloin miettimään, miten markkinointibudjetillani (0 € – tosin nyttemmin turvonnut parinkymmenen euron tuntumaan) voisi saada houkuteltua uusia käyttäjiä.

Ensin korvasin kökön Facebook-likeboxin perussiistillä mainossisällöllä applikaation omalla promosivustolla. Selkeämpi url ja seurattavuus Google Analyticsillä olivat isoimmat syyt, miksi sinänsä selkeä iTunes-sivu ei tuntunut riittävän. Joskus aiemmin avaamani Google AdWords -tili mainosti sattumalta juuri samoihin aikoihin 100 € promootiokoodilla, joten käytin sen applikaationi mainontaan kids apps -tyylisillä hakusanoilla. Siitä seurasi vajaat parisataa klikkausta promosivulle, muttei kuitenkaan myyntiä.

Muistelin myös tunnukset pitkään unohduksissa olleeseen Twitter-tiliini ja aloin twiittailemaan applikaatiooni liittyvistä uutisista.

Jonkin aikaa harkittuani linkitin promosivulle jopa sattumalta melko suosituksi nousseesta YouTube-vitsistäni – alkuun mietin, tuleeko sivuille tuolta vääräntyyppistä yleisöä, mutta YouTube Insightin ja oman järkeilyni perusteella tuohon videoon päätyvät muutama tuhatta päivittäistä katsojaa saattavat hyvinkin olla lasten vanhempia, eikä läppävideon katsominen välttämättä sulje pois kiinnostumista “vakavahenkisestä” applikaatiosta.

Näistä toimenpiteistä on seurannut vaatimattomia kävijämääriä promosivulla, mutta ei 0-1 päivittäistä ostoa enempää tuloksia. Aloin googlailla aiheesta, ja päädyin Moms with Apps -sivulle. Ryhmä edistää pienten perheystävällisiä applikaatioita kehittävien tekijöiden asiaa, ja kelpuuttaa nimestään huolimatta mukaan myös isejä. Ryhmän aktiivisuus ja avuliaisuus yllätti, esimerkiksi pelkästään esittäytymällä jäsenfoorumilla sain yllättäen applikaationi mukaan heidän blogiinsa ja kanssadevaajien Facebook-sivuja promotaan anteliaasti. Genre on ilmeisen rajattu, mutta vastaavanlaisia yhteisöjä löytynee muunkinlaisten applikaatioiden kehittäjien keskuudesta.

Myös muutama arviointipyyntö on vetämässä – hyvillä arvosteluilla voisi kuvitella olevan seurauksena myös myyntiä. Uusien (perhe)applikaatioiden virta on valtava, joten arvioitavaksi pääseminen ei ole ihan itsestäänselvää eikä varsinkaan nopeaa, mutta yksi arvio “the iPhone Mom”in blogissa on kuulemma jo aikataulutettuna aatonaatoksi. Jännä nähdä, minkälainen arvio sieltä on luvassa…

Olen myös kokeillut yhden päivän väliaikaista ilmaisjakelua (erittäin vaivaton ja yksinkertainen, minuutin homma iTunes Connectissa muuten) ja tulokset olivat myyntimääriin suhteutettuna melko yllättävät.

CyberMondayn ilmaisjakelu: 99 latausta!

Sweetest Kid oli ilmainen yhden päivän ajan (28.11. eli online-kaupan promotoimiseen lanseerattu CyberMonday), minkä seurauksena sitä ladattiin 99 kappaletta. Absoluuttisessa mielessä ei mikään suuri määrä, mutta 0-1 maksulliseen lataukseen verrattuna prosentuaalinen ero on huima. Vaikka ajattelisi, että yksi dollarihan on käytännössä ilmainen, on ero applikaatiomarkkinoilla kaikkea muuta kuin merkityksetön. Kuulin eräästä devaajasta, joka muutti muutama päivä sitten (erittäin monipuolisen ja laadukkaan) applikaationsa ilmaiseksi, ja 1 osto /1–4 päivää -tahti muuttui 15000 globaaliksi lataukseksi muutosta seuraavana päivänä.

Oma kampanjani ei vielä vaikuttanut seuraavien päivien myyntiin, mutta 100 käyttäjää ei vielä olekaan kovin massiivinen alkujoukko. Siksipä ajattelin kokeilla näin joulun alla pidempää giveaway-kampanjaa, josko sillä saisi houkuteltua isomman käyttäjäkunnan, ja sitä kautta applikaation some-ominaisuuksien perusteella myöhemmin myös ostavia asiakkaita. Aloitin kampanjan eilen, joten ensimmäiset lataustilastot pitäisi ilmestyä muutaman tunnin sisällä. Ihan kiinnostavaa nähdä, mitä sieltä paljastuu!

Sweetest Kidin myöhemmät vaiheet selviävät tätä blogia seuraamalla – pysykää kanavalla Pohdintaa erilaisista ennakkomarkkinoinnin keinoista saattaa olla luvassa myös. Siihen asti: kuulemiin!

• Sweetest Kid iTunesissa
• Sweetest Kid Facebookissa
• Sweetest Kid netissä (ainakin toistaiseksi vain Facebook-likeboxin muodossa)

Applikaation ideana on klassista Lumikki-sadun taikapeiliä soveltaen kertoa lapselle, että tämä on suloisin asia maailmassa. Lapsen kuva ilmestyy peiliin, ja sen voi sitten jakaa Facebookissa ja sähköpostilla. Aikuisetkin saavat tätä toki käyttää

Ellei muuta, niin onhan tämä kannuste muille samassa tilanteessa oleville ei-dippainssi-devaajille: kyllä, on se mahdollista! Ja allekirjoittaneen joulu alkoi muuten nyt

Nyt kun ensimmäinen applikaationi on pientä hiomista vaille valmis lähetettäväksi ehdolle App Storeen, voisin kerrata hieman mitkä asiat tuossa valmisteluprosessissa tuottivat itselleni eniten päänvaivaa, ja miten ne lopulta ratkesivat – lähinnä painotus siis tuossa App Storessa myymiseen liittyvässä (virtuaalisessa) paperityössä.

Ihan ensimmäiseksi

Jos olet juuri aloittamassa iOS (= kaikkien Applen mobiililaitteiden käyttis) -ohjelmointia, ihan ensiksi kannattaa huomioida, että sinulla on kaksi vaihtoehtoa:

1. Voit aloittaa ilmaiseksi yksinkertaisesti rekisteröitymällä Apple Developeriksi: http://developer.apple.com/programs/register/
2. Tai voit liittyä Applen maksulliseen (99 $/vuosi) Developer Programiin http://developer.apple.com/programs/ios/

Suurimmat erot ovat siinä, että maksullisen ohjelman jäsenenä pystyt testaamaan ohjelmiasi fyysisellä iPhone/iPad/iLaitteellasi, saat pääsyn suljetulle Developer-foorumille ja voit saada applikaatiosi App Storeen. Eli jos aiot julkaista jotain, ennemmin tai myöhemmin tarvitset tuon maksullisen tilin. Jos sata taalaa ei tunnu missään, voit kaikin mokomin liittyä Developer Programiin vaikka samantien. Omasta kokemuksesta voin kuitenkin sanoa, että opeteltavaa kyllä riittää ennen kuin laitteella testaaminen tai App Storeen pääsy alkaa olla välttämätöntä. Maksu on kuitenkin voimassa vuoden sopimuksen aloituspäivästä, joten jos opettelet perusteita suurinpiirtein puoli vuotta, kuten minä, tuolta ajalta maksaminen ei välttämättä ole kovin viisasta.

Kantapään kautta voittoon

Xcoden ja iOS SDK:n (Software Development Kit) lataamisessa ja asentamisessa ei ollut mitään ihmeellistä, Applella on tähän hyvät ja täsmälliset ohjeet.

Xcode on mainio kehitysympäristö, jonka vipstaakien opetteluun menee toki oma aikansa. Sitten tietysti pitää opetella kielen (Objective C), järjestelmän (Cocoa Touch) ja koko Applen voimakkaasti objektiorientoituneen ohjelmointifilosofian perusteet. Helpommin sanottu kuin tehty, mutta kyllä se onnistuu ei-insinööriltäkin – aika ajoin päätä seinään hakaten. Edelleen suosittelen painokkaasti aloittamaan tästä loistavasta Stanfordin videoluentosarjasta (en tiedä, onko jo uudempikin lukukausi julkaistu, mutta tämän ääressä itse opiskelin): http://itunes.apple.com/us/itunes-u/developing-apps-for-ios-sd/id395631522

Developer Program

Huomaat kyllä itsekin, kun maksulliseen ohjelmaan liittyminen alkaa olla ajankohtaista. Liittyminen on helppoa ja yksiselitteistä, sen jälkeen tapahtuva omien tietojen täydentäminen voi aiheuttaa paikka paikoin hieman enemmän pähkäilyä.

Kun olet maksanut jäsenyytesi ja saanut Applelta varmistusmeilin, että kaikki on ok, käyttöösi tulleet ominaisuudet löytyvät nätisti yhdelle sivulle koottuna Member Centeristä: https://developer.apple.com/membercenter/index.action

Varmaan oudoimman kuuloiset ja samalla tärkeimmät käyttöösi tulleet työkalut ovat “iOS Provisioning Portal” ja “iTunes Connect”. Ensinmainitussa luodaan tarvittavat kehityssertifikaatit ja “App ID”:t  sekä rekisteröidään testauslaitteet. Jälkimmäisessä hallinnoit sopimus-, pankki-, ja verotustietojasi ja applikaatioidesi myyntiä/jakelua. Molemmat edellyttävät hieman pohjatyötä.

Provisioning Portal

Jos kuvaus Provisioning Portalista kuulosti heprealta, ei se mitään. Kaikki on yksityiskohtaisesti opastettu – sen ansiosta onnistuin saamaan kaiken toimimaan, vaikken yhtään tiennytkään, mitä olin tekemässä. Ainoa juttu, jota jouduin vähän korjailemaan jälkeenpäin, oli tuo App ID:n formaatti.

App ID koostuu siis Applelta automaattisesti tulevasta “Bundle Seed ID”:stä sekä itse määräämästäsi “Bundle Identifieristä”. Vaikka Bundle Identifierillä ei ymmärääkseni ole muuta ihan pakollista vaatimusta kuin että se on applikaatiosi tai applikaatiokokoelmasi uniikki tunnus, kannattaa noudattaa Applen suositusta ellei ole jotain erityistä syytä tehdä toisin. Applen suositus on “reverse domain name style”, jonka tajusin vasta googlailun jälkeen todellakin viittaavan yrityksesi tai oman nettisivustosi domainnimeen.

Täydellisen App ID:n rakenne on siis seuraavanlainen:

ABCDEFGHIJ.com.yrityksesinimi.applikaationnimi tai
ABCDEFGHIJ.com.omanimesi.applikaationnimi

Tuo ABC… on se Bundle Seed ID, 10 merkin/numeron sarja, joka tulee Applelta. Tuo com.yrityksesinimi.applikaationnimi on se Bundle Identifier (jota muuten tuolla iTunes Connectin puolella kutsuttiin hämäävästi vähän eri nimellä, muistaakseni se oli joku App ID Suffix tms.)

Ja suositus tosiaan olisi, että sinulla todella olisi hallussa tuo www.yrityksesinimi.com tai www.omanimesi.com -domain netissä (näin pystyttäisiin takaamaan se, että App ID:si todella on uniikki). Pakollista tämä ei ymmärtääkseni ole, mutta ihan järkevä periaate mielestäni.

Applikaatiokokoelmia (suite) varten App ID:ssä on mahdollista käyttää asteriskia * jokerimerkkinä, tähän tapaan:

ABCDEFGHIJ.com.yrityksesinimi.* tai
ABCDEFGHIJ.*

Ymmärtääkseni viimeistään applikaation julkaisuvaiheessa pitää kuitenkin täydentää tuo applikaatiokohtainen loppuosakin. Tämän asian voisi joku kokeneempi selventää, itselle jäi tuo vähän hämäräksi.

iTunes Connect

Ekalla kerralla saattaa hämätä hieman, että iTunes Connectiin kirjaudutaan erikseen, vaikka tunnukset ovatkin samat kuin Member Centeriin. iTunes Connectin Contracts, Tax, and Banking -osiossa olikin sitten ehkä koko prosessin hankalimmat kohdat. iOS Free Applications -sopimus pitäisi olla valmiiksi hyväksyttynä, se kuuluu jo Developer Programin sopimukseen. Maksulliseen tai mainosrahoitteiseen sopimukseen tarvitaankin sitten pankki- ja verotietoja.

Jostain syystä esitäytettyihin tietoihini oli tullut väärä lähiosoite (en vieläkään tiedä, mistä se putkahti: Applelta, luottokunnalta vai mistä lie). Osoite oli muutaman korttelin päässä kotoani, mutta ei kuitenkaan oma osoitteeni. Asia korjautui joka tapauksessa itsestään siinä vaiheessa kun ehdin kirjoittaa asiasta kyselyn Applelle.

Seuraava hakala kohta olikin sitten Bank Info. Pitkä tarina lyhentäen: kävi ilmi, että oman pankkitilini alkuosa (pankkikonttorin tunniste) ei vastannutkaan kotikonttoriani tai ylipäätään mitään virallisissa rekistereissä olevaa pankkia. Kummallista kerrassaan, mutta tilinumero ei siis kelvannut Applelle, eikä pankkini osannut tehdä asialle mitään(!) Kaikeksi onneksi sain vinkin käyttää S-etutilini tilinumeroa, jonka Apple tosiaan hyväksyi heittämällä. Problem solved!

Sitten oli vielä Tax Information, jota kohtaan olin kehittänyt melkoiset ennakkopelot erinäisiä foorumeita seuraamalla. Tätä varten on ei-usalaisena vielä hiljattain täytynyt soitella Jenkkien verotoimistoon asti, kirjautua verovelvolliseksi Yhdysvalloissa (!) ja täytellä jotain IRS ja W-8BEN -lomakkeita.

Nähtävästi (sanon nähtävästi, koska minulla ei vielä ole yhtään applikaatiota kaupassa, eikä näin ollen tilityksiäkään tullut) asia on kuitenkin hiljattain muuttunut, eikä meiltä ulkomaalaisilta kysytä enää muuta kuin vakuutus siitä, että meillä ei ole muuta liiketoimintaa tai alaisia Yhdysvalloissa. Ainakaan missään ei kyselty yllämainittujen verotusdokumenttien perään, ja sopimukseni status näyttää “hyväksyttyä”. Tällaisen keskustelun aiheesta löysin googlaamalla: http://www.iphonedevsdk.com/forum/busin … -info.html

Siinäpä se!

Verotus Suomen puolella on sitten ihan oma juttunsa. Se tuntuu olevan kaikille (eikä vähiten veroviranomaisille itselleen) täysin hämärän peitossa oleva juttu. Helpoin, ja näin ollen itselleni mieluisin tulkinta on se, että 8500 euroon asti tulot eivät edellytä yksityishenkilöltä muuta kuin yhdenkertaista kirjanpitoa ja tulojen kirjaamista verokortin kohtaan “1.4 muut ansiotulot” ja vero.fi:stä lomakkeen 15: “Taiteilijan ja freelancerin tulot” siihen liitteeksi. Lähde: Hopeisen Omenan keskustelu aiheesta: http://hopeinenomena.net/viewtopic.php?f=40&t=117834&start=25

iTunes Connect: Manage Your Apps

Jos “Add New App” -painiketta ekaa kertaa klikatessa yhtään jännitä, on jotain kyllä vialla. Applikaation tietoja voi käydä koetäyttelemässä, jotta lomake tulee tutuksi, mutta jos on aikomus oikeasti julkaista jotain, kannattaa olla valmiina ainakin seuraavaa:

• Applikaation virallinen nimi
• SKU Number; tämä on siis itse keksimäsi applikaatiokohtainen tunniste, jota käytät siis vain omassa kirjanpidossasi jne., tässä ei ole mitään pakollista virallista formaattia. Mulla on 1001_applikaationnimi (1 = tyyppi, esim. peli versus hyötyohjelma, 001 = applikaation numero – kuten huomaat, olen varautunut 999 eri applikaation softaimperiumin pyörittämiseen, hehe, sitten alaviiva koristeeksi ja applikaation nimi pienillä kirjaimilla yhteen). Mutta tosiaan, suit yourself. Seuraavaan näkymään et kuitenkaan pääse, ellet täytä tuohon ainakin jotain.
• Bundle ID: tämä valitaan siis tuolla Provisioning-puolella rekisteröimistäsi ID:stä, eli se pitää olla valmiina tässä vaiheessa. Jos käytät Bundle ID:ssäsi asteriskia jokerimerkkinä, ID:n loppuosa pitää täydentää tässä.
• Availiability Date: voit laittaa lähetyspäivän – tämä on mahdollista muuttaa applikaation hyväksymispäivänä, ja vain sinä päivänä. Se kannattaakin tehdä, jotta applikaatiosi saa 15 minuuttia feimiään uusien julkaisujen kärjessä.
• Price Tier. Eka tier näkyy App Storessa hintana 0.99$ / 0,79€ jne. – sinulle Apple tilittää sitten sen siivun kun tilittää
• Description – App Storessa näkyvä kuvausteksti. Tämä kannattaa miettiä tarkkaan!
• Keywords – näillä hakusanoilla softasi löytyy, todella tärkeä!
• Support URL: tämä on pakollinen, eli joku paikka pitää olla valmiina, josta applikaation ostajat saavat (ainakin teoriassa) yhteyden kehittäjään
• Vapaaehtoiset App URL (promoamiseen) ja Privacy Policy URL
• Rating – kaikki likaiset yksityiskohdat kysellään, kannattaa olla varautunut
• 512 x 512 px ikoni App Storea varten
• Vähintään 1, maksimissaan 6 näyttökaappausta applikaatiosta jokaisella applikaatiosi tukemalla laiteresoluutiolla (standard, retina display, iPad). Pikselikoko määrätty tarkkaan – joko koko näyttö tai sitten ilman ylälaidan vakiostatusbaria, jos se ohjelmassasi on näkyvissä.
• Jos juridinen kikkailu kiinnostaa, voit laatia oman EULA:si, muuten käytetään Applen standardipohjaa

Tässä vaiheessa tiedot voi tallentaa. Niitä pääsee muuttamaan vapaasti siihen asti, kunnes lähetät itse applikaatiopaketin tarkistukseen, ja taas applikaation hyväksymisen jälkeen hieman rajoitetummin.

Xcode-projektin puolella

Jos itsestäänselvyydet ohitetaan (softa ei saa kaatuilla jne.), ainakin pari kohtaa pitää säätää projektin asetuksissa.

Tuolla Applikaationnimi.plist-tiedostossa on tuo Bundle identifier – se on oletusarvoisesti tuollaisessa puoliautomaattisesti generoituvassa formaatissa (com.yourcompany.${PRODUCT_NAME:rfc1034identifier}, tuo hämärännäköinen rfc1034 paljastui lopulta kaikessa yksinkertaisuudessaan vaan muotoiluksi, joka varmistaa, ettei bundlenimessäsi ole erikoismerkkejä). Joka tapauksessa, jos toimintasi on pienimuotoista, eikä automatisoinilla ole tässä tilanteessa sinulle merkitystä, voit naputella bundle ID:n tuohon ihan rohkeasti käsin: “com.yrityksesinimi.applikaatiosinimi”. Sitä 10-merkkistä Bundle Seed ID:tä ei enää nykyään tarvitse eikä kuulu tuohon kirjoittaa.

Toinen tärkeä juttu on Deployment Target, eli vanhin käyttisversio, jota haluat applikaatiosi tukevan. Tästä on hyvät kuvitetut ohjeet esim. täällä: http://iphonedevelopertips.com/xcode/base-sdk-and-iphone-os-deployment-target-developing-apps-with-the-4-x-sdk-deploying-to-3-x-devices.html

Jos applikaatiosi käyttisversion lisäksi ehdottomasti vaatii laitteelta jotain tiettyä ominaisuutta (kahta kameraa, gyroskooppia tms.), se kannattaa laittaa tuonne info.plistiin myös (ominaisuuden nimi on Required device capabilities, ja sinne Item 0:ksi vaadittu ominaisuus, ja niin edelleen).

Ai niin, ja jos vakiokiilto ei jostain syystä sovi applikaatioikonisi tyyliin, info.plistiin voi myös lisätä kohdan “Icon already includes gloss effects”. Kulmanpyöristykset tulevat automaattisesti, niitä ei tarvitse eikä voi ottaa pois (tee siis ikonikuvasi ihan nurkasta nurkkaan asti).

Tein siis pikkiriikkisen testiapplikaation, jonka ajattelin jakaa tässä, josko siitä joku muukin hyötyisi. Kyse ei ole siis mistään sen kummemmasta kuin valmis Xcoden “Utility Application” -template, johon olen lisännyt NSLog-komentoja tyypillisimpiin applikaation eri vaiheisiin liittyviin delegate-metodeihin ym. – loki ei siis ole millään muotoa kattava, mutta perustoiminnoista päässee tämän avulla kärryille.

Huom! Ruudulla ei siis näy mitään muuta kuin perus Utility-template flipside-näkymineen – Xcoden Debugger Console (omppu-shift-R) pitää olla auki, jotta applikaatiosta saisi mitään irti.

Tässä Xcode-projekti zip-pakettina.

Asia konkretisoituu varsin mukavasti tiirailemalla konsolia applikaatiota käytellessä. Aika paljon konepellin alla tapahtuu, vaikka ulospäin ei näy juuri mitään. Esimerkiksi heti applikaatiota käynnistäessä pölähtää konsoliin tällainen raportti – MVC tarkoittaa MainViewControlleria, Flipside tietty kääntöpuolen ViewControlleria ja pelkät metodinimet viittaavat Application Delegaten metodeihin.

2011-10-19 23:17:26.485 AppDelegateHarjoitus[183:707] MVC - awakeFromNib
2011-10-19 23:17:26.496 AppDelegateHarjoitus[183:707] application:didFinishLaunchingWithOptions:
2011-10-19 23:17:26.516 AppDelegateHarjoitus[183:707] MVC - viewDidLoad
2011-10-19 23:17:26.520 AppDelegateHarjoitus[183:707] MVC - viewWillAppear
2011-10-19 23:17:26.525 AppDelegateHarjoitus[183:707] MVC - shouldAutorotateToInterfaceOrientation: Portrait
2011-10-19 23:17:26.529 AppDelegateHarjoitus[183:707] MVC - viewDidAppear
2011-10-19 23:17:26.535 AppDelegateHarjoitus[183:707] MVC - shouldAutorotateToInterfaceOrientation: Portrait
2011-10-19 23:17:26.543 AppDelegateHarjoitus[183:707] applicationDidBecomeActive:

Ihan mielenkiintoista oli huomata käytännössä esimerkiksi, että tuo awakeFromNib ilmoittaa olemassaolostaan ennen mitään muita viestejä, ja että tuo Autorotate-metodi tulee jostain syystä kutsutuksi kahdesti: sekä WillAppearin että DidAppearin jälkeen.

Jos App Delegaten ja View Controllereiden perustoiminnot vielä Dev Centerin kahlaamisen jälkeenkin vaikuttavat hieman hämäriltä, kuten minulla, tämän applikaation kanssa leikkiminen voi helpottaa asian hahmottamista.

Ekan applikaationi kehitystyö on siis edennyt debuggausvaiheeseen asti. Kuukausien simulaattorin tuijottelun jälkeen oman appin asennus oikeaan iPhoneen oli kieltämättä aika jänskä paikka. Kyllähän se pyörähti käyntiin, eikä edes aiheuttanut mitään kovin perustavanlaatuista katastrofia.

Silti, jos olet lineaarisen koodauksen kultakaudelta nykyaikaan eksynyt jäärä kuten minä, siinä vaiheessa kun oletat applikaatiosi olevan jotakuinkin valmis, kannattaa alkaa estottomasti näpyttelemään exit- ja sleep-nappeja sekä soitella testipuhelimeesi applikaatiosi pyöriessä. Todennäköisesti töitä riittää vielä, ennen kuin applikaatiosi käyttäytyy siivosti kaikenlaisia satunnaisia keskeytyksiä kohdatessaan – ja niitä puhelimessa kyllä riittää.

Tällä hetkellä tämän yökoodarin huomio on siis kohdistunut enimmäkseen AppDelegaten metodien suuntaan. Asiaa on selvitetty suht. selkeästi Applen Dev Centerissä ja Cocoaneticsissä, mutta kuten aina, periaatteen tajuamisesta on vielä aika lailla matkaa siihen, että hoksaa mitä käytännössä pitää omassa applikaatiossa naputella mihinkin metodiin.

Mutta eiköhän tuo moniajomörkökin tuosta seläty… sittenpä onkin enää jäljellä pientä loppuviilailua siellä täällä, jonka jälkeen täytyykin jo koittaa onnea App Storen hyväksymisprosessin kanssa. Huh! Oma pikkuruinen ikoni App Storen katalogissa alkaa olla kuviteltavissa olevaa lähitulevaisuutta. Olisipa kiva jo mainostaa omaa tuotosta, mutta odotellaanpa nyt vielä tovi, että softa ei sekoa ensimmäiseen vastaantulevaan keskeytykseen…

Loppuun pieni loppukevennys ja samalla käytännön vinkki debuggauksen parissa kamppaileville kanssa-amatööreille: kun olet ihmetellyt tuntikaupalla tyhjästä ilmestynyttä koko applikaation kaatavaa bugia, ei kannata unohtaa tätä: ne samaiset NSLog-komennot, joilla koitat bugia metsästää, eivät ole millään muotoa immuuneita bugiselle koodille itsekään.

Eli ihan – köh, köh – hypoteettisena esimerkkinä teille rakkaat lukijat, pätkä viewWillAppear-metodista:

- (void)viewWillAppear:(BOOL)animated {
    NSLog(@"wiewWillAppear: animated = BOOL (%d)", animated); // Tämä toimii ongelmitta
    // NSLog(@"wiewWillAppear: animated = BOOL (%@)", animated); // Kun taas tämä kaataa koko softan
    // %@ viittaa siis objektiin, jota BOOL ei taasen ole, joten seurauksena on
    // tiltti. Eli myös NSLogin kanssa kannattaa olla tarkkana 
}

Palasin siis metaforiselle Moleskinelleni, valitsin jokseenkin järkevien softaideoideni pinosta kaikista simppeleimmän, ja aloin hommiin. Kyseessä on pikkuruinen yhden näkymän viihdeapplikaatio, ja se alkaa itse asiassa olla olennaisilta osiltaan valmis! Suosittelen muuten kaikille samankaltaisessa tilanteessa oleville: aloittakaa yhden screenin applikaatiolla! Tekemistä ja opettelua riittää ihan varmasti, ja toisekseen, osa maailman suosituimmista iOS-applikaatioista on (ainakin pintapuolisesti) simppeleitä yhden ruudun softia.

Tilanne softan kanssa alkaa olla sellainen, että jotakuinkin kaikki sellaiset ominaisuudet jotka eivät edellytä todellisella iVehkeellä testaamista, alkavat olla valmiina. Toisin sanoen, hurja kahdeksankympin sijoitus omaan Developer Programiin on lähempänä kuin koskaan. Jotta kaikki vapaa-aikani ei menisi omilla applikaatioraakileilla leikkiessä oikealla iPhonella, olen kuitenkin edellyttänyt itseltäni tämän ekan applikaation viimeistelemistä kaikilta muilta osiltaan ennen Developer-tilin avausta ja fyysisellä laitteella testaamista.

Yksi näistä “muista osista” on ohjelmallinen Facebook-statuspäivitys, jota olen siis viime päivät (=yöt) opetellut. Ja se on myös tämän kirjoituksen pohjimmainen motivaattori.

Ja se varsinainen asia:

Siltä varalta, jos joku muukin sattumoisin haluaisi tehdä applikaatiollaan jotain niinkin poikkeuksellista kuin antaa käyttäjän liittää applikaatiosta lähettämänsä kuvan Facebook-statukseensa, eikä tunne tämän asian ympärillä kiehunutta kollektiivista devaajien raivoa, sanottakoon tässä: ei v**** onnistu.

Eli: kuvia voi uploadata FB:iin applikaatiosta käsin (helposti), käyttäjän seinälle voi laatia statuspäivityksen johon saa myös määritellä kuva-URLin, (helposti), näiden uploadattujen kuvien URLin pystyy selvittämään ohjelmallisesti FB graph API:n metodien avulla (pienellä perehtymisellä) mutta näitä nimenomaisia URLeja ei sitten saakaan käyttää statuspäivityksen kuva-URLeina (ei niin sitten millään).

Tulos on virheilmoitus, joka alkaa näin: “FBCDN image is not allowed in stream…” – googlailemalla löytyy muutama tuhat devausblogia, jossa lainataan Facebookin ilmoitusta nähtävästi viime vuoden kesältä:

“We no longer allow stream stories to contain images that are hosted on the fbcdn.net domain. The images associated with these URLs aren’t always optimized for stream stories and occasionally resulted in errors, leading to a poor user experience. Make sure your stream attachments don’t reference images with this domain. You should host the images locally.”

Että se siitä. Eipä siinä muuten mitään, mutta jokseenkin turhauttaa pari viime yötä, jotka meni FB:n developer-dokumentteja kahlatessa ja yllämainittuja tekniikoita opetellessa. Että ehkäpä olisi voinut jossain getting started -osion kohdalla vaikka ilmoittaa, että kenties yleisimmin kaivattu toiminnallisuus sosiaaliselle applikaatiolle on kerrassaan kielletty FB:n toimesta.

Kylläpä taas hieman paremmin osaa arvostaa Applen Dev Centerin loistavasti laadittuja ja käyttäjälähtöisesti kirjoitettuja dokumentaatioita. Jobs 6 – Zuckerberg 0.

Ei mulla muuta, piti vain tulla vähän päästämään höyryjä.

Kuten mainittu, Applella on Sample Code -arkisto, josta löytyy esimerkkitoteutuksia melkeinpä mistä vaan iOS-applikaation perustoiminnosta. Lähdekoodit eivät kuitenkaan näytä päivittyvän kovin usein, mistä seuraa että lataamani iOS SDK 4.2 antaa lähes jokaisen kohdalla virheilmoituksen “Base SDK missing”, eikä applikaatiota pääse testaamaan.

Ratkaisu on kuitenkin useimmiten hyvin yksinkertainen. Tässä kuvasarja toimenpiteistä, joilla vanhemmatkin Sample Codet pitäisi saada kääntymään:

Näistä lisää myöhemmin – tämän postauksen varsinainen tarkoitus on vain esitellä loistava linkkilöytö, joka tuli dokumentaatioita kahlaillessa vastaan.

Itunes U:ssa on nimittäin ladattavissa Stanfordin talven 2010 iPhone-ohjelmoinnin peruskurssin luentovideot kokonaisuudessaan, täysin ilmaiseksi!

Linkki esittelysivuille tässä.

Ekan luennon ensimmäiset parikymmentä minuuttia on vain kurssin käytännön asioiden läpikäymistä, ne voi vaikka skipata, mutta siitä lähtien kyllä täyttä asiaa. Olisinpa törmännyt tähän ekana treenipäivänäni, ei ehkä olisi tarvinnut opetella ihan niin paljon kantapään kautta!

Helpoin osuus oli odotetusti Planet-luokan laatiminen, koska MVC-mallin model-osio toimii täysin itsenäisesti, eikä itselleni vaikeita kytkyjä iOS-käyttöliittymään tarvinnut siis vielä miettiä.  Xcoden new filestä vaan Objective-C class > Subclass of NSObject (joka on iOS-ohjelmoinnissa jonkinlainen “kaikkien olioiden äiti”) ja tallennetaan nimillä Planet.h ja Planet.m. Tämän luokan muuttujien ja metodien määrittely muistutti eniten sitä ohjelmointia jota opettelin silloin joskus kun Ritari Ässä oli vielä kova juttu.

Planet.h

Header-tiedostossa oli #import <Foundation/Foundation.h> joten jätin sen siihen ja naputtelin perään muutamia vakioita kuten:

#define PLANET_GROWTH_RATIO 0.5
#define MAX_PLANET_RADIUS 50.0

Tämä on simppeli tapa määritellä nimettyjä vakioita. Muitakin tapoja näytti olevan, mutta tämä vaikutti tarpeisiini sopivalta.

Sitten määrittelin @interfacen, jossa esitellään luokan julkiset muuttujat, esimerkiksi nämä:

@interface Planet : NSObject {
    BOOL tooFar;
    float radius;
    float mass;
    NSTimeInterval birthday;
    // jne.
}

Noiden floatien sijaan suositeltiin käytettäväksi CGFloatia, kuulemma helpottaa 64-bittisyyteen siirtymistä, mutta kaipasin hämmentävän koodin joukkoon jotain ennestään tuttua, joten käytin float-määritystä. Tuo NSTimeInterval taisi olla sekin vain normaali float tms., mutta koska sitä käytetään nimenomaan ajan mittaamiseen se on ymmärrettävyyden vuoksi nimetty noin. En tiedä, olisiko jotenkin parempi käyttää näissäkin pointereita, mutta olen jotenkin vielä arka käyttämään niitä muuten kuin pakon edessä (olioihin viitatessa).

Sitten @propertyt (eli ne getter/setter-metodin automatisointikäskyt) samoille muuttujille tähän tapaan:

@property(nonatomic, readwrite, getter=isTooFar) BOOL tooFar;
@property(nonatomic, readwrite) float radius;
@property(nonatomic, readwrite) float mass;

Ja vielä metodien nimet:

-(id) initWithLocation: (CGPoint)theLocation birthday:(NSTimeInterval)theBirthday;
-(void) calculateGravityWithSolarSystem: (NSDictionary *)theSolarSystem;
//jne.

Tuo eka on alustusmetodi, joten siinä on paluuarvona (id), eli tässä tapauksessa planeetta-luokan instanssi. Tuo painovoima-metodi ei palauta mitään lopputulosta vaan muuttaa vain sen planeetta-instanssin sisäisiä arvoja, josta sitä kutsutaan,  joten paluuarvona on (void). Samaan tapaan kaikki tarvittavat metodit ja sitten loppuun vielä @end, niin päästään varsinaiseen metodien määrittelyyn.

Planet.m

Tässä jonkin verran karsittu listaus tiedoston alusta:

#import "Planet.h"
@implementation Planet

@synthesize tooFar;
@synthesize radius;
@synthesize mass;
// jne.

-(id) initWithLocation:(CGPoint)theLocation birthday:(NSTimeInterval)theBirthday
{    self = [super init]; //tämä rivi piti olla, se liittyi jotenkin periytymishommiin mutten nyt muista tarkemmin
    if (self) { //pitää varmistaa että edellisen rivin komento onnistui ennen kun aloitetaan alustelu
        self.xCenter = theLocation.x;
        self.yCenter = theLocation.y;
        self.birthday = theBirthday;
        self.tooFar = NO;
        self.radius = BABY_PLANET_RADIUS;
        self.diameter = self.radius*2;
        self.mass = (self.radius * self.radius * self.radius) / MASS_DIVIDER;
        self.xSpeed = 0;
        //jne.
    }
    return self;
}

-(void) calculateGravityWithSolarSystem: (NSDictionary *)theSolarSystem {
    float xDistance, yDistance, distance = 0.0;
    double multipliedMasses, distanceSqr, gravity, xGravity, yGravity = 0.0;
    // seuraavat kolme riviä käyvät läpi theSolarSystem -Dictionaryn
    // kaikki planeetat, eräänlainen looppi siis, kiitti vinkistä www.hopeinenomena.net
    NSEnumerator *enumerator = [theSolarSystem keyEnumerator];
    id key;
    while ((key = [enumerator nextObject])) {
        xDistance = ([[theSolarSystem objectForKey:key] xCenter] - self.xCenter);
        yDistance = ([[theSolarSystem objectForKey:key] yCenter] - self.yCenter);
        distance = sqrtf((xDistance * xDistance) + (yDistance * yDistance));
        if (distance != 0) {
            if (distance < (self.radius + [[theSolarSystem objectForKey:key] radius])){
                // Ympyröiden törmäystunnistus, hillitsee älytöntä kiihtymistä pakottamalla
                // etäisyysmuuttujan vähintään planeettojen säteiden summan suuruiseksi.
                // Ei kimpoamislaskelmia tms. vielä, väri vain muuttuu punaiseksi
                distance = (self.radius + [[theSolarSystem objectForKey:key] radius]);
                NSLog(@"Hit!");
                self.red = 1;
            }
            multipliedMasses = (self.mass * [[theSolarSystem objectForKey:key] mass]);
            distanceSqr = (distance * distance);
            gravity = multipliedMasses / distanceSqr;
            xGravity = gravity * xDistance / distance;
            yGravity = gravity * yDistance / distance;
            self.xForce += (xGravity);
            NSLog(@"distance: %f, gravity: %f, multipliedMasses: %f, distanceSqr: %f", distance, gravity, multipliedMasses, distanceSqr);
            NSLog(@"xDist: %f, xForce: %f, xGravity: %f", xDistance, self.xForce, xGravity);
            self.yForce += (yGravity);                    
            NSLog(@"yDist: %f, yForce: %f, yGravity: %f", yDistance, self.yForce, yGravity);

        }
    }
}
// jne.

Tuo calculateGravity… oli melko kinkkinen, mutta ei varsinaisten gravitaatiolaskelmien takia, vaan koska en meinannut millään osata tehdä luuppia. Samaan ongelmaan törmäsin myös myöhemmin, kun ajastinmetodin sisällä piti kutsua kaikkien planeettojen päivitystoimintoja vuorotellen. Onneksi  hopeinenomena.netin avuliaat toverit tulivat hätiin ja neuvoivat tuon enumerator-objektin käytön. Tästä tarkemmin vähän jäljempänä. Tuo Dictionary joka koodissa paljon toistuu, on muuten kuten taulukko, mutta siihen tallennetaan objektin kaveriksi aina key-arvo, jota käyttämällä päästään aina tarvittaessa käsiksi oikeaan objektiin.

SolarSystemView.h ja .m

Planeetat piirretään view-luokan drawRect-metodissa, jonka käyttöä aiemmin jo vähän opeteltiinkin. View-luokassa tarkkaillaan kuitenkin myös kosketusnäyttöä ja luodaan kosketusten perusteella uusia planeettoja. Header on lyhyt, kokonaisuudessaan tässä:

#import <UIKit/UIKit.h>
#import "Planet.h"
#import "SolarSystemViewController.h"
#import "SolarSystemAppDelegate.h"

@class SolarSystemViewController;

@interface SolarSystemView : UIView {
    SolarSystemViewController *solarSystemViewController;
    float dashes[2];
    NSMutableDictionary *solarSystem;
}
@property(nonatomic, retain) SolarSystemViewController *solarSystemViewController;
@property(nonatomic, readwrite, retain) NSMutableDictionary *solarSystem;

@end

Siinä pohjustetaan Viewin paritusta ViewControllerin kanssa, josta tarkemmin kohta. Ekaksi kurkataan kuitenkin pari juttua View.m:stä. Se alkaa näin:

#import "SolarSystemView.h"
@implementation SolarSystemView
@synthesize solarSystemViewController;
@synthesize solarSystem;

- (id)initWithFrame:(CGRect)frame {

    self = [super initWithFrame:frame];
    if (self) {
        self.backgroundColor = [UIColor blackColor];
        dashes[0] = 2;
        dashes[1] = 5;

        solarSystem = [[NSMutableDictionary alloc] initWithCapacity:20];
    }

    return self;
}
//jatkuu...

Tuossa heti alussa on taas ilmiö, joka tulee Cocoan kanssa usein vastaan: tuota initWithFrameahan ei määritelty headerissa lainkaan, silti sen toiminta tuossa selvästi määritellään. Se on yksi näistä lukuisista vakiomuotoisista metodeista, joita iOS kutsuu automaattisesti sopivissa tilanteissa, ja jotka koodaaja uudelleenmäärittelee tekemään mitä sitten haluaakaan. Tässä tapauksessa määrittelemään taustavärin sekä vähän nolosti tuon dashes-taulukon tuossa, koska en osannut tehdä taulukkoa vakiona (tuota dashes-taulukkoa tarvitaan myöhemmin planeettojen ääriviivoissa käytetyn katkoviivan määrittelyyn). Ja sitten alustetaan tuo solarSystem -dictionary, johon kaikki luotavat planeetat tullaan laittamaan talteen.

Saman tiedoston drawRect-metodissa loopataan läpi kaikki kirjastoon tallennetut planeetat ja piirretään niiden perustella sopivankokoiset ympyrät oikeille paikoilleen, tähän tapaan:

// Only override drawRect: if you perform custom drawing.
// An empty implementation adversely affects performance during animation.
- (void)drawRect:(CGRect)rect {
    CGContextRef solarSystemContext = UIGraphicsGetCurrentContext();
    //CGContextClearRect (solarSystemContext,CGRectMake(0, 0, 320, 480));
    CGContextSetLineWidth(solarSystemContext, 2);
    CGContextSetLineDash (solarSystemContext, 0, dashes, 2);
    CGContextSetLineCap(solarSystemContext, kCGLineCapRound);
    NSString *key;
    for(key in solarSystem){
        CGContextSetRGBFillColor (solarSystemContext, [[solarSystem objectForKey: key] red], [[solarSystem objectForKey: key] green], [[solarSystem objectForKey: key] blue], [[solarSystem objectForKey: key] alphaValue]);
        CGContextSetRGBStrokeColor (solarSystemContext, [[solarSystem objectForKey: key] red], [[solarSystem objectForKey: key] green], [[solarSystem objectForKey: key] blue], [[solarSystem objectForKey: key] alphaValue]);    
        CGContextAddEllipseInRect (solarSystemContext, CGRectMake ([[solarSystem objectForKey: key] leftEdge], [[solarSystem objectForKey: key] topEdge], [[solarSystem objectForKey: key] diameter], [[solarSystem objectForKey: key] diameter]));
        CGContextDrawPath(solarSystemContext, kCGPathFillStroke);
    }
    [key release];
}

Tuossa olin näköjään osannut käyttää luuppia Dictionaryn läpikäyntiin noin yksinkertaisesti, miksihän en muistanut tuota tapaa siellä Planet-luokan koodissa tai myöhemmin siellä Timer-metodissa… no, tulipa treenattua erilaisia luuppaustapoja!

Edelleen, täällä SolarSystemView.m:ssä on määritelty uudestaan kosketusnäytön tapahtumiin reagointimetodit. Nämä voisivat ymmärtääkseni olla View Controllerinkin puolella kuten ajastinmetoditkin (oho, spoileri!), ja minulla on sellainen fiilis, että ehkä niiden tyylikkyyden nimissä pitäisikin, jotta View-objektille jäisi selkeästi pelkkä ruudun piirto. Mutta en ole ihan varma, joten ne nyt jäivät tähän – kumpikaan tapa ei siis ole varsinaisesti laiton. Mutta ne touches-metodit, tässä:

// Handles the start of a touch
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{    
    //NSUInteger numTaps = [[touches anyObject] tapCount];
    // Enumerate through all the touch objects.
    for (UITouch *touch in touches) {
        CGPoint touchLocation = [touch locationInView:self];
        NSString *addressToTouchThatCreatedAPlanet = [[NSString alloc] initWithFormat:@"%u", touch];
        Planet *aPlanet = [[Planet alloc] initWithLocation:touchLocation birthday:[touch timestamp]];

        [solarSystem setObject: aPlanet forKey: addressToTouchThatCreatedAPlanet];
        [aPlanet release];
        [addressToTouchThatCreatedAPlanet release];

        /*
        Tällä palautetaan osoite takaisin integeriksi
        unsigned int addressAsInteger = [addressToTouchThatCreatedAPlanet intValue];
        UITouch *testTouch = addressAsInteger;*/
        [self setNeedsDisplay];
    }    
}

// Handles the continuation of a touch.
-(void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{  
    // Enumerates through all touch objects
    for (UITouch *touch in touches) {
        CGPoint touchLocation = [touch locationInView:self];

        Planet *aPlanet = [solarSystem objectForKey: [NSString stringWithFormat:@"%u", touch]];
        [aPlanet movePlanetToLocation:touchLocation];
    }

}

// Handles the end of a touch event.
-(void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    // Enumerates through all touch object
    for (UITouch *touch in touches) {
        CGPoint touchLocation = [touch locationInView:self];
        CGPoint previousTouchLocation = [touch previousLocationInView:self];

        Planet *aPlanet = [solarSystem objectForKey: [NSString stringWithFormat:@"%u", touch] ];
        [aPlanet setPlanetFreeWithXSpeed: (touchLocation.x - previousTouchLocation.x) ySpeed:(touchLocation.y - previousTouchLocation.y)];
    }
}

-(void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
    // Enumerates through all touch object
    for (UITouch *touch in touches) {
    // täällä pitäisi varautua siihen, jos touch-tapahtuma keskeytyy esim. puhelimen soidessa, mutta en ole viitsinyt 
    }
}

Tuossa ekassa metodissa touchesBegan käy ilmi myös minkä takia päädyin Dictionaryyn planeettojen tallentamiseksi enkä settiin tai arrayhin. Kaunis ajatukseni oli tallentaa planeetan key-pariksi sen kosketuksen pointteriosoitteen, jolla kyseinen planeetta on luotu, jotta multitouch-tilanteessa planeetta osaisi pysytellä juuri oikean kosketuksen mukana. Itse asiassa tämä toimiikin, mutta samalla syntyi koodin toistaiseksi järein bugi. iOS nimittäin kierrättää kosketusten pointteriosoitteita aika tehokkaasti vanhojen kosketusten päätyttyä,  joten uudet planeetat alkavat ennen pitkää tallentua vanhojen päälle. Tämä pitäisi korjata käyttämällä dictionaryä vain kosketusten ajan, tai tallentaa koko kosketuksen osoitetieto vaikka tuonne planeetta-luokan muuttujaan ja tarkistaa touchesMoved-metodissa sieltä käsin. Tämä on vielä vähän hakusessa

SolarSystemViewController.h

Tämä on hyvin simppeli:

#import <UIKit/UIKit.h>
#import "SolarSystemView.h"
#import "Planet.h"

@class SolarSystemView;

@interface SolarSystemViewController : UIViewController {
    SolarSystemView *solarSystemView;
    NSTimer *solarSystemTimer;
}

@property (nonatomic, assign) SolarSystemView *solarSystemView;

-(void) updateSolarSystem:(NSTimer*)theTimer;

@end

Tuossa määriteltiin solarSystemView-instanssi, jotta näkymää päästään kontrolloimaan. Ja sitten tuo tärkeä NSTimer *solarSystemTimer -ajastinobjekti, jota tarvitaan säännöllisen tilannepäivitysrutiinin käynnistämiseen. ViewControllerin ainoa oma metodi onkin tuo updateSolarSystem, jota tuolta ajastimesta sitten säännöllisesti kutsutaan.

SolarSystemViewController.m

Täällä ei oikeastaan olekaan muuta kuin tuo updateSolarSystem-metodi sekä ViewController-templatessa valmiina tulleet metodit, joista tarvitsi uudelleenmääritellä vain tuo loadView

#import "SolarSystemViewController.h"
@implementation SolarSystemViewController
@synthesize solarSystemView;

-(void) updateSolarSystem: (NSTimer*)theTimer {
     NSMutableArray *keysForPlanetsToRemove = [NSMutableArray array];
     NSEnumerator *enumerator = [[solarSystemView solarSystem] keyEnumerator];
     id key;
     while ((key = [enumerator nextObject])) {

         if ([[[solarSystemView solarSystem] objectForKey:key] isTooFar])
         { [keysForPlanetsToRemove addObject:key];
         NSLog(@"%@", keysForPlanetsToRemove);}

         else {
             [[[solarSystemView solarSystem] objectForKey:key] growPlanetUnderConstruction];
             [[[solarSystemView solarSystem] objectForKey:key] calculateGravityWithSolarSystem:[solarSystemView solarSystem]];
             [[[solarSystemView solarSystem] objectForKey:key] movePlanet];    
         }
     }
    [[solarSystemView solarSystem] removeObjectsForKeys:keysForPlanetsToRemove];

    NSLog(@"Planeettoja: %u", [[solarSystemView solarSystem] count]);
    [solarSystemView setNeedsDisplay];
}

// Implement loadView to create a view hierarchy programmatically, without using a nib.
- (void)loadView {
    self.wantsFullScreenLayout = YES;
    SolarSystemView *view = [[SolarSystemView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame];
    view.solarSystemViewController = self;
    self.view = view;
    self.solarSystemView = view;
    self.view.multipleTouchEnabled = YES;
    [view release];
    // Timerin ohjelmointi
    solarSystemTimer = [[NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(updateSolarSystem:) userInfo:nil repeats: YES] retain];

}

/*
// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad {
    [super viewDidLoad];
}
*/

/*
// Override to allow orientations other than the default portrait orientation.
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
    // Return YES for supported orientations.
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}
*/

- (void)didReceiveMemoryWarning {
    // Releases the view if it doesn't have a superview.
    [super didReceiveMemoryWarning];

    // Release any cached data, images, etc. that aren't in use.
}

- (void)viewDidUnload {
    [super viewDidUnload];
    // Release any retained subviews of the main view.
    // e.g. self.myOutlet = nil;
}

- (void)dealloc {
    [super dealloc];
}

@end

Tämä rivi oli itselleni ehkä koko harjoituksen valaisevin:

solarSystemTimer = [[NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(updateSolarSystem:) userInfo:nil repeats: YES] retain];

Tuolla siis laitetaan käyntiin ajastin, joka lähettää kerran sadasosasekunnissa (jos pystyy) kohteelle self, eli tälle ViewControllerille itselleen metodikutsun updateSolarSystem. Tuossa siis vihdoin on se “pääluuppi” tai ainakin niin lähellä sitä kuin Cocoa-maailmassa pääsee ilman todellisia hc-kikkoja. Ja tuolta loadView-metodin lopusta sille löytyi mielestäni ihan looginen paikkakin – ajastinta tarvitaan ekan kerran siinä vaiheessa kun eka näkymä on latautunut loppuun.

Jaha, kello on 4:22

Ehkä pitää muuten mainita, että tässä harjoituksessa jätin tarkoituksella kaikki Interface Builderilla wysiwyg-tyyliin laaditut näkymät kokonaan pois, ja kokeilin näkymän luomista ohjelmallisesti – osittain harjoittelun vuoksi ja osittain, koska IB-elementtien linkitys koodiin aiheuttaa vielä toistaiseksi enemmän hämmennystä kuin helpotusta. Kannattaa kuitenkin ehdottomasti käyttää Interface Builderia, jos tarvitset lähimainkaan Apple-tyylistä vakionavigointia – vakioelementit ovat aika pitkälle tuunattavissa, joten omaakin ilmettä niillä kyllä saa. Tähänkin projektiin varmaan käyttäisin IB-näkymiä esimerkiksi preferences-valikkoon ja planeettanäkymän päälle tuleviin pistelaskureihin tms.; pitää vain ensin opetella se linkitys paremmin.

Tuo NSLog on muuten aika välttämätön komento työstövaiheessa. Xcoden Run-valikosta löytyvä Console kannattaa pitää auki ja NSLogilla lähetellä työstövaihessa tarvittavaa tietoa sinne, jotta pääsee kärryille esim. ohjelmakoodin bugeista.

Korostan siis vielä, että näitä lähdekoodeja ei missään tapauksessa kannata pitää esimerkkitapauksina oikeaoppisesta Cocoa-ohjelmoinnista. Nämä ovat harjoitusvaiheen koodeja ja täynnä tehottomuuksia ja epäloogisuuksia. Otan mielelläni vastaan kaikenlaisia vinkkejä edistyneemmiltä iOS-koodaajilta!

Testatessa on kyllä ilmennyt harmillinen juttu, jota en osannut ihan ennakoida, nimittäin fysiikan lait. Planeetan saaminen toisen kiertoradalle onkin muuten aika pirun tarkkaa hommaa, eikä se oikein onnistu näppituntumalta, kuten olin mielessäni alunperin hahmotellut. Jos näkymän laittaisi zoomailemaan ulospäin tarvittaessa, jotta pystyisi hahmottamaan isomman palan avaruutta kerralla, voisi tämä helpottua, mutta varsinaisen aurinkokunnan kasaaminen edellyttäisi kyllä koodiin jonkinlaista tekoälyä, joka vaivihkaa avustaisi planeettoja toisiaan kiertäville radoille. Se on ehkä tässä vaiheessa turhan monimutkaista, joten tämä harjoitus taitaa nyt  jäädä odottelemaan taitojeni karttumista. Monenlaista muuta on kuitenkin kehitteillä, ei tämä tähän lopu!

Kurkista tästä applikaatiota toiminnassa.

Kuva 6.0. Kuten yleisesti tiedetään, aikamatkustaja ei yleensä saa mukaansa irtainta omaisuutta, joten tämä referenssiteos ei selvinnyt vuoteen 2011 asti. Kirjoittaja joutuu siis tyytymään Googleen.

Viimeksi raaputeltiin vähän iPhone-arkkitehtuurin pintaa ja saatiinkin siitä ainakin jonkinlainen alkeellinen kuva. On isot Cocoan frameworkit joihin tukeutua, on oliot ja Model-View-Controller -filosofiat. Jottei homma menisi ihan teoretisoinniksi, nyt pitäisi taas päästä tekemään jotain käytännössä.

Käytin autoilupeliä esimerkkitapauksena jossain aiemmassa kirjoituksessani, mutta kaahailugenre on harjoitteluvaiheessa  aivan liian vaativa ja kaiken lisäksi melkoisen loppuunkaluttu pelimarkkinoilla. Jotakin simppelimpää siis.

Ympyröitä on jo saatu ruutuun, mitäs niistä saisi aikaan? No vaikka – planeettoja. Painovoima on aina muodissa ja sen laskemiseen löytyy kaavat googlaamalla (ensimmäinen ajatukseni oli kaivaa MAOL:n taulukkokirja esiin, kunnes muistin taas että nyt ollaankin 2000-luvulla). Näyttöä koskettamalla voisi luoda planeettoja, jotka sitten vaikuttaisivat toistensa liikeratoihin painovoimalain määräämällä tavalla. Suhteellisen helppo toteutus ja lopputuloksena mahdollisesti jopa ihan viihdyttävä lelusovellus. Hei, et sitten ryövää tätä ideaa ja tienaa sillä miljoonia, senkin lurjus, tai David Fincher tekee sinusta leffan, jonka perusteella kaikki alkavat pitää sinua kusipäänä.

Kuva 6.1. Kirjoittajan ensimmäisen applikaation ansaintalogiikka graafisena esityksenä.

Eli töihin sitten vaan. Tarvitaan ainakin luokka planeetan ominaisuuksien ja toimintojen kokoamiseen. Planeettojen sijainnit ja keskinäiset vetovoimat pitää päivittää säännöllisesti, siihen tarvitaan Timer Eventiä. Uusia planeettoja pitää päästä luomaan näyttöä koskettamalla, sitä varten täytyy ottaa haltuun Touch Eventeihin reagointimetodit. Ja pitäähän ne planeetat myös piirtää ruutuun; aiemman harjoituksen ympyränpiirtorutiinit saavat kelvata siihen toistaiseksi, hieman tuunattuina toki.

Tietysti oikeassa pelissä on myös jonkinlainen intro, highscore-näkymät, preferences-osio ynnämuut, mutta sille kaikelle on aika sitten myöhemmin – ensin pitää saada perustoiminnot kasaan. Motivoin itseni lupaamalla, että jos saan tämän applikaation julkaisukuntoon, voin sijoittaa 100 taalaa Applen Developer Programin vuosimaksuun, joka tarvitaan jotta omia softia voi testata puhelimessa – tai, sitten joskus, julkaista App Storessa!