Forcing Local asset use when User doesn't want to download

I've got a use case for Addressables that I can't seem to find any documentation or info for.

We're planning on using Addressables to update content on a mobile app and the workflow seems much better than the previous asset bundle route, until I get to optional downloading.

To be respectful of a user's data plan, we'd like to give them the option to update the assets, rather than assume that we're going to use their mobile data even if they're not on WiFi. We can check whether there are updates available via Addressables.GetDownloadSize() and then ask the user if they want to download. If the user declines the download and we want to load the scene that is currently on their device I can't see an obvious way to request the Addressable from the cached data on the device instead of it attempting to pull from a remote location.

Any help here gladly received and apologies if I've managed to gloss over an obvious reference somewhere

Mark

 

there is no obvious reference, because that's a really tough problem to solve. The essence of addressables is that we map an address to a location. Having that location isn't really supported. In the short term, you'd need to solve this by creating a caching layer of your own. You can create a custom Provider that saves off locations once they are downloaded. You need to save it yourself because our catalog, once updated, will forget where the old thing was. You need to keep up with the old bundle name, so if the user rejects a download, you can reroute the request.

Longer term, we're working on a solution to this. We are debating between a global and a more granular solution, but are leaning towards the global one. The way the global solution would work (if we can pull it off) would be to pull a fresh catalog, and allow the developer to (with permission) download items from the new catalog while still using the old one. After any relevant downloads are done, the game code would approve the switch to the new catalog. We clearly don't have this yet, but it's on the to-do

 

Actually this what we've done, it's not that hard to implement. At the moment to make this work you need at least modify how the Addressables manages the catalogs, which means throwing the ContentCatalogProvider out of the window and download the catalog through other means, You can actually use the addressables for this, e.g.

Code (CSharp):

1. AsyncOperationHandle<ContentCatalogData> loadCatalogOp = ResourceManager.ProvideResource<ContentCatalogData>(
2.     new ResourceLocationBase(catalogPath, catalogPath, typeof(JsonAssetProvider).FullName, typeof(ContentCatalogData)));

Then you grab those locations with:

Code (CSharp):

1. ResourceLocationMap newMap = loadCatalogOp Result.CreateLocator();
2. IEnumerable<object> keys = newMap.Keys.Where(k => k.Equals("DownloadAsap"));
3. await DownloadDependenciesAsync(keys.ToList(), Addressables.MergeMode.Union).Task;

And then you replace the old catalog with the new one you downloaded and it will simply work. Of course this code is way simplified and there's a lot of stuff missing but that's the gist of it. Unfortunately I can't share my wrapper here, but if you need any tips or help @mdooneymill, I'll be glad to help.

 

That's very similar to what we're looking at for our long term solution. This is an all-or-nothing solution, which may be what is needed, but I'm not sure yet. The other piece of the puzzle we're currently lumping in with this is the ability to download data for the new catalog in the background, while using the old catalog. Which opens up the question of what to do once the download is done (wait for restart, or do some sort of hot-swap).

All in all, I appreciate the input, and am glad you were able to proceed without us blocking you. Over time, we'll keep adding features, but more important to us than adding features is ensuring we haven't blocked a user from adding their own.

 

Apologies for the slow reply, I've been away for a week.

Thanks for the input you two! Very much appreciated.