Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IOS 5's "Cleaning" Behavior

marco.org

Post reply on HN
Print view View original

41–50 of 207 posts

Re: IOS 5's "Cleaning" Behavior

#41

Post by ryanpetrich »

droithomme wrote: post #36

That's pretty interesting. So, the three non-backed locations are tmp, Caches and the Application Bundle. tmp and Caches are now swept. So, if you store your real cache stuff in the Application Bundle, it won't be backed up or auto-deleted. But maybe it gets trashed when you update the app. I wonder if OS X, in line with its trend to be more like iOS, is going to start automatically clearing the ~/Library/Caches dire…

The application bundle is signed. Writing to that location should be blocked by the sandbox.

Re: IOS 5's "Cleaning" Behavior

#42

Post by Scorponok »

Maybe the solution is to make it a choice for the user? An option to "clean up documents when space is low on the device" in the instapaper options. If checked, stuff gets stored in cache. If not, in documents.

That way, the default behavior is that "download something = want to keep it on device", but users can do the other one too if they want. I don't think the option is particularly useful, but it might make the app reviewer happy?

Re: IOS 5's "Cleaning" Behavior

#43

Post by voxmatt »

smackfu wrote: post #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.

I had the exact same question and your idea as to the answer is interesting. Perhaps this new behavior is in response to Newsstand's ability to automatically download new issues--users may allow those to stack up without any thought and run out of space. The question then becomes: why not just enforce this behavior for Newsstand?

Re: IOS 5's "Cleaning" Behavior

#44

Post by lukeredpath »

Lots of people are focussing on Marco's particular use case in the comments, and I think it's a valid one, but this extends beyond simple documents.

There is a category of data that is aimed at offline use. Streaming apps like Spotify, that let you download playlists for offline use. GPS apps that download hundreds of MB of map data. You get the idea.

On one hand, this data is a form of cache. The data is always available elsewhere (on the content provider servers) and it can be restored if necessary in a worst case scenario. But the key word here is "offline". This is the kind of data that, by definition depends on being around if the user is offline and therefore cannot be easily restored on demand, when the user needs it.

Obviously, having all of this stuff backed up to iCloud and using up GBs of people's capacity is not feasible or even logical. So this kind of data does not belong anywhere that iCloud will back up. But it must be stored somewhere that is safe from being purged.

Yes, a users GPS maps can be restored eventually but that doesn't help them when they are stranded in the middle of nowhere with nothing but a weak GPRS signal and all of their maps gone.

Apple have made an almighty cockup in overlooking the "offline data" use case.

In Marco's case, I'd agree that the articles represent user data that should be stored somewhere like Application Support, which will be backed by iCloud but I think that's probably fine in this case.

Re: IOS 5's "Cleaning" Behavior

#45

Post by akmiller »

wrs wrote: post #38

It seems fair to say that Instapaper's version of an article can't be "redownloaded" for various reasons (offline, paywall, article removed, etc.) so it would be OK to put it in the Documents folder. The argument against that is that you're now syncing that article with iCloud in addition to Instapaper. But I wonder whether the correct answer is instead to eliminate Instapaper's sync feature, and just let iCloud do i…

Instapaper is more than just an iOS application, so no, iCloud is not the answer for syncing.

Re: IOS 5's "Cleaning" Behavior

#46

Post by lukeredpath »

baddox wrote: post #19
jmcnevin wrote: post #10

Is it possible that a user could use Instapaper to save a document that they wouldn't be able to download later, even if they had access to an internet connection? If that's possible, I think Instapaper would have every right to store things in the Documents folder, since you're asking it to create something more akin to an archive than a temporary cache of data.

That seems to be the only way for Instapaper to give their users a reasonable experience, but it's still a bad solution. It doesn't make much sense for the Instapaper app to backup its users' cached articles to iCloud, when the whole point of the app is to backup the articles on the iPhone. If you have access to iCloud, you have access to the original article, so it's a waste of bandwidth. Not to mention that Instapa…

I honestly don't think there is an issue with allowing Instapaper content to get backed up to iCloud here. The analogy of a user created archive is a good one.

If people don't want the benefit of having their Instapaper content transfers across their devices automatically (and I do think this is a good feature) then they are free to disable iCloud backup for Instapaper in Settings.

Re: IOS 5's "Cleaning" Behavior

#47

Post by smokey_the_bear »

I write several offline mapping apps, and this is totally throwing us for a loop. We're recommending our power users not upgrade to iOS 5. Users download gigabytes of maps to their cache directory, they don't want to eat their iCloud allotment with that, or their slow their iTunes sync. But they also don't want to have to download those maps again, or find themselves in the middle of the woods without the maps they downloaded.

Re: IOS 5's "Cleaning" Behavior

#48

Post by andrewljohnson »

smokey_the_bear wrote: post #47

I write several offline mapping apps, and this is totally throwing us for a loop. We're recommending our power users not upgrade to iOS 5. Users download gigabytes of maps to their cache directory, they don't want to eat their iCloud allotment with that, or their slow their iTunes sync. But they also don't want to have to download those maps again, or find themselves in the middle of the woods without the maps they d…

I guess I will have to write a blog post for us too.

I wonder if there is any chance that Apple will change how this works - it seems like this should be doomsday for a large swath of apps.

(married to Smokey and partner on all these apps!)

Re: IOS 5's "Cleaning" Behavior

#49

Post by esutton »

Mavrik wrote: post #25
pohl wrote: 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.

So really what would make everyone is a type of Selective_Sync, i.e. there are three file types. those that are ephemeral and can be deleted. those that are ephemeral but should only deleted if given permission And those that need to be backed up.

Re: IOS 5's "Cleaning" Behavior

#50

Post by lukeredpath »

sp332 wrote: post #18
jmcnevin wrote: post #10

Is it possible that a user could use Instapaper to save a document that they wouldn't be able to download later, even if they had access to an internet connection? If that's possible, I think Instapaper would have every right to store things in the Documents folder, since you're asking it to create something more akin to an archive than a temporary cache of data.

I could be wrong, but I think all the articles are on Instapaper's servers, so you can re-download them.

But only if you are online, which defeats the object of "offline access".
Post reply on HN