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
Added new result awaiting and setting ViewModel navigation #4848
base: develop
Are you sure you want to change the base?
Conversation
- survives Android restoration - does not use Task to await the result - uses callbacks to handle the result - 3 new navigation extensions - navigation with result put back into Playground
Thanks will have a look at reviewing this one soon. |
@Cheesebaron Can you say when you think you'll be looking at this? We are currently migrating a project and are considering whether to use the code from this PR or our own implementation from another project. (it's a similar strategy, but we would prefer to use framework features if possible. But unfortunately we can't wait that long anymore.) |
@picosmos |
Sorry, I won't rush a review just because someone needs it. This looks something that would be easy to add to your own presenter override or use an alternative. Even if it gets reviewed and merged in, there is no guarantee there is a release with this in soon either. I hope you understand :) |
Sure, that's the right way to do. I think we use our own implementation. |
✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)
Adds new
IMvxResultAwaitingViewModel<TResult>
andIMvxResultSettingViewModel<TResult>
interfaces and corresponding abstract classes to create a result navigation contract between the awaiting and setting the result ViewModels. Under the hood it uses a newIMvxResultViewModelManager
that registers, unregisters and sets the result to the registered result awaiting ViewModels.It's better to use predefined abstract classes
MvxResultAwaitingViewModel<TResult>
,MvxMultiResultAwaitingViewModel<TResult1, TResult2>
,MvxResultSettingViewModel<TResult>
,MvxNavigationResultAwaitingViewModel<TResult>
,MvxNavigationResultSettingViewModel<TResult>
, and their overloads with parameters. Because when implementingIMvxResultAwaitingViewModel<TResult>
andIMvxResultSettingViewModel<TResult>
manually it requires implementing ViewModels registering, saving, restoring, unregistering, and setting the result manually as well.No navigation with awaiting the result.
🆕 What is the new behavior (if this is a feature change)?
Navigation with awaiting the result that also survives Android restoration.
💥 Does this PR introduce a breaking change?
No.
🐛 Recommendations for testing
Fragment
on bottomFragment
on bottom.Fragment
.You can test this with any dangerous permissions.
Developer option "Don't keep activities" works differently - it does not shut down the app. Though the feature also works in this case.
For other platforms it just works without restoration issues.
📝 Links to relevant issues/docs
PRs: #4312 #4652
Issues: #3342 #3980 #4230 #4262 #4553 #4651
🤔 Checklist before submitting
🧠 Extra
I am open for discussing changes for the implementation.
Here are some ideas: