[FEATURE] - Remote asset sync

[chrismclarke]

Updates 2023-04-10

Work started in #1873, summary tasks below

Generating asset packs

• [ ] Download assets from gdrive and bundle them together in "asset packs"
• [ ] Upload bundle and manifest to supabase

Hosting asset packs

• [x] Set up supabase
• [x] Define structure of supabase Storage

Download asset packs

• [ ] Check config and download relevant manifest of expected files
• [ ] Compare to manifest of local files to determine which files need to be downloaded
• [ ] Download required files from supabase to device
• [ ] Populate app with assets from downloaded bundle

Links

• PICSA repo which uses similar methods to download/store files https://github.com/e-picsa/picsa-apps/blob/main/libs/shared/src/services/native/storage-service.ts

Updates 2023-03-14

@jfmcquade taken on and has created Remote Assets RFC

---

Original Issue

What? The current app bundle is approaching size limits that surpass play store limit (150MB) and forces users to download a large number of assets that they may never need (e.g. translated audios)

We need to improve on this system by:

1. Explore use of android asset delivery as a means to distribute bundles larger than 150MB if required.

2. Implement a system that allows users to download resources direct from a server and integrate into the app

How? For task (1) that should be a more simple task of exploring the docs to see what is possible and propose how we might integrate into existing pipelines. This is not a preferred option but may be something quick that can be achieved in the short term. Longer term it may still have some use to distinguish between code that could be updated OTA and/or assets that can be optimised to not repeatedly download

For task (2) likely will involve

• Tracking external download URLs for assets (either from google drive or copied to another s3 storage/server equivalent)
• Possible server updates to allow static file storage in case drive URLs not supported (e.g. minio)
• Scripts update to summarise asset packs that may need to be downloaded to support a specific deployment/language
• Capacitor Filesystem API used to detect what files a user has downloaded and provide the means to download and extract assets from the server as required
• UI pages to manage download
• Possible future updates to allow sharing of asset packs via Bluetooth or similar app sharing means

Other details This is not an uncommon use-case/pattern so it might also be worth spending a bit of time to figure out how similar applications achieve such things

[esmeetewinkel]

Timeline: needed before June 2023 for ParentApp for Teens. Also needed by ParentApp for Kids around that time.

[chrismclarke]

Current RFC working doc for reference https://docs.google.com/document/d/10I7lB5q4VzSiGUeenugP9guWUZ8Tnq95/edit?rtpof=true

[jfmcquade]

Notes taken from #1989

• [ ] TODO: add support for service-worker/caching assets on web (from comment)

• [ ] TODO: Write tests for new remoteAsset and fileManager services. Options (from this comment):

  1. Create mock implementations for the required services and inject instead of real. Some of these already exist, e.g. MockLocalStorageService and MockErrorHandlerService to replace the corresponding services. Example use in tests in src\app\shared\services\data\app-data-variable.service.spec.ts

  2. Extend the class for test cases and replace/mock methods as required. There some examples of this in src\app\shared\services\data\app-data.service.spec.ts

  3. Use spies/stubs to replace functions. I usually find this option as the best-sounding in theory but hardest to implement in practice (due to quirks with how jasmine defines imports). But there's at least some example in src\app\shared\components\template\services\instance\template-action.registry.spec.ts

TODO/needs discussion

asset_packs as manifests for downloading files

• When determining which files to download from the remote server, an asset_pack is used as a manifest

• It was agreed that for an MVP, we don't necessarily need to worry about managing asset packs from an author's perspective

• Currently this PR supports downloading a complete set of assets that is explicitly specified in an asset_pack json file

  • This is triggered through a template action, e.g. asset_pack: download: asset_pack_name, where an asset_pack_name.json exists in the appropriate folder in supabase storage

• We need to think about how these asset packs are generated and consumed

  • The asset pack generation could work something like this:
    1. The assets post-processor generates multiple asset_pack manifest files, e.g. "core", "pack_1", "theme_professional", based on some folder/tagging system within gdrive
       • Initially, this would coincide with our theme and language override folder structure
    2. Only core assets get included in app, the other assets get uploaded to supabase, along with their respective manifest files
    3. The remote-assets service checks which additional asset packs are required and downloads all the assets defined by each required pack
  • This seems sufficient to work towards for now, but we are likely going to also want a system of checking what files from a given asset pack have already been downloaded, and only downloading those which have not, or which have been updates since the previous download (see below)

    Handling overrides (theme/language)

• I'm not sure how we should handle asset overrides in terms of asset pack manifests used to specify files to be downloaded

• Consider the case where a remote asset pack contains just an override version of an asset that exists in the "core" bundle – i.e. What if we want to download just an override for an existing asset? What would the entry in the asset_pack manifest look like for this asset?

• Maybe an asset needs to "travel" with its override names, meaning that an asset entry of type IAssetEntry would contain the properties theme and language alongside filePath and size_kb. E.g.

  "plh_audio/relax/relax_10.mp3": {
  "filePath": "global/plh_audio/relax/relax_10.mp3",
  "md5Checksum": "f763a01ba394cb5b8d7ecc03e421d8e0",
  "overrides": {
    "theme_default": {
      "tz_sw": {
        "filePath": "tz_sw/plh_audio/relax/relax_10.mp3",
        "md5Checksum": "4cc3755f3c8c496de3e8fb9e8f59f65c",
        "size_kb": 724.1,
        "theme": "default",
        "language": "tz_sw"
      },
    }
  },
  "size_kb": 749
  }

  • We can always just read these from the object (i.e. from the nested path of the asset within its asset_pack entry), but that doesn't seem trivial in JS, and it's not clear to me how to handle the case of downloading a specific override asset.
  • Do we effectively want to undo the work of the assets post-processor in order to get the original filepath, or a normalised version of it, for each file, e.g. overrides/theme_professional/tz_sw/file_name.jpg?

• I'm starting to think we might want to take a step back and consider the asset system as a whole, including the overrides system, when thinking about a solution.

  • See #1950
  • But a new system will take significant work to design, so maybe best to keep that separate for now.

Version tracking

• How do we track file versions to ensure that the user has an up-to-date version of a file, and prompt a download if the file has been updated?
  • Currently using the md5Checksum that is read from the asset_pack file (not re-generated for the actually downloaded file itself)
  • This should be sufficient as long as the asset_pack files are being generated and updated correctly
• Explicitly query supabase for resources that have been updated since a certain datetime?

Fallbacks/placeholder assets

• Still need to think about fallbacks/placeholder assets
• It seems likely that our target users may have issues with downloading additional assets (internet access/data/storage space)