Drawables should have build-based cache id

[magicseth]

Drawables should not be cached by ints, as they can change at each compilation. Instead, they should be cached based on a combination of the specific build and the int identifier (or the resource name).

Just caching based on resource name alone is not sufficient, because the resource can change on each build also.

I'd recommend using the app signature to generate the cache key:
http://stackoverflow.com/questions/5578871/how-to-get-app-signature

FIXES: 17831665

[TWiStErRob]

I think the versionCode should be sufficient, based on the fact that you need to increment it every time you upload an apk to Play store (regardless of alpha/beta/prod).
That in itself should solve your issue assuming you're using applicationIdSuffix for debug.

[magicseth]

That will lead to strange bugs in development, as each install will potentially show the wrong drawables.

[TWiStErRob]

Ah, very true. I wasn't thinking about continuous build/run cycles just from the perspective of what a user may experience.

A concern: that means that each debug deploy will have a differrent id, even if no drawable changed, so it'll always be a cache miss.

Based on the above two I think it's better to clear the cache when drawables changed.

What's that "FIXES:" in the report?

[magicseth]

Another option would be to not even cache drawable at all, as presumably,
they are already on disk locally.

The fixes is just a reference to the bug in my internal bug tracker so I
can keep track when this is resolved 😎

[sjudd]

This ties into a larger issue we have where we generically cache content at Uris (#174). For drawables we can either, as @magicseth suggests, not cache content all or we could also probably get away just caching drawables in the memory cache. Unlike most Uris, the only way the drawable id would change would be on re-install so the memory cache should be safe.

I'd also be totally open to trying to mix something into the disk cache key for Drawables, but it would have to work for developers as well as end users and I can't think of anything that changes after each compilation?

[magicseth]

I think the hash of the signature will change each install. But honestly,
the memory cache is probably fine.

[sjudd]

I tested Signatures, they're consistent across installs/compilation. Signatures are used to validate permissions so I'd assume they're tied to the key used to sign the application and shouldn't change.

For now I think I'll do just versionCode + resource name (rather than id), which will make things much more consistent. We can address broader concerns about caching data at uris in #174

[TWiStErRob]

How about getting the hash of the .apk file?

They're reading the whole file into memory but it would be more efficient to call .update with the buffer in each iteration.

Would it be a big deal to provide a public interface with 1-2 default implementations mentioned above and expose something in the Glide builder for example to set it? That way the default could be versionCode, but extremists can use the apk hash or something else.

[sjudd]

The hash of the apk (or maybe more precisely the drawable in question?) is certainly the most correct, but, at least currently, glide requires that cache keys are generated synchronously on the main thread, which rules out IO. We could change that but then memory cache keys wouldn't be invalidated at the same time as disk cache keys which would open a different can of worms.

I'm inclined to stick with name and version code for now which will make things mostly consistent and focus on trying to solve the problem generally for all Uris.

[sjudd]

Going to call this fixed in #179.

It's not perfect for developers, but the switch to resource names in sjudd@a1912e2 should help mitigate that, and for end users results will be consistent.