-
Notifications
You must be signed in to change notification settings - Fork 6.1k
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
Updating a requests RequestOptions #2858
Comments
You can already apply RequestOptions to both RequestBuilders and other RequestOptions. The only caveat is that the apply method may return a new object, which it sounds like you're fine with. |
Here are my final functions every request runs through. I use a custom target to identify synchronous calls without the need of changing anything in my The functions show what I would like to do - add an option to the options already present in the
|
|
Thanks, did not realise this |
------------- Include the debug aar in release artifacts for Android projects. We removed the release variant a while ago to speed up the build, which has the side affect of removing the release aar from artifacts. Since we expect the debug and release variants to be identical (hence why we disabled the release variant), it should be safe to just use the debug aar instead. We will have to specify it explicitly since android’s rules unsurprisingly only add the release variant by default. ------------- Bump version to 4.6.0 ------------- Update readme to 4.6.0 Also removes the old v4 dependency from maven deps, I don’t think it’s necessary. ------------- Change update_javadocs to use debugJavadocJar instead of release. We’ve disabled the release variant. ------------- Bump version to 4.7.0-SNAPSHOT ------------- Add POM dependencies explicitly. Fixes bumptech#2863. ------------- Bump version to 4.6.1 ------------- Update readme to 4.6.1 ------------- Fix param mistake (bumptech#2873) ------------- Update SimpleTarget javadoc to match v4 API. ------------- Add javadoc for RequestOptions.apply/RequestBuilder.apply. Related to bumptech#2858. ------------- Add support for Uri data uris. Previously we only supported data uris if they were provided as Strings. Fixes bumptech#556. ------------- Make GlideBuilder.build package private. It shouldn’t have been made visible and can’t safely be used directly outside of the library. Fixes bumptech#2885 ------------- Handle notifications in MultiFetcher after cancellation. We can’t guarantee that every fetcher implementation will strictly avoid notifying after they’ve been cancelled. This also improves the behavior in VolleyStreamFetcher so that it attempts to avoid notifying after cancel, although it still doesn’t make any strict guarantee. Fixes bumptech#2879 ------------- Re-enable -Werror for java compilation. Related to bumptech#2886. ------------- Fix a deprecation warning in DataUriTest. ------------- gradle 4.5.1 ------------- deprecate fragments ------------- add @deprecated to javadoc and suppress deprecations in code ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=99229725401d5777e059da7b6331134bf73fbcdf ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=185535564
Glide Version: 4.5
Integration libraries: none
Device/Android Version: all
Issue details / Repro steps / Use case background:
I would like to have following feature: updating request options.
Why
I manage image loading in a simple class, so it's not a big problem here to solve my issue, but I'm preparing requests and hand them on from function to function. In the end I just start the reqeust with a target. So far so good.
Sometimes I want to manipulate the request based on the position where I called it from. In my case, I have one
ModelLoader
that executes requests internally to prepare the images it needs. Therefore I would like to be able to update the options in the request (it's immutable I think, making a copy of them is fine for me here). Or to have a possibility to get the current options, create new ones based on them and set the resulting options to my request.Examples
Any reasons to not support this sort of thing in any way?
The text was updated successfully, but these errors were encountered: