Android UI Development with Jetpack Compose by Thomas Künneth

Author:Thomas Künneth [Thomas Künneth]
Language: eng
Format: epub, pdf
Publisher: Packt Publishing
Published: 2022-02-21T00:00:00+00:00

Surviving configuration changes

Please recall that our definition of state as data that may change over time is quite broad. For example, we do not specify where the data is stored. If it resides in a database, a file, or some backend in the cloud, the app should include a dedicated persistence layer. However, until Google introduced the Android Architecture Components back in 2017, there had been practically no guidance for developers on how to structure their apps. Consequently, persistence code, UI logic, and domain logic were often crammed into one activity. Such code was difficult to maintain and often prone to errors. To make matters a little more complicated, there are situations when an activity is destroyed and recreated shortly after. For example, this happens when a user rotates a device. Certainly, data should then be remembered.

The Activity class has a few methods to handle this. For example, onSaveInstanceState() is invoked when the activity is (temporarily) destroyed. Its counterpart onRestoreInstanceState() method is called only when such an instance state has been saved before. Both methods receive an instance of Bundle, which has getters and setters for various data types. However, the concept of instance state has been designed for the traditional view system. Most activities held references to UI elements and therefore could be accessed easily inside onSaveInstanceState() and onRestoreInstanceState().

Composables, on the other hand, are usually implemented as top-level functions. So, how can their state be set or queried from inside an activity? To temporarily save state in a Compose app, you can use rememberSaveable {}. This composable function remembers the value produced by a factory function. It behaves similarly to remember {}. The stored value will survive the activity or process recreation. Internally, the savedInstanceState mechanism is used. The sample ViewModelDemo app shows how to use rememberSaveable {}. Here's what the main activity looks like:

class ViewModelDemoActivity : ComponentActivity() {

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

setContent {

ViewModelDemo()

}

}

}

We don't need to override onSaveInstanceState() to temporarily save our state used with composables:

@Composable

@Preview

fun ViewModelDemo() {

...

val state1 = remember {

mutableStateOf("Hello #1")

}

val state2 = rememberSaveable {

mutableStateOf("Hello #2")

}

...

state3.value?.let {

Column(modifier = Modifier.fillMaxWidth()) {

MyTextField(state1) { state1.value = it }

MyTextField(state2) { state2.value = it }

...

}

}

}

The app shows three text input fields that receive their values from states assigned to state1, state2, and state3. For now, we will focus on the first two. state3 will be the subject of the Using ViewModel section. state1 invokes remember {}, whereas state2 uses rememberSaveable {}. If you ran ViewModelDemo, changed the content of the text input fields, and rotated the device, the first one would be reset to the original text, whereas the second one would keep your changes.

MyTextField is a very simple composable. It looks like this:

@Composable

fun MyTextField(

value: State<String?>,

onValueChange: (String) -> Unit

) {

value.value?.let {

TextField(

value = it,

onValueChange = onValueChange,

modifier = Modifier.fillMaxWidth()

)

}

}

Have you noticed that value is of State<String?>? Why would I need a value holder whose value can be null, and therefore need to check with value.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.