Görünümler'den Compose'a geçiş tamamen kullanıcı arayüzüyle ilgili olsa da güvenli ve artımlı bir taşıma gerçekleştirmek için dikkate alınması gereken birçok nokta vardır. Bu sayfada, görüntülemeye dayalı uygulamanızı Compose'a taşırken dikkate almanız gereken bazı noktalar açıklanmaktadır.
Uygulamanızın temasını taşıma
Android uygulamalarında tema oluşturmak için önerilen tasarım sistemi Materyal Tasarım'dır.
Görüntü tabanlı uygulamalar için üç Material sürümü mevcuttur:
- AppCompat kitaplığının kullanıldığı Materyal Tasarım 1 (ör.
Theme.AppCompat.*
) - MDC-Android kitaplığını (ör.
Theme.MaterialComponents.*
) kullanan Materyal Tasarım 2 - MDC-Android kitaplığını (ör.
Theme.Material3.*
) kullanan Material Design 3
Oluşturma uygulamaları için Material'ın iki sürümü vardır:
- Compose Material kitaplığını (ör.
androidx.compose.material.MaterialTheme
) kullanan Material Design 2 - Compose Material 3 kitaplığını kullanan Materyal Tasarım 3 (ör.
androidx.compose.material3.MaterialTheme
)
Uygulamanızın tasarım sistemi bunu yapabilecek durumdaysa en son sürümü (Material 3) kullanmanızı öneririz. Hem Görünümler hem de Oluştur için taşıma kılavuzları mevcuttur:
- Görünümlerde 1. Malzeme ile 2. Malzeme Arasında
- Görünümlerde 2. Malzeme ile 3. Malzeme Arasında
- Oluştur'da 2. Malzeme'den 3. Malzeme'ye
Compose'da yeni ekranlar oluştururken, hangi Material Design sürümünü kullandığınızdan bağımsız olarak Compose Material kitaplıklarından kullanıcı arayüzü yayınlayan tüm derlenebilir öğelerin önüne bir MaterialTheme
uyguladığınızdan emin olun. Malzeme bileşenleri (Button
, Text
vb.), bir MaterialTheme
öğesinin mevcut olmasına bağlıdır ve bu bileşen olmadan davranışları tanımlanamaz.
Tüm Jetpack Compose örnekleri, MaterialTheme
üzerine inşa edilmiş özel bir Compose teması kullanır.
Daha fazla bilgi edinmek için Compose'daki tasarım sistemleri ve XML temalarını Compose'a taşıma sayfalarına göz atın.
Navigasyon
Uygulamanızda Gezinme bileşenini kullanıyorsanız daha fazla bilgi için Compose ile Gezinme - Birlikte Çalışabilirlik ve Jetpack Gezinmeyi Gezinme Oluşturmaya Taşıma konularına bakın.
Karma Oluştur/Görüntülemeler kullanıcı arayüzünüzü test etme
Uygulamanızın bazı bölümlerini Compose'a taşıdıktan sonra, herhangi bir sorun yaşamadığınızdan emin olmak için test yapmanız önemlidir.
Bir etkinlik veya parça Compose'u kullandığında ActivityScenarioRule
yerine createAndroidComposeRule
kullanmanız gerekir. createAndroidComposeRule
, kod oluşturma ve kod görüntüleme işlemlerini aynı anda test etmenizi sağlayan bir ComposeTestRule
ile ActivityScenarioRule
'i entegre eder.
class MyActivityTest { @Rule @JvmField val composeTestRule = createAndroidComposeRule<MyActivity>() @Test fun testGreeting() { val greeting = InstrumentationRegistry.getInstrumentation() .targetContext.resources.getString(R.string.greeting) composeTestRule.onNodeWithText(greeting).assertIsDisplayed() } }
Test hakkında daha fazla bilgi edinmek için Oluşturma düzeninizi test etme başlıklı makaleyi inceleyin. Kullanıcı arayüzü test çerçeveleriyle birlikte çalışabilirlik için Espresso ile birlikte çalışabilirlik ve UiAutomator ile birlikte çalışabilirlik konularını inceleyin.
Compose'u mevcut uygulama mimarinizle entegre etme
Tek Yönlü Veri Akışı (UDF) mimari kalıpları, Compose ile sorunsuz bir şekilde çalışır. Uygulamada bunun yerine Model View Presenter (MVP) gibi başka mimari kalıpları kullanılıyorsa Compose'u kullanmaya başlamadan önce veya bu işlemi yaparken kullanıcı arayüzünün bu bölümünü UDF'ye taşımanızı öneririz.
Oluşturma'da ViewModel
kullanma
Mimari BileşenleriViewModel
kitaplığını kullanırsanız Oluşturma ve diğer kitaplıklar bölümünde açıklandığı gibi viewModel()
işlevini çağırarak herhangi bir composable'dan ViewModel
öğesine erişebilirsiniz.
Oluştur'u benimserken ViewModel
öğelerinin görüntüleme yaşam döngüsü kapsamlarını izlemesi nedeniyle farklı composable'larda aynı ViewModel
türünün kullanılmasına dikkat edin. Kapsam, ana makine etkinliği, parça veya Gezinme kitaplığı kullanılıyorsa gezinme grafiği olacaktır.
Örneğin, composable'lar bir etkinlik içinde barındırılıyorsa viewModel()
, yalnızca etkinlik tamamlandığında silinen aynı örneği her zaman döndürür.
Aşağıdaki örnekte, ana makine etkinliği altındaki tüm composable'larda aynı GreetingViewModel
örneği yeniden kullanıldığından aynı kullanıcı ("user1") iki kez karşılanır. Oluşturulan ilk ViewModel
örneği, diğer composable'larda yeniden kullanılır.
class GreetingActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { MaterialTheme { Column { GreetingScreen("user1") GreetingScreen("user2") } } } } } @Composable fun GreetingScreen( userId: String, viewModel: GreetingViewModel = viewModel( factory = GreetingViewModelFactory(userId) ) ) { val messageUser by viewModel.message.observeAsState("") Text(messageUser) } class GreetingViewModel(private val userId: String) : ViewModel() { private val _message = MutableLiveData("Hi $userId") val message: LiveData<String> = _message } class GreetingViewModelFactory(private val userId: String) : ViewModelProvider.Factory { @Suppress("UNCHECKED_CAST") override fun <T : ViewModel> create(modelClass: Class<T>): T { return GreetingViewModel(userId) as T } }
Navigasyon grafikleri ViewModel
öğelerini de kapsama aldığından, bir navigasyon grafiğinde hedef olan derlenebilir öğeler ViewModel
öğesinin farklı bir örneğine sahiptir.
Bu durumda ViewModel
, hedefin yaşam döngüsü kapsamına alınır ve hedef arka yığıntan kaldırıldığında temizlenir. Aşağıdaki örnekte, kullanıcı Profil ekranına gittiğinde yeni bir GreetingViewModel
örneği oluşturulur.
@Composable fun MyApp() { NavHost(rememberNavController(), startDestination = "profile/{userId}") { /* ... */ composable("profile/{userId}") { backStackEntry -> GreetingScreen(backStackEntry.arguments?.getString("userId") ?: "") } } }
Doğru bilgi kaynağı
Oluştur'u kullanıcı arayüzünün bir bölümünde kullandığınızda, Compose ve View sistem kodunun verileri paylaşması gerekebilir. Mümkün olduğunda bu paylaşılan durumu, her iki platform tarafından kullanılan UDF en iyi uygulamalarını kullanan başka bir sınıfta (ör. veri güncellemeleri yaymak için paylaşılan veri akışını sunan bir ViewModel
içinde) kapsamanızı öneririz.
Ancak paylaşılacak veriler değiştirilebilirse veya bir kullanıcı arayüzü öğesine sıkıca bağlıysa bu her zaman mümkün olmayabilir. Bu durumda, bir sistem doğruluk kaynağı olmalı ve bu sistemin diğer sistemle veri güncellemelerini paylaşması gerekir. Genel bir kural olarak, doğru bilgi kaynağı, kullanıcı arayüzü hiyerarşisinin köküne daha yakın olan öğeye ait olmalıdır.
Doğru bilgi kaynağı olarak yazın
Oluşturma durumunu Compose dışı bir koda yayınlamak için SideEffect
composable'ı kullanın. Bu durumda, doğruluk kaynağı, durum güncellemeleri gönderen bir bileşende tutulur.
Örneğin, analiz kitaplığınız, sonraki tüm analiz etkinliklerine özel meta veriler (bu örnekte kullanıcı özellikleri) ekleyerek kullanıcı kitlenizi segmentlere ayırmanıza olanak tanıyabilir. Mevcut kullanıcının kullanıcı türünü analiz kitaplığınıza iletmek için değerini güncellemek üzere SideEffect
kullanın.
@Composable fun rememberFirebaseAnalytics(user: User): FirebaseAnalytics { val analytics: FirebaseAnalytics = remember { FirebaseAnalytics() } // On every successful composition, update FirebaseAnalytics with // the userType from the current User, ensuring that future analytics // events have this metadata attached SideEffect { analytics.setUserProperty("userType", user.userType) } return analytics }
Daha fazla bilgi için Compose'da yan etkiler bölümüne bakın.
Bilgi kaynağı olarak sistemi göster
Görünüm sistemi eyalete aitse ve E-posta Oluşturma ile paylaşıyorsa durumu, Compose için iş parçacığı açısından güvenli hale getirmek amacıyla mutableStateOf
nesne için sarmalamanızı öneririz. Bu yaklaşımı kullanırsanız composable işlevler basitleştirilmiştir çünkü artık doğru kaynağa sahip değildirler, ancak View sisteminin, değişken durumu ve bu durumu kullanan görünümleri güncellemesi gerekir.
Aşağıdaki örnekte, bir CustomViewGroup
içinde bir TextView
ve TextField
bileşeni içeren bir ComposeView
yer almaktadır. TextView
, kullanıcının TextField
ürününde yazdığı içeriği göstermelidir.
class CustomViewGroup @JvmOverloads constructor( context: Context, attrs: AttributeSet? = null, defStyle: Int = 0 ) : LinearLayout(context, attrs, defStyle) { // Source of truth in the View system as mutableStateOf // to make it thread-safe for Compose private var text by mutableStateOf("") private val textView: TextView init { orientation = VERTICAL textView = TextView(context) val composeView = ComposeView(context).apply { setContent { MaterialTheme { TextField(value = text, onValueChange = { updateState(it) }) } } } addView(textView) addView(composeView) } // Update both the source of truth and the TextView private fun updateState(newValue: String) { text = newValue textView.text = newValue } }
Paylaşılan kullanıcı arayüzü taşınıyor
Kademeli olarak Compose'a geçiş yapıyorsanız hem Compose hem de View sisteminde paylaşılan kullanıcı arayüzü öğeleri kullanmanız gerekebilir. Örneğin, uygulamanızda özel bir CallToActionButton
bileşeni varsa bunu hem Oluşturma hem de Görüntüleme tabanlı ekranlarda kullanmanız gerekebilir.
Oluşturma'da, paylaşılan kullanıcı arayüzü öğeleri, XML kullanılarak stilize edilmiş veya özel görünümlü olup olmadığına bakılmaksızın uygulama genelinde yeniden kullanılabilen bileşenler haline gelir. Örneğin, özel harekete geçirici mesaj Button
bileşeni için bir CallToActionButton
composable'ı oluşturursunuz.
Kompozitleri görünüm tabanlı ekranlarda kullanmak için AbstractComposeView
'ten başlayan özel bir görünüm sarmalayıcısı oluşturun. Oluşturduğunuz composable'ı, geçersiz kılınan Content
composable'a aşağıdaki örnekte gösterildiği gibi Compose temanıza sarmalanmış olarak yerleştirin:
@Composable fun CallToActionButton( text: String, onClick: () -> Unit, modifier: Modifier = Modifier, ) { Button( colors = ButtonDefaults.buttonColors( containerColor = MaterialTheme.colorScheme.secondary ), onClick = onClick, modifier = modifier, ) { Text(text) } } class CallToActionViewButton @JvmOverloads constructor( context: Context, attrs: AttributeSet? = null, defStyle: Int = 0 ) : AbstractComposeView(context, attrs, defStyle) { var text by mutableStateOf("") var onClick by mutableStateOf({}) @Composable override fun Content() { YourAppTheme { CallToActionButton(text, onClick) } } }
Oluşturulabilir parametrelerin, özel görünüm içinde değişebilir değişkenler haline geldiğine dikkat edin. Bu sayede özel CallToActionViewButton
görünümü, geleneksel bir görünüm gibi şişirilebilir ve kullanılabilir hale gelir. Aşağıda, Görüntü Bağlantısı ile ilgili bir örneğe bakın:
class ViewBindingActivity : ComponentActivity() { private lateinit var binding: ActivityExampleBinding override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) binding = ActivityExampleBinding.inflate(layoutInflater) setContentView(binding.root) binding.callToAction.apply { text = getString(R.string.greeting) onClick = { /* Do something */ } } } }
Özel bileşen değişken durum içeriyorsa Durum ve doğruluk kaynağı bölümüne bakın.
Sunudan bölme durumuna öncelik verme
Geleneksel olarak View
durum bilgisine sahiptir. View
, ne gösterileceğini ve nasıl gösterileceğini açıklayan alanları yönetir. Bir View
öğesini Compose'a dönüştürdüğünüzde, durum kaldırma bölümünde daha ayrıntılı açıklandığı şekilde tek yönlü bir veri akışı gerçekleştirmek için oluşturulan verileri ayırmaya bakın.
Örneğin, bir View
öğesinin görünür, görünmez veya kaldırılmış olup olmadığını belirten bir visibility
özelliği vardır. Bu, View
'ün doğal bir özelliğidir. Diğer kod parçaları bir View
öğesinin görünürlüğünü değiştirebilir ancak mevcut görünürlüğünü gerçekten bilen tek öğe View
'dir. Bir View
öğesinin görünür olmasını sağlama mantığı hataya açık olabilir ve genellikle View
öğesine bağlıdır.
Buna karşılık Compose, Kotlin'de koşullu mantık kullanarak tamamen farklı kompozisyonlar göstermeyi kolaylaştırır:
@Composable fun MyComposable(showCautionIcon: Boolean) { if (showCautionIcon) { CautionIcon(/* ... */) } }
Tasarım gereği, CautionIcon
'ün neden gösterildiğini bilmesi veya dikkate alması gerekmez ve visibility
kavramı yoktur: Kompozisyon'da ya vardır ya da yoktur.
Durum yönetimini ve sunum mantığını net bir şekilde ayırarak, durumu kullanıcı arayüzüne dönüştürme işlemi olarak içeriği nasıl görüntülediğinizi daha özgürce değiştirebilirsiniz. Eyalet sahipliği daha esnek olduğundan, gerektiğinde kaldıraç duruma getirebilme olanağı, composable'ları yeniden kullanılabilir hale de getirir.
Kapsüllenmiş ve yeniden kullanılabilir bileşenleri tanıtma
View
öğeleri genellikle nerede bulundukları hakkında bir fikir sahibidir: Activity
, Dialog
, Fragment
veya başka bir View
hiyerarşisinin içinde bir yerde. Genellikle statik düzen dosyalarından şişirildiği için View
'lerin genel yapısı çok katı olma eğilimindedir. Bu, daha sıkı bağlantı sağlar ve View
öğesinin değiştirilmesini veya yeniden kullanılmasını zorlaştırır.
Örneğin, özel bir View
, belirli bir kimliğe sahip belirli bir türde alt görünüme sahip olduğunu varsayabilir ve bir işleme yanıt olarak özelliklerini doğrudan değiştirebilir. Böylece, söz konusu View
öğeleri sıkı bir şekilde bağlanır: Özel View
, alt öğeyi bulamıyorsa kilitlenebilir veya bozulabilir ve alt öğe, büyük olasılıkla özel View
üst öğesi olmadan yeniden kullanılamaz.
Bu, yeniden kullanılabilir composable'larla Compose'da daha az sorun yaşanır. Ebeveynler, durumu ve geri çağırmayı kolayca belirtebilir. Böylece, kullanılacak yeri tam olarak bilmek zorunda kalmadan yeniden kullanılabilir composable'lar yazabilirsiniz.
@Composable fun AScreen() { var isEnabled by rememberSaveable { mutableStateOf(false) } Column { ImageWithEnabledOverlay(isEnabled) ControlPanelWithToggle( isEnabled = isEnabled, onEnabledChanged = { isEnabled = it } ) } }
Yukarıdaki örnekte, üç parça da daha kapsüllenmiş ve daha az ilişkilidir:
ImageWithEnabledOverlay
'nin yalnızca mevcutisEnabled
durumunu bilmesi gerekir.ControlPanelWithToggle
'nin var olduğunu veya nasıl kontrol edilebileceğini bilmesi gerekmez.ControlPanelWithToggle
,ImageWithEnabledOverlay
alanının varlığından haberdar değil.isEnabled
'ün sıfır, bir veya daha fazla şekilde gösterilmesi mümkündür veControlPanelWithToggle
'ün değişmesi gerekmez.Üst ağ için,
ImageWithEnabledOverlay
veyaControlPanelWithToggle
öğesinin ne kadar derin bir şekilde iç içe yerleştirilmiş olduğu önemli değildir. Bu çocuklar, değişikliklere animasyon katıyor, içeriği değiştiriyor veya içeriği başka çocuklara veriyor olabilir.
Bu kalıp, kontrolün ters çevrilmesi olarak bilinir. Bununla ilgili daha fazla bilgiyi CompositionLocal
belgelerinde bulabilirsiniz.
Ekran boyutu değişikliklerini işleme
Farklı pencere boyutları için farklı kaynaklara sahip olmak, duyarlı View
düzenleri oluşturmanın ana yollarından biridir. Ekran düzeyinde düzen kararları için uygun kaynaklar kullanılmaya devam etse de Compose, normal koşullu mantıkla düzenleri tamamen kodda değiştirmeyi çok daha kolay hale getirir. Daha fazla bilgi edinmek için Pencere boyutu sınıflarını kullanma bölümüne bakın.
Ayrıca, Compose'un uyarlanabilir kullanıcı arayüzleri oluşturmak için sunduğu teknikler hakkında bilgi edinmek üzere Farklı ekran boyutlarını destekleme başlıklı makaleyi inceleyin.
Görünümler ile iç içe kaydırma
Kaydırılabilir View öğeleri ve her iki yönde iç içe yerleştirilmiş kaydırılabilir composable'lar arasında iç içe kaydırma birlikte çalışmasını etkinleştirme hakkında daha fazla bilgi için İç içe kaydırma birlikte çalışabilirliği makalesini okuyun.
RecyclerView
uygulamasında oluştur
RecyclerView
'teki Composables, RecyclerView
1.3.0-alpha02 sürümünden beri performanslıdır. Bu avantajları görebilmek için RecyclerView
uygulamasının en az 1.3.0-alpha02 sürümünü kullandığınızdan emin olun.
WindowInsets
, Görünümler ile birlikte çalışabilir
Ekranınızda aynı hiyerarşide hem Görünümler hem de Oluştur kodu varsa varsayılan iç içe eklemeleri geçersiz kılmanız gerekebilir. Bu durumda, hangi öğenin içe yerleştirilenleri kullanması ve hangi öğenin bunları yoksaması gerektiğini açıkça belirtmeniz gerekir.
Örneğin, en dıştaki düzeniniz bir Android View düzeniyse View sisteminde iç içe yerleştirilen öğeleri kullanmanız ve Oluştur için bunları yok saymanız gerekir.
Alternatif olarak, en dıştaki düzeniniz bir composable ise Compose'da ek öğeleri kullanmalı ve AndroidView
composable'ı buna uygun şekilde doldurmalısınız.
Varsayılan olarak her ComposeView
, tüm iç metinleri WindowInsetsCompat
tüketim düzeyinde tüketir. Bu varsayılan davranışı değiştirmek için ComposeView.consumeWindowInsets
değerini false
olarak ayarlayın.
Daha fazla bilgi için E-posta Yazma'da WindowInsets
dokümanlarını okuyun.
Sizin için önerilenler
- Not: JavaScript kapalıyken bağlantı metni gösterilir
- Emoji gösterme
- Compose'da Materyal Tasarım 2
- Oluştur'daki pencere iç içe eklemeleri