Organics + Binary

Caching Tiers

• 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

Data Fetching

• 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.

Offline-generated Data

• Store locally, then upload
• Append only - not destructed

Strategies

• 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)