Junior’muşum gibi açıkla I
Bugün genelde Android’de uygulama geliştirmek için kullanılan kütüphane ve teknikler Android’in ilk geliştirme zamanlarından çok farklı. Yeni başlayanlar için birçok şeyin neden kullanıldığını anlamak güç. Çünkü bu yeniliklerin hangi problemleri çözdüğününe çok fazla değinilmiyor. Bu konuda Android’e yeni başlayan junior geliştiricilerden bir çok soru aldım. Gerçi Türkiye’de yazılımcılar junior olmadan direk senior olarak işe başlıyorlar ama bu ayrı bir konu. Bu baya uzayabilecek bir konu bu yüzden muhtemelen üç parçaya bölünmüş bir yazı dizisi olacak. İlk konu Android Support Library ve Google Play Services.
Android Support Library
Android Support Library ve buna benzer kütüphaneler Jetpack adı altında birleştirildi. Android Support Library çok daha eskilere dayanıp daha temel şeyleri gerçekleştirdiği için Jetpack olarak değil Android Support Library’den başlayacağım. Her projenin olmazsa olmazı bu kütüphaneleri neden kullanmamız gerekli?
Android Support Library aslında Android’deki güncelleme problemleri yüzünden ortaya çıktı. Bu problemin kaynağı Android’in iOS’dan farklı olarak bir çok fazla marka ve model cihazda çalışması. Her cihaz için işletim sistemi güncellemesi yapmak bayağı zorlu bir süreç ve cihaz üreticileri maliyet yüzünden güncellemelerden mümkün olduğunca kaçtı. Google bile Pixel ve Nexus cihazları ilk piyasaya çıktığı süreden iki sene sonrasına kadar güncelliyor. Bu sebepten Google, Android’de yayınlamak istediği yeni özelliklerin bazılarını işletim sistemi yerine harici kütüphane olarak yayınlamak zorunda kaldı. iOS’da yeni bir versiyon çıktığında desteklenen cihazlara kolayca yüklenebildiği için buna ihtiyaç duyulmuyor.
Peki Google işletim sistemi güncellemelerini beklemeden neleri yayınlamak istedi bunların önemli olanlarına bakalım.
Fragment
Fragmentları ilk olarak tabletlere özel çıkan Android sürümü 3.0 HoneyComb ile kullanmaya başladığımızı hatırlıyorum. Bu sayfa beni doğruluyor. Google aslında Fragment’ları hem işletim sistemine hem de Support Library’e koydu. Bu hatasını bir süre önce android.app.Fragment’i depreciate ederek düzeltti zira hangi package’daki Fragment’ın kullanılacağı çok kafa karıştırıyordu. Fragment’ın ortaya çıkış sebebi tabletlerde Multi Pane Layout denilen, landscape ekranda iki bölümlü, portrait’de tek bölümlü kullanımı desteklemek amacı ile ortaya çıktı. Bunu neden custom View kullanarak çözmediler sorusunun cevabı ise işleri biraz daha karıştıracak nitelikte. Temelde bence Fragment’ların çıkış amacı Layout’u yeni bir yapıda paketlemekden ziyade konfigürasyon değişikliklerinde(ekranın döndürülmesi) Activity ile kullanılan fakat Activity yok edildiğinde hayatta kalabilen yapılar oluşturmaktı. Konfigürasyon değişikliklerinde Activity’nin yok edilip yeni bir Activity oluşturulması iki problem ortaya çıkıyor:
- Yok edilen Activity’nin o anki durumunun(state) yeni yaratılan Activity’e kolayca aktarılamaması.
- Konfigürasyon değişikliği sırasında yapılan bir asenkron işlem bittiğinde verilen callback’lerden yok edilen Activity’nin elemanları erişmeye çalışıldığı için alınan crash’ler ve Asenkron işlemin sonucunun kullanıcıya bildirilememesi.
Bu iki konuda aslında çözümsüz şeyler olmamasına rağmen hem çok fazla boilerplate kod yazmayı gerektirmesi hem de kod örneklerinde bunlara yer verilmemesinden dolayı bir çok kişinin başını ağrıttı. Sonuç olarak Google, Activity’nin lifecycle problemlerinin bir kısmını çözmek için kendi lifecycle’ları olan ve Activity destroy olduğunda hayatta kalıp yeni Activity’de hayatına devam eden Fragment’ları piyasaya sürdü. Kimilerine göre bu problemleri daha da büyüttü. Ben de buna katılanlardanım. Fragment’lardan bu yönde pek yararlanabildiğimi zannetmiyorum.
Layout
Support Library ile gelen layoutlarda temel amaç uygulamalara OS’da olmayan yeni component’lar eklemek ve mevcut component’lara yeni özellikler eklemek. Fakat burada biraz Android tarihi ile birlikte en çok kullanılan üç layouttan bahsedeceğim.
Toolbar
Android 3.0 ile Multi Pane Layout’un yanında Android uygulamalarında Holo denilen yeni bir tasarım dili kullanılması tavsiye edilmeye başlandı. Bu tasarım dilinin en kayda değer özelliklerinden birisi ActionBar kullanımı. Fakat ActionBar 3.0 öncesi sürümlerde yoktu. Jake Wharton Android source kodunu port edip ActionBar Sherlock adında bir kütüphane ile daha önceki versiyonların ActionBar kullanabilmesini sağladı. Benim için layout alanında ilk Support Library budur. Böyle bir library olduğu için Google uzun bir süre ActionBar’ı Support Library olarak yayınlamak zorunda kalmadı. Material Design geldikten sonra ActionBar yerine Toolbar kullanmaya başladık.
RecyclerView
Android’de RecyclerView’den önce ListView ve GridView kullanılırdı. Bu üç component’ın amacı benzer tipte bir listenin dinamik ve verimli bir şekilde göstermektir.
ListView ve GridView’de scroll performansını arttırmak için adapter’in getView()metodunun içerisinde yapılması gereken iki şey var. İlki yeni bir View yaratıp döndürmek yerine bize sağlanan convertView’i tekrar kullanmak, ikinci ise view’in child’larına erişmek için her seferinde findViewById() yapmamıza gerek bırakmayan ViewHolder pattern’i. Bu iki yöntem sayesinde RecyclerView’e yakın performans almak mümkün belki fakat ListView api, geliştiricileri bunları yapmaya zorlamıyor. Fakat RecyclerView ve adaptörü bu işlerden halledebildiği kısmı kendi halledip geri bizi geri kalanları yapmaya zorluyor.
ListView ve GridView’deki özelleştirme(customization) sorunları RecyclerView’de LayoutManager (listenin grid ya da liste şeklinde gösterilmesini belirliyor) ve ItemDecorator (divider ve header gibi yapıları ekliyor) kullanılarak çözüldü. RecyclerView.Adapter’daki diğer bir güzellik ise kolay bir şekilde farklı tiplerde view’leri listeleyebilmesi.
ConstraintLayout
FrameLayout, RelativeLayout ve LinearLayout temel olarak kullanılan üç layout’du. Bunlarla aşağı yukarı istediğimiz ekranları elde etmemiz mümkün fakat bazı durumlarda nested(iç içe) layout’lar kullanmamız gerekiyor. Her kullandığımız layout’un ve view’in performansa etkileri olduğu için iç içe olmadan tek bir layout kullanıp aşağı yukarı tüm ekranları oluşturabileceğimiz ConstraintLayout geldi yardıma. Şunu eklememde fayda olduğunu düşünüyorum; eğer tek bir FrameLayout ya da LinearLayout işimizi görecekse bunları kullanmamız daha performanslı olacaktır.
MultiDex
Android’de apk oluşturulurken yazdığımız kodlar ve kullandığımız kütüphaneler bytecode’a çevriliyor ve .dex uzantılı dosyalara konuluyor ve Dalvik dex dosyasında 64k yani 65,536 adet metodu referanslayabiliyor. Android 5’den önce build aldığınız zaman apk’lara tek dex dosyası konuluyordu. Dolayısı ile uygulamada ve dex dosyasında 64k’dan fazla metod olduğu zaman uygulama açılırken crash alınıyordu. Support Library’nin Android’e girmesi ile birlikte OS’de olması gereken Class’lar uygulamaların içerisine girmeye başladı. Support Library’nin ve Google Play Services kütüphanelerinin boyutu büyüdükçe uygulamaya daha fazla metod eklendi. Projelerin de büyümesi birlikte uygulamalar 64k limitine erişmeye başladı. Facebook gibi büyük firmalar kendi çözümlerini getirdi ama çoğu geliştirici için böyle çözümler çok mümkün değildi. Uygulamadan kütüphane çıkarmamız gerektiğini hatırlıyorum. Android Support Library ve Google Play Services Library de sanırım bu sıralar birden fazla kütüphaneye bölünerek uygulamalardaki metod yükü azaltıldı. Proguard kullanılan projelerde bu limite daha geç ulaşıldı. Multidex’in yaptığı şey adından da anlaşılacağı gibi birden fazla .dex dosyasının kullanımına izin vermesi. Android 5’de buna OS seviyesinde destek geldi fakat önceki versiyonlarda Multidex support kütüphanesi kullanılması gerekiyor. Umarım projeler minSdkVersion 21+ olur ve Multidex support hayatımızdan çıkar(çıkmadı).
AppCompat
Aslına bakarsanız bu kütüphane yeni özellikler ekliyor ve bana göre asıl amacı OS’da hali hazırda kullanılabilecek ne varsa api versiyonunu düşünmeye gerek kalmadan kullanmamızı sağlamasıdır. Bu da farklı api seviyelerinde farklı sonuçlar almamıza yol açabilir. NotificationCompat’ın dökümanına baktığımızda şu örneği veriyor: “Action butonları Android 4.1 versiyonundan önceki versiyonlarda gösterilmez. Action butonlar için genişleyebilen bildirimler gereklidir, bu da Android 4.1 versiyonu ve sonrasında olan bir özelliktir”
Google Play Services
Android bilindiği gibi açık kaynak bir işletim sistemi. Yani isteyen bu işletim sistemini alıp kodunu kullanabilir. Fakat bu açık kaynak kısmına Google Servisleri dahil değil. Yani açık kaynak kodu aldığınız zaman içerisinde Google Play, arama motoru ve hatta Firebase Cloud Messaging(Push Notification servisi eski adıyla Google Cloud Messaging) dahil değil. Bir firma cihazına Android kurmak istediği zaman iki şey yapabiliyor. İlki Google’ın isteklerine boyun eğip lisans alarak Google servislerini ekleyebiliyor ya da eksikleri kendisi tamamlıyor (Amazon ve zamanında BlackBerry ikinci yolu seçti). Google servislerinin ortasında Google Play Services bulunuyor. Google Play Services aslında Google Play üzerinde güncellenebilen bir uygulama. Bu uygulama root yetkisinde ve normalde uygulamalardan erişemediğimiz yerlere erişmesi mümkün. Biz kullandığımız Google Play Services ve Firebase kütüphaneleri ile aslında bu uygulamanın api’lerini çağırıyoruz. Google Firebase’i satın aldıktan sonra Google’ın bazı hizmetleri Firebase çatısında birleştirdi ve Android’de bunları Google Play Services’in altına koydu. Başlangıçta muhtemelen sadece Google Play’e yönelik bu servis kendi alanını aşarak baya büyük bir hale geldi.
Bu yazı serisinin ikinci kısmında Android’de kullanılan mimariden ve son kısımda Architecture Components’dan bahsetmek istiyorum. Sizin de eksik kaldığını düşündüğünüz ve bahsedilmesini istediğiniz konular varsa bildirirseniz elimden geldiğince değinmeye çalışırım.
Bu yazıyı gözden geçiren Furkan Aşkın’a teşekkür ediyorum. Sonraki bölümde görüşmek üzere.
Yazının ikinci bölümüne buradan erişebilirsiniz:
