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

31–40 of 207 posts

Re: IOS 5's "Cleaning" Behavior

#31

Post by adgar »

luchak wrote: post #12
hernan7 wrote: 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…

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?

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.

Re: IOS 5's "Cleaning" Behavior

#32

Post by masklinn »

JeffDClark wrote: post #13

The whole idea of an app like Instapaper (or any of the other examples presented) is that the "stuff" that is saved for later is all user-generated content. Some articles may even vanish (different location, move behind a paywall, deleted, etc...). In this case those articles would become inaccessible when the OS deletes the cache. It seems that the argument that only the list of metadata is user-generated can apply…

> Some articles may even vanish (different location, move behind a paywall, deleted, etc...). In this case those articles would become inaccessible when the OS deletes the cache.

As far as I know, all scraped articles are stored in Instapaper's server and downloaded from there, you don't get them directly from the source page.

Re: IOS 5's "Cleaning" Behavior

#33

Post by mynegation »

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.

Why there is no point in burning Apple's bandwidth, but there is a point in burning Instapaper servers' bandwidth?

I don't care how Apple (or Marco) solves the problem, but I sure do not want to lose Instapaper articles at random.

Re: IOS 5's "Cleaning" Behavior

#34

Post by psychotik »

Isn't NSApplicationSupportDirectory for stuff that isn't "Documents" and yet needs to be managed as app state (not in 'Caches')? Why not just use that instead? That's what my app does and it seems to be OK with iOS 5.

Re: IOS 5's "Cleaning" Behavior

#35

Post by sudoman »

ender7 wrote: 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…

This general problem is a symptom of a major issue regarding the use of software that does not respect the freedom of its users. Every non-apple developer and user is required to bend to the will of the programmers who develop the proprietary iOS. Any negative choices or limitations imposed by Apple Inc. are virtually uncircumventable.

On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.

If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.

Re: IOS 5's "Cleaning" Behavior

#36

Post by droithomme »

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 directory as well.

Re: IOS 5's "Cleaning" Behavior

#37

Post by zamfi »

There needs to be a file storage location that behaves the way Caches did before iOS 5

I'm confused. If the goal is for documents to be available in the near future in offline form, why not keep documents in /Documents until the user has read them (or some sane amount of time has passed), and then move them to /Caches or some temporary storage?

I've never used Instapaper, so perhaps documents are only stored until read anyway?

Re: IOS 5's "Cleaning" Behavior

#38

Post by wrs »

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 it. Once you have system-level cloud sync, don't you want to let Apple do the work? Sync is hard, and it isn't really the core value of Instapaper.

Edit: I was wondering about iCloud only for iOS 5/MacOS 10.7.2 devices with iCloud accounts. But that story does fall apart for people with mixed devices. So never mind.

Re: IOS 5's "Cleaning" Behavior

#39

Post by sbov »

masklinn wrote: post #29
Mavrik wrote: post #25

Earlier quoted context omitted.

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.

You're quoting that out of context.

His point is, if you back it up to iCloud, to get any use out of the backup, you need to be online. Therefore it's a waste, because in that scenario, you can just download it from Instapaper anyways.

Re: IOS 5's "Cleaning" Behavior

#40

Post by hamrickdavid »

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…

Unfortunately you can't write data to your application bundle. That folder is read-only.
Post reply on HN