Content Delivery content-delivery

Mobile Apps should be able to use any and all content in AEM as needed to deliver the targeted app experience.

This includes using assets, site content, CaaS content (over-the-air) content, and custom content that may have its own structure.

There are three main types of material that Content Services deliver:

Assets assets

Asset collections are AEM constructs that contains references to other collections.

An Asset collection can be exposed through Content Services. Calling an asset collection in a request returns an object that is a list of the assets - including their URLs. Assets are accessed via a URL. The URL is provided in an object. For example:

Asset Optimization asset-optimization

A key value of Content Services is the ability to return assets that are optimized for the device. This reduces local device storage needs and improves app performance.

Asset optimization will be a server side function, based on information supplied in the API request. Wherever possible, the asset renditions should be cached so similar requests will not require a re-generation of the asset rendition.

Assets Workflow assets-workflow

The asset workflow is as follows:

The following diagram shows the Assets Reference Workflow:

Managing Assets managing-assets

Content Services provide access to AEM managed assets that may not be referenced through other AEM content.

Existing Managed Assets existing-managed-assets

An existing AEM Sites and Assets user is using AEM Assets to manage all of their digital material for all channels. They are developing a native mobile app and need to use several assets that are managed by AEM Assets. For example logos, background images, button icons, etc.

Currently these are spread around the Assets repository. The files the app needs to reference are in:

Accessing CS Asset Entities accessing-cs-asset-entities

Let’s put aside the steps of how the page is made available through the API for now (it will be covered by the AEM UI description) and assume it has been done. Asset entities have been created and added to the “appImages” space. Additional folders were created under the space for organization purposes. So the asset entities are stored in the AEM JCR as:

Getting a list of available asset entities getting-a-list-of-available-asset-entities

An app developer can get a list of what assets are available, by retrieving the asset entities. The Content Services space endpoint can provide that information through the web service API SDK.

The result would be an object in a JSON format that would provide a list of the assets in the “icons” folder.

Getting an Image getting-an-image

The JSON provides a URL for each image, generated by Content Services to the image.

To get the binary for the “cart” image, the client library is used once again.

Packaged HTML Content packaged-html-content

HTML content is needed for customers that need to maintain the layout of content. This is useful for native applications that are using a web container - such as a Cordova webview - to display the content.

AEM Content Services will be able to provide HTML content to the mobile app via the API. Customers wanting to expose AEM content as HTML will create an HTML page entity that points to the AEM content source.

The following options are considered:

Channel Independent Content channel-independent-content

Channel independent content is a way of exposing AEM content constructs - such as pages - without worrying about layout, components or other channel specific information.

These content entities are generated using a content model to translate the AEM structures into a JSON format. The resulting JSON data contains information about the content’s data, that is decoupled from the AEM repository. This includes returning metadata and AEM reference links to assets as well as the relationships between content structures - including entity hierarchy.

Managing Channel Independent Content managing-channel-independent-content

Content can get to the app in several ways.