-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Implement request group and pause/resume support #665
Conversation
@Override | ||
public void onScrollStateChanged(AbsListView absListView, int scrollState) { | ||
final Picasso picasso = Picasso.with(context); | ||
if (scrollState == SCROLL_STATE_IDLE || scrollState == SCROLL_STATE_TOUCH_SCROLL) { |
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.
No settling state :( Damn you, AbsListView
.
Updated the branch:
|
@@ -156,6 +157,35 @@ public RequestCreator error(Drawable errorDrawable) { | |||
} | |||
|
|||
/** | |||
* Assign this request to a group. Request groups are an easy way to logically | |||
* associate related requests that must managed (paused, resumed, or canceled) |
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.
Small nitpick: Should be "that must be managed"
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.
Fixed, thanks.
This is awesome and a great example why I love OSS. I am curious about the performance gains from this change. I've always thought the sample app had good performance and near 60fps but everynow and then it would skip a frame. I think this will eliminate this. |
What do you think about naming this "tag" for parity with OkHttp and Volley (and eventually maybe Retrofit)? |
@JakeWharton I'm fine with "tag". I started with it but thought the notion of "request groups" sounded cooler :-) Method names looked a bit verbose though e.g. |
Maybe just |
Updated branch:
|
I was going to say we could just do |
@JakeWharton Good point. Done. |
Updated branch:
FWIW, I'm happy with the state of the branch now. The only open question I can think of is whether or not we want to have APIs to cancel/pause/resume all requests. We can do this in a follow-up ticket after merging this PR though. Thoughts? |
Also, maybe add this PR to the 2.4 milestone and close #561? |
We don't really use milestones much. Just when were planning issues for the
|
* associate related requests that can be managed (paused, resumed, or canceled) | ||
* as a tag. | ||
* <p> | ||
* Most of the time, you'll be using {@link String} tags but you can also use objects |
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 will never use strings so let's not say most.
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.
Done.
This looks fantastic. Beers will reign down upon you the next time you come to SF. Thanks for putting up with our sometimes ridiculous nit picking. |
Branch updated with all suggested changes. |
if (pausedTags.contains(action.getTag())) { | ||
pausedActions.put(action.getTarget(), action); | ||
if (action.getPicasso().loggingEnabled) { | ||
log(OWNER_DISPATCHER, VERB_IGNORED, action.request.logId(), |
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 we want to reuse the "Paused" verb here. "Ignored" makes it seem like we aren't deferring the request.
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.
Done.
Sorry one more tiny, tiny thing. LGTM otherwise! |
@JakeWharton Branch updated. |
You need to rebase, but only because I merged your other awesome PR. |
Rebased. |
Implement request group and pause/resume support
Thanks! |
\o/ |
When can we expect a release? |
We don't provide ETAs. We'll release when we feel that it's been thoroughly tested and stable. |
This is awesome. Big kudos! |
Ok, here's an initial take on the whole pause/resume support for Picasso.
This PR adds a new API to
RequestCreator
that allows you set a group tag/marker to specific requests:By default, all requests are associated with the default group defined as
Picasso.DEFAULT_GROUP
. This tag can be used to cancel, pause, and resume requests in the same group. To do so, you can use the following new APIs inPicasso
:cancelRequestGroup(String group)
pauseRequestGroup(String group)
resumeRequestGroup(String group)
Maybe we should also have
pauseRequest(Target|ImageView|RemoveView)
andresumeRequest(Target|ImageView|RemoveView)
for parity with the existingcancelRequest(Target|ImageView|RemoveView)
. Let me know what you think.Here are a few general notes on how this new API behaves:
BitmapHunter
until the group gets resumed. In this case, the requests for a paused group will be queued in theDispatcher
(seepausedActions
member).BitmapHunter
is either running or waiting for its turn), the requests in the now paused group will get detached from any pendingBitmapHunter
immediately. If the affectedBitmapHunter
ends up with no pending actions, it will get canceled (seeperformPauseGroup
).performCancel
). This might happen, for example, if a new request is initiated for the same target than a paused request.BitmapHunter
might containActions
from multiple groups at any given time. Not likely to happen in practice, but it's something we have to handle. This is why there's no 1-to-1 mapping betweenBitmapHunter
and requests groups.I should probably add some more tests for the new APIs. But I wanted to get some early feedback before spending more time on them. I've added a super simple scroll listener based on the new API. Works like a charm ;-)
closes #561