Pugpig Bolt aims to strike a balance between ensuring content is available whenever a user wants to read it, and respecting the limitations of data usage and storage space. This document details:

1. What content a user should have available offline
2. When this content is fetched 
3. How you can manually make your user’s apps fetch content

What content a user will have available

This differs according to whether the content is an edition or timeline and is detailed below. Any content added to the saved timeline is also proactively downloaded and preserved.

Editions

Editions are asynchronously downloaded or updated when opened or the download icon on the storefront is tapped and are stored indefinitely as long as the edition remains available to the user and the user does not manually delete it. 

We don’t impose a limit on how many editions can be stored, and the user is able to trigger multiple edition downloads at once. We have the ability for the user to select a time period after which editions are automatically deleted (auto-archiving) and they can also be manually deleted  

These downloads include:

1. Article text
2. Article images
3. PDF pages

Timelines

Timeline content is saved to the users device when they navigate to a timeline or pull to refresh on a timeline. Any articles the user has read are also saved. This content is cached up to 200 MB and remains available for some time depending on usage. The reason we can’t specify exactly how long is fundamental to our use of the Least Recently Used (LRU) algorithm. Additionally, mobile operating systems retain the ability to reduce or remove an app’s stored data when device storage runs low.

This cached data includes:

1. Article text

In discussion with you, we can alter this to increase or decrease the amount that is fetched. For example, you may want the background downloads to include the article images, because you have a lot of image-centric content. This will substantially increase the data usage for both you and your users, but may offer an improved reading experience.

Background fetching of content

In addition to the user-initiated methods of downloading content mentioned above, Bolt uses background fetch in order to maximise the availability of fresh content. This means that the app periodically wakes up when backgrounded and fetches content from the server. What content we fetch is based on a heuristic which prioritises content from timelines the user frequently visits. This means that some timelines might not be refreshed in the background, particularly in the case of apps with a large number of timelines. This is what will be actively fetched:

1. The first timeline in the first timelinegroup tab
2. The saved timeline
3. "Interacted" timelines, but only if you've interacted with them within the last 3 days. You're considered to have interacted with a timeline if: 
   1. You scroll a short distance down that timeline
   2. You've read 3 articles from that timeline in the last 72 hours

We also default to only prefetching the first 50 articles of a timeline. This should be reduced in the case of apps with a large number of timelines.

The frequency and timing of this content refresh is dictated by the operating system, and is likely to happen more regularly the more a user engages with the app. The volume of content fetched is also controlled by the operating system, as the app is effectively given a certain amount of resource (time, storage and bandwidth) and we’ll do the best we can in that time. Furthermore, the operating system chooses the order in which the queued files are downloaded, hence the articles not necessarily being fetched in the same order as they’re listed on the timeline

Background push

It’s also possible to proactively trigger a background content fetch via a silent push notification, this will have the same effect described above, just at a time of your choosing. This is particularly useful in the case of apps with clear usage patterns (i.e. a morning edition) or shortly after any other notable content drop.

It is possible to trigger a specific edition download using background push. These silent notifications must include a single edition ID in the payload, and that edition will then be downloaded in full. We're expanding our automated notification capabilities to optionally send such a notification whenever a new edition is published.