Multiple requests occur after configuration changes (rotate device)

[davekaro]

I have my own Turbo Native android app, that I was using the ViewFlipper for to handle bottom tab navigation. However, I noticed the same issues you brought up in #12. I saw your new implementation using supportFragmentManager and tried to implement in my app as well, but I discovered a new issue. I decided to run black candy locally to see if the same issue exists and it did. Here is what I am seeing:

1. Launch the app and sign in
2. Click the Library tab, observe the Rails logs show a single request to /library
3. Rotate the device (I'm using the emulator)
4. Observe the Rails logs now show a request for / and /library
5. Rotate the device again
6. Observe multiple requests to /library - each subsequent device rotation will increase the number of requests to /library every time.

I was able to debug to the point where I saw that in the MainActivity the libraryNavFragment is coming back as null after a device rotation, and therefore we call delegate.registerNavHostFragment(R.id.library_container) again, but the old "nav host fragment" must still be hanging around and executed somehow. I don't understand enough about Android and Turbo Native to have any good solutions. Do you have any ideas?

[aidewoode]

I have investigated a bit about the issue. I've found out the source of the issue is val libraryNavFragment = supportFragmentManager.findFragmentById(viewModel.libraryNav.id) always return null even the fragment has already been added to the fragment container. And that will cause fragment to be added again and again with supportFragmentManager, so there will be multiple same requests after configuration changed.

The correct way to determine the library fragment is added or not is using val libraryNavFragment = binding.libraryContainer.getFragment<LibraryNavHostFragment?>()

[davekaro]

Thanks! I can confirm this works. I think the key is using the navHostFragment function, and catching the exception to then register the fragment. Then, you can still use supportFragmentManager like:

val libraryNavFragment = supportFragmentManager.findFragmentById(R.id.library_container)

I don't have a solid mental model for how Android creates views, but I just noticed while debugging that the R.id.library_container id was always the same as the viewModel.libraryNav.id but only after having added it with

supportFragmentManager.commitNow {
  add(R.id.library_container, viewModel.libraryNav)
}

But binding.libraryContainer.getFragment<LibraryNavHostFragment?>() works too and feels more explicit. Anyways, this is a huge improvement I think. I'm still seeing all the tabs reload after orientation changes, but only the tabs you have previously selected, so much less concerning.

[aidewoode]

I'm still seeing all the tabs reload after orientation changes

I believe it's the behavior of android webview see: https://stackoverflow.com/questions/1002085/android-webview-handling-orientation-changes . Android webview will reload when configuration
changed. There are a lot of solutions to handle this issue, I need to find the best one that work with turbo-android.