Logopicto

Uploading Assets

Make your app's bundled images resolvable when a recording is replayed on the web dashboard.

When your app draws a bundled image (Image.asset(...)), the recording captures a lightweight reference to it (its asset path) rather than the actual pixels — cheaper, and there's no need to re-upload the same app icon or avatar with every single recording. Replaying on the same device the recording came from works out of the box, since the app's own asset bundle is right there.

Replaying in the web dashboard is different — the browser has no access to your app's bundle. To make asset references resolve there too, upload your asset bundle to the backend once (per release, or whenever your assets change), using the upload_assets script that ships inside the picto package itself — no separate download or checkout needed.

Running the script#

From your Flutter project's root (the one whose pubspec.yaml declares the assets, and which already depends on picto):

dart run picto:upload_assets \
  --client-app-id ca_... \
  --owner-id us_... \
  --api-key oc_...
FlagMeaning
--client-app-idSame client app ID used everywhere else.
--owner-id Your dashboard account's own ID — same value as RECORDING_OWNER_ID.
--api-keyThe client app's API key.
--flavor Which picto.yaml flavor to read the above from, if you have more than one — see picto.yaml & Flavors .
--project Optional — path to the Flutter project to read assets from. Defaults to the current directory.

Any of --client-app-id/--owner-id/--api-key can be skipped entirely once your project has a picto.yaml — see picto.yaml & Flavors for the file format and dart run picto:setup for generating one interactively.

The script reads the flutter.assets section of your pubspec.yaml — both individually-listed files and directory entries — and uploads each one, keyed by its exact declared path (e.g. assets/images/logo.png), which is the same key Image.asset references resolve against.

Re-running it#

The script is idempotent: uploading an asset whose name already exists for that client app is treated as success, not an error, so re-running it after a release that didn't change any assets is a harmless no-op. To actually replace an asset's image, there's no update path — remove the old one in the dashboard first, then re-run the script.

When to run it#

Run it once per release, or any time your bundled assets change — as part of your normal release checklist, alongside building the app itself. It has no runtime relationship to the recording SDK; it's a standalone maintenance step.