I think Graham is mostly talking about OS X while you are obviously on iOS, Alex….
-Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com On Aug 22, 2012, at 17:02, Alex Zavatone <z...@mac.com> wrote: > Since the preferences folder lives in the app, the preferences are deleted > when the app is deleted, or reinstalled. That's what I've seen. > > According to the docs, (and the scratch files in your /library folder if you > use the simulator, everything is in the app and nowhere else. If reality is > different, I wonder why it conflicts with what the documentation says. > > If "every app is an island", then I don't see how what you say an be true. I > hope you are right, however. > > And restricting general access to the file system is a royal PITA. > > On Aug 22, 2012, at 7:37 PM, Graham Cox wrote: > >> >> On 23/08/2012, at 1:18 AM, Alex Zavatone <z...@mac.com> wrote: >> >>> Regarding Sandboxing on Mac OS or iOS, the situations I want to see >>> addressed are these: >>> >>> The app gets regularly updated. Preferences must exist out side of the >>> app. What easy and straightforward method that does not require the >>> developer to jump through hoops supports preservation of app preferences >>> when an app may be deleted or upgraded WITHOUT using "the cloud", as this >>> is completely in violation of many companies' policies. >> >> >> Well, much as I hate the sandbox implementation (and note, that's the >> implementation, not necessarily the concept, though I believe that the >> concept as it stands isn't well thought-through) this particular aspect >> isn't a major factor. >> >> Your preferences live in your sandbox, to which you have free access without >> jumping through any hoops, as long as you use the usual directory discovery >> APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app >> could be a problem but AFAIK the sandbox for an app is not automatically >> deleted if you trash an app in Mac OS (in iOS, that's another thing, as you >> have only one means to trash an app and it deletes its sandbox). The sandbox >> itself is not inside your app bundle, it lives elsewhere, so you can trash >> the app and leave its sandbox behind. Since the sandbox is identified using >> the bundle ID, a new version of the app will inherit the old version's >> sandbox. >> >> Where life is made difficult is with more general access to the file system, >> which is a perfectly legitimate thing to do. A user stores various media all >> over the file system and there is no reason why an app shouldn't have access >> to it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also >> manage media and it is perfectly reasonable for another app to want access >> to that data. Doing this in a manner that is consistent across OS versions, >> sandboxing, localizations and so on is extremely difficult if not impossible >> right now. Apple are severely handcuffing us on the sandboxing front, but >> are not giving anything back to sweeten the deal. If they provided a >> sanctioned API for accessing media consistently that would go a long way, >> for me at least, to accept sandboxing. Trying to work around this is proving >> impossible with the current sandbox implementation - there are too many >> opaque hacks in the system that mean you cannot trust the URLs you get from >> anywhere to actually point to the right place, and you also have to >> hard-code paths in your entitlements which are extremely fragile under both >> localisation and system updates. (For example, if I add a temporary >> entitlement to ~/Pictures/iPhoto Library, if that location changes, or is >> named differently, my app stops working. Note the name of the iPhoto Library >> did subtly change between 10.7 and 10.8 - the space is a different unicode >> character now). >> >> The only bright spot in all of this is the fact that on Mac at least you >> have a channel other than the App Store to deliver apps, but since the App >> Store is responsible for 90% of our sales, it would be commercial suicide to >> leave it. So we're stuck. >> >> The other aspect of this is that the way the App Store staff treat the >> developer in the face of sandboxing issues is seriously hurting developer >> relations and Apple's image. But that's a separate issue I suppose. I do >> remember a time when Apple's developer relations were second-to-none. Oddly, >> the company was on death's door at the time. Success (which we've all had a >> small part to play in) breeds contempt, it seems. >> >> --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
