#tutkimusmikroblogi

Minulla on >20 vuoden kokemus koodauksesta. Matkan varrella pääkielinä Delphi (object pascal) ja Java. Kaikenlaista muutakin on tullut opeteltua/koodailtua. Delphin oliomallista olen tykännyt kovasti. Toisaalta sen käyttöliittymän/koodin yhteiselo on niin hienosti tehty, että Microsoftin kannatti palkata Delphin pääkehittäjä kun he tekivät .Netin. Sen ideologiat ovat hyvin delphimäisiä -- Jos ei tunne delphiä, mutta tunnet .netin, moni asia on mietitty samaan tapaan, ainakin kun puhutaan käyttöliittymistä.

iPhonessa kielenä on object-C ja kehitysympäristönä XCode - Sinänsä kiva, että samalla oppii koodaamaan myös Mac OSX:ään.
C ja C++ on sinänsä tuttuja, mutta object-C:ssa on muutamia ainakin aluksi hyvin kummallisia juttuja. Kerron niistä tuonnempana.

Vielä kummallisempaa on tapa, jolla koodi ja käyttöliittymä yhdistetään. Delphissä olen tottunut, että piiretelen näyttöformille objecteja, annan niille nimen ja klikkaamalla siiryn kirjoittamaan koodia ko. objectin haluttuun eventtiin. Tässä ympäristössä kaikki näyttöobjektit pitää ensin itse esitellä koodissa (=kirjoittaa koodiin muuttujamäärityksiä joiden tyypit ovat näyttöobjekteja) ja sitten graafisella puolella pudottaa näytölle vastaava kenttä. Tämän jälkeen näiden välille tehdään mäppäys graafisesti vetämällä. Melko rumaa.

Muistihallinnastakin löysin jotain ihmeellisyyksiä. Ehkä niistäkin tuonnempana.

XCode sinänsä on aika kivan oloinen ympäristö.

+1 mainiota että aloitit @Ile.Äkkiseltään tulee mieleen aihe, josta jätin juuri MB-kolumninkin sisään. Ilmestynee noin 1kk päästä printissä.

Voisiko jossain vaiheesssa saada kännykameroihin helposti rukattavan rajapinnan siis meille tampioille? Jonkinlainen html-kuvauskieli? Voisiko esm känny - ja mielellään myös ajan myötä digikamerat - tuottaa digikuviin metadatan automaattisesti?

Kameroiden kanssa homma on työläämpää, mutta kämmykameroilla voisi kuvitella sen onnistuvan helposti. Netistä voisi hakea mp3:n tapaan paikan perusteella yleisimmät tägit. Käyttäjä voisi upata vaikka kalenterinsa kännyyn ja oletuksena kuvia otettaisiin sen perusteella. Toisaalta voisi kirjoittaa (känny)kameraan, että tästä alkaa setti "Kyoto" ja kamera(känny) laittaisi sen jokaiseen kuvatiedoston nimeen ja myös metadataan.

@ubiq Miksi noi tagit/tapahtumat pitäisi valua sinne kameraan? Ei niitä siellä kuitenkaan käytetä (vai olisiko niille siellä oikeasti käyttöä?). Eikös riitä, jos kamera osaa toimittaa kuvien mukana mahdollisimman paljon metatietoa, joka tallentuu verkkoon kuvan kera.

Tarkka lokaatio on kaikkein tärkein (itse kerään kännyni sijaintia Google Latitudesta kantaan, joten saan liitoksen ottamiini kuviin tätä kautta ilman, että kamera osaa sitä tehdä).
Sen lisäksi voisi olla kiva saada metatietoa ympäristöstä. Esim. kaverien kännyt voisi olla kiva bluetoothpariuttaa kameran kanssa niin, että se tunnistaisi keitä on ollut 10 metrin säteellä kamerasta kuvanottohetkellä. Säätila (vaikkapa paine+lämpötila) voisi olla kiva, tosin nämäkin voisi saada lokaation+ajan mukaan liitettyä kuviin avoimista säätietojärjestelmistä.

Ympåäristöön olisi kiva voida jättää tageja (tähän on jo jokin palvelu). Nämä toisi mukavan lisän siihen, että kuvat tagittuisivat automaattisesti myös crowdsourcingilla, jopa jälkikäteen. Luulen, että tällaisen kuvatagin teko kamerasta voisi olla kiva ominaisuus. Kun sen tekee, se tallentuu kamerann. Kun kuva viedään koneelle/verkkoon, softa kysyisi, haluatko julkaista sen ko. lokaatioon muillekin ja samalla kysyisi, mitä muiden julkaisemia tageja haluaa mukaan...

Kyse on siis enemmän siitä, mihin kuvat valuvat ja miten siinä vaiheessa ne voitaisiin täydentää metadatalla (esim. EXIF tietoihin). Lokaation perusteella maa ja kaupunki, säätila, kalenterista viittaus reissuun (jos ei ole merkintää, voisi siirtosofta kysyä lisätäänkö -- Tämä voisi tehdä kalenterimerkinnän), kameran metatiedoista kaveritägit jne.

@ile ei mitenkään välttämättä kameraan. Kirjoittelin juuri MB-kolumin aiheesta. Paikkatieto on ehdottoman hyvä alku automatisoinnille, mutta jotain muutakin voisi kaivata, kuten kirjoitat, säätiedoista alkaen.

Mitä itse hahmottelin, niin olisi 3 tasoa tai vaihtoehtoa metadatan automatisoinnille: kamera, tietokone ja netti. Vastaavasti kotikuvien tuotanto- ja jakelumallissa on 3 vaihetta automatisoidulle täggäykselle: ennen kuvan ottamista, kuvan siirtäminen tietokoneelle ja siirto nettiin.

Vaihtoehdoista riippumatta mielestäni tuossa olisi bisneksen paikka ;)

Voin pistää kolumnin maililla, pistä osoitteesi mailia kari.hintikkä ät gmail.com, niin voit vapaasti ampua sen als LOL

@ubiq Vielä kun joku keksisi alkaa laskea joka digikuvalle yksilöllisen identiteetin (sha1 hash originaalin pikselidatasta tms). Tämä kulkisi EXIFfinä kuvan kaikissa versioissa. Jos tämä kenttä olisi hakukoneiden hakutekijänä, voisi kaivaa tietoa kuvan käytöstä takaisin. Varsinainen hauskuus syntyisi siitä, kun joku tagittelisi kuvaa (esim. FB:ssä kertoo, ketä on kuvassa) ja hakukoneella/erilaisilla API-kirjastoilla saisi raavittua tätä tagitusta takaisin omaan originaalikirjastoon..

..palataanpas aiheeseen.

Kehitämme iPhone-softaa @viljami:n MacBook Prossa. Koneessa on meillä kummallakin omat tunnukset. Olimme viritelleet XCoden Viljamin tunnukselle jo aiemmin. Jotta yhteinen devaus onnistuisi, päätimme tehdä koneeseen uuden tunnuksen Developer, johon kumpainenkin tietää salasanan.

XCode käynnistyi Developer-tunnuksella ok, mutta aiemmin tehtyihin sourcetiedostoihin piti antaa toki oikeuksia. Viljamin tunnuksella tehdyt softakokeilut kääntyivät ja toimivat simulaattorissa, mutta ei valunut laitteelle asti, koska tällä "uudella" kehittäjällä ei ollut sertifikaatit kunnossa.

Saimme lopulta toimaan, homma meni suunnilleen näin (tästä lähin tuo Developer on vain D):

• teimme D:lle gmail-postilaatikon
• logattiin iPhonen devaussivulla mun päätunnuksella
• Lisättiin sinne tiimiin uusi devaaja D - Tähän annettiin äsken tehty gmail-tunnus
• D meni iPhonen devaussivulle ja teki sinne tilin
• gmailiin tuli konfirmointilinkki tuohon tiimiin lisäyksen perusteella, aktivoitiin tällä itsemme tiimin jäseneksi.
• jokainen devaaja tarvitsee oman kehittäjäsertifikaatin. Pyydettiin tällainen ko. saitilta. Tätä varten piti avainnipun hallinnasta tehdä sertin allekirjoituspyyntötiedosto
• kirjauduttiin ulos D-tililtä ja sisään iPhone devaussivustoon mun päätunnuksella
• Hyväksyttiin devaaja tiimin
• Takakisin D-tilillä -- Nyt sai ladata devaajan sertifikaatin. Klikkaamalla asentui avainnippuun
• Nyt takaisin päätunnuksella
• Lisättiin ko. devaaja haluttujen sovellusten sertifikaatteihin
• Ladattiin sovellusten sertifikaatit. Nämä Xcode lisäilee itse johonkin

@Ile Näillä on aika pitkä historia: Objective-C tehtiin alkuun esikääntäjänä C:n laajennukseksi, sillä sitten tehtiin aikanaan paljon softaa NeXTiin (jonka Apple sitten osti ja sitä rataa). Sen perusmalli on viestin lähetys a la Smalltalk, tästä varmaan nämä outoudet. Xcode ja Interface Builder antavat kyllä mahdollisuuden siihenkin, että käyttöliittymää piirrellessä voidaan generoida pohjakoodi. (Niin, näillä välineillä kehitettiin www, Xcode ei silloin vielä tietenkään ollut olemassa...) Parhaita puolia IB:ssä ja käyttöliittymän rakentamisessa on, että simppeleitä asioita voi tehdä kirjoittamatta riviäkään koodia.
Aikomus ei ole häiritä mikroblogiasi, mutta noille outouksille on tosiaan omat taustansa, jotka saattavat auttaa ajattelutavan avaamisessa.

Kiitos @jwa -- Kyllä tänne saa kommentoida sekaan. Hauska kuulla vähän historiaa, tuolla tulee tosiaan eteen juttuja, joista voi päätellä että nuo on vähän pidemmän historian takana..

Ihmettelin aiemmin, miten syvältä XCoden Interface Builder (IB) vs. koodin välinen linkitys on. Tänään ihmettelin aikani, kuinka Tab Control -tyyppinen näyttö tehdään ja aiemmat ihmettelyt jatkuivat.

Löysin tämän foorumikeskustelun, jossa DevTeamOfOne kertoo, että kannattaa unohtaa koko IB ja rakentaa nuo simppelit näytöt suoraan koodissa. Taidanpa kokeilla tätä tietä seuraavaksi...

Tästä sain lisää vahvistusta, että kannattaa unohtaa IB. Samoin tästä.

Lähetin FB:ssä viestiä kaverille, joka on koodannut iPhonelle. Häneltä sain vahvistusta, että kannattaa kuitenkin opetella IB:n kaveriksi. Pelit tehdään ilman IB:tä, mutta kaikki käyttöliittymäintensiivinen kannattaa opetella tekemään IB:llä.

--> Paluu IB:n opiskeluun, mutta tulipahan tutustuttua ympäristön alkulähteisiin. Samalla syntyi ymmärrystä, miksi tuo näyttää jostain kohdasta vähän purkkaviritykseltä...

Huh, onpas pitkä aika edellisestä postauksesta. Olen pikku hiljaa opiskellut iPhone / Objective-C-koodausta ja tykkään koko ajan enemmän. @jwa Kiitos noista taustoituksista. Kaikelle tosiaan löytyy hyvät perusteet kun tietää historian.

Viestien välitys ja perintämekanismit miellyttää, kun on oppinut perusmekanismit. Myös muistinhallinta on hieno. Ihmettelin tuolla alussa, miten ensin alloikoidaan objekti, sitten se lisätään listalle ja heti perään deallokoidaan. Nyt ei ihmetytä, kun tiedän, että objekteilla on automaattisesti referenceCount, jota objektista kiinnostuneet päivittävät isommaksi ja release itse asiassa vain vähentää tätä yhdellä. Näin samaa objektia tosiaan varaillaan vapautellaan eri paikoissa, mutta tämä malli toimii hienosti, kun tehdää mobiilisoftaa eikä välttämättä ole keskitettyä älyä, mitä tarvitsee pitää muistissa ja mitä ei.

Samoin MVC (model-view-controller) on helppo toteuttaa. Datat saa viuhumaan käyttöliittymämoduleihin delegaateilla, viestibroadcasteilla tai "tilaamalla muutoksista" tieto (publish/subscribe-malli, tätä en vielä ole käytännössä kokeillut/tarvinnut).

Ensimmäin appstoreen menevä softa valmistuu hitaasti mutta varmasti. Olen tehnyt jo pari rundia refaktorointia jolla on syntynyt muutama kätevä uudelleenkäytettävä palikka.

iTunesista ilmaiseksi ladattavissa olevasta iPhone-koodausluentosarjasta (Standfordin yliopistosta tältä keväältä) on ollut paljon apua.

Harrastus jatkuu. Nyt alkaa iPhone-koodaus tuntua kivalta kodilta -- Enää ei mene päivätolkulla ihmettelyyn vaan kohtuu isojakin koodaushaasteita / refaktorointeja saa toimimaan suoraan.

Frameworkkiin sisäänrakennettu unittestaus vaikuttaa hienolta: Buildtargetiksi voi määrittää projektin unittestit, jotka ovat riippuvaisia itse projektitargetista --> jokainen käännös ajaa testit ja jos ne eivät mene läpi, ei softa käynnisty simulaattoriin vaan raportoi syntyneet virheet unittesteissä. Näin hyvin tekemiseen integroitua unittestausta en ole ennen kokenut.

Kohta on #trendyhangman julkaisukunnossa. No, on sitä väännettykin :-)

Ainiin -- XCode 4 näyttää ennakkotietojen mukaan hienolta. Siinä vihdoin tuo Interface Builder integroituu XCodeen, jolloin monesta noista aiemmin valittamastani outoudesta päästään eroon.

@ubiq @jwa Nyt on eka iOS-softa menossa AppStoreen. Ehti tulla jo yksi reject, mutta ihan selkeä moka testauksessa: iPhone 4:lla pari ikonia tuli väärän kokoisena ja myös simulaattorilla tuon olisi huomannut. Sinänsä ihan hieno eka softa: Sama binääri on testattu iPod Touch 1, iPhone 3GS ja iPad iOS4:ssa. Toimii siis kaikissa julkaistuissa laitteissa.

Nyt odotellaan...

@Ile Hienoa! Tosin täytyy todeta, että minulla on vielä 3G-malli, toiminee siinäkin!?

Mitä nimikettä sitten kannattaa tarkkailla Storessa?

@jwa Toki! Nuo on siis fyysiset laitteet mitä minulla on ja niillä ole testattu "oikeassa raudassa". Muiden osalta luotan simulaattoreihin.

Viesti kuitenkin kuuluu: Sama binääri, tuen kaikkia olemassaolevia ajoalustoja.

Ei ollut ihan triviaalia. Käytössä on joitain ominaisuuksia, jotka ovat ilmestyneet APIin matkan varrella (esim. audion panorointi stereokuvassa). Jos koodissa käyttää tällaista, se kaataa ohjelman, jos ajaa alustassa josta sitä ei löydy (ei siis mitään käännösaikaisia virheitä). Tämän takia pitää tutkia monenlaisien APIen kautta, mitä laite osaa.

Esim. retina-displayn katson, onko näytön Scale-arvo 2. Kun pyydään scale-arvoa, ohjelma kaatuu iOS3:ssa, koska siinä ei ole scale-arvoa :-) Näin ollen katson ensin, tukeeko laite moniajoa. Jos tukee (=iOS 4-->), sitten kurkataan vasta scale-arvoa ..

edit: Niin, näitä voi seurata:
http://www.facebook.com/pages/TrendyH...
Twitterissä @trendyhangman.

@Ile Oivallista! Rapoa miten asia etenee.

Tuo framework alkaa kuulostaa siltä, että kun vielä joitain vuosia odottelee, niin pääsee jo koodaamaan osaamatta koodata. Olen kärsivällinen.

Lueskelin jostain, että tällä hetkellä Applella menee 5-10 päivää sovellusten hyväksyntäprosessissa. Ovat mitä ilmeisimmin automatisoineet alkutarkastuksen, koskapa enää binääriä ei voinut enää lähettää iTunes Connect-palveluun lainkaan http:lla (vaikka ohjeet näin kertoivatkin). Lähetystä varten piti asentaa Application Loader-ohjelma macciin, joka on alunperin kehitetty musakustantajille -- Sillä ne lähettävtä isot määrät musaoriginaaleja iTunesiin.

Nyt siis myös AppStoreen lähetetään tuolla. Kun ohjelman tiedot on kirjattu iTunes Connect-palveluun, ko. softa näyttää, että voin lähettää binäärin. Oikealla tavalla paketoitu binäärizippi osoitetaan softalle, jolloin se tekee sille esitarkastuksen. Meidän tapauksessa se huomasi, että yksi ikoni ei ollut iPadille oikeassa resoluutiossa. Arvaan, että ohjelmaan on leivottu monia muitakin tarkastuskohteita, eli ovat saaneet manuaalitarkastuksesta joitain tarkastuskohteita pois.

Korjattuamme jakelupaketin, se meni iTunes Connectiin tilaan "Waiting for Review". Meni 6 arkipäivää, kunnes se muuttui tilaan "In Review". Noin tunnin kuluttua tuli kohtelias Reject-email. Siinä oli ensin koneen tekemää proosaa, miksi softa hylättiin. Sen jälkeen tuli tarkastaja käsin kirjoittama bugiraportti, jossa kerrottiin, millä laitteella oli bugi ja ystävällisesti myös screenshotti.

Korjasin softan ja lähetin uudestaan. Nyt se on jälleen "Waiting for Review"-tilassa, katsotaan kauanko menee ennenkuin seuraavan kerran menee tarkastukseen.

Toivotaan, että nyt menisi jo läpi (toivotaan, etteivät huomaa että käytän yhtä privaatti-APIa joka on yksi hylkäysperuste :-)

@Ile Onnea ekasta appista! Sinulla on näköjään ollut samoja ongelmia sertifikaattien ja profiilien kanssa kuin minulla alussa :) En itse osaa kaikkia vaiheita ulkoa vieläkään, vaikka olen noiden kanssa puljannut vuoden verran.

Suosittelen IB:n käyttöä kaikkialla muualla kuin peleissä. Etenkin vaaka- ja pystykuvaa tukevien ohjelmien näkymien tekeminen on paljon helpompaa IB:llä kuin ohjelmallisesti.

WWDC:n videoluennot on kanssa hyvää oppimateriaalia. Löytyvät developer portalista.

@arttue kiitos!
TrendyHangman ilmestyi AppStoreen tänään. http://itunes.apple.com/WebObjects/MZStore.woa/wa/...

Linkkasin tänne tästä blogista.

3 vuotta on mennyt kun aloitin iPhone-koodauksen. Nyt homma alkaa sujua. Kun saan idean, pienet sovellukset syntyvät jopa päivässä. Tämä ei olisi toki mahdollista, ellei matkan varrella olisi syntynyt yleiskäyttöisiä palikoita, kuten esim.

• httpGetJSONparser
• httpGetXMLparser
• locationAnalyzerOSM
• locationAnalyzerYahoo
• KMLgetter
• KMLhandler