Kategoriler


SON YORUMLAR
Kaan çok eziksin
bsg. yazılımdan anlıyorsan bir işe gir.
İREM
Veri yapıları sınavım var..sınav süresi 30dk ve test..Veri yapılarında bilgili biri ücret karşılığında yardımcı olabilirse çok mutlu olurum..
Eray
29.8.2020 tarihli telefon numaram ile yaptığım yorum, ÖZEL DERS vermek, konu anlatımı yapmak veya freelancer olarak yazılım projelerinde yazılımcı olarak çalışmak içindir. Ödev yaptırmak, sınava girmek gibi isteklere geri dönüş yapmıyorum.
Tatar Ramazan
CLASS (Inheritance, abstract, interface, static) Kurallar: 1- Abstract ve interface classlarda new ile obje oluşturulamaz. Bu kural static sınıflar için de geçerlidir. 2- Statik metotlardan yalnızca statik değişken ve metotlar çağırılır. 3- Sınıfın tüm objeleri statik alanın aynı değerini paylaşır. 4- Sınıftan her obje oluştuğunda statik değişken değeri sıfırlanmaz kaldığı yerden devam eder. 5- Statik alana sınıftan obje oluşturmadan direk ulaşılabilir. 6- Statik değişken her zaman bir değere sahiptir. Nümerik değerler için değer atanmadıysa değeri sıfırdır. 7- Virtual metod, abstract ya da static olamaz. 8- Bir metod ya da properties override edilirken tipi değiştirilmez. 9- Türetilen sınıfta metod override edilmemişse ana sınıftaki içerik geçerli olur. 10- Bir interface uygulayan metod public olmalıdır. 11- Static metod abstract, virtual, override olamaz. 12- Properties?ler abstract ya da virtual olabilir. 13- Türetilen sınıf ana sınıftaki tüm abstract metodları uygulamazsa o da abstract olmalıdır. 14- Abstract metod içeren sınıf da abstract olmalı. 15- Abstract metod otomatikman virtual olur. 16- Türetilen sınıf abstract classtaki tüm metodları uygulamalıdır. 17- Virtual metod birden fazla türetilen sınıfta yeniden tanımlanabilir. 18- Bir sınıf birden fazla interface?i aralarına virgül konularak kullanabilir. 19- Interface tek başına hiçbir uygulama sağlamaz. 20- Abstract metod gövde içermez ve ana sınıf tarafından uygulanamaz. 21- Abstract sınıf içinde statik ya da virtual metod tanımlanabilir. 22- Bir interface metod uygulanırken public değilse başına tanımlandığı interface koyulur. 23- Protected tanımlanan field?a sadece türev sınıf içinden erişilir. 24- Fields (alanlar) virtual ya da abstract olamaz. 25- Interface?ler fields içermez. Properties içerebilir. 26- Bir constructor base ile miras alıyorsa hem aldığı mirası hem kendi içindekini uygular. İçi boşsa yalnızca kalıtım aldığını uygular. Miras alırken de derived (türetilen) classtaki parametre değerini esas alır. 27- Interface metod implemente edilirken override yazılmaz. Override virtual ya da abstract metodlar uygulanırken kullanılır.
World
Hello PIO
PIO
hello world
Tatar Ramazan
2009-10 yıllarında millet maaşını yazardı yüksek miktarlar alırlardı şimdi kimse yazmıyor zavallılar sürünüyorlar. Yanlışsam, durumunuz iyiyse çıkın yanlışlayın beni. Az bir kısmınız mutlu olacak diğerleri kıvransın dursun.
Tatar Ramazan
çok para bayılacaklar osuracaklar, sıçacaklar size zort zort zort...muhahah, puahahah...
tatminsiz
10.000 tl den aşağı çalışmam.

java ve c# ı yalayıp yuttum mssql oracle pl sql ibm db2 biliyorum. projeler yaptım kaç para alcam?
memnun
Muhasebe bölümünden bilişime geçtim 2 ay geride kaldım şimdi geri muhasebeye nakîl verdim ama bu parayı duyunca çallşmaya başladım
muhendis
Eskidendi o çok eskiden..mühendisler artık aç..4 yıllık mühendisim aldığım ücret 5000 tl...
cengiz
Ben de bilmiyorum faidesini...
orhon
ilk önce sql sonra t-sql

Bilgisayar Mühendisleri
Here is the website inspired me to use 
it as a guide when I tried to define 
myself as an engineer candidate a few 
years ago. It really helped me to work
 and study feeling in confidence with 
being on the right way. I suggest this 
website to whom it may direct her/his 
to find the right career path. It 
includes many articles varies from 
real life experiences to detailed 
software engineering issues. But the 
most dignified parts for me are the 
articles in general and career titles.
Son okunan makaleler:
Programcı Gözüyle iPhone OS ve Android Karşılaştırması
Bilgisayar Mühendisleri Kaç Para Alır?
Bilgisayar Mühendisleri Kaç Para Alır?
En iyi bilgisayar mühendisliği bölümüne sahip üniversiteler
Bilgisayar Mühendisleri Kaç Para Alır?
Bilgisayar Mühendisi Ne İş yapar? Program Nedir? Çeşitli Sorular?
Bilgisayar Mühendisliği Hakkındaki 10 Büyük Yalan!
İşsizlik psikolojisi
Bilgisayar Mühendisi Ne İş yapar? Program Nedir? Çeşitli Sorular?
Bir bilgisayar mühendisinin bilmesi gereken en temel teknolojiler
YAZ TATİLİNDE YAN GELİP YATMAK
Bilgisayar Mühendisleri Kaç Para Alır?
Oracle - Object Pinning nedir?
SQL Server - SP için önemli ipuçları
Bilgisayar Mühendisliği Hakkındaki 10 Büyük Yalan!
Bilgisayar Mühendsileri için CV hazırlama rehberi - 1
Kurumsal firmalarda iş yaşamı
Bilgisayar Mühendisliği Hakkındaki 10 Büyük Yalan!
DOKTOR GİBİ BİLGİSAYAR MÜHENDİSİ OLMAK
ViewState’in Sunucuda Saklanması

