Add signature

[sjudd]

Allows users to easily mix in additional data into cache keys.

This would fix #178, and would be a step in the right direction for #174 and #172

[TWiStErRob]

If I see it correctly from the diff, you've created an optional Key argument for the load overloads. Why didn't you go with the usual builder pattern like .cacheSignature(Key)?

[sjudd]

Amusingly I didn't even think of adding it to the Builder pattern until you mentioned it. In part because I think it's so closely tied to the model you pass in. You could make an argument that the builder arguments apply generally to a style of load for any model, but the signature typically would apply only to a specific model (url etc).

I'm not sure that's a good enough reason to special case it though?

[TWiStErRob]

Try to look from the user point of view... and use it in a sentence:
Glide.with(this).using(...).load(uri, key).into(view);
versus
Glide.with(this).using(...).cacheSignature (key).load(uri).into(view);
For one: you're not loading the key into the view, that's only for cache refresh.

Second I personally like to not repeat code and the way I used Picasso and then Glide was to create my own factories pre-attaching the error Drawable, transformation and other stuff and returning a builder to call .load.into on it or override whatever special thing I wanted (e.g. noTransform). As far as I remember this pattern is already a little bit broken because a lot of stuff can only be specified after the .load with Glide, however my intuition would put the most varying parts last. If I were to use this key overload I would probably set it in the factory, calculating/caching the versionCode or hashOfApk there.
It feels like using it in an Adapter for example would pull the versionCode/hash calculation there which really should have to do anything in an adapter.

Third, when you say it's tied to the model it feels like you're only thinking about the opposite of using versionCode and having a separate Key for everything.

Please note that I like to trigger thoughts in other people and defend my initial view, though usually it's really easy to find arguments for both sides. You most likely see now where my original question came from and have enough to make an informed decision.

[sjudd]

Thanks for the feedback! I definitely appreciate having another point of view. I've changed this so that signature() is now another method on the builder. I also added some reasonable defaults for disk caching, memory caching and signatures for certain data types.

Hopefully this is more in line with what you were thinking? I agree it's strange to pass in the signature along with the model.

[sjudd]

Thanks for taking a look, I always appreciate the feedback! I pushed a few more commits to fix the issues we've found so far. If no one objects I'll aim to rebase this in tomorrow.