-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Firestore adapter lifecycle lint checks #1340
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
Firestore adapter lifecycle lint checks #1340
Conversation
This class is responsible to detect: 1) Missing call on startListening() when using a FirestoreRecyclerAdapter. 2) Missing call on stopListening() when a startListening() method call has occurred previously. 3) Missing call on setLifecycleOwner() in case FirestoreRecyclerOptions are being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice tests!
context.getLocation(it.uField), | ||
"Have called .startListening() without .stopListening()." | ||
) | ||
} else if (!it.hasCalledStart) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this trigger if startListening
is not called but setLifecycleOwner
is called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope have not taken that into account, but I was thinking of it as well. I am not quite sure on the proper approach to solve this.
Currently setLifecycleOwner
is applied on FirestoreRecyclerOptions
which should be applied on FirestoreRecyclerAdapter
, but there is nothing stopping the user of using both that method, as well as, the start/stopListening
ones. So I am not quite sure how to prioritize those two together and chose to just add warnings based on the general usage and existence of lifecycle method invocations. That lets the user decide which warning to suppress, effectively acknowledging that it is the desired behavior and not just a method call that they forgot to invoke.
@samtstern I am open to suggestions on the matter if you have anything to suggest :D
Edit 1: I would probably turn the invocation of startListening
after setLifecycleOwner
has been called, into a RuntimeException
so as to give a clear option on the user. Not sure if it should just be a Lint check since in the future those two method calls might conflict in an unpredictable way!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think (as @SUPERCILEX mentioned) understanding lifecycle in a lint could be very tricky. Would you be ok with reducing this PR down to just the start
/stop
calls and not the lifecycle bits?
We'd also have to do the work to ship our custom lint checks, which may be kind of slow, but we don't have to do that in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure I can do that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@samtstern I removed setLifecyleOwner
related Lint checks and code :)
@pavlospt thanks for making the changes! This looks good for merging into |
Glad to see so :D Thanks @samtstern ! |
This PR adds the following Lint checks:
Missing call on
startListening()
when using aFirestoreRecyclerAdapter
.Missing call on
stopListening()
when astartListening()
method call has occurred previously.Missing call on
setLifecycleOwner()
in caseFirestoreRecyclerOptions
are being used.Relevant issue: #1339