Günlük Arşivi
Günlük girdilerini RSS ile takip edin.Son 4-5 aydir moonit'de moonit'in iphone uygulamasini gelistirmeye calisiyoruz. Web'deki seyler rutin bir sekilde devam ediyor zaten fakat su an genellikle xcode'da calisiyor ve genellikle iphone, ipad gibi cihazlar ustunde testler yapiyorum. Daha once de masaustu veya mobil cihazlar icin uygulama gelistirmisligim var fakat uzun suredir boyle bir gelistirme ortamindan uzaktim. Ozellikle de objective-c gibi statik bir dilden ve apple gibi herseyi low level tutan bir sirketin frameworku/gelistirme ortami ile calismanin web'deki esnek ve hareket edilebilirligin bir yandan programciyi tembellestirdigi, bir yandan da amatorlestirdigini farketmemi sagladi. Her ne kadar yaptiginiz seyi profesyonel yaparsaniz yapin calistiginiz ortam sizi bazi seylere zorlamiyorsa bu kacinilmaz.
Neyse bu yazida bahsetmek istedigim sey web ile iOS gelistirme ortami arasinda test sureci, uygulamaniza bir tester daha dahil etmenin farklarini anlatmak. Web ornegini hepimiz biliyoruz, yine de hizlica ozetliyorum. Bir web uygulamasini gelistirirken eger php gibi bir ortamda calisiyorsaniz zaten uygulamanizi derleme, proje olarak butun halde degerlendirme gibi bir durum soz konusu olmayacaktir, bunun olmamasindan dolayi bircok gelistirici ftp'den sunucularindaki calisan uygulamayi anlik olarak duzenleyip gelistirebiliyorlar, hatta bu bazen kotu bir aliskanlik olarak gelistiricilerin eline yapismis bile olabiliyor. Bir web uygulamasi calisirken guncellenip hatalarin giderilmis olmasi veya degisikliklerin uygulanmasi sadece tester/kullanici'nin ziyaretine kaliyor. Hatta sunucu/domain konfigurasyonunuza gore uygulamanizi daha ilk satirdan itibaren public bir yerde online hale getirip insanlardan test etmelerini isteyebiliyorsunuz. Ne kadar esnek ve guzel degil mi?
Iste bu surec iOS uygulama gelisiminde cok farkli bir perspektifte. Aslinda ben bi sureci, bir masaustu uygulamasi gelistirmeyle esdeger goruyorum. Iphone veya ipad'e uygulama yaziyorsaniz yazdiginiz uygulamayi bir kere app store'a submit ettiginizde onaylandiktan sonra mudahala edemediginiz bir seye donusuyor. Tabi ki update'ler cikarip yeni surumler yayinlayabilirsiniz fakat artik oyle bir konumdasiniz ki her surumu kullanan bir kullanici kitlesiyle karsi karsiyasiniz. Web uygulamasinda boyle bir sey yoktur, uygulamanizi guncellediginizde herkes guncel surume erisir. Farkli surumlerle basa cikma disinda eger bir hata gorurseniz bu hatayi duzeltmek icin yeni surum yayinlamaniz, bu yeni surumu tekrar onay prosedurunden gecirmeli ve kullanicilarin cihazlarini guncellemelerini beklemelisiniz. Dolayisiyla bir hatayi veya gelistirmeyi yayina almak aynen bir dergi cikariyor gibi zahmetli oldugu gibi riskli de. Bu riskten dolayi uygulamanizi yayina almadan once cok iyi ve defalarca test etmeniz gerekiyor. Butun bunlarin yaninda web gibi kucuk parcalara ayirip her gelistirmeden sonra deploy etme aliskanliginizi birakmaniz gerekiyor. Cunku artik o kadar hizli update olabilen ve/veya update edince o problemden kurtuldugunuz bir uygulamaniz yok.
Boyle bir dezavantaji dusundugunuzde cok surum cikarmak yerine az surum cok degisiklik/duzenleme yapmayi tercih etmeye basliyorsunuz. Bunlarin arasinda en onemlisi ilk surum tabi ki. Cunku artik public bir directory'ye kaydoluyorsunuz ve aninda bircok insan uygulamanizi indirmeye/kullanmaya basliyor. Dolayisiyla ilk cikisi saglam ve stabil bir uygulama ile yapmak zorundasiniz.
Bu da test surecini ne kadar dogru yapabildiginizle ilgili. Tabi ki apple'in gelistirici sinirlamalari uygulamanizi kucuk de olsa bir alpha test grubuna dagitmanizi cok engelliyor. Bu konuda birkac arac kullaniyoruz moonit'de. ios uygulamalarinin test grubuna dagitimi ve o test grubuna spesifik cihazlara yuklenebilirligini saglamak icin TestFlight diye bir servisi kullaniyoruz. Servisin yaptigi sey test grubundaki insanlarin cihazlarini bu servise kaydetmesi, sonrasinda da gelistiricinin bu kisileri test grubuna dahil etmesinin ardindan test icin derlenmis uygulama surumlerini bu gruba dagitmak.
Bunun disinda uygulamaniza checkpoint'ler koyup her checkpoint'de tester'dan feedback isteyebiliyorsunuz. TestFlight da size bunlari istatistik ve veri olarak sunuyor.
Eger iOS uygulamasi gelistiren birisiyseniz veya bir iOS gelistirici takiminin parcasiysaniz TestFlight bircok isi kolaylastiracaktir.
Neyse bu yazida bahsetmek istedigim sey web ile iOS gelistirme ortami arasinda test sureci, uygulamaniza bir tester daha dahil etmenin farklarini anlatmak. Web ornegini hepimiz biliyoruz, yine de hizlica ozetliyorum. Bir web uygulamasini gelistirirken eger php gibi bir ortamda calisiyorsaniz zaten uygulamanizi derleme, proje olarak butun halde degerlendirme gibi bir durum soz konusu olmayacaktir, bunun olmamasindan dolayi bircok gelistirici ftp'den sunucularindaki calisan uygulamayi anlik olarak duzenleyip gelistirebiliyorlar, hatta bu bazen kotu bir aliskanlik olarak gelistiricilerin eline yapismis bile olabiliyor. Bir web uygulamasi calisirken guncellenip hatalarin giderilmis olmasi veya degisikliklerin uygulanmasi sadece tester/kullanici'nin ziyaretine kaliyor. Hatta sunucu/domain konfigurasyonunuza gore uygulamanizi daha ilk satirdan itibaren public bir yerde online hale getirip insanlardan test etmelerini isteyebiliyorsunuz. Ne kadar esnek ve guzel degil mi?
Iste bu surec iOS uygulama gelisiminde cok farkli bir perspektifte. Aslinda ben bi sureci, bir masaustu uygulamasi gelistirmeyle esdeger goruyorum. Iphone veya ipad'e uygulama yaziyorsaniz yazdiginiz uygulamayi bir kere app store'a submit ettiginizde onaylandiktan sonra mudahala edemediginiz bir seye donusuyor. Tabi ki update'ler cikarip yeni surumler yayinlayabilirsiniz fakat artik oyle bir konumdasiniz ki her surumu kullanan bir kullanici kitlesiyle karsi karsiyasiniz. Web uygulamasinda boyle bir sey yoktur, uygulamanizi guncellediginizde herkes guncel surume erisir. Farkli surumlerle basa cikma disinda eger bir hata gorurseniz bu hatayi duzeltmek icin yeni surum yayinlamaniz, bu yeni surumu tekrar onay prosedurunden gecirmeli ve kullanicilarin cihazlarini guncellemelerini beklemelisiniz. Dolayisiyla bir hatayi veya gelistirmeyi yayina almak aynen bir dergi cikariyor gibi zahmetli oldugu gibi riskli de. Bu riskten dolayi uygulamanizi yayina almadan once cok iyi ve defalarca test etmeniz gerekiyor. Butun bunlarin yaninda web gibi kucuk parcalara ayirip her gelistirmeden sonra deploy etme aliskanliginizi birakmaniz gerekiyor. Cunku artik o kadar hizli update olabilen ve/veya update edince o problemden kurtuldugunuz bir uygulamaniz yok.
Boyle bir dezavantaji dusundugunuzde cok surum cikarmak yerine az surum cok degisiklik/duzenleme yapmayi tercih etmeye basliyorsunuz. Bunlarin arasinda en onemlisi ilk surum tabi ki. Cunku artik public bir directory'ye kaydoluyorsunuz ve aninda bircok insan uygulamanizi indirmeye/kullanmaya basliyor. Dolayisiyla ilk cikisi saglam ve stabil bir uygulama ile yapmak zorundasiniz.
Bu da test surecini ne kadar dogru yapabildiginizle ilgili. Tabi ki apple'in gelistirici sinirlamalari uygulamanizi kucuk de olsa bir alpha test grubuna dagitmanizi cok engelliyor. Bu konuda birkac arac kullaniyoruz moonit'de. ios uygulamalarinin test grubuna dagitimi ve o test grubuna spesifik cihazlara yuklenebilirligini saglamak icin TestFlight diye bir servisi kullaniyoruz. Servisin yaptigi sey test grubundaki insanlarin cihazlarini bu servise kaydetmesi, sonrasinda da gelistiricinin bu kisileri test grubuna dahil etmesinin ardindan test icin derlenmis uygulama surumlerini bu gruba dagitmak.
Bunun disinda uygulamaniza checkpoint'ler koyup her checkpoint'de tester'dan feedback isteyebiliyorsunuz. TestFlight da size bunlari istatistik ve veri olarak sunuyor.
Eger iOS uygulamasi gelistiren birisiyseniz veya bir iOS gelistirici takiminin parcasiysaniz TestFlight bircok isi kolaylastiracaktir.
Google gecen gunlerde music servisinin iOS tarayici uygulamasini yayinladi. Beni sasirtan sey yillardir insanlar native uygulama mi yoksa web app mi diye mobil sunumlarini doldurup durdular, hatta ben de hatirliyorum bunu yaptigimi defalarca. Sonunda herkes native uygulamanin avantajini soyleyip durup tarayici uygulamalarini yerlere vuruyorlardi. Google gmail vs gibi bircok tarayici uygulamasindaki basarisini burada da gostermise benziyor. Ilk denememde ilk merak ettigim tarayici kapandiginda da calismaya devam edip etmemesiydi, tabi ki devam ediyormus. Diger sey ise iphone veya ipad'den cihazdaki kontrollerle tarayicidaki kontrolleri yonetebilmekti. Bunun anlami iphoneu kapatsam bile kulakliktaki tuslarla kontrol edebilecegimdi. Son olan sey ise airplay ile muzigi televizyona daha dogrusu apple tv bagli ses sistemine yayin yapabilmekti ve burada gercekten sok oldum. Sonuc olarak google ios tarayici uygulamalari konusunda asfalti aglatmis biraz.
Denemek icin sahip oldugunz google hesabinizla iOS cihazinizda safariden music.google.com adresine girmeniz yeterli.
Tabi ki native bir uygulamanin yerini tutmaz ve en kisa zamanda ios uygulamasini gorecegimizi dusunuyorum google music sevrisi icin. Google music'de gordugum tek eksik sosyal bir yaninin olmamasi. Su an ortaya cikan servislerin sosyal networklere bagli olmamasi gibi bir secenegi olmadigini dusunuyorum artik. Umarim google bu sosyal aglari sallamama tavrini yeni servislerinde de devam ettirmez. En azindan google+ entegrasyonu yapmalari viralite icin servisin kaderini etkileyecek bir unsur bana gore.
Surada tech crunc'daki habere ait google music ekran goruntulerini gorebilirsiniz.
Kaynak: http://goo.gl/I09yh
Birkac ay once buyuk bir led tv almistim, tabi televizyon seyretmeyi seven biri olmadigim icin hicbir kablo tv servisinden televizyon servisi almadim, dolayisiyla tv alma sebebim playstation, stream icerik servisleri idi.
Uzun suredir netflix kullaniyordum ve buna bir de apple tv ile itunes icerigi de eklendi. Tabi netflixi hem playstationdan hem de apple tvden normal olarak izleyebiliyordum. Fakat apple tv almadaki amacim apple tv'yi kirip wireless ustunden time capsule'e ulasip oradaki filmleri izleyebilmekti.
Cunku her ne kadar film indirme aliskanligini kessem de sagdan soldan bir sekilde avi, mkv formatlarinda film veya baska icerikler (belgesel, tv showlari vs) var disklerimde. Bu icerikleri apple urunlerinde izlemek tamamen bas agrisi. Dolayisiyla bir sekilde bunlari apple cihazlarindan izlemenin bir yolu olmaliydi.
iPad ve iPhone'da VLC player ile rahatlikla bunlari izleyebiliyorsunuz, tabi sistem kaynaklari yettigi yere kadar. Yani teoride 1080p videolari bile oynatsa da ram, grafik islemci gibi seyler yetmedigi zaman yetmiyor, yapacak birsey yok.
Ancak cogunluk dosyalarin standart dvd ve 720p oldugunu dusunursek 1080'leri de bilgisayardan izlemek cok da problem degil.
Sonuc olarak Turkiyedeyken bir arkadasimin cok basarili sekilde apple tv'yi kirip tum icerigine XMBC ile eristigini gormustum, apple tv aldiktan sonraki ilk is bilgisayar baglantisi icin micro usb kablosunu siparis etmekti, hizli bir sekilde alip hic sorunsuz apple tv'yi kirdim. Tabi darwin oldugu icin klasik bsd debian karisimi bir isletim sistemine ssh ile baglaniyorsunuz temelde. Gordugum seyi kurarak neler yapabilecegimi test ettim ve su an apple tv'mde bir medya cihazindan bekledigim nredeyse herseyi yapabiliyorum.
Bu apple tv kirma isini illegal bir aktivite olarak gormuyorum cunku hala en cok netflix ve itunes icerigini izliyorum ve bunun icin para oduyorum, sadece elimde olan disklere ulasip dosya formatlarini cevirmek zorunda kalmadan dosyalarima ulasabiliyorum.