Bilgisayar Mühendisleri Portalı

Programcı Gözüyle iPhone OS ve Android Karşılaştırması

Bu yazımda iPhone OS (iOS) ve Android işletim sistemleri arasında, her iki platforma da oldukça uzun süredir uygulama geliştiren birinin gözüyle kısa bir karşılaştırma yapacağım. Yapacağım karşılaştırma normal kullanıcıları değil, bu işletim sistemlerine uygulama geliştiren ya da geliştirmeyi düşünen insanların işine yarayacak bir karşılaştırma olacak, çünkü işletim sisteminin kendinden çok, yazılım geliştirirken kullanılan araçlar, SDK'lar ve tamamlanmış olan yazılımın store'a çıkarılma süreçlerinden bahsedeceğim. Eğer bu platformlardan herhangi birini öğrenmeye başlamak istiyorsanız o zaman mutlaka okumanızı tavsiye ederim.

Karşılaştırmayı fazla uzatmamak için sadece uygulama geliştirenleri en çok ilgilendiren şeyleri bir kaç başlık içerisinde göz önüne alacağım. Her konuda detaylı bir kıyaslama yazmak için bir kaç sayfalık bir yazı değil, kitap yazmam lazım zaten. Burada bahsettiğim şeyler çoğunlukla benim en çok beğendiğim ve en çok sinir olduğum şeylerden uygulama geliştirmeyi yeni öğrenen insanları ilgilendirenler olacak.

Programlama Dilleri - Objective-C ve Java
iOS için uygulama geliştirirken Objective-C, Android için ise Java kullanılıyor. Java hakkında fazla bir şey söylemeye gerek yok, zaten çok yaygın olarak kullanılan bir dil. Kullanım kolaylıklarını kıyaslarsak Java'nın kazanacağı kesin. Ancak ben Objective-C'nin mobil cihazlar için daha uygun olduğunu düşünüyorum çünkü aynı C++ gibi işaretçiler kullanmaya imkan tanıyor ve herhangi bir runtime environment üzerinde çalışmadığı için çok daha hafif ve hızlı. Bunun ne kadar önemli olduğunu iPhone için yazmış olduğum bir VoIP uygulamasını Android'e port etmeye kasarken görmüştüm. iPhone'da gayet hızlı çalışan program, Java'ya geçirilip Android'de çalıştırıldığında yavaşlıktan saçmalamaya başlamıştı. Çözümü Native Development Kit aracılığı ile kodun bir kısmını C++ ile yazılı halde bırakmakta bulmuştum. Neyse ki Android, Blackberry'nin aksine NDK araclığı ile C++ kullanma imkanı sunuyor ve bu yüzden Java büyük bir problem olmaktan çıkıyor. Objective-C'nin herhangi bir runtime environment üzerinde çalışmaması ve dolayısı ile garbage collection'a sahip olmaması (iOS üzerinde), bellek yönetimi işinin de size bırakılmış olduğunu gösteriyor. Bu birçok kişi için kötü olsa da konuyla ciddi olarak ilgilenenler için iyi bir şey. Bellek yönetimi gibi şeyler üzerinde kontrole sahip olmak özelikle çok bellek kullanan uygulamalar yazıyorken çok önemli. iOS 4'ten itibaren uygulamaları geliştirirken XCode 4.2 içerisindeki "Automatic Reference Counting" (ARC) seçeneğini seçip bellek yönetimi ile ilgili yazmanız gereken kodların (retain & release) derleyici tarafından sizin yerinize yazılmasını sağlayabiliyorsunuz. Ancak bu da sizi bellek yönetimi probleminden tamamen kurtarmıyor ve düzgün çalışması için sizin kodunuzu belli kurallar çerçevesinde yazmanız ve bazı durumlarda derleyiciye ne yapmak istediğinizi anlamasını sağlayacak ipuçları vermeniz gerekiyor ARC ile birlikte dile eklenmiş olan bazı keyword'leri kullanarak.

Objective-C'nin güzel yanlarından biri de Java'da olmayan bir çok özelliğe sahip olması. Bu özelliklerin başında, başkaları tarafından yazılmış olan ve kaynak koduna sahip olmadığınız sınıflara yeni metodlar eklemenizi sağlayan category özelliği geliyor. Bunun sayesinde SDK içerisideki sınıflara ihtiyacınız olan istediğiniz metodu ekleyebilir ve o sınıftan türemiş olan tüm nesnelerde kullanabilirsiniz. Diğer bir özellik de dinamik bir dil olması. Metod çağrıları aslında nesnelere mesaj yollamak anlamına geliyor. Bu bağlamda, nesnelerin metodlarını çağırmadan önce o metoda sahip olup olmadıklarını, Objective-C jargonu ile söylemek gerekirse, o mesaja cevap verip veremeyeceklerini öğrenebiliyor ve ona göre mesajı yollayıp yollamayacağınıza karar verebiliyorsunuz.

Objective-C dili ve dilin kullanıldığı platform Apple tarafından devamlı olarak geliştirilmekte. Örneğin Mac OSX platformunda olan ve sizi fonksiyon işaretçilerinden kurtarıp bazı metodları aynı Javascript'te olduğu gibi gerektiği yerde ilgili scope'taki değişkenleri de kullanabilecek şekilde tanımlamanıza imkan veren "blocks" özelliği iOS platformuna tüm Grand Central Dispatch sistemi ile birlikte sonradan aktarıldı. Bu özelliğinin benzeri Microsoft tarafından C#'a "Lambda Expressions" adıyla eklenmiş durumda.

Objective-C'nin kötü yönü çok farklı bir dil olması. C/C++, C#, Java, PHP, Pascal farketmez hangi dilleri biliyor olursanız olun, Objective-C'yi öğrenirken zorluk çekeceksiniz. Hatta hiçbir programlama dilini bilmiyorsanız daha kolay öğrenebileceğinizi bile söyleyebilirim çünkü sentaksı diğer dillerden çok farklı ve garip. iPhone SDK'sındaki sınıfların çoğu bellek yönetimi mekanizması olarak referans counting kullandığından bu kavrama yabancıysanız bellek yönetimine alışmanız da uzun sürebilir. Hatta sürecek. Kim neyi ne zaman neden retain ediyor, yeni yarattığınız bir objeyi kim release etmiş de havaya uçmuş diye düşüneceksiniz. ARC kullanmaya kalksanız da bu sefer nereye hangi keyword'ü koymanız gerektiğine karar vermekte zorlanacaksınız.

Yazılım Geliştirme Ortamları - XCode ve Eclipse
iOS için yazılım geliştirirken, MacOSX işletim sistemine yazılım geliştirirken de kullanılan XCode adlı IDE, Android için ise belki de en ünlü açık kaynaklı IDE olan Eclipse kullanılıyor. Bu iki IDE arasında normal kod yazma sırasında çok fazla bir fark yok, her ikisinde de ihtiyacınız olan temel özellikler var. Ancak XCode'un intellisense ve code completion gibi özellikleri Eclipse'ten, hatta Visual Assist eklentisi kurulmuş olan bir Visual Studio'dan bile daha iyi. Bir kere "context sensitive" intellisense olayının dibine vurmuş XCode. Sizin yazdığınız şeyleri tamamlarken o satır etrafındaki diğer satırlarda yapılmış olan işleri de göz önünde bulundurarak çok mantıklı önerilerde bulunuyor. Fonksiyon parametrelerini gösteriş ve tamamlayış şekli de daha iyi ama zaten Objective-C gibi acayip bir fonksiyon çağrı sentaksına sahip olan bir dil kullanılırken olmazsa olmaz bir şey bu. Java'da ise pek önemli değil o yüzden bunu karşılaştırmada bir artı olarak saymak adil olmaz. Kendi pisliğini kendi temizliyor diyebiliriz.

XCode'un debug sırasında değişkenlerin değerlerini göstermek ile ilgili ciddi problemleri var. Çok basit yerler haricinde fareyi değişkenin üzerine getirip değerini okuyamıyorsunuz. Okuyabilmek için konsolu açıp debugger komutlarını kullanmak gerekiyor. Uygulama geliştirirken harcanan vaktin yaklaşık üçte birinin debug işlemine gittiği düşünülürse, bunun ne kadar sinir edici bir problem olduğunu tahmin edebilimek güç değil. Eclipse'te ise bu konuda herhangi bir problem yok. Zaten native kod yazmadığınız için istediğiniz değişkenin içerisine rahatlıkla bakabiliyorsunuz.

XCode kod tamamlama konusunda iyi olmakla birlikte, Eclipse'in sahip olduğu, bir interface ya da parent class'taki metodların listesini gösterip seçtiklerinizi override edebilmeniz için editöre sizin yerinize yazma özelliğine sahip değil. Eğer yazdığınız sınıfta bir sürü delegate metodu implement etmeniz gerekiyorsa hepsinin prototipini ya dökümantasyondan kopyalayıp yapıştırmanız, ya da adını hatırlıyorsanız yazmaya başlayıp auto-completion'a güvenmeniz gerekiyor. Bu da gereksiz vakit kaybı demek ne yazık ki.

Bunlara ek olarak fazla detaya girmeden, XCode'un Eclipse'ten daha hızlı çalıştığını, proje yönetiminin yine XCode ile daha kolay yapıldığını ve 4. sürümünden itibaren genel olarak daha kullanışlı bir arayüze sahip olduğunu söyleyebilirim. Dahili Git desteği olması da versiyonlama için oldukça yararlı bir özellik.

XCode özellikle 4. sürümü ile birlikte çok gelişti ancak yine de Eclipse'ten daha iyi bir IDE olduğunu söylemek çok güç çünkü yukarıda yazdıklarıma ek olarak bu gelişmelerin beraberinde getirdiği sayısız hata var. Eski XCode çok güvenilir, sağlam bir IDE iken, XCode 4. sürümünden itibaren biraz(!) dengesiz ve güvenilmez bir IDE oldu. Düzeltilmesi gereken çok sayıda hatası var ve bunlara her sürümde yenileri ekleniyor. Dolayısıyla şu anki hali için Eclipse'ten iyidir diyemem, ancak daha kötü de demeyeceğim. Bu sorunun cevabı kişiye göre değişecektir kesinlikle.

Uygulamalar İçin Arayüz Tasarımı - Interface Builder ve ?
iPhone uygulamaları için arayüz tasarlarken Interface Builder (XCode 4'ten itibaren artık XCode'a tamamen entegre oldu) adlı bir uygulama kullanılıyor. İlk bakışta garip gelse de, alışınca son derece kullanışlı olan bir program bu. İşleyiş mantığı Visual Studio'dakine benzer. Bir kütüphaneden arayüzünüze bileşenler sürükleyip sağ taraftaki özellikler panelinden çeşitli özelliklerini değiştiriyorsunuz. Özellikle ekran boyutuyla birlikte ekrandaki bileşenlerin yerlerinin ve boyutlarının nasıl değişeceğini detaylı olarak ayarlamak için kullandığınız "springs and struts" adı verilen özellikler müthiş kullanışlı. Yaptığınız tasarım cihazda da birebir aynı görünüyor. iOS işletim sistemini kullanan cihazlar sadece 4 farklı ekran boyutuna sahip (iPhone, iPad ve bunların retina ekranlı versionları) ve eğer uygulamanızda standart bileşenler kullanıyorsanız bu "springs and struts" mekanizması sayesinde sadece 2 farklı tasarım yaparak (iPhone ve iPad için ayrı) arayüzün her 4 ekran boyutunda hem dikey hem de yatay modda aynı şekilde gözükmesini sağlayabiliyorsunuz. Eğer arayüzü tasarlarken resimler de kullandıysanız, bu durumda da uygulamanızın hem normal ekranlarda hem de retina ekranlarda aynı gözükmesi için yapmanız gereken tek şey arayüzde kullandığınız tüm resimlerin bir de 2 katı boyuta sahip olanlarını adlarının sonuna @2x koyarak projeye eklemek. Az önce söylediğim gibi iPad için ne yazık ki ayrı arayüz tasarlamak zorundasınız ancak Interface Builder size iPhone arayüzünü baz alaran bir template vererek iPad arayüzü tasarlamanızı da çok kolaylaştırıyor.

Arayüz konusundan bahsediyorken iOS'nin arayüzlerde kullanılan bir çok animasyonu otomatik olarak sizin yerinize yaptığını da söylememek olmaz. Bunların başında ekran geçiş animasyonları geliyor. Tuşlara bastığınızda karartma işlemini bile ayrı resim gerektirmeden yapıyor iOS. Ancak yine aynı iOS en son birkaç sürümünden önce üzerine hiç resim kullanmadan gradient falan atabileceğiniz tuşları size standart bileşen olarak sunmuyordu ilginç bir şekilde.

Android'de arayüz tasarımı ne yazık ki biraz pis bir iş. Bir kere arayüz editörü diye bir şey yok. Arayüzler tamamıyla XML dosyaları kullanılarak hazırlanıyor. Üstelik tuşların stillerini falan değiştirmek isterseniz her stil için yine ayrı ayrı XML dosyaları hazırlamanız gerekiyor. iOS'ta olduğu gibi tuşların basılı halleri de Android tarafından otomatik yapılmıyor, onlar için de XML lazım. Bu yüzden özellikle çok fazla resim kullanan çok sayıda ekrana sahip uygulamalar geliştiriyorsanız, projenizin içerisinde kaynak kod dosyasından çok XML dosyası olması muhtemel. Bende öyle oldu. Ayrıca topu topu 4 farklı ekran boyutu olmasına rağmen Interface Builder'da bulunan "springs and struts" benzeri özelliklerin, bir sürü farklı ekran boyutuna sahip cihazlarda kullanılan Android'e yazılım geliştiren kişilere sunulmamış olması kötü. Ancak tabi bu Android'de farklı ekran boyutlarını destekleyemiyorsunuz demek değil. Web sayfalarında olduğu gibi 9 parçaya bölünmüş ve bir kısmı tileable olan resimler kullanarak ve XML dosyalarındaki layout'ları iç içe birden fazla container (mesela LinearLayout) içerecek şekilde dikkatle tasarlayarak boyuttan bağımsız arayüzler yapmak mümkün. Ancak bu kesinlikle XCode'da yapmak kadar kolay bir şey değil. Ama bu beklenen bir şey zaten, sonuçta sabit ekran boyutlarına sahip olmayan cihazlar için tasarlanmış bir işletim sistemi için arayüz tasarlama işinin çok kolay olması zaten mümkün değil. Google bu konuda fena bir iş çıkarmamış aslında, alıştıktan sonra çok da rahatsız gelmiyor bu süreç. Ancak ben yine de bir grafik editör ve "springs and struts" benzeri bir mekanizmayı tercih ederdim.
Android için tasarladığınız arayüzün, emülatör ve cihazda bire bir aynı gözükmediği durumlar olabiliyor. Çünkü işletim sistemi açık ve dolayısıyla her üretici kafasına göre değişiklikler yapabiliyor. Piyasada Android işletim sistemini kullanan, farklı üreticiler tarafından üretilmiş, onlarca farklı ekran boyutuna sahip, onlarca cihaz olduğunu da hesaba katarsanız, yaptığınız arayüzün tüm cihazlarda aynı görünmesinin pratikte imkansız olduğunu görebilirsiniz. Bu tutarsızlık işlevselliklerde de var ancak o buranın konusu değil o yüzden ondan bahsetmeyeceğim. Eğer arayüz tasarımının her cihazda aynı görünmesini kafaya takmış, pikselleri tek tek kontrol eden bir müşteriniz varsa, başınızın çok ağrıyacağından şüpheniz olmasın.
Şimdi bu son dediğimin aksini iddia edenler mutlaka çıkacaktır. Ancak bu iddiaların bir anlam teşkil etmesi için iddiayı ortaya kişilerin, benim gibi her biri tamamen custom tasarıma sahip bileşenlerle dolu olan 10'dan fazla ekrana sahip uygulamalar geliştirmeye kalkmış olması gerekiyor. Yoksa 1-2 ekranlı, basit uygulamalar yazarken bu dediklerim kimseyi rahatsız etmez zaten.
Simülatörler - iPhone/iPad Simulator ve Android Emulator
< iPhone simülatörü, bir simülatörden beklediğiniz işi yapıyor. Gerçek bir iPhone/iPad'i kusursuz bir şekilde simüle ediyor (ekleme: bellek ile ilgili konular hariç). Cihazda olan bir şeyin simülatörde olmadığına şahit olmadım şu ana kadar. Apple'ın bu konuda çok iyi bir iş yapmış olduğunu söyleyebilirim. iPhone/iPad simülatörünün hızı da çok iyi, gerçek cihazdakinden daha hızlı çalışıyor (olması gerektiği gibi). Ancak simülatör çok iyi olmakla birlikte, mükemmel değil. Bunun sebebi de ivme sensörü, GPS, kamera, ses giriş çıkışları vb. özelliklerin bilgisayarda bulunan donanımlar kullanılarak simüle edilemiyor olması. Bunları yapan tek simülatör Blackberry'ninki zaten.

Android simülatörü ise ne yazık ki gibi kötü bir şaka. Ben hayatımda bu kadar yavaş çalışan bir simülatör görmedim. iPhone/iPad simülatörü ile Android emülatörünün açılma ve çalışma hızları kıyaslandığında iPhone simülatörünün F-16, Android emülatörünün ise bisiklet hızında olduğunu gönül rahatlığıyla söyleyebilirim. Kim nasıl yazmışsa artık, gerçek cihazdan çok daha yavaş çalışıyor. Üstelik yavaşlık ekran boyutuyla birlikte artıyor. Yani bir tablet emülatörü sizi sinir krizlerine sokabilecek bir hızda çalışıyor. Hız konusundaki rezilliği görmezden gelirsek geriye gerçek cihazlar ile tutarlılık kalıyor. Bu konuda Android emülatörü her ne kadar hız konusunda olduğundan daha başarılı da olsa, iPhone simülatörüne kıyasla yine kötü. Şu ana kadar Android emülatörünü iPhone simülatörünün onda biri kadar kullanmış olmama karşın cihazlarla daha fazla tutarsızlık yaptığını gördüm. iPhone simülatörü hiç tutarsızlık yapmadı zaten.

Özetlemek gerekirse, simülatör konusunda Apple, Google'a fark atmış. Ancak tamamlamış olduğunuz programınızı simülatörde değil de, cihaza atıp denemek isterseniz, ya da denemesi için müşterinize göndermek isterseniz işiniz Android ile daha kolay. Çünkü Android'e uygulama kurmak için telefonu bilgisayarınıza bağlamanıza bile gerek yok direk kablosuz ağ üzerinden çekebiliyorsunuz ve herhangi bir sertifika ile falan uğraşmıyorsunuz. iPhone için ise telefonu bilgisayarınıza bağlamanız şart ve ondan çok daha beteri, hangi cihazlarda deneyekseniz, o cihazların ID'lerinin eklenmiş olduğu bir sertifika ile imzalamanız gerekiyor ve bir dizi işlemden oluşan bu süreç bazen bitirmiş olduğunuz uygulamanızı müşteriye yollamadan önce çabucak denemek istediğiniz zamanlarda oldukça can sıkıyor.

iOS (iPhone OS) SDK ve Android SDK
iOS SDK, MacOSX'e uygulama geliştirirken de kullanılan MacOSX SDK'sının lite versiyonu aslında. Dolayısı ile oldukça gelişmiş ve kapsamlı bir SDK. İçerisinde ne ararsanız var. Mobil uygulama açısından bence en iyi yani çok ekranlı uygulamaları yazmayı içerdiği NavigationController ve TabBarController sınıflarıyla çok kolaylaştırmış olması. Yeni bir ekran açtığınızda eskisi yerinde duruyor ve her şeyine erişebiliyorsunuz. Tablar için de benzer durum geçerli. iOS SDK'nın en kötü yanı birbirinden tamamen farklı yapılarda, hatta farklı dillerle yazılmış olan birden fazla Framework içermesi. Bu durum bazen oldukça kafa karıştırıyor. Mesela arayüz bileşenlerini içeren UIKit ile çizim yapmanızı yarayan Quartz2D kütüphanelerinin kullandığı koordinat sistemleri ters. Biri sol üst köşeyi orijin olarak kabul ediyor, diğeri sol alt köşeyi. Birinde referans sayıları retain/relase komutları ile artırılıp/azaltılırken, ötekinde farklı release komutları kullanılıyor. Birinin metodlarının Objective-C sentaksı ile çağrılması gerekirken, ötekininkiler C ile yazılmış oldukları için C sentaksı ile çağrılmaları gerekiyor. Quartz2D'ye ek olarak CoreData, CoreText, Grand Central Dispatch, OpenGL ES vb.. gibi yine farklı özelliklere sahip olan Framework'ler mevcut.

Her yeni iOS sürümünde de hepsi de çok gerekli olmayan (örneğin iOS 5.0 ile gelen Storyboard) yeni özellikler ekleniyor SDK'ya ve eski proje taslakları ile dökümantasyonlardaki örnekler bunları kullanacak şekilde güncelleniyor. Bu yüzden bir kere öğrenmekle kurtulamıyorsunuz iOS SDK'yı. İstemeseniz de yeni taslakları kullanmak ya da eski projelerinizde kullandığınız taslakları sıfırdan kendiniz oluşturmanız gerekiyor. Proje yaratma işlevinden daha önemlisi, yeni SDK'nın eskileriyle uyumlu olması. Apple ne yazık ki eskiden bu işi çok iyi beceriyorken 4.2'den itibaren saçmalamaya başladı. Artık her yeni çıkan SDK'da eski SDK'larda kullandığınız bazı özellikler ya kaldırılmış ya değiştirilmiş oluyor ve eğer o anda bir uygulama geliştirmekte iseniz kaynak kodunun bazı yerlerini tekrar gözden geçirmek, karşılaştığınız garip hataların sebeplerini bulmak zorunda kalıyorsunuz. İşin daha da kötüsü bu hataların sebebi bazen sizin yazdığınız kod değil, Apple'ın SDK'nın yeni sürümünde yapmış olduğu bir bug olabiliyor. Böyle durumlarda iş daha da can sıkıcı bir hal alıyor çünkü problemi çözmek için acayip work-around'lar bulmak durumunda kalıyorsunuz.

Android SDK, bildiğiniz JDK'dan türemiş bir kütüphane. Bu sebeple genel olarak iOS SDK'dan daha kullanıcı dostu. Bilgisayarda Java uygulamaları yazarken kullandığınız çoğu sınıf burada da mevcut. Ancak SDK ne yazık ki mobil uygulama geliştirirken işleri kolaylaştıracak hiçbir şey yapmıyor. Demin örnek verdiğim ekran geçişleri mesela. Android'de yeni bir ekran açtınız mı öteki uçabiliyor. Özellikle tab'lı navigasyon kullanan uygulamalarda ekranların içerisinde olan şeyleri sizin saklamanız, daha sonra o ekrana geri dönüldüğünde tüm içeriği ile birlikte tekrar yaratmanız gerekiyor. Bu hem performans açısından kötü hem de programı yazan kişinin ruh sağlığı açısından. Bunun dışında bir çok ufak detay da var Android SDK'nın zayıf kaldığı ancak arayüzden bağımsız yazdığınız kodlarda işiniz tabi ki iPhone SDK'ya göre daha kolay.

Burada Android'in açık kaynaklı olmasından kaynaklanan tutarsızlık problemine tekrar değinmek istiyorum. Ne yazık ki Android SDK içerisinde çok spesifik işler yaptığı için çok sık kullanılmayan metodların farklı üreticilerin cihazlarında farklı şekilde çalışmaları, ya da hiç çalışmaması eğer bu işle profesyönel olarak uğraşıyorsanız mutlaka karşılaşacağınız bir durum. Ben hem arayüz konusunda, hem işlevsellik konusunda karşılaştım. Bu yüzden etrafta kendinin hiçbir işine yaramıyor olmasına rağmen "Android'in açık kaynaklı olması çok iyi" diyen tipleri kaale almayın, farklı donanımlarda kullanılan böyle bir işletim sisteminin kısmen de olsa açık kaynaklı olmaması gerekirdi. Olursa sonucu da böyle oluyor ne yazık ki.

Bahsettiğim problemlere örnek olarak yine yukarıda bahsetmiş olduğum VoiP uygulamasından örnek vereyim: Android'de real-time audio desteği yok, istediğiniz sesi anında çalmıyor, çalması için bir buffer'ı tamamen doldurup beklemeniz gerekiyor. Buffer'ın boyutu ise cihazdan cihaza değişiyor. Bu yüzden sesler bazı cihazlarda gecikmeli olarak çalıyordu mesela. Bu da kullandığım echo-cancellation algoritmasının işe yaramamasına ve konuşurken kendi sesimin ekosunu duymama sebep oluyordu. Probleme çözüm bulmak günlerimi aldı.

Eğer birilerine para karşılığında Android uygulaması yazacaksanız, elinizde en azından bir adet HTC üretimi, bir adet de Samsung üretimi cihaz olduğundan emin olun. En çok değişiklik Samsung'un cihazlarında var. Özellikle tabletinde. Sonra demedi demeyin.

Dökümantasyon
iOS SDK'nın dökümantasyonunun pek bir özelliği yok. Yani .NET Framework gibi her metod için örnekler verilmiş, süper detaylı bir referans dökümantasyon beklemeyin. Özellikle örnek sayısı çok az. Genellikle bir örnekte 50 şeyi gösterme yoluna gitmişler. Ancak aradığınızı rahatlıkla bulabiliyorsunuz ve sınıflar/metodlar ile ilgili açıklamalar yeterince detaylı. Çoğu durumda örneğe ihtiyaç kalmıyor bu yüzden. Artık iPhone'a uygulama geliştirme işi çok yaygınlaştığı için orada bulamadığınuz her şeyi internette bulmanız mümkün zaten. Ancak referans kısmını bir kenara bırakıp dil ve platform hakkında bilgiler içeren kısımlarına gelirsek işte o zaman .NET dökümantasyonuna bile fark attığını söylemek mümkün. Eğer spesifik bir konuyu (Objective-C, Quartz, multi-resolution ekranları desteklemek, Grand Central Dispatch, vs..) öğrenmek isterseniz hepsi hakkında kitap gibi detaylı yazılmış "guide"lar bulmak mümkün Apple'ın sitesindeki dökümantasyonda. Eğer yeni başlıyorsanız internetten aramak ya da kitap okumak yerine buraları okumanızı öneririm.

Android genel olarak her açık kaynaklı Java projesinde olduğu gibi JavaDoc ile hazırlanmış bir dökümantasyona sahip. Bu sebeple arama yeteneği iyi değil (offline dökümantasyon için konuşuyorum, online için zaten dökümantasyonla sınırlı değilsiniz) , ve birçok sınıf vemetod ile ilgili yeterli açıklama ve örnek yok. Buna karşın dökümantasyonun içerisinde aynı iOS'in dökümantasyonunda olduğu gibi işletim sisteminin geneli ve belli başlı bazı önemli konular ile ilgili yazılmış yazılar mevcut ancak bu yazıların detay seviyesi Apple'ın guide'ları kadar değil. Sonuç olarak Apple'ın dökümantasyonundan daha kötü olduğunu söyleyebilirim. Dökümantasyonda bulamadığınız şeyleri aynı iOS SDK için olduğu gibi internette bulabilmeniz tabi ki mümkün.

Uygulamayı Piyasaya Sürme - AppStore ve Android Market
İşte Apple'ın tokatı hakettiği bir kategori. Yazdığınız iPhone uygulamasını AppStore'a çıkarmak için iTunesConnect üzerinde sertifika yaratmanız, yarattığınız sertifikayı kullanarak uygulamanızı paketlemeniz, paketlediğiniz uygulamayı da yine iTunesConnect üzerinden submit etmeniz gerekiyor. Buraya kadar normal (sayılır). Saçmalık buradan sonra başlıyor. Uygulamanız 15-20 güne kadar uzayabilen sürelerde Apple'ın tutarsız çalışanları tarafından tutarsız bir şekilde inceleniyor ve sonuçta ya uygulamanız onaylanıyor, ya da daha önceden bir yerde görüp de önlem almanız mümkün olmayan bazı saçma sebeplerden ötürü reddediliyor. Sorunu düzeltip tekrar submit ediyor ve tekrar 15-20 güne kadar uzayabilen sürelerde onaylanmasını bekliyorsunuz. Yine ya onaylanıyor ya da döngünün başına dönüyorsunuz. Aynı problem ne yazık ki çıkardığınız her güncellemede de var çünkü onlar da onaydan geçiyor. Ancak onaylanma süreleri genellikle daha kısa. Bu 15-20 gün süre iyileşmiş hali, store ilk açıldığı zamanlarda 1 ayı geçebiliyordu bu süreler. Benim ilk uygulamam 33 günde onaylanmıştı mesela. Bir diğer problem de adaletsizlik. Büyük firmaların milyonlarca satan uygulamalarında yapmış oldukları bazı şeyleri sizin yazdığınız uygulamalarda yapmanıza izin vermedikleri de oluyor ne yazık ki. Bunu gözlerine soktuğunuzda da "Diğer uygulamaları örnek göstermeyin, siz kendi uygulamanızdan sorumlusunuz" gibi dangalakça bir cevapla karşılaşıyorsunuz. Aynı problem daha kısa sürelerle olmasına karşılık her güncelleme çıkartışınızda da mevcut. Acil düzeltilmesi gereken bir şeyleri düzeltmek için gönderdiğiniz update'in onaylanması en azından 3-4 gün sürüyor.

Uygulamanız AppStore'a çıktıktan sonra üzerinde istediğiniz değişikliği istediğiniz zaman yapabiliyorsunuz. Fiyat değiştirebiliyorsunuz, açıklamasını değiştirebiliyorsunuz, piyasadan çekip tekrar piyasaya sürebiliyorsunuz vb. Ayrıca eğer iyi bir uygulama yapmışsanız hemen Apple çalışanları tarafından AppStore'un "New and Noteworthy", "What's Hot", "Staff's Favorites" gibi bölümlerine konuyor ve görünürlük kazanıyor. Ancak uygulamanız buralara konmazsa para kazanmayı unutabilirsiniz çünkü durum Android Market'tekine dönüyor. Uygulamanızı adını bilmeyen kimse bulamıyor o kadar uygulama arasında. Ne yazık ki yazdığınız uygulamanın göz önüne konulması için de ya dikkat çekici bir şey yazmış olmanız gerekiyor, ya da tanınan bir firma olmanız. Yoksa oradan milyonlarca dolar kazanmış firmalar varken işiniz zor.

Android Market'e submit süreci daha basit, ayrıca uygulamalar herhangi bir onaydan geçmediği için hemen markete çıkıyor. Ancak Android Market'te AppStore'da olduğu gibi uygulamanızı milletin gözüne sokacak yerler yok. O yüzden uygulamanız çıktıktan sonra ortalıktan kayboluyor ve adını bilip aramayanlar göremiyor. Dolayısı ile Android Market'ten para kazanma şansınız AppStore'a kıyasla çok düşük. Hatta 0'a yakın. Zaten bu durum AppStore'da olan bir çok kaliteli uygulamanın Android Market'te olmamasının 1 numaralı sebebi. Ayrıca markete çıkmış olan uygulamanızın fiyatını AppStore'da olduğu gibi değiştiremiyorsunuz. Bir kez bedava yaptınız mı, paketinizi güncellemeden tekrar paralı yapamıyorsunuz mesela ki bu çok saçma bir şey.

Peki Sonuç?
Okumuş olduğunuz yazı, her ne kadar uzun da olsa, istesem yazabileceklerimin sadece %1'inden falan ibaret. Ancak daha fazla detay yazacak zamanım yok ne yazık ki. Her bir şeyi yazmanın bir anlamı da yok. O yüzden şimdilik yazdığım her iki platformun da beni en çok rahatsız eden ve en çok sevdiğim özelliklerini göz önüne alarak iPhone programlama ve Android programlama arasında bir kıyaslama yapmaya çalıştım. Bir sonuca varmam gerekirse ulaşacağım sonuç, yazımdan da anlayabileceğiniz üzere iOS'in ve yazılım geliştirme araçlarının genel olarak Android'den biraz daha programcı dostu ve daha iyi düşünülmüş olduğu. Bununla birlikte her iki platformda da çok iyi yapılmış olan şeylerle birlikte eksikler var. Android 1 yıl kadar önce yazılım geliştirme araçları ve genel olarak platform desteği konusunda iOS'ten çok gerideydi. Ancak geçen süreçte Google'ın yapmış olduğu iyileştirmeler sayesinde farkı biraz kapattı. Ancak hala tam olarak kapayamamış olduğunu, ve fragmentasyon problemi yüzünden hiçbir zaman da kapayamayacağını düşünmekteyim. Yazımı bir tavsiye vererek bitireyim: Eğer mobil uygulama işine hobi amaçlı değil de, profesyönel olarak, yani para kazanma amaçlı girmeyi düşünüyorsanız birincil platformunuz iOS olsun. Etrafta ilginç bir şekilde çok fazla Apple düşmanı ve Android fanboy'u var. Böyle insanların ne dediğini kaale almayın, kişisel takıntılara değil gerçeklere ve piyasaya göre hareket edin.

alıntı: www.cihantek.com

Bu makaleyi beğendin mi? Yorumunu Yaz!







Sizden Gelen Yorumlar:

Yorum Yazın

bighead(4.1.2015 01:21:15)
Yazanın kalemine sağlık. Paylaşım için teşekkürler. Çık faydası oldu eyv.
%83 %0 %17
Katılıyorum Çekimserim Katılmıyorum



iphone(1.1.2013 18:32:27)
iphone foever... apple bir numara. android berbat. kahrolsun android
%4 %4 %92
Katılıyorum Çekimserim Katılmıyorum



Ömer(30.12.2012 13:17:39)
Programlama, uygulama geliştirme konusunda hiç bir bilgisi olmayıp sadece uygulama kullanan kişiler (Bkz. Ben) bile bu yazıyı okumalı. Yazarın da dediği gibi işin %1.i olsa da bu uygulama dünyasının kökünü kavrayıp sağlam bir genel yargıya ulaşmanız mümkün. Mesela ben artık Android marketten daha çok bedava uygulama indirebileceğimi fakat her telefonumda düzgün çalışabileceğini sanmıyorum. iOS uygulamaları daha çok ücretli olsa da ciddi bir gözetimden geçtiği için ve programlama yöntemi olarak daha işlemci dostu olduğu için hızlı, stabil ve kullanıcı dostu bir arayüz ile çalıştığını söyleyebilirim. Ki hiç iPhone sahibi olmamama rağmen bunu rahatlıkla söyleyebilirim.Fakat iOS kapalı kaynak olduğu için son kullanıcının dışarıdan müdahele etmesine izin vermiyor.Mesela ben Android cihazıma Sony.nin Bravia Engine 2.si yine aynı şekilde sony NXT serisi telefonların HDR kamera sistemini, HTC telefonların Beats ses teknolojisini, Samsung.un Touchwiz Nature UX arayüzünü uyguladım. iOS.ta bu zenginlikler yok fakat genel bir uygulama kalitesi hakim. Bu da kullanıcıya elitlik hissi tanıyor. Fakat ne yazık ki iPhone.un piyasaya giriş politikasından ötürü ilk telefon sahiplerinin verdiği etkiden dolayı ve Apple.ın pazarlama politikalarından dolayı özellikle iPhone ve iPad ürünlerine karşı bir çok insan var. Fakat Google Android sistemini hızla geliştirdiği için aradaki açık kapanıyor ve önümüzdeki 3-5 sene içerisinde artık cihaz seçimi tamamen bir kişisel zevke dönüşecek. Yazınız için de tekrar teşekkür ediyorum.
%75 %10 %15
Katılıyorum Çekimserim Katılmıyorum



Yunus(8.12.2012 05:54:49)
Tam istediğim gibi açıklamışsınız, bu yazıya zaman ayırdığınız için çok teşekür ederim
%45 %0 %55
Katılıyorum Çekimserim Katılmıyorum



ahmet(3.12.2012 03:03:51)
gerçekten güze lbir yazı olmuş. ios a dalmayı düşündüğüm bugünlerde gayet güzel oldu bu yazı :)
%25 %8 %67
Katılıyorum Çekimserim Katılmıyorum



Sinem(13.7.2012 14:25:27)
Teşekkürler yazı için. Ben de android ile çalışmayı planlıyordum iyi oldu bu yazı. Android ile uğraşırken Java.yı da iyice öğrenirim diye android seçtim.
%71 %7 %21
Katılıyorum Çekimserim Katılmıyorum



...(26.4.2012 01:09:20)
Tamda ihtiyacım olan bir konu hakkında birhayli detaylı bir yazı olmuş. Elinize sağlık.
%50 %11 %39
Katılıyorum Çekimserim Katılmıyorum






Copyright© 2001-2024. Bilgisayar Mühendisleri Portalı | Bütün hakları saklıdır.