I am trying to convert a view based screen to Compose and while what I need should be very basic, somehow I can’t get this to work. The use case at hand is a serial task where one step follows the other and the UI should reflect progress. But I seem to miss something fundamental because none of my Text() will update. Below is a simplified example of what I got:

    override fun onCreate(savedInstanceState: Bundle?) {
        …
        
        setContent {
            Import()
        }
    }
    
    
    @Composable
    fun Import() {        
        var step1 by remember { mutableStateOf("") }
        var step2 by remember { mutableStateOf("") }
          
        Column() {
                Text(text = step1)
                Text(text = step2)
            }
        }

        step1 = "Open ZIP file"
        val zipIn: ZipInputStream = openZIPFile()
        step1 = "✓ $step1"
    
        step2 = "Extract files"
        val count = extractFiles()
        step2 = "✓ $step2"
        …
    }

If I set the initial text in the remember line, like this

var step1 by remember { mutableStateOf("Open ZIP file") }

the text will show, but also never gets updated.

I also tried to move the logic part into a separate function which gets executed right after setContent() but then the step1/step2 aren’t available for me to update.

#######

Edit:

Well, as expected this turned out to be really easy. I have to break this one

var step1 by remember { mutableStateOf("Open ZIP file") }

into 2 statements:

var step1String =  mutableStateOf("Open ZIP file")

With step1String as a class wide variable so I can change it from other functions. In the Import() composable function al I need is this:

var step1 by remember { step1String }

Have to say Compose is growing on me… :-)

  • dan0
    1·
    1 year ago

    I would make sure to use the IO dispatcher instead and probably a lifecycle scope.

    • Thomas@lemmy.zell-mbc.comOP
      1·
      1 year ago

      Ha, thank you. I didn’t even realize that there is such granularity in dispatchers. Changed accordingly 👍 I assume the IO dispatcher is somehow more efficient when it comes to IO tasks?

      Would you care to elaborate about the lifecycle scope? I somehow don’t seem to be able to add the dependency and am not sure how this is going to improve things? Is this about making sure that the coroutine does or doesn’t get canceled in case the user quits the activity before the import is complete?

      //        LifecycleCoroutineScope(Dispatchers.IO).launch {
//        LifecycleScope(Dispatchers.IO).launch {
        CoroutineScope(Dispatchers.IO).launch {
            importLogic()
        }
      • dan0
        2·
        1 year ago

        For the dispatchers, the docs do a better job explaining then I should try to give, but in short IO is optimized for long running operations, whereas Default is optimized for running more intensive computations.

        For the lifecycle scope that’s basically it. Fragments, Activities, and ViewModels all have their own variants of this. It’s almost always bad practice to have a coroutine not scoped to some form of lifecycle or you could easily end up with a bunch of memory leaks and unreported issues (https://kotlinlang.org/docs/coroutines-basics.html#structured-concurrency).