AI Integration Quick Reference
AI Integration Quick Reference
Media caching applies only while offline support is active for the logged-in user (
CometChat.isOfflineEnabled() is true). See Enable Offline Support.Caching modes
The caching mode is set once, in theOfflineConfig you pass at initialization, and is fixed for the SDK session. There is no runtime switch — to change it, re-initialize the SDK with a new config.
Sending media always works in both modes.
CometChat.getMediaCachingMode(). It returns MediaCachingMode.off whenever offline support is not active, whatever the app configured, so a UI layer can rely on it without reading the config itself.
What downloads automatically
Inauto mode, media bytes are downloaded and cached automatically on the two live receive paths:
- a realtime media message received while connected, and
- opening a chat online (the server read refreshes and caches its media).
auto and off.
In off mode, nothing is auto-downloaded on any path; media loads live from its URL when online.
Reading cached media
When bytes are already cached, the SDK hydrates the local path automatically on every message it delivers — you do not have to ask. Read it straight off the attachment:getCachedMediaPath. It is a cheap filesystem check that never touches the network and returns null when the bytes are not cached (call downloadMedia to fetch them). The path is a cache hint that can disappear (LRU eviction, cache clear, auth wipe): re-resolve it on each render and never persist it in your own storage.
Each attachment of a multi-attachment message resolves independently. An attachment with no cached bytes keeps
localPath == null and the UI loads it from the URL as before.Downloading on demand
CalldownloadMedia to fetch and cache a message’s attachment bytes — for example when the user taps a placeholder. It is honored in both caching modes (an explicit download always wins). The SDK resolves off the main isolate (cached bytes, then a valid URL, then, for a CometChat-hosted URL the server rejects as expired or forbidden (HTTP 403 or 410), one re-signed URL) and reports back through the MediaCallbackListener you pass.
onProgress(int percent) reports 0..100, best-effort and monotonic non-decreasing. It is emitted only when the server reports a content length; for an unknown-length download it is skipped and the call goes straight to onSuccess. Progress never blocks or fails the download.
onError receives a MediaException whose code is one of these typed MediaErrorCode values:
Observe background downloads
Inauto mode, incoming media downloads in the background with no per-call callback. Register a MediaDownloadListener to learn when the bytes land (or fail) so a UI tile can refresh. All callbacks fire on the main isolate.
CometChat.removeMediaDownloadListener("MEDIA_LISTENER"). The background MediaDownloadListener carries no progress callback — progress is reported only on the explicit downloadMedia path above, and its onMediaDownloadFailed delivers a typed MediaException rather than a raw HTTP failure.
Media cache size limit
Cached media bytes are bounded bymaxMediaCacheSize (default 500 MB; 0 means unlimited). When the cache exceeds the limit, the least recently accessed media is deleted first until it is back under budget. Media for un-sent (queued) messages is never evicted, though it still counts toward the budget; copies held for an in-progress upload are excluded from the budget. Because protected media is never evicted, the cache can briefly exceed maxMediaCacheSize. Bulk list loads and syncs do not refresh an item’s recency.
Media is stored as files in durable, app-private per-user storage; the location is not configurable. Eviction runs silently in the background — there is no cache-limit callback. To reason about size, use CometChat.getCacheSize() (a Future<int> of the total local bytes held) and the configured limits. See the configuration reference for the full set of options.