Yazdığınız iPhone uygulamasını cihaza veya simülatöre yüklendiğinizde iOS uygulamanız için sadece o uygulamanın erişebileceği özel bir alan yaratıyor. Bu alan içerisinde uygulamanızın kendisini ve uygulamayla birlikte verdiğiniz dosyaları içeren "Application Bundle" konuluyor. Daha sonra uygulamanız çalışırken bu bundle içerisinden istediği verileri okuyabiliyor ancak değişiklik yapamıyor (Aslında yapmanın yolu var ancak kesinlikle tavsiye edilmiyor). Uygulamanın üzerinde değişiklik yapacağı dosyaları koymanız için iOS tarafından önceden tanımlanmış bazı klasörler var. Bunlardan en önemli 2 tanesi Documents ve Library klasörleri.

Önceki yazılarımda çok ekranlı iPhone uygulamaları yazmanın 3 farklı yolu olduğunu söylemiştim:

• UIScrollView kullanarak tek ekranda birden fazla sayfa göstermek
• UITabBarController kullanarak tab'lı menü yapısı kurmak
• UINavigationController kullanarak tab'sız, derinlikli menü yapısı kurmak.

Bunlardan ilkinin nasıl yapılacağını daha önce ele almıştım. Bugünkü yazımda da ikinci yöntemi ele alacağım. Tab'lıarayüzler tipik olarak az sayıda, birbirinden bağımsız işlevselliğesahip ekranları olan uygulamalarda kullanılmakta. iPhone uygulamalarında kullanılmaları çok kolay çünkü iOS işletim sistemi tabdeğiştirdiğinizde ekrana o tab ile ilgili olan ekranın getirilmesi içinyapılması gereken her şeyi sizin yerinize yapıyor. Şimdi bu tip arayüzesahip bir uygulamanın nasıl yapıldığını basit bir örnek üzerindegöstereceğim.

Senelerdir Windows kullanıcısı olmama rağmen işim gereği son yıllarda oldukça sık OSX kullanmaktayım bu yüzden tek başına monitör almak yerine 27" iMac almayı da düşünmedim değil ancak;

• taşıdığı vasat donanıma rağmen çok yüksek bir fiyata sahip olması (Yaklaşık 5000TL)
• dar bir kasada tüm bilgisayar bileşenlerini barındırdığı (ısınan CPU ve GPU dahil) için arıza yapma olasılığının yüksek olması ve internette hakkında çok şikayet yazılmış olması
• gelecekte donanımını güncellemenin mümkün olmaması ve ekran ile diğer bileşenler aynı kasada olduğu için donanım eskidiğinde ekranın da çöpe gidecek olması

gibi nedenlerden dolayı vazgeçtim ve mecburen oldukça kazık bir fiyata satılan 27" Cinema Display'i aldım. Ancak iş tek başına monitörü almakla bitmiyor.

Bu monitörün de en büyük sorunu Mini Display Port dışında görüntü alma amaçlı hiçbir girişe sahip olmaması. Sanırım bunu monitörün PC'lerde kullanılamayıp sadece Macbook veya Mac Mini'ler ile birlikte kullanılabilmesini sağlamak için yapmışlar. Amaçlarına ulaşmış olduklarını söyleyebilirim çünkü NVIDIA'nın hiçbir ekran kartında Mini Display Port yok ve sadece bir kaç tanesinde Display Port var. ATI/AMD'nin kartlarında ise genellikle normal Display Port bulunmakla birlikte, sadece en son çıkan HD6XXX serisindeki kartlarından bazılarında Mini Display Port var. Yani eğer NVIDIA marka bir kart kullanıyorsanız bu monitörü bilgisayarınıza doğrudan takmanızın bir yolu yok.

Göstereğim uygulamanın kendi bir pek işe yarar bir şey yapmıyor belki ancak iOS ortamına giriş yapmak için yeterli olduğunu düşünüyorum. Bu yazımda objective-c dilini anlatmak gibi bir amacım yok, ancak yine de yeri geldiğinde çok kullanılan bazı yapıların ne anlama geldiği hakkında kısa açıklamalar yapacağım. Bu yazıyı okuduktan sonra aşağıdaki soruların cevaplarını almış olacaksınız.

• iPhone uygulamaları geliştirmek için hangi yazılım ve donanıma ihtiyaç vardır?
• XCode ile bir iPhone projesi nasıl oluşturulur?
• Bir iPhone projesi hangi klasör ve dosyaları içerir ve bunların işlevi nedir?
• Interface Builder kullanılarak nasıl arayüz tasarlanır?
• Arayüz ile kod arasında nasıl bağlantı kurulur?
• Tuşa basmak gibi basit olaylar nasıl karşılanır?
• Kullanıcıya bir mesaj en kolay nasıl gösterilir?
• iPhone simülatörü nasıl kullanılır?

Bu cevaplar, iPhone programlama ile ilgili Türkçe bilginin neredeyse hiç olmadığı bu zamanda iPhone uygulamaları geliştirmeye başlangıç yapmak için yeterli olacaktır. Eğer vakit bulabilirsem gelecekte farklı arayüz bileşenlerinin nasıl kullanıldıklarını, cihaz içerisine nasıl kalıcı veriler tutulacağını ve ivme sensörü, GPS, pusula gibi donanımların nasıl kullanılacağını örnekler ile gösteren yazılar yazmayı planlıyorum. 

İlk yazımda bahsedeceğim container, içerisindeki bileşenlerin web tarayıcılarında olduğu gibi box model'e göre yerleşmesini sağlayan ve bu sebeple de en çok kullanılan container olan LinearLayout.

Programın kendi bir pek işe yarar bir şey yapmıyor belki ancak bu yazının amacı için fazlasıyla yeterli. Bu yazıyı okuduktan sonra aşağıdaki soruların cevaplarını almış olacaksınız.

• Eclipse ile bir Android projesi nasıl oluşturulur?
• Bir Android projesi hangi klasör ve dosyaları içerir ve bunların görevleri nedir?
• XML kullanılarak basit bir arayüz nasıl tanımlanır?
• Tuşa basmak gibi basit olaylar nasıl karşılanır?
• Kullanıcıya bir mesaj en kolay nasıl gösterilir?
• Sanal bir cihaz nasıl oluşturulur ve yazılan program bu cihaz üzerinde nasıl çalıştırılır (emülatör nasıl kullanılır)?

Tabi ki bu cevaplar sadece başlangıç için yeterli olacak ancak sonraki günlerde bu konuların her birine ayrı ayrı değinmeyi planlıyorum.

Kurulumundan bahsedeceğim şeyleri saymam gerekirse:

• JDK
• Eclipse ve ADT
• Android SDK

Google bu dil ile yazılmış programların daha hızlı derlendiğini, daha hızlı çalıştığını, daha güvenli olduğunu iddia ediyor. Python gibi dinamik bir programlama dili ile çalışmanın hızı ile, C++ gibi bir dilin performans ve güvenilirliğini birleştiriyormuş (Vay be iddiaya bak!). Go'nun göze çarpan diğer özellikleri ise şöyle:

• Açık kaynaklı olması.
• Garbage collection'a sahip olması. Yani kullanılan bellek alanlarını geri verme derdi yok (Java ve C#'ta olduğu gibi).
• Çok işlemcili sistemlere yönelik yazılım geliştirmeyi kolaylaştıracak yapılara sahip olması.
• C++ kadar yüksek performansa sahip olması.
• Basit olması.

Şu an için Windows üzerinde çalışan bir versiyonu olmayan ve daha emekleme aşamasında olan Google GO'nun ne kadar yaygınlaşacağını zaman gösterecek. Bu yazıda dil hakkında genel bilgi vereceğim. Detaylı bilgileri bu adresten öğrenebilirsiniz.

Her tıklayışımda yapması gereken şeyi 1-2 saniye donup bekledikten sonra yerine getiriyordu. Klasörler arasında dolaşmak bile işkence halini almıştı. Terminalden "top" komutu ile çalışan proseslerin listesini açıp bu yavaşlığın sebebinin hangi proses olduğuna baktım ve Xorg prosesinin işletim sisteminde yaptığım her hareket sonrasında işlemcinin %100'e yakın kısmını kullandığını gördüm. Bu da doğal olarak beni Xorg'un kullandığım ATI Radeon X1950 ekran kartımla ilgili ciddi problemleri olduğunu düşünmeye itti.

İnernet üzeride yaptığım araştırma sonucunda sorunun çözümünün Xorg server ile ilgili ayarların bulunduğu xorg.conf dosyasında olduğunu öğrendim. Bu dosyaya gerekli satırları ekledikten sonra Ubuntu en az 9.04 sürümü kadar hızlı çalışmaya başladı. Eğer sizin de ATI Radeon ekran kartınız varsa ve benzer bir problemle karşı karşıyaysanız, bu yazıda söylediğim şeyleri yaparak sorununuzu çözebilirsiniz.

Aslına bakarsanız çok fazla yenilik var. Yani yeni bir Ubuntu sürümünün bir öncekinden bu kadar ileride olduğunu çok sık göremeyeceğimizi rahatlıkla söylebilirim. Ancak bu yazdıklarım size Ubuntu 9.10'u kurduğunuzda çok farklı bir manzara ile karşılaşacağınızı düşündürmesin. Çünkü yapılmış olan yığınla yeniliğin büyük çoğunluğu altyapıda. Bir çoğu da Ubuntu'yu geliştirenlerin bayağı uzun bir süre önceden öne sürdükleri "10 saniyede boot edilen, hızlı ve güvenli işletim sistemi" iddiasının gerçekleşmesi için atılmış adımlar. Bu yazımda gerek arayüz, gerekse de altyapıda yapılmış bir çok yenilikten en önemli olanları üzerinde duracağım.

İşletim sistemini deneme amaçlı olarak kullandığımda performansı kötüydü. Bunun sebebinin VmWare içerisinde kullanmış olmam olduğunu tahmin ediyorum. Ancak önceki versiyonlarda böyle bir yavaşlık yoktu. Umarım yakında normal bir kurulum yapıp denediğimde de benzer bir durumla karşılaşmam. Eğer karşılaşırsam burada anlattığım hiçbir özelliğin bir anlamı kalmamış oluyor çünkü.

Normalde .NET Framework içerisinde bu işi Image objesinin metodlarından biri olan GetThumbnailImage() metodunu kullanarak tek satırda halletmek mümkün. Ancak bu yöntemi kullanmışsanız, oluştuduğu thumbnail resimlerinin genelde düşük (bazen de berbat) kalitede olduklarını görmüşsünüzdür. Yazımda bu sorunu ortadan kaldıran ve resim kalitesine önem veren birçok kişinin GetThumbnailImage() metodu yerine tercih ettikleri başka bir yöntemi göstereceğim. Göstereceğim yöntemi kullanarak JPG, PNG, GIF gibi çok kullanılan formatların hepsi için kaliteli thumbnail'ler oluşturabileceksiniz. Ayrıca GetThumbnailImage() metodunun neden her zaman iyi sonuçlar vermediğinden de kısaca bahsedeceğim.

Bir çok kişinin böyle durumlarda çözüm olarak gördüğü şey söz konusu sorguyu her tablo/veritabanı için bir kez çalıştırmaktır. Ancak bu yöntemin aslında bir çözüm olmadığı tablo/veritabanı sayısı arttıkça gittikçe kullanılamaz bir hal almasından belli olmaktadır.

Konu hakkında biraz daha bilgi sahibi olan kişilerin aklına ise büyük ihtimalle cursor kullanmak ya da verdikleri sorguyu söz konusu olan her tablo/veritabanı için bir kez çalıştıracak olan bir stored procedure yazmak gelecektir. Her iki çözüm de yukarıdaki paragrafta bahsettiğim çözüme göre çok daha mantıklı olmakla birlikte, basit işler için karmaşık ve gereksizdir. Öyle olmasının sebebi ise SQL Server'daki master veritabanı içerisinde bu tür işlemlerin kolaylıkla yapılmasını sağlayacak stored procedure'lerin  zaten tanımlanmış olmasıdır. Bu yazımda, bahsetmiş olduğum işlemleri tek komutla yapmanızı sağlayan, çok işe yarar bulduğum sp_Msforeachtable ve sp_MSforeachdb prosedürlerinden bahsedeceğim.

URL Rewriting dendiğinde muhtemelen birçok web programcısının aklına ilk gelen şey Apache sunucularda kullanılan mod_rewrite özelliğidir. Ancak bu özellik doğal olarak sadece PHP ile yazılmış olan uygulamalarda kullanılabiliyor. Bu yüzdne Windows sunucular üzerinde çalışacak olan ASP.NET ile yazılmış web uygulamalarında URL Rewriting işlemini yapmak yakın bir zamana kadar Apache'deki gibi kolay değildi. Çünkü IIS'in URL Rewriting yapmayı kolaylaştıracak bir özelliği yoktu. Ancak artık durum değişti.

Microsoft'un yakın bir zamanda çıkarmış olduğu URL Rewrite modülü sayesinde IIS 7 kullanıcıları da artık kolayca URL Rewriting yapma imkanına kavuştu. Bu yazımda Microsoft Url Rewrite modülünün IIS 7 üzerine kurulumunu ve yazım kurallarının doğrudan web.config içerisinden nasıl tanımlandığını örnekler ile birlikte anlatacağım.

Problem kendini, Management Studio 2008 ile veritabanı sunucusuna gayet normal bir şekilde bağlandıktan sonra, sol taraftaki "Object Explorer" bölümündeki "Databases" dalını açmaya kalktığınız zaman belli ediyor.

Databases dalına basıldıktan sonra, object explorer yukarıda göstermiş olduğum halde uzun bir süre beklemeye başlıyor. Siz sabırla listenin alınmasını bekliyorsunuz ancak bir süre sonra veritabanlarının listesiyle değil, aşağıdaki hata mesajı ile karşılaşıyorsunuz.

Bu mesajda mavi ile kapatmış olduğum yerde veritabanına girerken kullandığım kullanıcı adım, siyah ile kapatmış olduğum yerde ise benimle uzaktan yakından alakası olmayan birinin veritabanının adı yazıyordu. Mesajı ilk gördüğümde hatanın bende olduğunu düşünüp yaptığım her adımı defalarca kez kontrol ettim. Ancak sonuç alamayınca biraz araştırma yaptım ve sorunun benden değil, Management Studio 2008'deki saçma bir bug'dan kaynaklandığını öğrendim.

Artık sitemi açmış olduğuma göre, 4 yıl önce yazmış olduğum ve o zamandan beri her dönem daha fazla İTÜ öğrencisinin keşfedip kullanmaya başladığı Programcı'yı da İTÜ'nün bana vermiş olduğu kısıtlı web alanında tutmama gerek kalmadı. Bugünden itibaren Programcı'nın resmi sayfası burası. Eski sayfayı biraz değiştirip yüksek lisansım bitene kadar öyle bırakacağım. Zaten yüksek lisansım bittikten sonra o sayfa ben istesem de istemesem de İTÜ Bilgi İşlem Daire Başkanlığı bünyesindeki insanlar tarafından büyük bir zevkle silinecektir.

Evet, üniversiteye girdiğim yıldan beridir açmayı planladığım, ancak bir türlü vakit bulup da açamadığım sitemi, programlama ile uğraşan kişiler için özel bir anlamı olan bu iki kelime ile birlikte resmi olarak (nihayet!) açmış bulunuyorum.

Aslında siteyi bu kadar üzün süre boyunca açmamış olmamın tek sebebi hazır site kullanmamaya yemin etmiş olmam. İster deli deyin, ister takıntılı deyin farketmez, ben buyum. Ne zaman üçüncü kişiler/firmalar için değil de, kendim için bir şey yazmaya kalksam, yazacağım kodun vaktim varsa hepsinin, vaktim yoksa da büyük çoğunluğunun kendim tarafından yazılmış olmasını isterim. Zaten şu ana kadar ne öğrendiysem, süre sınırı olmadan kendi çapımda yaptığım şeyler sayesinde öğrendim. Ayrıca Wordpress gibi hazır bir sistem kullanmak yerine kendim yazmış olduğum bir sistemi kullanmanın hem beni ihtiyacım olmayan bir sürü gereksiz özellikten kurtardığını, hem de bana sitenin herhangi bir yerinde istediğim zaman istediğim değişikliği kolayca yapabilme imkanı verdiğini düşünüyorum. Açık kaynaklı sistemlerde düzenli olarak bulunan güvenlik açıkları ise ayrı bir mesele.