Odd, my experience has been exactly the opposite. Unless I bind to
NSUserDefaultsController, I don't get notified when other parts of my app
change a default. So I guess the answer is: It always breaks on Uli's work
Mac :-)
Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
I guess Cocoa just likes me more. :-)
Thanks for the answers.
--
Seth Willits
On Mar 18, 2013, at 7:44 AM, Uli Kusterer wrote:
Odd, my experience has been exactly the opposite. Unless I bind to
NSUserDefaultsController, I don't get notified when other parts of my app
change a default.
I have a main window which has a child/auxilary window. When the user presses a
button in the UI the main window controller inits the child, assigns itself as
the object for the child window's myOwner property and then launches the child
window as a modal via NSApp runModalForWindow. This
On Sat, 16 Mar 2013 11:14:55 +0100, Jean Suisse said:
According to you, what would be the best course of action ? Should I
write into my application's bundle ?
Never write into your application bundle. It will fail in many cases, most
notably: read-only file systems and App Sandbox.
Cheers,
On Mar 18, 2013, at 1:46 PM, Sean McBride s...@rogue-research.com wrote:
On Sat, 16 Mar 2013 11:14:55 +0100, Jean Suisse said:
According to you, what would be the best course of action ? Should I
write into my application's bundle ?
Never write into your application bundle. It will fail
Normally for shared preference or data you would write to a shared file in
/Library/Application Support/companyname/filename, but you have to take
special care if you're sandboxing your app.
Indeed. It would seem this requires to be root.
Never write into your application bundle. It will
On Mar 18, 2013, at 2:12 PM, Jean Suisse wrote:
Normally for shared preference or data you would write to a shared file in
/Library/Application Support/companyname/filename, but you have to take
special care if you're sandboxing your app.
Indeed. It would seem this requires to be root.
On 19/03/2013, at 10:07 AM, Rick Mann rm...@latencyzero.com wrote:
I'm a little bit surprised that I can't add my NSCoding-conforming object
directly to NSUserDefaults. Why is this? Is it just a long-standing oversight
of NSUserDefaults, or is there a technical reason why it doesn't work?
On Mon, Mar 18, 2013, at 04:07 PM, Rick Mann wrote:
I'm a little bit surprised that I can't add my NSCoding-conforming object
directly to NSUserDefaults. Why is this? Is it just a long-standing
oversight of NSUserDefaults, or is there a technical reason why it
doesn't work?
A couple possible
On 19/03/2013, at 10:21 AM, Rick Mann rm...@latencyzero.com wrote:
t seems like an NSArchiver subclass could call -encodeWithCoder: to create a
dictionary that could live in a plist file (as opposed to creating an
NSData), and it could easily be used transparently. The advantage to this is
I'm using NSUbiquitousKeyValueStore (KVS) to store some basic prefs for my app.
I always write to NSUserDefaults and iCloud each time I update things. As I was
building up my code, I was running into some issues getting the coding right,
so I ended up with data in NSUserDefaults (on local
On Mar 18, 2013, at 4:21 PM, Rick Mann rm...@latencyzero.com wrote:
It seems like an NSArchiver subclass could call -encodeWithCoder: to create a
dictionary that could live in a plist file (as opposed to creating an
NSData), and it could easily be used transparently. The advantage to this
On Mar 18, 2013, at 16:46 , Jens Alfke j...@mooseyard.com wrote:
It wouldn’t be human-readable. NSArchiver doesn’t produce readable output.
Even if you made a version whose output was a tree of directories, it would
still be pretty unreadable due to all the metadata in it. (After all, XML
On Mar 18, 2013, at 16:30 , Kyle Sluder k...@ksluder.com wrote:
2. NSCoding is not trustworthy. Your app must blindly trust any object
archive it loads. This is a significant security risk.
I don't think that argument is any more true for what I'm proposing than what
what exists today.
--
On Mar 18, 2013, at 5:14 PM, Rick Mann rm...@latencyzero.com wrote:
NSArchiver calls look like -setValue:forKey:, so it seems reasonable that the
protocol could be usurped to write out fairly clean user defaults plists.
There’s a lot of other gunk the archiver needs to store so it can handle
On Mar 18, 2013, at 5:15 PM, Rick Mann rm...@latencyzero.com wrote:
2. NSCoding is not trustworthy. Your app must blindly trust any object
archive it loads. This is a significant security risk.
I don't think that argument is any more true for what I'm proposing than what
what exists
On Mon, Mar 18, 2013, at 05:15 PM, Rick Mann wrote:
On Mar 18, 2013, at 16:30 , Kyle Sluder k...@ksluder.com wrote:
2. NSCoding is not trustworthy. Your app must blindly trust any object
archive it loads. This is a significant security risk.
I don't think that argument is any more true
17 matches
Mail list logo
