- Installed - always there
- Permanently caches - download on first use, keep until updates
- Temporarily caches = stored on cache directory, periodically cleaned
- Never cached - needs internet to work
Design Considerations: Which tier?
- First use - you may lose your users if they have to wait too long to see something real in your app.
- Offline experience - think about how users will use your data offline
- Data expiration rate - e.g. weather forecasts are transient, may not want to cache; may want to be aggressive in expiring it.
- Storage constraints - e.g. photo alumni case; most of the time you could put things are SD card; there is on device storage as well that is much smaller
- Always use a background thread (not UI), with callbacks.
- Use a placeholder (e.g. a blank grid of placeholder images that shows what will happen after the data is returned. It enhances perceived performance.
- Think about breadth first - get albums first instead of all the wedding pictures.
- Use a splash screen as slight of hand to distract the user from waiting.
- Store locally, then upload
- Append only - not destructed
- Server side caching is good too for things that happen often.
- Consider batch sizes when making requests for data; adjust for optimal experience
- When should you fetch new items? What makes sense for your use case?
- How much control should you give to user? Good example: number of days or max number of articles per source; not things like how much storage/MB, doesn’t mean anything to the user.
- Consider caching sharing actions/user generated data so that users that don’t have to wait until there is internet again; typing on the device is annoying.
Case study: Monkey Write
- Installed - initial/free workbook
- Permanently cached - workbook catalog (bookstore)
- Temporarily cached - workbook cover images
- Never cached - workbook purchasing
Case study: Offlane (offline newsreader)
- Installed - none; data isn’t relevant to ship with this app
- Permanently cached - sources; client tells server what it has, server returns new sources; pre-computed list for first use.
- First use - display screen while fetching in background
Case study: Triposo
- Installed - list of guidebooks & introductions
- Permanently cached - guidebook articles, maps
- Temporarily cached - weather & currency rate
- Never cached - none
- Data is open and editable (e.g. wikipedia input and other sources); they rank and prioritize submitted data and handle merging server side.
Case Study: Twitter Android
- Installed - none
- Permanently cached - none
- Temporarily cached - profile pictures, tweets, media attached to tweets
- Never cached - none
- Fixed number of records stored in a local DB; delete oldest records to free space
- Fetch incremental updates
- Tiered fetch - Fetch text for tweets very frequently; profile photos don’t need to be updated all the time! Attached media, retweets, favorites only fetched on opening individual tweets.
- Doesn’t prefetch because you are likely scanning the timeline instead of looking at every tweet (breadth vs. depth)