Live data from Hacker News

IOS 5's "Cleaning" Behavior

marco.org

91–100 of 207 posts

Re: IOS 5's "Cleaning" Behavior

#91
post #43
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?

Somewhat of a conspiracy theory - but if the choice for developers is risk losing losing local data or back data up to the cloud unnecessarily, I think they'll choose to store it to the cloud, as they will be the ones blamed when their app "deletes data randomly".

The more storage space taken up by local files being backed up to iCloud, the more people will end up going over their 5GB capacity, and will have to upgrade to the higher capacity plans to cover it. I'm not sure I actually believe this right now, but if they refuse to fix the problem, then I might...

Re: IOS 5's "Cleaning" Behavior

#92

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…

Instead of just saying "don't install iOS5", can't you continue to store files in their Documents, but tell them to flip off the sync switch for your app? http://i.imgur.com/acOje.png

Re: IOS 5's "Cleaning" Behavior

#93
post #35

Earlier quoted context omitted.

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…

For the vast majority of developers of iOS apps the specifics of how their data is stored and backed up do not matter. If they were not forced by Apple to adopt this set of constraints they would make decisions on a whim, it would lead to less freedom for user, because where there is uniformity, there is a power to abstract, there is a freedom to not micromanage. Circumventing design decicions is hard. Learning the s…

So let's all wear the same clothes, eat the same foods, engage in the same pastimes, work the same hours, walk at the same speeds, drive the same car. Then the only abstraction will be in our dreams - the only place we will be free! Our dreams will then be the blessed relief that we will always look forward to as our own little free moment.

Point is, such didactic statements are stupid, as is the whole 'less choice is actually more freedom' mantra.

Put it this way. Say the government mandated one phone. One car. One style of house. One fashion outfit. You don't need any more than that. You're freed from having to micromanage your stuff. Sure, you can wear your outfit any way you want, and get your one car in whatever colour, but hey, uniformity breeds freedom from the enduser, right? Because 'micromanagement' is bad, right?

Re: IOS 5's "Cleaning" Behavior

#94

Earlier quoted context omitted.

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.

It's not just Apple's bandwidth; it's users' iCloud storage, which costs users money.

The user can always choose not to sync Instapaper if he feels its costing him storage (though in reality, I have to wonder how much storage simple articles with occasional images could really take).

I think that has to be the best solution. It's far better to just have everything sync to iCloud and let the user choose to disable it rather than having Instapaper's primary core functionality - being able to read articles offline - not work properly.

Re: IOS 5's "Cleaning" Behavior

#95
post #57

So, people (developers) are going to have to put their stuff in Documents, and instruct users to disable the iCloud sync for their particular app, unless the user really wants to have it eat into their iCloud storage. Would that work?

The whole quagmire is bigger than just flushing Cache. Apple prohibits developers to store stuff that can be regenerated or re-downloaded. So, arguably, you can't just switch to using Documents for downloadable data.

[deleted]

Re: IOS 5's "Cleaning" Behavior

#96
post #57

So, people (developers) are going to have to put their stuff in Documents, and instruct users to disable the iCloud sync for their particular app, unless the user really wants to have it eat into their iCloud storage. Would that work?

The whole quagmire is bigger than just flushing Cache. Apple prohibits developers to store stuff that can be regenerated or re-downloaded. So, arguably, you can't just switch to using Documents for downloadable data.

Is there a source for this? By definition, isn't nearly everything we have on our devices capable of being regenerated or re-downloaded?

This is clearly the crux of the problem -- Apple should allow developers (or, god forbid, users!) the choice to install things in a secure location regardless of "ease of re-download." How do they know when I'll have the bandwidth to re-download?

Re: IOS 5's "Cleaning" Behavior

#97
post #92

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…

Instead of just saying "don't install iOS5", can't you continue to store files in their Documents, but tell them to flip off the sync switch for your app? http://i.imgur.com/acOje.png

That's what I thought, but see marchdown's comment later on this page -- he says: "Apple prohibits developers to store stuff that can be regenerated or re-downloaded. So, arguably, you can't just switch to using Documents for downloadable data." If that's true, it would prevent such a simple solution.

Re: IOS 5's "Cleaning" Behavior

#98
post #88

Earlier quoted context omitted.

I would bet Apple's never going to make this sort of a choice obvious to the user -- it goes against the "just working" (whether or not it works the way you want) they're currently pushing. It sure does worry me to read all these comments though; it seems like you'll never be able to count on an app having the data it needs to run, without re-downloading. As somebody who spends half his day in an airplane or a subway…

Actually a couple video players right now do make this choice available to the user - OPlayer and AVPlayer. They both say something to the effect of "Backup media" in their settings. This simply toggles which location the media is stored in (AVPlayer even seems to move the media on the fly). This is literally exactly how I would implement the choice if I were Marco.

The problem is if the user chooses not to backup the data, it'll get wiped if she runs out of storage space. What would be nice would be to not sync to iCloud AND not get cleaned out.

Re: IOS 5's "Cleaning" Behavior

#99
post #92

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…

Instead of just saying "don't install iOS5", can't you continue to store files in their Documents, but tell them to flip off the sync switch for your app? http://i.imgur.com/acOje.png

We could, but it would involve pushing an update to the app. The 'don't install' is a stopgap for people who may be counting on using their maps this weekend. Additionally, people collect geo information with our app, tracks and waypoints that they like to backup.
Post reply on HN