-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AppNavigator#setupFragmentTransaction
public signature compatibility
#149
Comments
This is good point. Sorry for changing this external API. class AnimatedScreen(
val animation: Any
) : FragmentScreen(
key = "AnimatedScreen",
fragmentCreator = { AnimatedScreen() }
) override fun setupFragmentTransaction(
screen: FragmentScreen,
fragmentTransaction: FragmentTransaction,
currentFragment: Fragment?,
nextFragment: Fragment
) {
if (screen is Screens.AnimatedScreen) {
val animationData = screen.animation
// some animation setup
}
} |
At the moment I'm going to move add/replace flag from command parameter to FragmentScreen property |
I think it's more right way cause FragmentScreen is class for description all parameters for opening new fragment: |
New version 7.0 has been published |
It's very nice to see the library fully rewritten in a pure Kotlin. I understand the need of reviewing some internal solutions in favor of better approaches, etc. However, I believe that public API should not be changed due to internal rewrite until there are specific technical reasons.
Currently, I'm talking about
AppNavigator#setupFragmentTransaction
which now has a reduced number of arguments in a signature. In most of the projects with Cicerone I've used this callback to setup generic animations along with shared transitions and achieved this by extending the commands with transition arguments. The new implementation of a navigator does not have this argument. Yes, the transitions/animations are a separate topic to discuss, but still, this is not about animations but transaction options in general. With the new callback signature, there is no good way to pass such options into a transaction. Fragment arguments may look like workaround but they are not supposed to store transaction options.You may suggest overriding
commitNewFragmentScreen
. This technically means copy-paste of this function with a slight change just for transaction options callback. I consider this as not a good solution eighter as instead of extending you are copying functionality and creating one more place to check on each library update (it may receive updates and fixes and you need to check this part manually).I'd like to suggest adding a command argument to the
setupFragmentTransaction
like in previous versions.The text was updated successfully, but these errors were encountered: