Junior’muşum gibi açıkla III- Android Architecture Components

Android mimarisi ve Dependency injection hakkındaki ikinci bölüme burdan erişebilirsiniz:

Junior’muşum gibi açıkla II -Android Mimarisi

Bu yazı dizisinde Android geliştirme ile alakalı problemleri ve bunları nasıl çözdüğümüzden bahsettim. Bu problemlerin bazıları yazılımcı komunitesi tarafından çözüldü. Bu sırada Google son kullanıcı tarafındaki problemleri çözmekle meşguldü. Geliştirme araçları tarafında gelişim oldukça kısıtlıydı. Android Studio’nun gelişi problemlerin bir kısmını çözdü fakat çözemediği bir çok problem vardı.

Yaklaşık iki sene önce Google ilk Android Architecture Component olan Lifecycle’ı yayınladı. Daha sonra başka problemleri çözen başka Android Architecture Components(AAC)’lar yayınlandı. AAC kütüphaneleri kullanımı kolay, üzerinde iyi düşünülmüş ve birlikte de çok güzel çalışan kütüphaneler. Fakat aslında bunların bazılarına hiç ihtiyacımız olmaması ya da harici ve ikincil bir çözüm olmak yerine, Android işletim sisteminin bir parçası olmaları gerekiyordu. Bu kütüphaneler sistemdeki problemli alanların üzerini kapatan bir katman görevi görüyorlar. AAC kullandığınızda problemler aslında çözülmüyor fakat bu problemlerle uğraşmanıza gerek kalmıyor. Yani AAC kullanmak için genellikle iki katman derinliğinde bilgiye sahip olmak gerekebiliyor.

İlk ve ikinci yazılarda LiveData ve ViewModel’den yeterince bahsettiğimi düşünüyorum. Bu yüzden bunlara değinmeyeceğim. Daha aşina olduklarımdan başlayarak bakalım başka hangi AAC’lerimiz var:

Navigation

Muhtemelen navigation favorim. CitizenMe’de navigation’u magic link kullandığımız yeni kayıt ve giriş ekranları için kullandık. Navigation’un en güzel yanı tek bir aktivite ile birden fazla fragment kullanırken çirkin fragment transactionlar ile uğraşmanıza gerek kalmıyor. Fragment transaction’lar benim kabusum diyebilirim. Nasıl çalıştıklarını %100 bildiğim halde istediğim şeyleri yapabilmek için baya uğraşmam gerekiyor. Bu konuda ayrı bir blog yazısı yazabilirim muhtemelen fakat şimdilik bunu yapmayıp Junior geliştiricilere fragment transactionları anlamaya çalışmak yerine navigation’u kullanmalarını öneririm. 😞 Malesef bunu şu anda yapabilmeniz çok mümkün değil çünkü piyasadaki Android uygulamalarının çoğunda fragment transaction’lar kullanılıyor.

Navigation component ile gereksiz detaylar ile uğraşmadan yeterince kontrol sahibi olarak yapmak istediğiniz şeyleri yapmanız mümkün. Navigation geliştirici klavuzunu inceleyip neler yapabildiğinizi görebilirsiniz. Burda iddia edilen şeyleri yerine getirdiğini söyleyebilirim. “Benefits” kısmına bakıp aslında hangi problemleri çözdüğünü çıkartabilirsiniz.

Data Binding

Android’in ilk zamanlarında Java kodundan XML dosyalarında oluşturduğumuz viewlere findViewById(id:Int) ile erişirdik. Bu şimdi de kullanılabilecek bir yöntem tabi ki. Bu yöntem ingilizce boilerplate denilen aslında bir iş yapmayıp bir şey yapmanıza aracı olan fazlalık kod yazmamıza neden oluyor. Android Annotations ve Butterknife gibi kütüphaneler findViewById(id:Int) kullanmadan annotasyonlar yardımı ile view’lere erişmemize yardımcı oldu. Google bu probleme farklı bir bakış açısı getirmek istedi. Databinding ile Java’dan viewlere erişmek yerine XML tarafında yaptığımız tanımlamalar ile java tarafındaki değişkenlere erişmemiz mümkün oldu. Aslında tersine bir mantık sağladı.

