DialogFragment

[DAKolesnikov]

• Cicerone Version: 6.6

• This discussion is a continuation of the issue DialogFragment support? #106

• Sorry for long read)

We need dialogs

I agree with @terrakok's point of view. DialogFragmen are not navigation screen. Despite being called Fragmen, DialogFragmen has different interface.

But I disagree that Dialog should not be part of Cicerone. Look at it as a feature. Now I will try to explain my point of view.

For us - Android developers, Cicerone is a simple and powerful tool for app navigation from the ViewModel/Presenter. The library helps you forget about what you need "to keep in mind" all the time - Android Lifecycles.

Let's be honest, half of the opening and closing of screens occurs after asynchronous net response or cache saves events. Which are processed in the ViewModel/Presenter. Thus Cicerone becomes the core of the navigation layer.

Today, dialogs are increasingly used in the design of mobile app, in particular the material BottomSheetDialogFagment. They are used for product cards, share screens, option selection and ect, which contain actions. "Here's the design now do it". So to implement DialogFragment, you have to use WeakReferences, which look ugly next to Cicerone. I prefer more clean architecture in my code. So let's code it!

About DialogFragment

DialogFragment extends Fragment, which means that it can be used as a regular Fragment.

But if you use the show methods, Android put DialogFragment in window over Activity and show dialog.

DialogFragment#show(manager:FragmentManager, tag:String)
//or
DialogFragment#show(transaction:FragmentTransaction, tag:String)

Why should we betray FragmentManager? DialogFragment like other fragments is added to the FragmentManager list. You can check this by looking at FragmentManager#fragments after show dialog.

However, the dialog is not added to the backstack. This is quite logical, because the dialogs have a slightly different back navigation. You can close the dialog in 3 ways:

1. System back button. Window where dialog is displayed intercepts this event and closes it automatically. No need to handle onBackPressed in the Activity. Realy convenient.
2. User click outside the dialog. Works as system back button.
3. Closing the dialog after remove it from FragmentManager.

It doesn't matter how the dialog is closed, Dialog#dismiss() will be called and FragmentManager will remove the fragment from the list. You can see this in the method DialogFragment#dismissAllowingStateLoss. This works because DialogFragment implements DialogInterface.OnDismissListener and set itself into inner dialog mDialog.setOnCancelListener(this).

Anyway for close DialogFragment the use the dismiss methods.

DialogFragment#dismiss()
//or
DialogFragment#dismissAllowingStateLoss()

DialogFragment Cicerone integration

Create custom Screen

Сreate a custom screen to avoid unnecessary cast and not accidentally show the Activity as a dialog =)

// DialogScreen.kt
open class DialogScreen constructor(
    key: String,
    private val dialogCreator: Creator<FragmentFactory, DialogFragment>
) : FragmentScreen(key,
    object: Creator<FragmentFactory, Fragment> {
        override fun create(argument: FragmentFactory): Fragment {
            return dialogCreator.create(argument)
        }
    })
{
    fun createDialog(factory: FragmentFactory) : DialogFragment{
        return dialogCreator.create(factory)
    }
}

• Extending the FragmentScreen class.
• Adding the createDialog(factory: FragmentFactory) method that creates our DialogFragment. We also create an object in the constructor that creates a fragment for the FragmentScreen. You can not cast dialogCreator to Creator<FragmentFactory, Fragment>.
• You can use DialogScreen in the navigateTo, replacesceen, and other methods designed for fragment, because DialogScreen extends FragmentScreen and DialogFragment extends Fragment and can be used as a regular fragment.

As for me this code looks much better, but AppScreen is sealed.

// Not working in Cicerone =(
open class DialogScreen @JvmOverloads constructor(
        private val key: String? = null,
        private val dialogCreator: Creator<FragmentFactory, DialogFragment>
) : AppScreen() {
    override val screenKey: String get() = key ?: super.screenKey
    fun createDialog(factory: FragmentFactory) = dialogCreator.create(factory)
}

Create custom Command and Router

Just commands for show and close dialogs .

// DialogCommands.kt
data class ShowDialog(val screen: DialogScreen) : Command

data class CloseDialog(val screen: DialogScreen) : Command

// DialogRouter.kt
class DialogRouter : Router() {

    fun showDialog(screen: DialogScreen) = executeCommands(ShowDialog(screen))

    fun closeDialog(screen: DialogScreen) = executeCommands(CloseDialog(screen))
}

If you need more flexible work with dialog methods. I suggest adding flags to the commands. Look at Forward command in Cicerone.

// DialogCommands.kt
data class CloseDialog(
    val screen: DialogScreen,
    val allowingStateLoss: Boolean
) : Command

// DialogNavigator.kt
 protected open fun closeDialog(command: CloseDialog) {
   .....
        if(allowingStateLoss)
            dialog.dismissAllowingStateLoss()
   	else
   	    dialog.dismiss()
   ......
 }

Create custom Navigator

Let's create our own Navigator in which we implement methods for dialogs.

// DialogNavigator.kt
open class DialogNavigator(activity: FragmentActivity,
                      containerId: Int,
                      fragmentManager: FragmentManager = activity.supportFragmentManager,
                      fragmentFactory: FragmentFactory = fragmentManager.fragmentFactory) :
    AppNavigator(activity, containerId, fragmentManager, fragmentFactory){
 
    override fun applyCommand(command: Command) {
        when (command) {
            is CloseDialog -> closeDialog(command)
            is ShowDialog -> showDialog(command)
            else -> super.applyCommand(command)
        }
    }

    protected open fun showDialog(command: ShowDialog) {
        val tag = command.screen.screenKey
        val dialog = command.screen.createDialog(fragmentFactory)
        dialog.show(fragmentManager, tag)
    }

    protected open fun closeDialog(command: CloseDialog) {
        val tag = command.screen.screenKey
        val dialog = fragmentManager.findFragmentByTag(tag)
        if(dialog is DialogFragment)
            dialog.dismiss()
    }

}

• Extending the AppNavigator class.
• Override applyCommand to handle dialog events.
• For show and dismiss methods use attached fragmentManager.
• Use Screen#screenKey like a tag in FragmentManger. Note that it is not null

Usage

In MyDialogFragment add DialogScreen.

class MyDialogFragment : DialogFragment() {

    companion object {
        val screen =  DialogScreen("MyDialogFragment", object: Creator<FragmentFactory, DialogFragment> {

            override fun create(argument: FragmentFactory): DialogFragment {
                return MyDialogFragment()
            }
        })
    }
}

In MainActivity use DialogRouter and DialogNavigator.

class MainActivity : AppCompatActivity() {

    companion object{
        val cicerone = Cicerone.create(DialogRouter())
        val navigator = cicerone.getNavigatorHolder()
        val router = cicerone.router
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
      
        findViewById<Button>(R.id.show).setOnClickListener{
            router.showDialog(MyDialogFragment.screen) // show by click
        }
      
        findViewById<Button>(R.id.close).setOnClickListener{
            router.closeDialog(MyDialogFragment.screen) // close by click
        }
    }

    fun getNav():DialogNavigator{
        return DialogNavigator(this, R.id.frame)
    }

    override fun onResumeFragments() {
        super.onResumeFragments()
        navigator.setNavigator(getNav())
    }

    override fun onPause() {
        navigator.removeNavigator()
        super.onPause()
    }

}

Some notes and questions for @terrakok

1. Why AppScreen is sealed?

   I think creating custom screens will improve library usage. AppScreen - the navigation screen in the Android app. There are no others except Activity and Fragment.

   In my project, I animated several fragments in the same way. I marked them with a special empty interface, which I checked in setupFragmentTransaction. But the problem is that this fragment will always have this animation. The best way to avoid this is to make an AnimatedScreen, where you can specify how to animate the fragment.

2. Why don't you use FragmentManager#addOnBackStackChangedListener for localStackCopy?

That's all folks! Thanks for reading.

[terrakok]

Thank you for detail question! I like your points and will be think about support dialogs and other features.

[terrakok]

Some thoughts about dialogs:

• main scenario for dialog is ask user and receive answer (callback to the current screen or another listener). Any callback depends on lifecycle so unavailable in router.
• if router contains method for showing dialog it will provide strange scenario: show dialog then navigate to new screen in sequence. What does user expect to see on the screen?

1. I think if your dialog waits some user answer for the current screen then it is part of this screen (with lifecycle, callbacks and etc).
2. If dialog is just notification without callbacks then it maybe part of cicerone machinery but dualism between previous case will confuse users (I think).
3. If it is full-featured screen in navigation stack but looks like dialog then you can show your fragment via 'add' transaction with router.navigateTo(screen, clearContainer = false)