Because of the annoyance of sandboxing on iOS, I've been thinking how to write simple prefs outside the app so that I know the pref is written when I write it (no, iCloud is not a suitable solution).
Currently, I'm thinking of these options: Declare an address, a music file or a picture as a database. Write to it. In a PNG image, we have 8 bits of R, G, B and A (at least) so we can get 4 ascii chars per image using each value as an ASCII character. Considering that there are a boatload of ascii chars that we never use, this could be extended rather easily if needed. (We really only need chars 32 to 126 for basic English (94 chars) so without much effort, it's easy to squeeze two ASCII chars into one 8 bit group by using the value of first four bits as one char and the second four bits as the second char. This means that one 8 bit RGBA PNG pixel can be treated as a block of 8 ASCII characters. TL;DR: 1 pixel = 8 chars. It's seriously shameful that we have to resort to this level of BS thanks to Apple's sandboxing policies, to simply store a damn preference to the device. The amount of time we have to waste to simply find out a method to write to our device is sad. Thanks Apple. On Jun 21, 2012, at 2:17 PM, Michael Domino wrote: > Hi all, > > My preferences code strictly uses the CFPreferences api and has worked > reliably since Tiger. On Mountain Lion Preview 4 (with the recent update), > though, preferences writing has been erratic, sometimes my preferences are > updated correctly, sometimes not. Are there any known issues with > CFPreferences on Mountain Lion? > > I found this similar problem another developer is having: > > https://groups.google.com/forum/?fromgroups#!topic/munki-dev/fzp3SubBTJ0 > > There is a statement there, "In 10.8 preferences are all cached by a > preference daemon, and the point at which it reads from/writes to disk is not > reliable..." Is that true? Is so, how can one be sure that preferences are > updated at all? Is there any doc on the behavior of cfprefsd? The man page > says basically nothing. > > Thanks, > Michael Domino > _______________________________________________ > > 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/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ 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
