wear-os-samples
wear-os-samples copied to clipboard
Unclear what to do when ResourcesRequest doesn't have resource ids
onResourcesRequest(requestParams: ResourcesRequest)
the requestParams.resourceIds might be empty. When does this happen? What's the expected behavior from a tile developer in this case?
Documented here https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:wear/tiles/tiles/src/main/java/androidx/wear/tiles/RequestBuilders.java;l=127?q=ResourcesRequest
But it's hard to implement for say a Twitter tile, without remembering which Tiles you returned.
The documentation says to return all the resources for a given version if the list is empty (I wonder why the list can't just be exhaustive to save developers from having to do this check). It doesn't say why/when it will happen and I wonder if understanding this would be helpful to verify that we (as tile devs) are doing the correct thing for our particular cases.
Let's revisit this holistically inc the following comment:
SingleTileLayoutRenderer is hiding the complexity of versions and effect on resources. I wonder whether we should expose this to override in SingleTileLayoutRenderer, or if not, put a quick doc comment here to explain that images will be cached permanently, and ids should have a timestamp if we want them to evolve, or we should change the id to flush all...
It looks like resource versioning and resource IDs are related, and I think a good outcome for this issue would be a blog post explaining them, with examples. Perhaps in the same post as #495 if it makes sense.
I think a good approach might be to end with different scenarios that would be good reasons for the following versioning/resource strategies
- Simple app that returns static images that wouldn't change except for a release. Fixed version, and simple ids.
- App that returns ids that are not unique, so bumps versions to request refetching of images.
- App that returns a constant value, but expects new images (say a new contact added) or updates existing, by appending a timestamp to the id.
Closing - the TileService never actually receives resource ids, so must generate all images on every request.