Skip to content
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

Fix subscriptionLifecycleOwner to use viewLifecycleOwner in Fragment's onCreateView #533

Merged
merged 4 commits into from
Mar 31, 2021

Conversation

krage
Copy link
Contributor

@krage krage commented Mar 29, 2021

As discussed in #530, subscriptionLifecycleowner wasn't using a fragment's viewLifecycleOwner for subscriptions made during onCreateView. The previous implementation using viewLifecycleOwnerLiveData doesn't work there due to the LiveData's value remaining null until the view has been returned. New solution uses viewLifecycleOwner directly when available - exception for accessing too early is caught.

Also included is a new wrapper for Job in mvrx-rxjava2 to better reflect the status of the underlying job in the returned Disposable's isDisposed().

Copy link
Contributor

@elihart elihart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krage thanks for this, just a few small requests.

@gpeal do you have any objections?

@@ -211,6 +212,16 @@ interface MvRxView : MavericksView {
).toDisposable()
}

private fun Job.toDisposable() = Disposables.fromAction {
cancel()
private class JobDisposable(job: Job) : AtomicReference<Job>(job), Disposable {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a unit test for this? 🙏

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few simple unit tests here: 8e00379.

@@ -70,7 +70,11 @@ interface MavericksView : LifecycleOwner {
* By default [subscriptionLifecycleOwner] is the same as the MvRxView's standard lifecycle owner.
*/
val subscriptionLifecycleOwner: LifecycleOwner
get() = (this as? Fragment)?.viewLifecycleOwnerLiveData?.value ?: this
get() = try {
(this as? Fragment)?.viewLifecycleOwner ?: this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a comment explaining that this is necessary for the view lifecycle to be accessible in onCreateView?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized the old doc comment was still suggesting an incorrect fragment implementation so I rephrased it overall and included the how/why of the new implementation: 98afd3f

Tried to still keep it brief there, let me know what you think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great, thanks!

Copy link
Contributor

@elihart elihart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the improvements!

@@ -70,7 +70,11 @@ interface MavericksView : LifecycleOwner {
* By default [subscriptionLifecycleOwner] is the same as the MvRxView's standard lifecycle owner.
*/
val subscriptionLifecycleOwner: LifecycleOwner
get() = (this as? Fragment)?.viewLifecycleOwnerLiveData?.value ?: this
get() = try {
(this as? Fragment)?.viewLifecycleOwner ?: this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great, thanks!

@elihart elihart merged commit 082a810 into airbnb:master Mar 31, 2021
@elihart elihart mentioned this pull request Apr 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants