flow

Identical to flow with Target.SIZE_ORIGINAL as the dimensions

This isn't generally a good idea, Target.SIZE_ORIGINAL is often much larger than you need. Using it unnecessarily will waste memory and cache space. It will also slow down future loads from the disk cache.

Use this method only if you you expect the request and all of the subrequests ( RequestBuilder.override and RequestBuilder.error to have specific sizes set). Validation is only performed on the top level request because we cannot reliably verify all possible subrequests.

Identical to flow(dimension, dimension)

Identical to flow with dimensions, except that the size is resolved asynchronously using waitForSize.

If an override size has been set using RequestBuilder.override, that size will be used instead and waitForSize may never be called.

Placeholder values may be emitted prior to waitForSize returning. Similarly if RequestBuilder.thumbnail requests are present and have overridden sizes, Resource values for those thumbnails may also be emitted. waitForSize will only be used for requests where no RequestBuilder.override size is available.

If waitForSize does not return, this flow may never return values other than placeholders.

This function is internal only, intended primarily for Compose. The Target API provides similar functionality for traditional Views. We could consider expanding the visibility if there are use cases for asynchronous size resolution outside of Glide's Compose integration.

Convert a load in Glide into a flow that emits placeholders and resources in the order they'd be seen by a Target.

Just like a Target there is no well defined end to a Glide request. Barring cancellation, the flow should eventually reach Status.SUCCEEDED or Status.FAILED at least once. However connectivity changes, calls to com.bumptech.glide.RequestManager.pauseAllRequests or com.bumptech.glide.RequestManager.resumeRequests, or the lifecycle associated with this request may cause the request to be started multiple times. As long as the flow is active, callers will receive emissions from every run.

This flow will clear the associated Glide request when it's cancelled. This means that callers must keep the flow active while any resource emitted by the flow is still in use. For UI contexts, collecting the flow in the appropriate fragment or view model coroutine context is sufficient as long as you avoid truncating methods like kotlinx.coroutines.flow.take, kotlinx.coroutines.flow.takeWhile, etc. If you do use these methods, you must be sure that you're no longer using or displaying the associated resource once the flow is no longer active (ie kotlinx.coroutines.flow.collect finishes). One way to do this would be to mimic the UI by creating and keeping active a coroutine context that collects from the flow while the resource is in use. If this restriction is limiting for you, please file an issue on Github so we can think of alternative options.

If there have been any previous calls to this RequestBuilder's com.bumptech.glide.request.RequestOptions.override method, the size specified in that method will be used instead of the size provided here. This includes calls where override sizes may have been copied from other option sets via RequestBuilder.apply.