What is a Cache?
A “cache” is a temporary place where developers can store the data of an app. When attendees log in to the app for the first time, the API pulls all content in the app such as the Agenda, their Personal Agenda, Speakers list, and Exhibitors list, to be stored (cached) locally on the device. The next time you access the app the data from the cache files are used to load the pages instead of downloading it again – the main purpose of caches is to improve things like browsing experience by boosting the page loading speed or supporting the device when not connected to Wi-Fi.
The app will still need a way to reference its content against the database to check if the content is up to date or if any changes have been made. Redis is an in-memory cache, used across our applications to quickly reference database queries. These queries are stored in buckets based on content (object) type and by application ID along with their updated timestamp. When data is written to the database, a callback happens to calculate which queries are affected, to recompute the lists and push to in-memory and Redis. Then, when the app makes a request to view content, it will reference its local cache against Redis to verify if it needs to update the data.
A good deal of our customer issues are the by-product of our cache strategy as it is "polling" based. Rather than having the server push changes out to clients and sending the apps a command to refresh, each individual client needs to be responsible for polling the changes. This means each application must check (poll) at regular intervals to determine if its cache is out of date, and thus we establish regular refreshing cycles in the app. The polling mechanism for detecting cache refresh requests aligns each application to the same even polling times so all servers connected to the same site check for cache refresh requests and clear stale caches in unison.
The expected data refresh cycle in our applications follow the below time frames:
- all program data (CMS) may be cached at API level for up to five minutes
- config changes: up to 30 minutes
- program changes (agenda, attendee list, speaker list, etc.): up to 20 minutes
- user activity (logged-in user; likes, bookmarks, etc): up to 5 minutes
- activity feed: up to 45 seconds
Intentional Caching (Offline Mode)
As mentioned above, the app will intentionally cache content from the app locally to support the app's ability to call the content faster, and even when not connected to Wi-Fi in offline mode. Below outlines the content that will still be accessible even when the app is offline.
- The following items are available offline for both iOS and Android:
- My Agenda
- Attendee List
- Interactive Maps
- Custom Lists
- In-app Badges
- The following items are available offline to Android only:
- Like a status update
- Comment on a status update
- Add/Remove from Bookmarks
- Add/Remove from My Agenda
- Rate an item
- Review an item
- Follow/Unfollow a user
- Send Private Message
- Request meeting w/ Exhibitor
Note: the above offline actions will be lost and will not post when returning online if the user logs out and logs back in before re-connecting.
- The following items are not available offline:
- New posts in the Activity Feed (and Feed Cards)
- Post a status update
- Delete my own status update
- Delete my own comment
- Submit Poll response
- Submit Survey response
- Request Exhibitor Info
- Web Views
- Photo Feed
- File List/Hosted Files
- Session Notes
- DD Q&A
- Schedule Meetings
How do I know if content is cached in the app?
The best way to test if you are seeing the most up-to-date information in the app is to force the data refresh. iOS users must log out and log back in to download the updated configs, but Android users can perform the same action by navigating to the event picker and re-selecting the event.