apis & implementation

27 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Manifest TypeScript definition in Expo Updates

The Manifest type is defined as: type Manifest = { id: string; createdAt: string; runtimeVersion: string; launchAsset: Asset; assets: Asset[]; metadata: { [key: string]: string }; extra: { [key: string]: any }; }

Asset TypeScript definition in Expo Updates

The Asset type is defined as: type Asset = { hash?: string; key: string; contentType: string; fileExtension?: string; url: string; }

Manifest id field requirements

The manifest id field must uniquely specify the manifest and must be a UUID.

Manifest createdAt field requirements

The manifest createdAt field must contain the date and time at which the update was created, which is essential as the client library selects the most recent update subject to any constraints supplied by the expo-manifest-filters header. The datetime should be formatted according to ISO 8601.

Manifest runtimeVersion field

The runtimeVersion field can be any string defined by the developer. It stipulates what native code setup is required to run the associated update.

Manifest launchAsset field

The launchAsset is a special asset that is the entry point of the application code. The fileExtension field will be ignored for this asset and should be omitted.

Manifest assets field

The assets field is an array of assets used by the update bundle, such as JavaScript, pictures, and fonts. All assets (including the launchAsset) should be downloaded to disk before executing the update, and a mapping of asset keys to locations on disk should be provided to application code.

Asset hash field in Expo Updates

The hash field is an optional base64URL-encoded SHA-256 hash of the file to guarantee integrity. Base64URL encoding is defined by IETF RFC 4648 section 5.

Asset key field in Expo Updates

The key field is used to reference this asset from the update's application code. This key, for example, may be generated by a separate build step that processes the application code, such as a bundler.

Asset contentType field in Expo Updates

The contentType field contains the MIME type of the file as defined by RFC 2045. For example, application/javascript, image/jpeg.

Asset fileExtension field in Expo Updates

The fileExtension field is the suggested extension to use when a file is saved on a client. Some platforms, such as iOS, require certain file types to be saved with an extension. The extension must be prefixed with a dot. For example, .jpeg. In some cases, such as the launchAsset, this field will be ignored in favor of a locally determined extension. If the field is omitted and there is no locally stipulated extension, the asset will be saved without an extension. For example, ./filename with no dot at the end. A conforming client should prefix a file extension with a dot if a file extension is not empty and missing the dot prefix.

Asset url field in Expo Updates

The url field contains the location at which the file may be fetched.

Manifest metadata field

The metadata field is the metadata associated with an update and is a string-valued dictionary. The server may send back anything it wishes to be used for filtering the updates. The metadata must pass the filter defined in the accompanying expo-manifest-filters header.

Manifest extra field

The extra field is for storage of optional 'extra' information such as third-party configuration. For example, if the update is hosted on Expo Application Services (EAS), the EAS project ID may be included as: 'extra': { 'eas': { 'projectId': '00000000-0000-0000-0000-000000000000' } }

Extensions TypeScript definition in Expo Updates

The Extensions type is defined as: type Extensions = { assetRequestHeaders: ExpoAssetHeaderDictionary; ... } and type ExpoAssetHeaderDictionary = { [assetKey: string]: { [headerName: string]: string, }; }

assetRequestHeaders field in Extensions

The assetRequestHeaders field may contain a dictionary of header (key, value) pairs to include with asset requests. Key and value must both be strings.

Directive TypeScript definition in Expo Updates

The Directive type is defined as: type Directive = { type: string; parameters?: { [key: string]: any }; extra?: { [key: string]: any }; }

Directive type field

The type field specifies the type of directive.

Directive parameters field

The parameters field may contain any extra information specific to the type.

Directive extra field

The extra field is for storage of optional 'extra' information such as third-party information. For example, if the update is hosted on Expo Application Services (EAS), the EAS project ID may be included.

Custom directive types in Expo Updates

A conformant client library and server may specify and implement directive types specific to the needs of the application. For example, Expo Application Services makes use of one type: rollBackToEmbedded, which directs the expo-updates library to use the update embedded in the host application instead of any other downloaded updates.

Asset request headers in Expo Updates

A conformant client library must make a GET request to the asset URLs specified by the manifest. The client library should include a header accepting the asset's content type as specified in the manifest. Additionally, the client library should specify the compression encoding the client library is capable of handling. Example headers: accept: image/jpeg, */* and accept-encoding: br, gzip. A conformant client library must also include any header (key, value) pairs included in assetRequestHeaders for this asset key.

Asset immutability requirement in Expo Updates

An asset located at a particular URL must not be changed or removed since client libraries may fetch assets for any update at any time.

Asset hash verification requirement

A conformant client must verify that the base64url-encoded SHA-256 hash of the asset matches the hash field for the asset from the manifest.

Asset response encoding in Expo Updates

The asset must be encoded using a compression format that the client supports according to the request's accept-encoding header. The server may serve uncompressed assets. The response must include a content-type header with the MIME type of the asset. Example headers: content-encoding: br and content-type: application/javascript.

Asset cache control recommendation

An asset is recommended to be served with a cache-control header set to a long duration as an asset located at a given URL must not change. For example: cache-control: public, max-age=31536000, immutable.

Asset compression support in Expo Updates

Assets should be capable of being served with Gzip and Brotli compression.

Give your agent this brain