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:

1. Assets
2. Packaged HTML content (HTML/CSS/JS)
3. Channel independent content

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:

• A page entity returns JSON (page object) that includes an image reference. The image reference is a URL that is used to get the asset binary for the image.
• A request for a list of assets in a folder returns JSON with details about all of the entities in that folder. That list is an object. The JSON has URL references that are use to get the asset binary for each asset in that folder.

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

The asset workflow is as follows:

1. Asset Reference available in AEM out-of-the-box

2. Create Asset Reference Entity given its model

3. Edit entity

   1. Pick asset or asset collection
   2. Customize JSON rendering

The following diagram shows the Assets Reference Workflow:

Managing Assets

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

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:

• /content/dam/geometrixx-outdoors/brand/logo_light.png
• /content/dam/geometrixx-outdoors/brand/logo_dark.png
• /content/dam/geometrixx-outdoors/styles/backgrounds/grey_blue.jpg
• /content/dam/geometrixx-outdoors/brand/icons/app/cart.png
• /content/dam/geometrixx-outdoors/brand/icons/app/home.png

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:

• /content/entities/appImages/logos/logo_light
• /content/entities/appImages/logos/logo_dark
• /content/entities/appImages/bkgnd/grey_blue
• /content/entities/appImages/icons/cart
• /content/entities/appImages/icons/home

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

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

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:

• Zip file: To have the best chance at displaying properly on the device, all of the page’s referenced material - css, JavaScript, assets, etc. - will be included in a single compressed file with the response. The references in the HTML page will be adjusted to use a relative path to these files.
• Streaming: Getting a manifest of the required files from AEM. Then use that manifest to request all of the files (HTML, CSS, JS, etc.) with subsequent requests.

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

Content can get to the app in several ways.

1. GET content ZIPS via AEM Over-the-Air

   • Content Sync handlers can update the zip package directly or by calling existing content renderers

     • Platform Handlers
     • AEMM Handlers
     • Custom Handlers

2. GET content directly via content renderers

   • Out-of-the-box Default Sling Renderers
   • AEM Mobile/Content Services Content Renderers
   • Custom Renders