Add convenience methods for getting the storage size of existing offline resources

[friedbunny]

We should provide convenience methods for getting the total stored size of offline resources — both for individual offline regions and the aggregate.

As of iOS v3.3.0, to calculate the total size of all available offline resources, you would:

1. Wait for MGLOfflineStorage.sharedOfflineStorage().packs to populate by watching this property via KVO.
2. Get an array of all existing packs via the above packs property.
3. Request the progress for each item in that array via -[MGLOfflinePack requestProgress:].
4. Wait for each pack to return a value, either via KVO on its MGLOfflinePack.progress or by listening for MGLOfflinePackProgressChangedNotification notifications.
5. Total all of the packs’ MGLOfflinePackProgress.countOfBytesCompleted values.

/cc @1ec5 @jfirebaugh @zugaldia

[jfirebaugh]

That algorithm would double count resources that were shared by two packs. I agree there should be a method for getting aggregate statistics.

I'm not sure what you mean by "individual offline regions" -- this API already exists, and is likely as convenient as possible given the asynchronous nature of offline. Note that any aggregate statistic API would also be asynchronous.

[1ec5]

We could implement this API at the SDK level, more or less, by returning the file size of cache.db, which we already know the location of. It’d include any space taken up by ambient caching (which can overlap with offline packs).

[friedbunny]

"individual offline regions" -- this API already exists

Right, that’s essentially the singular version of steps 1 through 4. It may not be that the underlying API can be improved, but it would be nice if we could abstract the multilayered KVO grunt work — perhaps by providing completion blocks on the async methods.

[1ec5]

#5585 implements the synchronous API proposed in #5580 (comment) on iOS and macOS. Even if the cache’s file size differs from the size you’d get by enumerating the offline packs’ statuses, I think the former is what a developer would generally be interested in anyways.

[jfirebaugh]

I think we should hold out for a database-query based API, which would provide resource and tile counts in addition to total size, which people have been asking for.

[1ec5]

A more granular API for resource and tile counts would certainly be desirable. However, I think the API added in #5585 is valuable on its own, not least because it’s synchronous.

[1ec5]

Leaving this ticket open for both platforms in light of #5580 (comment).

[1ec5]

We left this issue open for #5580 (comment), but I think #9460 better covers that feature now.

[jfirebaugh]

If we're going to conflate this with #9460, we should at least do some issue retitling and / or description editing. The way they are currently described, they are distinct: this issue is about getting the total size (in bytes) of all resources in an offline region (or potentially broken down by resource type). #9460 is about getting the total number of tiles for a region (and for the use case described there, preferably before committing to downloading those tiles).

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.