[hernan7]

I wouldn't say that the articles' metadata (URL, title, date of download, maybe thumbnail of the 1st page) is downloaded content. It's clearly user-generated, and should be in the "home" of the app IMHO.

The articles themselves, yes, send them to the cache. If the user needs to reclaim the storage used up by the articles, let the OS delete them. Then, when the user needs to read the article again, it will take some time to download. But don't get into an "all articles gone" situation. Just my 2 cents.

[masklinn]

I'd submit that this is, in some ways, worse: instead of all articles being gone they're now all grayed out, so the user knows they were here, can still see there, but if he's offline he can not access them because only the metadata is left, the data itself is gone.

[luchak]

What problem are you trying to fix? If I'm offline, what good is being able to see my article list if I can't read the articles? If I'm online, why do I feel any less irritated when I try to go back to an article I was just reading only to find that I need to wait for it to download again?

[adgar]

The problem fixed is that the user has an indication as to what happened to all of their saved articles. That's a very big difference. It's not a full solution, as the parent noted, but the UX is far superior.

[scdc]

I thought Instapaper scraped the page and stored that, to accommodate sites that require login for access. So not trivial to just re-download the articles. Plus the whole point is to have them available when you're offline.

I'd say in this case, the content is user-generated and should be backed up.

[masklinn]

That's a tough line to argue: the scraped page is actually stored by Instapaper (otherwise you could not access it from the website), so you re-download it from there, and technically it's not user-generated it's at best user-curated.

But this does indeed defeat the point of having it offline, which is a significant part of IP's purpose.