Live data from Hacker News

IOS 5's "Cleaning" Behavior

marco.org

21–30 of 207 posts

Re: IOS 5's "Cleaning" Behavior

#21
post #15

I'm sympathetic to Marco's blog post here, but I wonder if he's failing to interpret the two paragraphs from the documentation within the context of Instapaper's purpose. With respect to point #1, and in the context of what Instapaper is for, the user is intending to read an article offline, and the local copy of the article was generated by the user's intent (and can, therefore, be considered user-generated even tho…

But it doesn't make sense to back this data up to iCloud, which is what happens to the Documents folder.

Re: IOS 5's "Cleaning" Behavior

#22
post #15

I'm sympathetic to Marco's blog post here, but I wonder if he's failing to interpret the two paragraphs from the documentation within the context of Instapaper's purpose. With respect to point #1, and in the context of what Instapaper is for, the user is intending to read an article offline, and the local copy of the article was generated by the user's intent (and can, therefore, be considered user-generated even tho…

But it doesn't make sense to back this data up to iCloud, which is what happens to the Documents folder.

Really? If I generate an offline copy of an article on my phone, wouldn't I want to have access to it on my iPad? Why wouldn't I want the truth to be in the cloud?

Re: IOS 5's "Cleaning" Behavior

#23
I don't understand Apple's logic here. You can't reconcile the idea of "cleaning because you can redownload" with "available offline". As soon as you clean up, you are going to break offline uses.

I would guess the idea is to help enable these 500 MB per issue magazine downloads. You download a new issue, you nuke some old issue, no one cares. As long as that wasn't an issue you cared about.

Re: IOS 5's "Cleaning" Behavior

#24
post #7

Clearly, apps that cache data need to be modified to show the difference between having no data and having no data cached. IMAP clients have dealt with this, for example; they show a message like "the contents of this folder are not available offline". Perhaps Apple could have made cache cleaning opt-in on a per-app basis until iOS 6, though.

The main issue is that iOS is deciding that you don't need something offline without asking you. I don't want my cached email to turn out to have been deleted because I downloaded something else entirely.

Many people would prefer the old method, where it would say you were out of space, and you would have to go free up some space.

Re: IOS 5's "Cleaning" Behavior

#25
post #22

Earlier quoted context omitted.

But it doesn't make sense to back this data up to iCloud, which is what happens to the Documents folder.

Really? If I generate an offline copy of an article on my phone, wouldn't I want to have access to it on my iPad? Why wouldn't I want the truth to be in the cloud?

Because there's no point in burning your cloud storage, Apple bandwidth and prolong backup times when those articles can be easly re-downloaded from Instapapers servers on iPad.

Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.

Re: IOS 5's "Cleaning" Behavior

#26
post #8
post #2

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 t…

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.

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.

Re: IOS 5's "Cleaning" Behavior

#27
post #14

Apple's in a tight spot here - either they leave things as they are and piss off developers (and, by fiat, piss off users), or they have to start forcing users to more proactively manage their remaining space. One can probably easily imagine an interface for showing the user how much data a particular app is using and allow them to nuke the temporary stuff. It might even look beautiful. It might even be fun to use. B…

iOS 5 now lets you see per app space usage. (it's under Settings > General > Usage) I don't see anyway to delete that temp data, however, only the app itself (for non-apple apps).

That's only the data that will be backed up to iCloud though, so it probably doesn't include cache/tmp.

Re: IOS 5's "Cleaning" Behavior

#28
post #25
post #22

Earlier quoted context omitted.

Really? If I generate an offline copy of an article on my phone, wouldn't I want to have access to it on my iPad? Why wouldn't I want the truth to be in the cloud?

Because there's no point in burning your cloud storage, Apple bandwidth and prolong backup times when those articles can be easly re-downloaded from Instapapers servers on iPad. Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.

...when those articles can be easly re-downloaded from Instapapers servers...

My premise, in point #2, is that this actually isn't the case with respect to Instapaper's raison d'être. In fact, that's sort of the premise behind much of Marco's post too.

Re: IOS 5's "Cleaning" Behavior

#29
post #25
post #22

Earlier quoted context omitted.

Really? If I generate an offline copy of an article on my phone, wouldn't I want to have access to it on my iPad? Why wouldn't I want the truth to be in the cloud?

Because there's no point in burning your cloud storage, Apple bandwidth and prolong backup times when those articles can be easly re-downloaded from Instapapers servers on iPad. Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.

> when those articles can be easly re-downloaded from Instapapers servers on iPad.

That's kind-of the issue though, is it not? One of Instapaper's strength is that it provides for reading in a nicely formatted and offline way. You don't need a connection to go through your IP stack, unless iOS has decided to clean out everything.

Post reply on HN