Görsel: Gezdiren için üretildi.
Telefon ekranında bir not oluşturmak ya da bir şarkı başlatmak, kullanıcı için çoğu zaman iki üç dokunuşluk bir iş. Android’in deneysel AppFunctions arayüzü, bu işleri uygulamanın içinden çıkarıp sistem ajanlarının kullanabileceği araçlara dönüştürmeyi öneriyor. Kullanıcı konuşarak “yarın sabah için not ekle” dediğinde ajan, uygulamanın tanımladığı işlevi bulup çalıştırabilecek. Android Developers’ın genel bakışı, bu işlevlerin Android 16 ve üzerindeki cihazlarda uygulama ile yetkili ajan arasında yerel bir köprü kurduğunu anlatıyor.
Bu değişiklik ilk bakışta arayüzdeki yolu kısaltıyor. Fakat uygulamadaki bir düğme, yanında başlık, geri dönüş oku, hesap bilgisi ve çoğu zaman son bir teyitle yaşar. Ajanın çağırdığı işlevde bunların bir bölümü yoktur. Geriye işlev adı, parametreler, açıklama ve çağıranın erişim düzeyi kalır. Geliştirici artık ekrana sığan akışı kurmanın yanında, makinenin yanlış anlamadan okuyacağı bir işlem sözleşmesi de yazıyor.
AppFunctions’ın teknik düzeni, bu sözleşmenin hangi alanlardan oluştuğunu kayıt altına alıyor. Uygulama, hangi işlevi sunduğunu XML meta verisinde bildiriyor; sistemde ayrıcalığı bulunan ajanlar bu bilgiyi arayıp işlevi çalıştırabiliyor. API başvuru belgesi, bu modelde uygulamayı işlev sağlayıcısı, ajanı da keşfedip çağıran taraf olarak ayırıyor. Bir işlevin açıklaması böylece geliştirici notu olmaktan çıkıyor: ajan hangi işlemi seçebileceğini ve hangi girdinin beklediğini o metinden anlıyor.
Bu noktada “not oluştur” işlevi ile “notları yönet” işlevi arasındaki fark, adlandırma zevkinin ötesine geçer. İlki tarih, başlık ve içerik gibi sınırlı parametrelerle tarif edilebilir. İkincisi arama, seçme, düzenleme, paylaşma ve silme yetkilerini tek kapıda toplayabilir. Kullanıcı ekranda bu seçenekleri tek tek görür; bir ajan ise geniş işlevi tek çağrı olarak değerlendirebilir. Bu nedenle uygulamanın eski menü yapısını araç adına taşımak, ajanın yanlış eylem seçmesi için gereksiz genişlik yaratır.
Android’in kendi uygulama rehberi de işlevi dar tutmayı, hassas bilgiyi ancak işlem bağlamında açıkça onaylanırsa paylaşmayı ve silme gibi geri dönüşü zor sonuçlarda uygulamanın kendi teyit adımını kurmayı öneriyor. Uygulamaya AppFunctions ekleme belgesi, bu teyidin ajan çağrısından sonra uygulama içinde sürmesini özellikle vurguluyor. Bunun pratik karşılığı açık: “eski alışveriş listesini sil” isteği, neyin silineceğini gösteren ve kullanıcıdan net cevap isteyen bir uygulama ekranına uğramalı.
Yerel çalıştırma da tek başına dar kapsam garantisi vermez. AppFunctions, telefonla uzaktaki bir servis arasındaki yolu kısaltabilir; yine de hangi işlevin hangi çağırana açıldığı, hangi alanların parametre olarak kabul edildiği ve sonuçların nereye döndüğü uygulamanın tasarımında belirlenir. Genel bakış belgesinin anlattığı uçtan uca ajan erişimi şimdilik deneysel; bu nedenle bugünün ürünü için kesin bir kullanıcı davranışı varsaymak erken. Buna karşılık, işlev açıklamasını ve kayıt biçimini bugünden dikkatle kurmak için yeterince somut bir yön var.
Geliştiricinin yeni yükü burada test senaryosuna da giriyor. İşlev kayıtlı mı diye bakmak yetmez. Aynı işlev; eksik tarih, birden çok hesap, kapalı ağ, paylaşılmış cihaz ve silme isteğiyle sınanmalı. Rehberin önerdiği `adb shell cmd app_function` komutları işlevi listelemeyi ve doğrudan çağırmayı sağlıyor. Bu denemeler, sohbetin rahat cümlesi ile uygulamanın gerçek veri modeli arasındaki boşluğu yayına çıkmadan görmeye yarar.
Yakın gelecekte bazı telefon uygulamaları, insan arayüzüne ek olarak sistem ajanının çağırabileceği ayrı işlev tanımlarını taşıyacak. Ürün ekibi, ekrandaki veri ve teyit sınırını bu tanımın açıklamasına, parametresine ve onay yoluna da taşımalı. Aksi durumda silme işlevi, kullanıcıya hangi listeyi ve hangi hesabı etkileyeceğini göstermeden çalışabilir.
