Ich studiere derzeit Jetpack Compose, um eine funktionsreiche Anwendung mit modernen Android-Architekturkomponenten zu erstellen. Traditionell wäre jeder Bildschirm (oder jede Navigationseinheit) in meiner Anwendung entweder eine Aktivität oder ein Fragment mit jeweils eigenen Lebenszyklusbindungen, aber mit Jetpack Compose und der Compose-Navigationsbibliothek würde ich so etwas tun:
MainActivity.kt:
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
val navController = rememberNavController()
NavHost(navController = navController, startDestination = "main") {
composable("main") { MainScreen(navController) }
// More composable calls
}
}
}
}
Woher MainScreen ist nur ein Composable. Meine Fragen sind:
- Was ist hier das Äquivalent eines “Lebenszyklus” für dieses Composable? Angenommen, ich möchte eine Aktion ausführen, wenn der Bildschirm geladen wird, wenn er zerstört wird usw. Dies ist möglicherweise relevanter für den Fall, in dem ich mehrere Bildschirme habe und zwischen ihnen navigiere
- Gibt es eine Möglichkeit, zwischen Compose und Standardaktivitäten zu integrieren? Das heißt, definieren Sie Aktivitäten für Bildschirme so, wie Sie es tun würden, wobei jede Aktivität eine ist
ComponentActivity und ein eigenes zusammensetzbares Layout definieren? Wird dies aus irgendeinem Grund entmutigt?
Die Compose-Anwendung ist für die Verwendung in einer Einzelaktivitätsarchitektur ohne Fragmente konzipiert.
Sie können immer noch mehrere Aktivitäten oder Fragmente haben und verwenden setContent in jedem von ihnen, aber in diesem Fall fällt die Übertragung von Daten zwischen Aktivitäten auf Ihre Schultern. Verwenden Sie diesen Ansatz, wenn Sie neue Compose-Bildschirme zu einer vorhandenen Anwendung hinzufügen, die auf die alte Weise erstellt wurde.
Aber mit Compose ist es viel einfacher, die gesamte Navigation innerhalb einer einzigen Aktivität mit Compose Navigation durchzuführen. Viel weniger Code, bessere Performance durch Verzicht auf unnötige Code-Layer, einfach zu übertragende Daten etc.
Um mit dem Ansichtslebenszyklus zu arbeiten, check out Nebenwirkungen zusammenstellen:
LaunchedEffect kann verwendet werden, um eine Aktion auszuführen, wenn die Ansicht erscheint. Es wird auch in einem Coroutine-Kontext ausgeführt, der an das aktuelle Composable gebunden ist: Sie können problemlos Suspend-Funktionen ausführen, und wenn die Ansicht aus der Ansichtshierarchie verschwindet, wird die Coroutine abgebrochen.DisposableEffect kann verwendet werden, um Rückrufe zu abonnieren/abzubestellen.
Wenn Sie den Bildschirm drehen, werden alle Effekte neu gestartet, egal welche Taste Sie passiert haben.
@Composable
fun MainScreen(navController: NavController) {
LaunchedEffect(Unit) {
println("LaunchedEffect: entered main")
var i = 0
// Just an example of coroutines usage
// don't use this way to track screen disappearance
// DisposableEffect is better for this
try {
while (true) {
delay(1000)
println("LaunchedEffect: ${i++} sec passed")
}
} catch (cancel: CancellationException) {
println("LaunchedEffect: job cancelled")
}
}
DisposableEffect(Unit) {
println("DisposableEffect: entered main")
onDispose {
println("DisposableEffect: exited main")
}
}
}
Beachten Sie auch, dass Sie in beiden Fällen und in vielen anderen Fällen in compose bestehen key zu diesen Funktionen. Dies hilft Compose zu verstehen, wann der Wert neu berechnet werden sollte. In meinem Beispiel ist es Unit, was bedeutet, dass es sich nicht ändert, bis die Ansicht weg ist. Aber wenn Sie eine erstellen remember Wert, verwenden Sie einen anderen dynamischen Wert aus dem Ansichtsmodell oder übergeben Sie ein anderes Argument an Composable, Sie können es als übergeben keywird dies den Strom abbrechen LaunchedEffect Job und Anruf onDispose zum DisposableEffectund Ihr Job wird mit der aktualisierten neu gestartet key Wert. Sie können so viele Schlüssel übergeben, wie Sie möchten.
Lesen Sie mehr über den Status in Compose in Dokumentation.
