IOS5 Breaks Data Storage and Crushes My Soul(gaiagps.com)
gaiagps.com
IOS5 Breaks Data Storage and Crushes My Soul
http://www.gaiagps.com/news/article/iOS5%20Breaks%20Data%20Storage%20and%20Crushes%20My%20Soul
8 comments
I read all the comments in this thread, and it surprises me that so many people have a hard time imagining a case where the user wants to store several gigabytes of data locally - maybe 10 gigs - but not have that data backed up to a cloud.
As a user, I can't imagine a class of data that is so important it should never be reclaimed to save space, and is so worthless it should not be backed up.
The important use case is what should happen when you lose your phone/tablet and buy a replacement. Or wipe it. Should the data be restored or should it be lazily regenerated/redownloaded?
For map cache data, re-download it. Otherwise, the map app runs fast at the expense of all the other apps on the device.
Data that has been preloaded to read offline (e.g., Instapaper) should be stored in Documents. If I lost my iPad, I would not want to have to manually reload a bunch of articles when I got a replacement.
I understand that IOS5 has gratuitously broken a lot of apps, and the new regime may have been communicated badly. (May have. I'm not an IOS developer; I don't know what the developer documentation says.) But IOS is user-centric, not dev-centric.
The important use case is what should happen when you lose your phone/tablet and buy a replacement. Or wipe it. Should the data be restored or should it be lazily regenerated/redownloaded?
For map cache data, re-download it. Otherwise, the map app runs fast at the expense of all the other apps on the device.
Data that has been preloaded to read offline (e.g., Instapaper) should be stored in Documents. If I lost my iPad, I would not want to have to manually reload a bunch of articles when I got a replacement.
I understand that IOS5 has gratuitously broken a lot of apps, and the new regime may have been communicated badly. (May have. I'm not an IOS developer; I don't know what the developer documentation says.) But IOS is user-centric, not dev-centric.
Imagine I have a Flight Charts application. The app automatically downloads charts for the entire US, and when the charts are soon to be updated, it also grabs them ahead of time so it can update the charts when the cycle changes, without needing to spend hours downloading new charts.
Now imagine when they go to fly and they turn the app on, half of the charts disappear. Are you suggesting I architect the app to go ahead and download the new maps when this happens?
Because if that's your suggestion, the Air Force and commercial airlines no longer wants to use my app. Those charts darn well better be on board when they expect them to be. They need to be able to reliably have both gigs of current charts, and gigs of upcoming charts, ready to fly. They might fly to China or elsewhere they won't be able to update, enroute.
Now imagine when they go to fly and they turn the app on, half of the charts disappear. Are you suggesting I architect the app to go ahead and download the new maps when this happens?
Because if that's your suggestion, the Air Force and commercial airlines no longer wants to use my app. Those charts darn well better be on board when they expect them to be. They need to be able to reliably have both gigs of current charts, and gigs of upcoming charts, ready to fly. They might fly to China or elsewhere they won't be able to update, enroute.
You have successfully argued that the data is too valuable to purge. You haven't argued that it's not worth backing up. In this case, it sounds like it should be stored in Documents and backed up.
(Are you the original article's author? If so, sorry I misunderstood the lifetime of your mapping data.)
(Are you the original article's author? If so, sorry I misunderstood the lifetime of your mapping data.)
It's so much data that any user of the app would have to have an iCloud paid plan, and it would also swamp any 3G usage plan on an iPad. Both of those would put a chill on sales.
Also, is iCloud secure enough for sensitive military charts? Maybe it is, but even so, explaining that to buyer is going to be a problem.
If Apple insists on this course of action, the eventual solution is probably vector maps. But a good vector mapping API doesn't exist for developers, doesn't work for many maps that only exist as rasters, and will take much R&D to make into a reasonable reality. In the meantime, I would hope that Apple chooses to unbreak the hundreds of popular mapping apps they broke last week.
If Apple insists on getting rid of the old behavior of the Caches folder, they need to deprecate it over the course of a year or so. None of us even figured out this would happen until after iOS5 went live, despite extensive testing from many devs. How this went live is beyond me.
Also, is iCloud secure enough for sensitive military charts? Maybe it is, but even so, explaining that to buyer is going to be a problem.
If Apple insists on this course of action, the eventual solution is probably vector maps. But a good vector mapping API doesn't exist for developers, doesn't work for many maps that only exist as rasters, and will take much R&D to make into a reasonable reality. In the meantime, I would hope that Apple chooses to unbreak the hundreds of popular mapping apps they broke last week.
If Apple insists on getting rid of the old behavior of the Caches folder, they need to deprecate it over the course of a year or so. None of us even figured out this would happen until after iOS5 went live, despite extensive testing from many devs. How this went live is beyond me.
The flight chart data is already backed up, is it not?
One way to get to the issue is to ask these questions, I think: "is the data copied from another source?" and "is the data needed in offline use?" (where data is some amount of data larger than Apple can handle)
One way to get to the issue is to ask these questions, I think: "is the data copied from another source?" and "is the data needed in offline use?" (where data is some amount of data larger than Apple can handle)
N,N = Documents
Y,N = Cache
N,Y = Documents
Y,Y = ???
Apple wants Cache (stuff that can be re downloaded and not core to the experience, just to improve performance) to actually be deletable when space is low. A valid point.
Developers want a place to store app information that is critical and sometimes a very important part of the app(example main feature of instapaper is to view offline content). This should not be backed up since its redundant and when the phone needs to be restored(rarely) this data can be re-downloaded. Also backing up will be slow and destroy user experience.
Solution make another location which is used for storing the data(not backed up) so then all are happy. Maybe you can have data from hidden directories not backed up inside the Documents directory. Then Apple can delete caches in apps like browsers. User critical data like settings can be backed up and app critical data that need not be backed up can also exist
Developers want a place to store app information that is critical and sometimes a very important part of the app(example main feature of instapaper is to view offline content). This should not be backed up since its redundant and when the phone needs to be restored(rarely) this data can be re-downloaded. Also backing up will be slow and destroy user experience.
Solution make another location which is used for storing the data(not backed up) so then all are happy. Maybe you can have data from hidden directories not backed up inside the Documents directory. Then Apple can delete caches in apps like browsers. User critical data like settings can be backed up and app critical data that need not be backed up can also exist
In the Stack Overflow article linked from the parent, the dev describes the scenario this way: "No, users explicitly download sets of map tiles, that they will need when they are in the forest, or flying their airplane, or sailing their boat."
If it's that important, it SHOULD go in a folder that's backed up/synced to the cloud or so it seems to me. What happens when users conditioned to expect that all their documents will automagically appear on all their Apple products discover that the maps they set up on their iPad at home aren't on on their iPhone when they get out in the field? Food for thought.
If it's that important, it SHOULD go in a folder that's backed up/synced to the cloud or so it seems to me. What happens when users conditioned to expect that all their documents will automagically appear on all their Apple products discover that the maps they set up on their iPad at home aren't on on their iPhone when they get out in the field? Food for thought.
You have a valid question about whether or not map data should be backed up locally. But the answer in practice, as the author pointed out, is no. It takes time, which isn't fun to spend, and as you pointed out, potentially money.
($10 isn't a lot until you divide it by the dollar value of what you're getting, namely virtually nothing in the case of map tile backup.)
Why back up? Peace of mind for when your phone dies, is the reason. Backing up map tiles, while marginally useful on a restore, becomes not worth the time spent because there is no peace of mind benefit--the map tiles are already backed up. All the user experiences is that the sync is taking forever.
($10 isn't a lot until you divide it by the dollar value of what you're getting, namely virtually nothing in the case of map tile backup.)
Why back up? Peace of mind for when your phone dies, is the reason. Backing up map tiles, while marginally useful on a restore, becomes not worth the time spent because there is no peace of mind benefit--the map tiles are already backed up. All the user experiences is that the sync is taking forever.
No, users shouldn't have to back up 5 gigs of maps to their 5 gig iCloud storage.
Making an assertion isn't answering the question.
Modding someone down for stating a fact isn't legitimate discussion, either. Unless Apple somehow guaranteed that stuff in the Cache folder was permanent (which more or less violates the definition of "cache" as widely understood) you relied on undocumented behavior, and you got burned by it. It happens all the time (it's happened to me before, definitely). If the data is that important (and I agree that it could be in this cae) the user needs to take the hit and pay for permanent cloud storage. That 5 gigs of storage would cost them a whopping $10.00 per year at Apple's announced price. BFD.
Maybe i'm not understanding this correctly (I'm not an iPhone dev), but why don't you just store the data in the Documents folder ? Or maybe make it the user's choice:
1. Save data in the Documents folder - > slower itunes backup
or
2. Save data in the Caches folder -> Arbitrarily deletion of data
The whole point of this conversation is that a real class of problems exist (think "offline Google Maps": download all of France to your phone, so you can have driving directions while you don't have data roaming on your trip) that wants option 3: not backed up (as you just downloaded a gigabyte of data that you can download again any time you want), but guaranteed to be available when offline (as the whole point was to accidentally have your data get deleted while you are travelling through Germany on your way to France).
Not to trivialize the problem, but I can't be the only one to think "Hey, maybe it's not a good idea to store permanent data in a directory called Caches".
That was exactly what I was thinking while reading this.
Have you ever read any of Raymond Chen's "oldnewthing" blog? He talks a lot about app compatibility between Windows versions, and how they are forced to not change certain undocumented behaviors because developers end up relying on them regardless of the documentation.
I didn't read the docs for iOS "caches" storage but I have a feeling this is another case of Apple's "break clients for a better OS" view on app-compat, compared to the MS's "buggy-er OS that still runs Windows 1.0 apps" view (I'm primarily a Windows dev, writing this from my iMac, so I'm not really biased either way, just an observation/guess).
Have you ever read any of Raymond Chen's "oldnewthing" blog? He talks a lot about app compatibility between Windows versions, and how they are forced to not change certain undocumented behaviors because developers end up relying on them regardless of the documentation.
I didn't read the docs for iOS "caches" storage but I have a feeling this is another case of Apple's "break clients for a better OS" view on app-compat, compared to the MS's "buggy-er OS that still runs Windows 1.0 apps" view (I'm primarily a Windows dev, writing this from my iMac, so I'm not really biased either way, just an observation/guess).
[deleted](1)
If Apple could offer a way for users to allocate a fixed amount of space for certain apps and opt out of syncing certain data per app, it wouldn't be a problem.
What's more this change suddenly happened. There was no bright red warning sign going into the release, these developers are finding out the hard way.