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

Allowing to force the loading of the image on targets even if the same m... #39

Closed

Conversation

savvasdalkitsis
Copy link
Contributor

...odel has been loaded on the same target before

This allows the listeners to be called every time you call load into on a target. We need this for our adapter views where Glide would not even try to load the image if it was the same but we needed the callbacks to happen

…e model has been loaded on the same target before
@sjudd
Copy link
Collaborator

sjudd commented Nov 7, 2013

You should be able to get the same affect by calling Glide.clear(youImageView) right before you call Glide.load.

Maybe this really implies that we should call the request listener synchronously if you try to load an image into a target that is already displaying that image?

@savvasdalkitsis
Copy link
Contributor Author

Sounds good. The only subtle point is that we need the listeners to be called even if the initial call failed to load. Basically, any time I call Glide.into, I should receive a callback no matter what.

To keep the API cleaner, it might be good to specify a third callback like onImageAlreadyLoaded or something but still call the error callback if it fails to load again (either from any cache or the network).

@savvasdalkitsis
Copy link
Contributor Author

Also, I think you meant I should call Glide.cancel. Am I right? I can't see a clear method on Glide

@savvasdalkitsis
Copy link
Contributor Author

This, by the way, won't work for me since I am loading into a custom subclass on imageviewtarget, an instance I no longer have a reference to when I want to reload an image

@sjudd
Copy link
Collaborator

sjudd commented Nov 8, 2013

Yes I meant Glide#cancel, not clear. I was also incorrect in my previous post about the custom subclass.

You can and probably should be using a subclass of ImageViewTarget. However I was incorrect to say that you could pass in a new instance of your target subclass for each call to load. Instead you need to create and retain a single target per image view. If you pass in an ImageView directly, Glide will do this for you by calling ImageView#setTag. Otherwise it's up to you to retain the target in a non-static way.

The simplest thing to do is also to call setTarget if you're loading into a view, or if you're using the viewholder pattern, to add your target to your viewholder. You could also subclass the view directly and implement the interface in that subclass, although I think that's a bit uglier.

The fundamental problem is that we need to be able to retrieve information about the previous load when a new load starts so that we can do things like reuse bitmaps.

Sorry for the confusion!

@lalith-b
Copy link

If we subclass ImageView and do the manipulation on the imageview's overidden setImageBitmap(Bitmap bitmap) method it solves the issue of loading same model.

Also can we have a method/way to cancelAll() requests from glide or the ExecutorService exposed as a convenience method so it could be cleared ?

@sjudd
Copy link
Collaborator

sjudd commented Nov 24, 2013

@deathlord87 Please open a new issue for the cancelAll method and feel free to throw up some code, I think that would be relatively straight forward.

@sjudd
Copy link
Collaborator

sjudd commented Jun 28, 2014

For closure, in the 3.0 branch you can use a request listener which will be notified every time a load completes regardless of the source. Since that's fixed there, I'm going to close this. Thanks for reporting the issue and sorry it's taken so long to get it fixed.

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

4 participants