News
App Assets
Feed-driven set of app-wide assets
Many assets required by the articles are required by the article template, rather than by the content. It would be wasteful to declare such assets—typically CSS, JavaScript, fonts and graphics–for each article, when in fact they should be considered shared assets used throughout the application.
By providing an app asset feed, you can make sure that all your shared dependencies are fetched and kept up-to-date by the apps on every launch. Individual article HTML can then rely on those assets being available without explicitly declaring them in the article feed.
App Asset Properties
The app asset feed you provide is considered updated when its ETag
header changes. Richie servers poll the feed using a If-None-Match
conditional request, and will not process any updates when a 304 Not Modified
response is received. The ETag
header is mandatory for all app asset feeds.
In contrast to the feed itself, the individual assets at each remote_url
are expected to be immutable. The Richie servers polling your app asset feed deduplicate fetch requests and will not fetch an asset from a remote URL if it has already been fetched.
The local_name
is the local path to the resource in the app’s article HTML rendering context. The /app-assets/
prefix is mandatory.
Example App Asset Feed
In this example, a version parameter d=0.1.9
has been added to the remote URL query strings. When the version is incremented in the feed, Richie's servers will re-fetch all assets.
An article HTML file can refer to these files with the verbatim value of the local_name
property. For example:
Note that Richie's feed processing does not crawl the contents of assets like CSS and JavaScript to discover further assets. Your asset files can refer to each other with relative paths, but all assets have to be declared in the feed.