Closed yschimke closed 4 months ago
cc @castedmo @garanj
I'm tempted to introduce a first class VersionStrategy into the horologist APIs, something like
sealed trait VersionStrategy {
val versionId: String
}
object StaticVersion: VersionStrategy {
val versionId: String = "0"
}
data class IncrementingVersionStrategy(val versionId: String): VersionStrategy
class CollectedVersionStrategy(): VersionStrategy {
fun addResource(id: String)
val versionId: String
get() = // combine resources
}
Now exposed as
public open fun getResourcesVersionForTileState(state: T): String = PERMANENT_RESOURCES_VERSION
Apps can decide how to handle.
The tiles module was built with a false assumptions about resource version strategies.
However
The resource_ids field is not used at all in practice.
We originally came up with three strategies a) App has fixed resources, so has an immutable version and ships all resources at once. b) App has dynamic resources which all change on some frequency, bump the version at those points to get fresh resources. c) App has mostly static resources, that might occasionally change. Return a versioned resource id e.g._
However c) is a false assumption given resources are only refreshed when the version changes.
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:wear/tiles/tiles-renderer/src/main/java/androidx/wear/tiles/manager/TileUiClient.kt;l=153;bpv=1