.load(null) can be a valid .load request

[TWiStErRob]

In my app the user can create an entity and then take an OPTIONAL image for that entity.
If the image is not taken the entity's category is shown as the image. Category is mandatory, though it may be called unknown category which is visualized with a styled questionmark :)

So when loading with:

Entity e = ...;
Glide.with(this)
     .error(R.drawable.error) // red cross (Android res)
     .placeholder(e.categoryDrawable) // category's image (SVG)
     .load(e.imagePath) // user taken image (JPG)
     .into(imageView);

it may be expected to not take any action after setting the .fallback drawable:

.load	While loading	Load finished
null	fallback	fallback (currently error)
valid path	fallback	load
Exception	fallback	error

The current implementation treats null as an error, but in my case it's a valid non-image. This means that if a user didn't give take a picture it would display a red cross with Glide 3.4.
If I place the category image in .error() then I lose error indication, which may be appealing to the user (they never get a red cross). But while developing that's not useful and since it's an unexpected case I'm fine with users seeing it. So my current implementation is:

if (e.imagePath == null) {
    // note that categoryDrawable is never null, since it is used as a placeholder as well
    imageView.setImageDrawable(e.categoryDrawable);
} else {
    Glide.with(this).error(R.drawable.error).placeholder(e.categoryDrawable).load(e.imagePath).into(imageView);
}

[alex2069]

Just to justify this a little more - we also do this in a number of projects.
For us null is perfectly valid, in which case a default value is used - this is frequently the placeholder, but not always.
Perhaps a .default() option which is used when the request is null? If default is not set and null is used, then it could fallback like normal, preserving compatibility with old code/uses.

[Jogan]

+1

[TWiStErRob]

Nice :) Thanks @sjudd! So now, instead of the above if, I can use:

Glide.with(this)
     .placeholder(e.categoryDrawable) // while loading
     .fallback(e.categoryDrawable) // if load was null
     .error(R.drawable.error) // e.g. if path is not valid image
     .load(e.imagePath) // null or non-null image
     .into(imageView);

and it's backward compatible!

Too bad that I actually diverted from using this method because categoryDrawable is actually an SVG drawable that needs async loading. When I wrote this issue, I had my own cache and decoded SVGs on the UI thread. Would it be possible to extend the fallback interface to accept a full request builder?

[TWiStErRob]

Doing so would also help this scenario, however that 404 may be a little stretch, because that would validly display the error drawable.

[eicm]

it would have been more useful if fallback() was able to take any param that load() can take.

[sjudd]

We can re-open and target taking a second request later. It's vastly more complicated to do so, and in many ways similar to functionality you can already get out of thumbnail.

[sjudd]

Actually, lets close this an open a new issue: #451