Databinding’in en sevdiğim yanı LiveData’ya bağlanıp LiveData her güncellendiğinde view’i güncelleyebilmesi. Her ne kadar güzel bir kütüphane olsa bile Kotlin Android Extensions View Binding’i daha temiz bir kullanım sağladığı için tercih ediyorum.

WorkManager

Eski zamanlarda Activity yaşam döngüsünden etkilenmeden arka planda bir iş yapmak için Service kullanırdık(hala kullanabiliriz). Service’leri BroadcastReceiver ve AlarmManager ile birleştirip uygulama ön planda ayakta değilken bile arka planda iş yapabiliyorduk. Böyle bir yaklaşımda ne yanlış gidebilir ki? Anlaşıldı ki bir çok şey. Bir kısıtlama olmadan kullanılan bu yaklaşım geliştiricilerin kafalarına göre uygulamalarını ayağa kaldırıp pili tam anlamı ile sömürmelerine sebep verdi. Android API’s 19 ve 23'de arka plan kısıtlamaları başladı. Bu kısıtlamalar uygulamaların doğru çalışmamalarına sebep oldu ve Service yerine konulan yeni yapılar geriye dönük destek sağlamıyordu. Bu problemi çözmek için WorkManager tanıtıldı. WorkManager yapılacak işleri hangi API versiyonunda olduklarına göre uygun araçları kullanarak yapmaya olanak sağlıyor. Ayrıca geliştiricilere bağlantı ve şarj olma durumlarına göre arka planda işlemlerini yapmalarını sağlıyor.

Room

Room daha önce kullanma fırsatı bulamadığım fakat kullanmak istediğim bir kütüphane. Java’da kullanmayı sevdiğim Jdbi’a çok benzeyen bir kullanımı var. Room SQLite üzerinde kolay bir erişim sağlayan bir API’a sağlıyor. Room bizi cursorlar ile uğraşmaktan ve teker teker data objelerini oluşturmaktan kurtarıyor. Bunun için ihtiyacımız olan şey interface’lerin içerisinde SQLite sorguları ile annote edilmiş fonksiyonlar. Bu sorgu parametrelerini fonksiyonlara parametre olarak sağlayabiliyoruz. Bu interface’lerin implementasyonları ve çalışmaları bizim için hallediliyor.

Paging

Mobil bir cihazda hafızaya büyük veri yüklemek çok ideal olmayabilir. Veritabanından ya da bir API’dan çekip datayı deserialize etmek çok uzun sürer ve çok fazla hafızaya ihtiyaç duyulabilir. Bu durumda yeterince datayı çekip gösterdikten sonra gerektiğince datayı çekmeye devam etmek mantıklıdır. Android’de bu işlemleri RecyclerView ‘in OnScrollListener’ını dinleyip gerektiğinde sonraki datayı çekerek yapabiliyoruz. Eğer ne yaptığınızı bilmiyorsanız bu zor bir işlem olabilir. Paging bunu bizim için kolay bir şekilde hallediyor.

Gördüğünüz üzere Android’de AAC olmadan da geliştirme yapmamız mümkün, fakat bu AAC şu andaki modern Android geliştiriciliğinin ana parçalarından en büyüğü denilebilir. Aslında AAC’yi eleştiriyor gibi görünsem de AAC bizim için bir çok problemi hallediyor. Fakat söylemeliyim ki yalın ve günümüzdeki mimari elemanlar kullanılmadan yapılacak geliştirmenin de çok hayranı değilim. Bu yüzden AAC’ye minnettarım.

Android komünitesi benim de bir parçası olmaktan mutlu olduğum büyük ve güçlü bir geliştirici komünitesi. Bu komünite Android’deki problemlerin bir çoğunu Google’dan çok daha önce çözdü. AAC’deki devamlı sağlanan geribildirim çemberinden de çok memnunum. AAC’nin bu kadar başarılı olmasının ardında bu yattığını düşünüyorum. Geliştiriciler ve Google arasındaki bu ilişkiyi Compose’un da geliştirilmesinde de görüyoruz. Bu açıdan Compose’un çok iyi bir yere geleceğinden ve bu büyük mantalite değişikliğinin diğer android alanlarında da görüleceğini ümit ediyorum.