Parçalardan widget'lara taşıma

Hem kutucuklar hem de widget'lar içeriğinizi uzak bir sistem yüzeyinde gösterse de bunları oluşturmak için farklı yaklaşımlar gerekir. Mevcut kutunuzu widget'a taşıdığınızda, katı düzen oluşturma işleminden dinamik ve bildirimsel bir kullanıcı arayüzüne geçiş yapmış olursunuz. Bu sayede yeni özelliklerden yararlanabilir ve geliştirme modelini basitleştirebilirsiniz.

Uygulama stratejinizi seçin

Eski bir karo içeren bir uygulamayı taşıyorsanız uygulamanızın sisteme nasıl içerik sağlayacağına karar vermeniz gerekir. Yeni araç takımları tek bir Widget Hizmeti kullanmalıdır. Mevcut kutuları olan uygulamalar ise her iki hizmeti de korumayı veya tek bir Widget Hizmeti'nde birleştirmeyi seçmelidir.

Önerilen: Çift hizmet (tile + widget)

Mevcut kutusu olan tüm uygulamalar için hem kutu hem de widget bulundurmanız önerilir. İki ayrı hizmet sunmak, farklı cihazlarda mümkün olan en iyi kullanıcı deneyimini sağlar.

Çift Hizmet Kurulumu için Sistem Davranışı:

İşletim sistemi / Cihaz özelliği Sonuçlanan deneyim
Wear OS 3 Tile kullanılıyorsa
Wear OS 4, 5, 6 Tile kullanılıyorsa
Wear OS 7 (Kısmi yükseklik desteği yok, ör. Pixel Watch) Tile kullanılıyorsa
Wear OS 7 (Kısmi yükseklik desteği, ör. Galaxy Watch) Widget kullanılıyor

Alternatif: Tek hizmet (yalnızca widget)

Tek bir hizmet her iki protokolü de işler. Bu yaklaşımı uygulamak daha hızlı olsa da widget'ınızı Wear OS'in eski sürümlerini çalıştıran cihazlarda kutucuğa "uyarlamak" için uyumluluk modunu kullanır.

Bu yaklaşımı seçerseniz:

  1. Her iki amaç filtresini de belirtin: Hizmetiniz hem androidx.wear.tiles.action.BIND_TILE_PROVIDER hem de androidx.glance.wear.action.BIND_WIDGET_PROVIDER için amaç filtreleri içermelidir. Bu sayede widget'ınız Wear 4, 5, 6 ve 7'deki kutu yüzeylerinde (gerekli durumlarda) gösterilir.
  2. Mevcut hizmet adınızı koruyun (sorunsuz yükseltmeler için): Etkin bir kutuyu değiştiriyorsanız aynı hizmet sınıfı adını korumak, kutunuzu bantlarında bulunduran kullanıcıların yeni widget'a otomatik olarak güncellendiğini görmelerini sağlar. Wear OS 7, farklı bileşenleri mantıksal olarak bağlamak için widget yapılandırma XML'sinde group özelliğini kullanırken Wear OS'in 7'den önceki sürümleri, bunları "aynı" bileşen olarak tanımlamak için hizmet adına bağlıdır. Yeni bir hizmet adı kullanmayı tercih ederseniz uygulamanız sorunsuz bir şekilde çalışmaya devam eder. Ancak Wear OS 6 veya daha eski bir sürümü çalıştıran cihazlardaki kullanıcıların widget'ı karusellerine manuel olarak yeniden eklemesi gerekir.

Tek Hizmet Kurulumu İçin Sistem Davranışı:

İşletim sistemi / Cihaz özelliği Sonuçlanan deneyim
Wear OS 3 Desteklenmiyor
Wear OS 4, 5, 6 Widget, tam ekran kutu olarak gösterilir.
Wear OS 7 (Kısmi yükseklik desteği yok) Widget, karta çevrilir.
Wear OS 7 (Kısmi yükseklik desteği) Widget kullanılıyor

*Renderer 1.6 veya sonraki sürümler gerekir.

Kullanıcı Arayüzü Çevirisiyle İlgili İpuçları

Kullanıcı arayüzünüzü ProtoLayout'tan (Tiles) Remote Compose'a (Widgets) çevirirken zihinsel model, zorunlu düzen oluşturuculardan, kullanıcı arayüzü güncellemelerinin yeniden oluşturma yoluyla işlendiği duruma dayalı, Compose tabanlı bir mimariye dönüşür. Aşağıdaki ilkeleri göz önünde bulundurun:

  • Bildirimsel kullanıcı arayüzünü benimseme: Zorunlu ProtoLayout oluşturucuları (LayoutElementBuilders) RemoteText, RemoteColumn ve RemoteBox gibi bildirimsel Remote Compose eşdeğerleriyle değiştirin.
  • Temel İçeriğe Odaklanma (mainSlot): Kısmi yükseklikteki widget'lar (ör. SMALL ve LARGE kapsayıcı türleri) odaklanılmış ve bir bakışta görülebilen bir yüzey sağlar. Yoğun ve tam ekran bir karo düzenini bire bir aktarmak yerine, tasarımınızı ana içerik alanındaki birincil bilgileri vurgulayacak şekilde basitleştirin.
  • Kenara hizalı işlemleri yeniden tasarlama: Döşeme mimarisinde, EdgeButton gibi ekranı kaplayan bileşenler özel bir bottomSlot'ye sabitleniyordu. Kısmi yükseklikteki widget'lar doğrudan dikey olarak kaydırılan bir yüzeye entegre edildiğinden, bu sabit bottomSlot paradigması artık mevcut değildir. Kenara hizalanmış düğmeler genellikle çok belirgin birincil işlemler olarak kullanıldığından taşıma işlemi, doğrudan bileşen değişimi yerine kasıtlı bir kullanıcı arayüzü yeniden tasarımını gerektirir. Birincil işlemleriniz için alternatif kullanıcı deneyimi stratejilerini değerlendirin:
    • Satır İçi İşlemler: Satır içi RemoteButton öğesini doğrudan mainSlot düzeninize entegre edin.
    • Kapsayıcı dokunmaları: PendingIntentAction kullanarak tüm widget kapsayıcısına dokunulabilir hale getirerek etkileşimi birleştirin.
    • İçerik Pivotu: Widget'ın odağını yeniden değerlendirin. Özel bir işlem alanı olmadan, daha zengin ve bir bakışta görülebilen veriler sunmayı ve widget yüzeyinde belirli işlemleri izole etmek yerine tam uygulamayı açmak için tek bir dokunmaya güvenmeyi düşünebilirsiniz.
  • Etkinlik İşlemeyi Taşıma (İşlemler ve Lambda'lar): Döşemeler, kullanıcı arayüzünü yenilemek için tam hizmet geri çağırmalarını tetikleyen etkileşimlere (ör. LoadAction) dayanır. Wear widget'ları istemci tarafında çalışır. Standart Compose lambda'ları uzaktan çalıştırılamaz. Bunun yerine, serileştirilebilir bildirim temelli işlemler (ör. ValueChange veya PendingIntentAction) sağlayın. Uygulama gidiş dönüşleri olmadan anında kullanıcı arayüzü güncellemelerini desteklemek için bunları bildirim temelli durumla (ör. rememberMutableRemoteInt) birleştirin.
  • Boyutları ve Türleri Uyarlama: Düzen boyutlarını taşırken standart Dp yerine RemoteDp (ör. 10.rdp) kullanarak düzen çözümlemesini ertelemeyi tercih edin. Bu, sistem oluşturucunun piksel değerlerini görüntüleme sırasında doğru şekilde hesaplamasını sağlar. Benzer şekilde, standart Kotlin ve Remote Compose türlerini sorunsuz bir şekilde dönüştürmek için Remote Compose uzantı işlevlerini (.rc için Color, .rs için String, .rdp için Dp) kullanın.
  • Örnek Kodu İnceleyin: Düzen oluşturma, anlamsal tipografi uygulama ve Remote Compose'da durumu yönetme konularında kapsamlı örnekler görmek için Wear OS Samples deposunda bulunan resmi örnek kodu inceleyin.