Migrating to v1.10

Version v1.10 introduced major changes to how and where engine and the UI store assets. This guide helps you navigate those changes and explains what you need to do to bring your integration up to speed.

1. Scene Uploads are no longer serialized#

Image uploads are no longer stored in the scene and will not reappear upon scene load. To offer specific assets in your editor, configure and add an asset source containing the desired assets.

2. Deprecating Extensions#

Starting with v1.10 we fully embrace Asset Sources as our standard interface for asset management. We're deprecating extension packs, previously stored in /assets/extensions and indexed via manifest.json files.

Fonts are not affected by this deprecation yet, but will receive the same treatment in an upcoming version.

We'll deprecate the config.extensions field for CreativeEditorSDK. As part of this deprecation, we'll no longer ship the following packs in the /assets/extensions directory in our npm packages:

• ly.img.cesdk.images.samples
• ly.img.cesdk.shapes.default
• ly.img.cesdk.stickers.doodle
• ly.img.cesdk.stickers.emoji
• ly.img.cesdk.stickers.emoticons
• ly.img.cesdk.stickers.hand
• ly.img.cesdk.vectorpaths
• ly.img.cesdk.vectorpaths.abstract

To keep offering the contained assets in your deployment, use our new convenience functions to instantiate asset sources holding these assets. If you have existing scenes where an asset from an extension pack might be included, you must make sure you're still serving the corresponding files from your baseURL, so that <baseURL>/extensions/… paths still resolve properly. You can acquire a copy of the extension packs shipped in v1.9.2 from our CDN. Otherwise your scenes will render missing asset alerts.

2.1 Making use of Default and Demo Asset Sources#

We still want to offer a package, that has all batteries included and quickly gets you up to speed. To do so, we introduced two new convenience functions, that can be used to add a set of predefined asset sources to your integration:

addDefaultAssetSources#

Adds a set of asset sources containing our default assets.

These assets may be used in production and served from your own servers. The assets are parsed from the IMG.LY CDN at {{base_url}}/<id>/content.json, where base_url defaults to https://cdn.img.ly/assets/v1. Each source is created via addLocalSource and populated with the parsed assets. You can specify your own base_url or exclude certain source IDs.

The following sources are added:

addDemoAssetSources#

Registers a set of demo asset sources containing our example assets. These are not to meant to be used in your production code.

The assets are parsed from the IMG.LY CDN at https://cdn.img.ly/assets/demo/v1. The sceneMode and withUploadAssetSources parameters control whether audio/video and upload sources are added.

The following sources are added:

Modifying Default & Demo Sources#

After registration you can freely modify the contained assets using the Asset APIs. You can add or remove entire asset sources or individual assets.

Upload Asset Sources#

The upload asset sources and library entries for video and audio were added to the default configuration from addDefaultAssetSources. If you have added these sources manually (like mentioned in our video docs) you can remove them now.

3. AssetAPI Changes#

To further streamline interaction, the following breaking changes were made to the AssetAPI:

• The applyAsset callbacks and defaultApplyAsset API now return an optional design block id in their callback if they created a new block.
• thumbUri and size properties in AssetDefinition and AssetResult are now part of the meta property dictionary.
• Values of the blockType asset meta property must now be design block type ids (e.g. //ly.img.ubq/image)

4. A New Way to Add Images#

Instead of specifying additional images for the CreativeEditorSDK in config.presets.images, you should make use of asset.addAsset and add your images into the ly.img.image asset source.

5. General API Changes#

The blockType meta property for assets changed from ly.img.<type> to fully qualified block types: E.g. 'ly.img.image' now needs to be '//ly.img.ubq/image'.

As we're starting to apply the 'fill' concept to more parts of the interface, we deprecated various fill color related APIs:

• Deprecated hasFillColor, use hasFill and query block.getEnum(id, 'fill/type') for Solid type instead.
• Deprecated get/setFillColorRGBA, use setFillSolidColorinstead..
• Deprecated isFillColorEnabled, use isFillEnabled instead.
• Deprecated setFillType and setFillGradientType, use createFill, e.g., with type 'color' and then apply the fill block with setFill to the block instead. If the block has a fill, it should be removed with getFill and destroy.
• Deprecated getFillType and getFillGradientType, query block.getEnum(id, 'fill/type') and block.getEnum(id, 'fill/gradient/type') instead instead
• Deprecated add/removeFillGradientColorStop and get/setFillGradientColorStops.
• Deprecated get/setFillGradientControlPointX/Y, use block.getFloat(fill, keypath) and block.setFloat(fill, keypath, value) with key paths 'fill/gradient/linear/startPointX/Y', 'fill/gradient/radial/centerPointX/Y', and 'fill/gradient/conical/centerPointX/Y' instead.
• Deprecated get/setFillGradientRadius, use block.getFloat(fill, 'fill/gradient/radial/radius') and block.setFloat(fill, 'fill/gradient/radial/radius', value) instead."

camera/clearColor property was replaced it with a global clearColor setting to allow controlling the clear color before loading a scene.

Properties affecting playback that existed on both Audio and VideoFill where moved to a common playback/ namespace:

• 'fill/video/looping' and 'audio/looping' are now 'playback/looping'
• 'fill/video/volume' and 'audio/volume' are now 'playback/volume'
• 'fill/video/muted' and 'audio/muted' are now 'playback/muted'