Adobe recommends using the SPA Editor for projects that require single page application framework-based client-side rendering (for example, React). Learn more.
Mobile Apps should be able to use 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.
Over-the-Air Content can come from any of the above by way of ContentSync handlers. It can be used to batch package and delivery by way of zips and maintain updates or those packages.
There are three main types of material that Content Services deliver:
Asset collections are AEM constructs that contain 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 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 is a server-side function, based on information supplied in the API request. Wherever possible, the asset renditions should be cached so similar requests do not require regeneration of the asset rendition.
The asset workflow is as follows:
Asset Reference available in AEM out-of-the-box
Create an Asset Reference Entity given its model
The following diagram shows the Assets Reference Workflow:
Content Services provide access to AEM-managed assets that may not be referenced through other AEM content.
A user of AEM Sites and Assets is using AEM Assets to manage all of their digital material for all channels. They are developing a native mobile app and must use several assets that are managed by AEM Assets. For example, logos, background images, and button icons.
Currently these are spread around the Assets repository. The files that the app must reference are in the following:
Let’s put aside the steps of how the page is made available through the API for now (it is 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:
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.
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.
HTML content is needed for customers that must 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 provides HTML content to the mobile app by way of the API. Customers wanting to expose AEM content as HTML can create an HTML page entity that points to the AEM content source.
The following options are considered:
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. 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 and the relationships between content structures - including entity hierarchy.
Content can get to the app in several ways.
GET content ZIPS by way of AEM Over-the-Air
Content Sync handlers can update the zip package directly or by calling existing content renderers
GET content directly by way of content renderers