2 ms·
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
by kbob 15y ago
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.
- andrewljohnson 15y agoImagine 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.
- kbob 15y agoYou 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.)
- andrewljohnson 15y agoIt'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.
- beej71 15y agoThe 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) N,N = Documents Y,N = Cache N,Y = Documents Y,Y = ??? What about that last case? It's even more annoying with map tiles than flight charts, if you've ever spent time backing up map tiles when you know they're already backed up on the main map tile server.