Glide: Glide 4.0 - Overview

[sjudd]

Tracking bug for feature work for Glide 4.0.

See the design doc for more details. Feel free to comment on this issue or the document directly to provide feedback or input.

[FrancoisBlavoet]

These are some interesting improvements. I am particularly happy to see that Palette will get better support.
Another feature that I think is missing from Glide is a way to query the memory cache synchronously.
This needs has already been alluded to here : https://groups.google.com/forum/#!topic/glidelibrary/TcFOy0tcxXA .
The main use of this method would be in onCreateView() . You might want to apply a shared element Transition, or simply to smoothen the appearance of a new screen by immediately showing an image if it is in the cache, even without relying on the Lollipop API. In both cases, you need to make a synchronous get() on the memory cache in the onCreateView() method.
That way, you can set the resource if it is available.
Right now, it is not possible since the EngineKeyFactory is hidden in the Engine and uses parameters we can't easily access, like the transcoder (unless we keep references at module initialization, but that's not optimal either).
There might also be cases where we could similarly need to check both memory and disk cache.

[sjudd]

Thanks for the comment. Glide 4.0 (at least so far) does simplify the logic that would be required to construct the cache key: https://github.com/bumptech/glide/blob/4.0a/library/src/main/java/com/bumptech/glide/load/engine/ResourceCacheKey.java. Part of my hesitation to include this API in Glide 3 is just that the number of things required to construct they key was so large (as you mention) that it would be difficult to come up with a reasonable API.

It's still not totally straightforward in Glide 4. Although the above class works if you know exactly what class you decoded, much of the time you won't, and would have to try multiple keys. For example if we continue to default to loading Drawables, you may have loaded either a GifDrawable or a BitmapDrawable into memory, and would have to construct a cache key for each possibility.

[FrancoisBlavoet]

Glide 4 implementation of ResourceCacheKey looks reasonable to me.
I am not sure that 'decodedResourceClass' is needed though -> shouldn't the id be different anyway in that case ? I might not have a full view of this issue though.
Also, does the id need to be a key ? A string sounds enough to me.

I am nitpicking though, building a synchronized memory cache lookup method looks realistic with this key, it is conceivable to know these arguments from a caller perspective.

[drewhannay]

I would also REALLY love to see support for synchronously querying the cache, for the purpose of shared element transitions. I have a very ugly hack as a workaround right now and would love to remove it.

[jmrboosties]

@drewhannay would you mind sharing that hack? I was able to get shared element transitions to work with UIL. Glide is a better library overall I think, but I'm unable to get shared element transitions to work and that might be a blocker for me adopting it.

[drewhannay]

I'm just passing the Bitmap though the bundle to the new Activity...I'm worried there will be issues with that approach, but it seems to work.

[fbis251]

It would be nice to see the addition of a progress listener to Glide. I've been relying on using OkHTTP to get the image download progress as this provides a nicer UI to the user who can see roughly how long they'll have to wait until the image is displayed.

I posted a Gist that uses OkHTTP's ProgressListener interface with Glide:
https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/com/squareup/okhttp/recipes/Progress.java
https://gist.github.com/fbis251/cfa169fd9e1e142e042c

[mufumbo]

I see the specs talk about progressive for GIF. It would be really nice to cover progressive JPEG rendering for people with slower connection to enjoy the photos before they load completely.

[TWiStErRob]

@Teovald @drewhannay https://github.com/bumptech/glide/issues/627#issuecomment-146136474

[joebowbeer]

I'd like to see better support (or documentation) for configuring Glide for use in 3rd party library projects. The implementors of the library project need a robust way to configure their Glide requests (e.g., isolated Glide instance) so that their configuration doesn't corrupt other uses of Glide by the main app or any of its other library projects, and vice versa. The documentation is pretty vague about how to do this. It looks like a custom ModelLoader could be used, and maybe all of the global options can be configured somehow per request, but this is cumbersome and it's not clear (from documentation or source code) that it would actually work. Perhaps all that is needed is a "recipes" document or another sample..

[TWiStErRob]

@joebowbeer Can you please elaborate the use in third party projects? For example give an example of a project, how it is used and what problems come up implementing the library and using the lib in an app.

My current thoughts are that if the library loads an image from Uri then it should go the same way as configured in the app. What I mean is that the library shouldn't configure Volley, if the app is using OkHttp; this means no GlideModule in the library (except for custom model loaders).

I think the library should also specify general expectations like animations, caching, transformations explicitly per request so the app's global config can't intervene. Obviously the best implementation allows to replace the request builders all over the library, so the user of the library can decide all these things for themselves (with sensible defaults of course, to minimize time to first successful usage).

[joebowbeer]

@TWiStErRob I agree that many 3rd party libraries would want to play along with the global settings, which is why the Glide singleton is so easy to use. But other libraries may not. (And in Picasso, for example, it's fairly straightforward to create a dedicated, isolated Picasso instance using a dedicated OkHttp client.)

Typically, I think SDKs that are published as libraries tend to fall into the latter category. They are delivering a highly tuned, branded experience, and need to function independent from the other parts of the app. The needs of a Captcha widget, for example, are very different than the needs of an Uber widget, or a Getty Images widget, and different from the needs of the main application, whatever that may be. Using Glide in such a library, I can provide a custom ModuleLoader, but it's not clear how to setup/reset the global options for my request.

I think #414 is related.

[TWiStErRob]

@joebowbeer The whole point of Glide is to hide the complexity of loading images, which all your examples do, so the libs shouldn't need to do anything weird. Fire up the load, set transformation and animation (maybe caching) and you're likely good to go. There's no reset for global options, but you can simply specify all the options you think can change globally and really want to be specific about. I see what your general point is though, I just can't seem to find a use case that is large enough pressure to warrant a large scale rewriting like this (@sjudd may think differently though). If you have a concrete example where this causes a problem please share it, the ones you gave feel theoretical.

For example if you need auth headers in an SDK/lib then just create a GlideUrl with headers and let the hosting app decide about which networking lib to pass it through. Glide abstracted nicely and is network agnostic, just because the library creator likes OkHttp there's no point in forcing all of the library's users to include it in their app, some may want to use Volley for example.

Yes, #414 is about separate caches which is one thing a multiton Glide would allow.

[ZacSweers]

@TWiStErRob @sjudd any chance you guys could give an update on the progress of this? Or anywhere you could use help?

[FrancoisBlavoet]

@hzsweers I opened #1473 a couple of month ago with the same questions.
I am sure there are several people ready to help in order to ship the v4 branch.

[TWiStErRob]

If anyone is interested in helping I think you can pick an issue from https://github.com/bumptech/glide/milestone/5 and create a PR for the impl/fix, it'll be most welcome! (comment on it to make sure no dupe work is done)

[PaulWoitaschek]

Can't it be split up somehow? This is a huge thing, it would be great to see this library​ smoothly progress.

[sjudd]

This is pretty much all implemented, and then some. The two remaining items are to finish off the issues in the 4.0 milestone and documentation. Documentation is here (see contributing for instructions on how to add or update pages): http://sjudd.github.io/glide/. Updates to existing javadocs would also be welcome.

If anyone is interested in contributing and wants pointers or more information let me know and I'm happy to talk with you further.

[FrancoisBlavoet]

I am currently looking at how to migrate my very large project to glide 4.
I would be happy to provide some pointers on what could be improved in the documentation.

Currently, it looks like the large number of API differences is the main issue, which is expected.

[sjudd]

@Teovald this might be helpful: http://sjudd.github.io/glide/doc/migrating.html.

If there are things missing, let me know and I can try to fill them in (or help you do so :)).

[FrancoisBlavoet]

Thanks @sjudd !

I am reading this. The main difficulty right now is that the project is really large, so this migration might take some time.

For some context : we want to do a large refactorization of our glide integration, I am evaluating whether we want to take it as an opportunity to migrate to Glide 4 or if we stay with 3 for the time being.

It looks like ModelLoaders have changed a lot in Glide 4 and are not mentioned in the migration doc.

For the migration itself : it is painful but that's expected.
I guess that there is no way to use both Glide 3 & 4 at the same time (2 caches sounds insane), so we need to migrate the whole app in one go.
Since we have a lot of custom code based on ModelLoaders, DataFetchers, custom targets, etc, all this code needs to be migrated in one pass, which is just painful.