XML Neden Vardı, Neden Bırakılıyor?
Bir Standardın Yükselişi ve Alacakaranlığı
Android geliştirmeyi öğrenen herkes XML ile tanışır. Layout dosyaları, string kaynakları, drawable tanımları, manifest — Android'in her köşesinde XML vardır. Yıllarca bu böyleydi ve kimse bunu sorgulamıyordu.
Sonra Jetpack Compose geldi. Ve XML'in neden var olduğu sorusu, neden bırakıldığı sorusuyla birlikte sorulmaya başlandı.
XML Neden Seçildi?
Android'in ilk sürümleri tasarlanırken UI tanımı için bir format seçilmesi gerekiyordu. Bu seçim birkaç gereksinim çerçevesinde yapıldı.
UI tanımının koddan ayrı tutulması gerekiyordu. Tasarımcılar ile geliştiricilerin aynı dosyalar üzerinde çatışmadan çalışabilmesi isteniyordu. Görsel araçların bu tanımları okuyup işleyebilmesi gerekiyordu. Ve farklı ekran boyutları, yoğunlukları ve dil konfigürasyonları için farklı kaynakların kolayca tanımlanabilmesi şarttı.
XML bu gereksinimlerin tamamını makul biçimde karşılıyordu. İnsan tarafından okunabilirdi, araç desteğine açıktı, hiyerarşik yapısı View ağacını doğal biçimde ifade ediyordu ve o dönem için yaygın ve iyi anlaşılmış bir standartdı.
Seçim pragmatikti — ideal değil, o an için yeterli.
XML'in Getirdikleri
XML layout sistemi zamanla olgunlaştı ve güçlü bir araç seti ortaya çıktı.
Kaynak sistemi XML'in en güçlü yanıydı. Aynı layout'ın farklı ekran boyutları için farklı versiyonları layout-large, layout-sw600dp gibi klasörlerle tanımlanabiliyordu. Dil kaynakları values-tr, values-en gibi klasörlerde ayrı tutulabiliyordu. Bu sistem ekran parçalanması sorununu sistematik biçimde ele alıyordu.
Separation of concerns prensibi görece sağlanıyordu. Layout dosyaları UI yapısını tanımlıyor, Java ya da Kotlin dosyaları davranışı yönetiyordu. Bu ayrım teorik olarak temizdi.
Android Studio desteği zamanla mükemmelleşti. Layout Preview, Constraint Layout editörü, Resource Manager — XML ile çalışmayı kolaylaştıran araçlar geliştirildi.
XML'in Getirmediği Sorunlar
Yıllar geçtikçe XML'in yapısal sınırları daha da belirginleşti.
Runtime inflation maliyeti en somut performans sorunuydu. XML dosyaları derleme zamanında kod üretmez — çalışma zamanında parse edilir, View nesneleri oluşturulur, hiyerarşi kurulur. Bu işlem özellikle karmaşık layout'larda ciddi süre alırdı. İlk ekran açılış sürelerinin büyük bölümü bu inflation maliyetine aitdi.
Tip güvenliğinin yokluğu sinsi bir sorun kaynağıydı. findViewById ile bir View buldunuzda gerçekte ne döndüğünü derleyici bilmiyordu. Yanlış bir tip cast'i derleme zamanında değil, çalışma zamanında çöküşe yol açıyordu. ViewBinding bu sorunu büyük ölçüde çözdü ama XML'in kendisinden kaynaklandığı için tamamen ortadan kalkmadı.
Dinamik UI'ın zorluğu belki de en büyük pratik engeldi. XML statik yapılar için biçilmiş kaftandı. Ama kullanıcı etkileşimine bağlı olarak View'ların görünmesi, kaybolması, eklenmesi ya da değişmesi gerektiğinde işler karmaşıklaşıyordu. Visibility toggle'ları, adapter'lar, programmatic View oluşturma — XML'in sunduğu tanımsal yaklaşım burada yetersiz kalıyordu.
Kod ve XML arasındaki sürekli geçiş zihinsel yükü artırıyordu. Bir UI parçasını anlamak için hem Kotlin dosyasını hem de XML dosyasını aynı anda kafada tutmak gerekiyordu. Mantık kodda, yapı XML'de, stil başka bir XML'deydi.
View Binding ve Data Binding: Yama Girişimleri
Google bu sorunların farkındaydı ve çeşitli çözümler üretmeye çalıştı.
View Binding, findViewById sorununu çözdü. Her layout için tip güvenli bir binding sınıfı oluşturarak null pointer riskini ve yanlış cast riskini derleme zamanına taşıdı. Kullanışlıydı ama XML'in temel sorunlarına dokunmuyordu.
Data Binding, UI bileşenlerini doğrudan veri kaynaklarına bağlamayı mümkün kıldı. XML içine ifade yazılabildi, ViewModel değişkenleri doğrudan layout'a bağlanabildi. Güçlüydü ama karmaşıktı. XML içine mantık karışıyordu, hata mesajları anlaşılması güçtü ve derleme süreleri uzuyordu.
Bu araçların her biri XML'in üzerine konulan yamalar gibi hissettirdi. Temeli değiştirmiyor, üstünü örtüyordu.
Neden Bırakılıyor?
XML'i terk etme kararının arkasında tek bir sebep yok. Birden fazla etken bir araya geldi.
Kotlin'in dile entegre reaktif programlama desteği, UI'ı kod olarak ifade etmeyi çok daha anlamlı kıldı. Deklaratif UI paradigmasının Flutter ve React Native gibi platformlarda kanıtlanması, aynı yaklaşımın Android'e getirilmesi için güven sağladı. Ve Jetpack Compose'un sunduğu geliştirici deneyimi, XML ile çalışmanın getirdiği sürtünmeyi gözler önüne serdi.
XML gidiyor değil, yavaş yavaş ikincil konuma çekiliyor. Yeni projelerde Compose tercih ediliyor, XML ise mevcut kod tabanlarında varlığını sürdürüyor. Bu geçiş ani değil, kademeli bir dönüşüm.