Kullanıcı arayüzünü duyarlı düzenlere taşıma

Android uygulamalarının, sürekli genişleyen cihaz form faktörü ekosistemini desteklemesi gerekir. Bir uygulamanın kullanıcı arayüzü, farklı ekran boyutlarının yanı sıra farklı yönlere ve cihaz durumlarına uyacak şekilde duyarlı olmalıdır.

Uyumlu kullanıcı arayüzü, esneklik ve süreklilik ilkelerini temel alır.

Esneklik, kullanılabilir alanı en iyi şekilde kullanan ve kullanılabilir alan değiştiğinde ayarlanan düzenleri ifade eder. Ayarlamalar birçok şekilde olabilir: Tek bir görünümün boyutunu büyütmek, görünümleri daha erişilebilir konumlara yeniden konumlandırmak, ek görünümleri göstermek veya gizlemek ya da bunların bir kombinasyonu.

Süreklilik, bir pencere boyutundan diğerine geçiş sırasında sorunsuz bir kullanıcı deneyimi sunmayı ifade eder. Kullanıcının etkileşimde bulunduğu deneyim kesintisiz olarak devam etmelidir. Boyut değişikliği, görünüm hiyerarşisinin tamamının kaldırılıp yeniden oluşturulmasıyla birlikte gerçekleşebileceğinden, kullanıcının bulunduğu yeri veya verilerini kaybetmemesi önemlidir.

Yapılmaması gerekenler

Düzenleme kararları almak için fiziksel, donanım değerleri kullanmaktan kaçının. Sabit bir değere göre karar vermek cazip gelebilir ancak birçok durumda bu değerler, kullanıcı arayüzünüzün çalışabileceği alanı belirlemek için yararlı değildir.

Uygulamalar, çoklu pencere modunda, pencere içinde pencere modunda veya ChromeOS gibi serbest biçimli pencerelerde çalışırken pencere boyutunun değişmesiyle karşılaşabilir. Katlanabilir cihazlar veya birden fazla ekrana sahip cihazlar gibi birden fazla fiziksel ekran da olabilir. Bu durumların hiçbirinde, fiziksel ekran boyutu içeriğin nasıl gösterileceğine karar vermede önemli değildir.

Şekil 1. Pencere boyutları fiziksel cihaz veya ekran boyutundan farklı olabilir.

Aynı nedenle, uygulamanızı belirli bir yönde veya en boy oranında kilitlemekten kaçının. Cihazın yönü belirli olsa da uygulamanız, yalnızca penceresinin boyutuna bağlı olarak farklı bir yönde olabilir. Örneğin, çoklu pencere modu kullanılırken yatay modda olan bir tablette bir uygulama, genişliğinden daha uzun olduğu için dikey olabilir.

Ayrıca, cihazın telefon mu yoksa tablet mi olduğunu belirlemeye çalışmayın. Tablet olarak kabul edilen cihazların özellikleri biraz özneldir: Belirli bir boyuta, en boy oranına veya boyut ile en boy oranının bir kombinasyonuna sahip olmak mı? Yeni form faktörleri ortaya çıktıkça bu varsayımlar değişebilir ve ayrımın önemi azalır.

Önceki stratejilerden herhangi birini denemek yerine kesme noktalarını ve pencere boyutu sınıflarını kullanın.

Kesme noktaları ve pencere boyutu sınıfları

Ekranın uygulamanıza ayrılan gerçek kısmı, uygulamanın penceresidir. Uygulamanız tam ekranı veya ekranın bir kısmını kaplayabildiğinden, uygulamanızın düzeniyle ilgili üst düzey kararlar alırken pencere boyutunu kullanın.

Birden fazla form faktörü için tasarım yaparken bu üst düzey kararların farklı yönlere ayrıldığı eşik değerlerini bulun. Bu amaçla, Material Design duyarlı düzen ızgarası, genişlik ve yükseklik için kesme noktaları sağlar. Bu sayede, ham boyutları pencere boyutu sınıfları olarak adlandırılan ayrı, standartlaştırılmış gruplarla eşleyebilirsiniz. Dikey kaydırma yaygın olduğundan çoğu uygulama öncelikle genişlik boyutu sınıflarıyla ilgilenir. Bu nedenle, çoğu uygulama yalnızca birkaç kesme noktasını ele alarak tüm ekran boyutları için optimize edilebilir. (Pencere boyutu sınıfları hakkında daha fazla bilgi için Pencere boyutu sınıflarını kullanma başlıklı makaleyi inceleyin.)

Kalıcı kullanıcı arayüzü öğeleri

Materyal Tasarım düzenleme yönergeleri, uygulama çubukları, gezinme ve içerik için bölgeleri tanımlar. Genellikle ilk ikisi, görünüm hiyerarşisinin kökünde (veya çok yakınında) bulunan kalıcı kullanıcı arayüzü öğeleridir. "Kararlı" ifadesinin, görüntünün her zaman görünür olduğu anlamına gelmediğini, diğer içerik görüntülemelerinin hareket edebileceği veya değişebileceği durumlarda görüntünün yerinde kaldığını unutmayın. Örneğin, bir gezinme öğesi ekranın dışındaki bir kaydırılabilir çekmecede olabilir ancak çekmece her zaman oradadır.

Kalıcı öğeler duyarlı olabilir ve genellikle pencerenin tam genişliğini veya tam yüksekliğini kaplar. Bu nedenle, nereye yerleştirileceğine karar vermek için boyut sınıflarını kullanmayı tercih edin. Bu, içerik için ayrılan alanı gösterir. Aşağıdaki snippet'te etkinlik, kompakt ekranlar için alt çubuk, daha büyük ekranlar için ise üst uygulama çubuğu kullanır. Uygun düzenler, daha önce açıklandığı gibi genişlik aralarını kullanır.

<!-- res/layout/main_activity.xml -->

<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <!-- content view(s) -->

    <com.google.android.material.bottomappbar.BottomAppBar
        android:layout_width="wrap_content"
        android:layout_height="0dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        ... />
</androidx.constraintlayout.widget.ConstraintLayout>


<!-- res/layout-w600dp/main_activity.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.appbar.AppBarLayout
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        ... />

    <!-- content view(s) -->
</androidx.constraintlayout.widget.ConstraintLayout>

İçerik

Kalıcı kullanıcı arayüzü öğelerinizi yerleştirdikten sonra kalan alanı içerik için kullanın. Örneğin, uygulamanızın gezinme grafiğiyle birlikte bir NavHostFragment kullanın. Diğer hususlar için Duyarlı kullanıcı arayüzleri için gezinme bölümüne bakın.

Tüm verilerin farklı boyutlar için kullanılabildiğinden emin olun

Günümüzde çoğu uygulama çerçevesi, kullanıcı arayüzüne katkıda bulunan Android bileşenlerinden (etkinlikler, parçalar ve görünümler) ayrı bir veri modeli kullanır. Jetpack'te bu rol genellikle yapılandırma değişikliklerinde hayatta kalma avantajına sahip ViewModel'ler tarafından yerine getirilir (daha fazla bilgi için ViewModel'e Genel Bakış başlıklı makaleyi inceleyin).

Farklı boyutlara uyum sağlayan bir düzen uygularken mevcut boyuta göre farklı bir veri modeli kullanmak cazip gelebilir. Ancak bu, tek yönlü veri akışı ilkesine aykırıdır. Veriler Görüntüleme'ye doğru aşağı doğru, kullanıcı etkileşimleri gibi etkinlikler ise yukarı doğru akmalıdır. Veri modelinin kullanıcı arayüzü katmanının yapılandırmasına bağlı olduğu diğer yönde bir bağımlılık oluşturmak bu durumu önemli ölçüde karmaşık hale getirir. Uygulamanın boyutu değiştiğinde bir veri modelinden diğerine geçişi hesaba katmanız gerekir.

Bunun yerine, veri modelinizin en büyük boyut sınıfını barındırmasına izin verin. Ardından, mevcut boyut sınıfına uyum sağlamak için kullanıcı arayüzündeki içeriği seçerek gösterebilir, gizleyebilir veya yeniden konumlandırabilirsiniz. Boyut sınıfları arasında geçiş yaparken düzeninizin nasıl davranması gerektiğine karar verirken kullanabileceğiniz birkaç strateji aşağıda verilmiştir.

İçeriği genişletme

Standart düzenler: Feed

Daha fazla alan, öğeleri büyütmek ve içeriğinizi daha erişilebilir olacak şekilde yeniden biçimlendirmek için bir fırsat olabilir.

Koleksiyonları büyütebilirsiniz. Birçok uygulama, RecyclerView veya ScrollView gibi kaydırılabilir bir kapsayıcıda öğe koleksiyonu gösterir. Bir kapsayıcının otomatik olarak daha büyük hale gelmesi, daha fazla içeriğin gösterilebileceği anlamına gelir. Ancak kapsayıcıdaki içeriğin aşırı derecede uzatılmamasına veya bozulmamasına dikkat edin. Örneğin, RecyclerView için GridLayoutManager, StaggeredGridLayoutManager veya FlexboxLayout gibi farklı bir düzen yöneticisi kullanabilirsiniz.

Şekil 2. Farklı pencere boyutu sınıfları için farklı düzen yöneticileri.

Ayrı öğeler, daha fazla içerik görüntülemek ve öğe sınırlarını daha kolay ayırt etmek için farklı bir boyut veya şekil de kullanabilir.

Bir asıl öğeyi vurgulayın. Düzenin resim veya video gibi belirli bir odak noktası varsa kullanıcının dikkatini korumak için uygulama penceresi büyüdüğünde bu odağı genişletin. Diğer destekleyici öğeler, hero görünümünün etrafında veya altında yeniden düzenlenebilir.

Bu tür bir düzen oluşturmanın birçok yolu vardır ancak ConstraintLayout, alt görünümün boyutunu yüzdeye göre veya en boy oranını zorunlu kılarak kısıtlamanın ve alt görünümleri kendisine veya diğer alt görünümlere göre konumlandırmanın birçok yolunu sunduğundan bu amaç için özellikle uygundur. Tüm bu özellikler hakkında daha fazla bilgiyi ConstraintLayout ile duyarlı kullanıcı arayüzü oluşturma başlıklı makalede bulabilirsiniz.

Daraltılabilir içeriği varsayılan olarak gösterin. Yer varsa dokunma, kaydırma veya hareketler gibi ek kullanıcı etkileşimleriyle erişilebilen içerikleri gösterin. Örneğin, kompakt moddayken sekmeli bir arayüzde görünen içerik, daha fazla alan olduğunda sütunlara veya bir listeye yeniden düzenlenebilir.

Kenar boşluklarını genişletin. Alan o kadar genişse tüm içeriğinizi kullandıktan sonra bile ilgi çekici bir uyum bulamıyorsanız içeriğin ortada kalması ve her bir görünümün doğal boyutlara ve aralarında boşluk bulunması için düzenin kenar boşluklarını genişletin.

Alternatif olarak, tam ekran bileşenler yüzen iletişim kutusu kullanıcı arayüzüne dönüştürülebilir. Bu yöntem, özellikle de ilgili bileşenin acil bir kullanıcı görevini (ör. e-posta oluşturma veya takvim etkinliği oluşturma) yerine getirmek için özel odaklanma gerektirdiği durumlarda çok uygundur.

Şekil 3. Tam ekran iletişim kutusu, orta ve genişletilmiş genişlikte standart bir iletişim kutusuna dönüştürüldü.

İçerik ekle

Standart düzenler: Destekleyici bölme, Liste-ayrıntı görünümü

Destekleyici bir bölme kullanın. Destekleyici bölmede, birincil içerikle ilgili ek içerik veya bağlama dayalı işlemler (ör. bir dokümandaki yorumlar veya oynatma listesindeki öğeler) gösterilir. Bu reklamlar genellikle genişletilmiş yükseklik için ekranın alt üçte birini veya genişletilmiş genişlik için son üçte birini kullanır.

Bölme gösterilecek yeterli alan olmadığında bu içeriğin nereye yerleştirileceği önemli bir konudur. Aşağıda inceleyebileceğiniz bazı alternatifler verilmiştir:

• DrawerLayout kullanarak arka kenardaki yan çekmece
• BottomSheetBehavior kullanan alt çekmece
• Menü simgesine dokunarak erişilebilen menü veya pop-up pencere

Şekil 4. Ek içeriği destekleyici bir bölmede sunmanın alternatif yolları.

İki bölmeli bir düzen oluşturun. Büyük ekranlarda, genellikle küçük ekranlarda ayrı olarak görünen özelliklerin bir kombinasyonu gösterilebilir. Birçok uygulamada, kişiler veya arama sonuçları gibi öğelerin listesini göstermek ve öğe seçildiğinde öğenin ayrıntılarına geçmek yaygın bir etkileşim kalıbıdır. Listeyi büyük ekranlar için büyütmek yerine, her iki özelliği de iki bölmeli bir düzende yan yana göstermek için liste ayrıntıları görünümünü kullanın. Destekleyici bir bölmenin aksine, liste ayrıntıları görünümünün ayrıntı bölmesi, küçük ekranlarda bağımsız olarak gösterilebilen bağımsız bir öğedir.

Liste ayrıntıları görünümü uygulamak için SlidingPaneLayout özel widget'ını kullanın. Bu widget, iki bölme için belirtilen layout_width değerine göre her iki bölmeyi birlikte görüntülemek için yeterli yer olup olmadığını otomatik olarak hesaplar. Kalan alan layout_weight kullanılarak dağıtılabilir. Yeterli alan olmadığında her bölme, düzenin tam genişliğini kullanır ve ayrıntı bölmesi ekrandan kayar veya liste bölmesinin üstüne gelir.

Şekil 5. Genişletilmiş genişlikte iki bölme ve kompakt genişlikte bir bölme gösteren SlidingPaneLayout.

SlidingPaneLayout kullanımıyla ilgili daha fazla bilgi için İki bölmeli düzen oluşturma başlıklı makaleyi inceleyin. Bu kalıbın, gezinme grafiğinizi nasıl yapılandırdığınızı etkileyebileceğini de unutmayın (Duyarlı kullanıcı arayüzleri için gezinme bölümüne bakın).

Ek kaynaklar

• Materyal Tasarım — Düzen uygulama