feat: referenced assets

[mfazekas]

Implements referenced assets for RiveFile on iOS/Android. Create and update.

Since it's on file level to refresh views we need week links to views using that file. Also there is synchronisation so we only refresh after asset download and update has finished. Otherwise it's the same as the non nitro version.

Fixes: #7

[HayesGordon]

We could make something a bit more generic. refresh or restart.

The reason is because atm Android and iOS also does not restart the underlying graphic if it's in a settled state when updating data binding.

Something we should chat about though as part of a separate PR. Additionally, we should introduce the concept of paused/stopped/active in ReactNative that works independently from calling play/pause. But this may need to wait for the iOS and Android rewrites.

[HayesGordon]

We should add this (and the other two fileName + path options to the Android and iOS resources) if we want to keep these as examples

[HayesGordon]

Overall looks great!

A limitation with the old runtime is that you cannot reuse decoded assets across multiple files. Which I was hoping we could solve with this version - by creating a JS object that maps to a native RiveRenderImage, RiveFont, and RiveAudio, which you can then just pass/set at any point.

This will allow you to, for example, decode a font asset at the start of your app and then reuse that for multiple different Rive files.

I believe we might be restricted on iOS from doing this (cc @dskuza). Android has:

private fun processAssetBytes(bytes: ByteArray, asset: FileAsset) {
  when (asset) {
    is ImageAsset -> asset.image = RiveRenderImage.make(bytes)
    is FontAsset -> asset.font = RiveFont.make(bytes)
    is AudioAsset -> asset.audio = RiveAudio.make(bytes)
  }
}

So we can decode whenever.

But for iOS we're currently using the factory from the assetLoader.

Or alternatively, we could have some global cache to reuse decoded assets if the keys are the same across multiple file usage. But this might have limitations.

[mfazekas]

Overall looks great!

A limitation with the old runtime is that you cannot reuse decoded assets across multiple files. Which I was hoping we could solve with this version - by creating a JS object that maps to a native RiveRenderImage, RiveFont, and RiveAudio, which you can then just pass/set at any point.

This will allow you to, for example, decode a font asset at the start of your app and then reuse that for multiple different Rive files.

I believe we might be restricted on iOS from doing this (cc @dskuza). Android has:

private fun processAssetBytes(bytes: ByteArray, asset: FileAsset) {
  when (asset) {
    is ImageAsset -> asset.image = RiveRenderImage.make(bytes)
    is FontAsset -> asset.font = RiveFont.make(bytes)
    is AudioAsset -> asset.audio = RiveAudio.make(bytes)
  }
}

So we can decode whenever.

But for iOS we're currently using the factory from the assetLoader.

Or alternatively, we could have some global cache to reuse decoded assets if the keys are the same across multiple file usage. But this might have limitations.

I think for this a good first step could be like a HybridRiveImage we could accept values as HybridRiveImage-s, the the object we pass to referencedAssets.

[HayesGordon]

Overall looks great!
A limitation with the old runtime is that you cannot reuse decoded assets across multiple files. Which I was hoping we could solve with this version - by creating a JS object that maps to a native RiveRenderImage, RiveFont, and RiveAudio, which you can then just pass/set at any point.
This will allow you to, for example, decode a font asset at the start of your app and then reuse that for multiple different Rive files.
I believe we might be restricted on iOS from doing this (cc @dskuza). Android has:

private fun processAssetBytes(bytes: ByteArray, asset: FileAsset) {
  when (asset) {
    is ImageAsset -> asset.image = RiveRenderImage.make(bytes)
    is FontAsset -> asset.font = RiveFont.make(bytes)
    is AudioAsset -> asset.audio = RiveAudio.make(bytes)
  }
}

So we can decode whenever.
But for iOS we're currently using the factory from the assetLoader.
Or alternatively, we could have some global cache to reuse decoded assets if the keys are the same across multiple file usage. But this might have limitations.

I think for this a good first step could be like a HybridRiveImage we could accept values as HybridRiveImage-s, the the object we pass to referencedAssets.

Agreed, and should not be needed for releasing this as is.

[HayesGordon]

Thanks for this, it's great!