feat(cdn): adding in cdn caching

[bassrock]

Description

This PR adds URL-based asset caching to the ReferencedAssetLoader on both Android and iOS platforms. The implementation introduces a dedicated URLAssetCache module that caches downloaded HTTP/HTTPS assets to disk, improving performance by avoiding redundant network requests for the same assets.

Changes Made

URL Asset Caching

• New URLAssetCache Module: Created a dedicated caching system for URL-based assets on both platforms

  • Android (URLAssetCache.kt):

    • Uses SHA-256 hashing for cache key generation
    • Cache directory: cacheDir/rive_url_assets/
    • Thread-safe operations with error handling
    • Provides getCachedData(), saveToCache(), and clearCache() methods

  • iOS (URLAssetCache.swift):

    • Uses CryptoKit's SHA256 for cache key generation
    • Cache directory: cachesDirectory/rive_url_assets/
    • Thread-safe operations with silent error handling
    • Provides static methods for cache operations

ReferencedAssetLoader Updates

• Cache Integration: Both Android and iOS loaders now check the cache before downloading HTTP/HTTPS assets

  • Cache lookup occurs before network requests
  • Downloaded assets are automatically saved to cache
  • Non-URL assets (bundled, resources) bypass the cache and use direct loading
  • Cache operations are transparent to the asset loading flow

• Asset Cache Management in createCustomLoader:

  • Assets are immediately saved to the cache map when encountered (by both uniqueName and name keys)
  • Enables Dynamic Asset Updates: This allows users to pass in new referencedAssets later in the file lifecycle. Since assets are cached immediately, new referenced assets can be provided and will properly associate with existing file assets throughout the file's lifecycle.

Additional Changes

• HybridViewModelImageProperty Fix: Fixed listener callback to properly handle value changes by mapping to Unit instead of empty map

Additional Information

Technical Details

• Cache Key Generation:

  • Android: SHA-256 hash of the URL (64-character hex string)
  • iOS: SHA256 hash using CryptoKit (64-character hex string)
  • Both approaches ensure deterministic, filesystem-safe cache keys

• Cache Storage:

  • Files are stored with hashed filenames to avoid filesystem issues with special characters in URLs
  • Cache directory is created automatically if it doesn't exist
  • Cache persists across app restarts (stored in app's cache directory)

• Cache Strategy:

  • Cache-first approach: checks cache before network requests
  • Write-through: downloaded assets are immediately cached
  • Best-effort: cache failures don't block asset loading
  • Only HTTP/HTTPS URLs are cached; other asset sources (bundled, resources) bypass cache

• Asset Cache Management: The createCustomLoader function now immediately caches all assets (both by uniqueFilename/uniqueName and name) when they are first encountered, regardless of whether they've been loaded yet. This ensures:

  • The cache map is always up-to-date
  • Assets can be updated/reloaded with new referenced asset data
  • New referenced assets can be provided and will properly associate with existing file assets

Breaking Changes

None - this is a backward-compatible enhancement. Existing functionality remains unchanged, with caching added as an optimization layer.

[HayesGordon]

This is great @bassrock! We'll get this reviewed

Edit: and thanks for the contribution + early feedback

[mfazekas]

Where is this dispose is called from?!

[bassrock]

hmm actually looks like it never is. Guess its a bug

[mfazekas]

FWIW we've ended up merging a slightly different fix for the iOS crash. #45

[bassrock]

@mfazekas I was also seeing a similar issue on Android

[bassrock]

I removed the disposal on android and ios, and rebased on main

[bassrock]

@mfazekas I have made updates since the view stuff was fixed elsewhere. This now fixes just referenced assets and adds in a Cache layer

[mfazekas]

@bassrock FYI this approach is challenging to implement on the new experimental iOS runtime.

The experimental API uses Worker global assets instead of the LoadAsset callback:

// Experimental: register assets on Worker (can be before OR after File creation)     
let worker = await Worker()                                                           
let image = worker.decodeImage(from: imageData)                                       
worker.addGlobalImageAsset(image, name: "referenced-image-2929282")  // must know     
exact name                                                                            
let file = try await File(source: .data(data), worker: worker)                        

• Assets CAN be added/removed dynamically after file load
• No callback to discover asset names - you must know them upfront

Worker.swift

[bassrock]

@mfazekas when using the hosted RiveCDN does the new Runtime though have a way to cache the loaded assets (and the app doesnt know about it)? For example we use the same Rive File across our app that uses assets from the RiveCDN, ideally we don't want the same image loading from the network on each different view of the Rive file.