OK, I admit NSUserDefaults, being a Mac-specific thing (and me being a Mac programmer for the last couple of years), is one of the things I haven't delved into that much... so here are some issues/questions I've come across :
I understand that NSUserDefaults is basically an NSMutableDictionary written as a .plist.
My questions :
Given that I'm running OS X 10.7 (Lion) and having enabled Sandbox, where is my app's .plist file? (I've search in both ~/Library/Preferences/com.example.myapp.plist and ~/Library/Containers/com.example.myapp/Data/Library/Preferences/com.example.myapp.plist but none of these seems valid
I understand that this .plist file is created the first time the app launches, correct?
registerDefaults: is to be used at application launch (e.g. in awakeFromNib) and provide a Dictionary of default values that are immediately stored in the .plist file, and changed only if a different value is set at some point, correct?
When we're setting a specific Key-Value pair, is that pair automatically and immediately saved to the .plist file? And if so, why/when should we use synchronize? (Is using it every single time some value is set an overkill, or should it be reserved for special cases?)
Sidenote : I hope nobody complains about my use of the osx tag. However, I'm really tired of seeing Cocoa Touch / iOS related answers to my (mostly) OSX-related questions. So, here you are... :-)
EDIT : For some really helpful insight on the subject, please have a look at the accepted answer as well as the comments below it.
Answer 1. The home directory is hidden in Lion, so you are not able to enter the path(Without seeing the folder you can not enter inside the folder from Finder). You can use Path Finder to move around your hidden directories.
Answer 2. Not always. There can be multiple plists in a single application. Few gets created at first launch, few at some specific action. Actually it depends when the plist file are created and how to use it.
Answer 3. registerDefaults: registers default values are when the user has not set other values to that property. It will not override whatever the user has stored when the app is opened later. You can use it in anywhere, but as stated it will be used once.
Answer 4. For Mac OSX application there is no performance and overkill issues, however for iOS it has. It is always better to use [[NSUserDefaults standardUserDefaults] synchronize];
Related
I would like to use MapKit (on osx) to display custom map tiles from a .mbtiles (sqlite) database of the sort exported from TileMill.
MBXMapKit looks great, and is almost what I'm looking for. I could see how, with very little modification, MBXMapKit could be tweaked to point to a local .mbtiles database file.
Is there any way to use the MBXMapKit framework to accomplish this without tweaking? I did read the docs, and couldn't find a straightforward answer. I did find a private method on MBXOfflineMapDatabase called -initWithContentsOfFile: which sounds promising and looks like it does what I need -- is there anything to watch out for if I expose and use that method?
Alternate option is to subclass MKTileOverlay and use -loadTileAtPath:result:, which is easy to do, but also requires managing the connection to the sqlite file etc.
Have a look at this for the latest on MBTiles support:
https://github.com/mapbox/mbxmapkit/issues/3
It'll be coming probably in the next release. This should be distinct and separate from both the normal performance cache (NSURLCache) as well as the (also SQLite-backed) offline databases, which are meant for individual tile downloads being placed into a cache one-by-one.
It took me quite some time to work this out, but here is the link that got me on the right path.
https://github.com/mapbox/mbxmapkit/pull/110/commits/8b9fbf3fd56ae804a38c737305f128fd43a8225d
For some reason the method _mbtilesOverlay = [[MBXMBTilesOverlay alloc] initWithMBTilesURL:mbtilesURL]; can not be used on the latest version of MBXMapKit. I just replaced the .m and .h files with the files in the link, and used MBXViewController.m as a guide to get the map view to show the tile overlay.
I'm writing an OS X launch agent (which watches, as it happens, for FSEvents);
it therefore has no UI and is not started from a bundle – it's just a program.
The relevant documentation and sample
code
illustrates persisting FS event IDs between invocations, and does so using
NSUserDefaults. This is clear the Right Thing To Do(TM).
The documentation for NSUserDefaults in the
Preferences and Settings Programming Guide
would appear to be the appropriate thing to read.
This shows only the Application and Global domains as being persistent, but (fairly
obviously) only the Application domain is writable for an application. However
the preferences in the application domain are keyed on the
ApplicationBundleIdentifier, which a launch agent won't have. So I'm at a loss
how such an agent should persist state.
All I can think of is that the Label in the launchd job can act as the
ApplicationBundleIdentifier – it at least has the correct form. But I can't see any
hint that that's correct, in the documentation.
The obvious (unix-normal) thing to do would be to write to a dot-file
in $HOME, but that's presumably not the Cocoa Way. Google searches
on 'osx daemon preferences', and the like, don't show up anything useful,
or else my google-fu is sadly lacking today. Googling for 'set application
bundle identifier' doesn't turn up anything likely, either.
NSUserDefaults:persistentDomainForName looks like it should be relevant,
but I can't work out its intentions from its method documentation.
I've found one question here which seems relevant, but while it's tantalisingly close, it doesn't say where the daemon gets its identifier from.
I've limited experience with Objective-C and Cocoa, which means that by
now I rather suspect I'm barking up the wrong tree, but don't really know where
to look next.
You can (and imo should) have an Info.plist even in a single-file executable.(see http://www.red-sweater.com/blog/2083/the-power-of-plist)
However, NSUserDefaults is a little more questionable. Conceptually, it's intended for user settings, rather than internal state. However, there's no real reason it wouldn't be suited to this, so I'd probably go ahead and do so.
I am doing iOS game development using the cocos2d framework, and I tremendously envy the ability for Eclipse Java programmers to hot swap their code while they are debugging their application (i.e. change out variable values within a method and have the program live update as if you had a REPL without having to recompile).
This seems like something that would be absolutely tremendously helpful when it came to iOS development, where my development environment is (obviously) Xcode and the language I am programming in is Objective C. I have googled around but havent been able to find anything - so I thought I would ask the community.
Does anyone know if there a way to Hot Swap code in Xcode while programming in Objective C?
Thanks in advance
There is a great plugin which allow changing code in live, working APP. It is called InjectionPlugin.
As FAQ says:
How does it work? The Objective-C runtime allows you to load a new version of a class into an application using a bundle even if there is already an implementation linked into the application. Swizzling is used as the bundle is loaded to switch the existing class to use the methods of the new implementation. This can be done repeatedly and works for OSX and iOS applications and on iOS devices.
I made some small video which shows how to install and use this plugin
http://nomtek.com/developers/how-to-install-and-use-injection-plugin-for-xcode/
Hope it helps!
Not possible with the current tools.
Keep in mind that iOS applications are signed -- if you change a single byte you'd have resign the whole thing. One could imagine making it work using runtime's support for dynamically adding and removing methods. But that'd surely require adding some extra stuff to support it on the device, and that's something that malware could easily take advantage of. So it's probably not a feature you'll be likely to see anytime soon.
By the way, Xcode versions 1.x-3.x did have a "Fix and Continue" feature. You could edit as you were debugging, use the Fix and Continue command, and continue running the updated code. I believe it was removed at some point, perhaps due to some combination of: requiring that your project be configured to use "zero link" and perhaps some other things; being less than completely reliable; probably not supporting iOS; the switch to llvm; other changes in Xcode 4. Maybe it'll come back someday -- if you want it back, file a bug -- but again, I think supporting it on iOS would be a challenge.
If you're just talking about changing variable values then you can achieve that surreptitiously via lldb (or, presumably) gdb. Supposing you had:
- (void)uselessMethod
{
NSString *localString = #"I'm some local text";
NSLog(#"%#", localString);
}
And put a breakpoint on the NSLog, at that point you could ask lldb to evaluate a reassignment of localString as a means of performing it. E.g.
po localString = #"Hat"
If you then allow program execution to continue, you should find that the reassignment has stuck. Similarly you can call any method or perform any other sort of assignment.
I've just tested this against Xcode 4.3.2.
You can hot swap a variable value in Xcode by:
expression <variable> = <value>;.
By having a break point in the place where you wanna change the value and doing the command in Xcode console.
Example:
// Messages From Console
(lldb) expression graphFlag = #"X"; // Update variable value
(__NSCFConstantString *) $0 = 0x36f95718 #"X" // Xcode prints the updated value
(lldb) expression graphFlag; // Printing value through expression command
(__NSCFConstantString *) $1 = 0x36f95718 #"X" // Hot Swapped variable value
I'm having a strange issue with my application for Mac OS X. I have a process that runs in a secondary thread. The process repeats a certain action a user-specified number of times in a for loop.
With each iteration of the for loop, there is a string that is initialized with the contents of a strings file. If the content of the strings file equals "YES" then the loop breaks (the file is set to "NO" by default). When the user wants to stop the loop, they hit the "Stop" button which sets the contents of the file to "YES".
This actually works great when I run the application in Xcode and when I export the application as a .app. The problem occurs when I actually turn the application into a pkg and install it. The stop function no longer operates correctly. I'm pretty stumped as to what the issue is. I'm initializing all my references to my file using [NSBundle mainBundle] so I should be referencing the file in my application bundle.
EDIT: I actually decided to switch to checking an atomic BOOL value within the loop that I change when the stop button is pressed. This seems to be a simpler solution for me.
Regular users do not have permission to modify applications installed in the /Application folder for very good security reasons. Also, signed apps (ie, any app sold through the App Store) cannot be modified without invalidating your signed code.
Never, ever, ever rely on the application bundle being modifiable. It's never supposed to be. Always use standard user data folders like "~/Library/Application Support/" or "~/Library/Caches/" for app-related, non-document files.
As to your general approach, repeatedly polling a file - especially in a tight loop - is a lot of disk activity. "Laptop Killah" would be a good name for the app. :-) You should consider changing this approach altogether. If you provide more detail in another question (what you're doing and why) and ask for suggestions, I'm almost positive there'll be a number of better ways that don't chew through your users' battery charge like crack-addled rats in a grocery store.
Also, I'm guessing you never check to see if your file is written successfully. The standard -writeToURL/File:... methods return a BOOL to signal success or failure as well as set an NSError (if you pass a pointer to one) with further details. Get into the habit of not ignoring this. In this case, you might've found your own answer because you'd have known just where your code is breaking. From there, it wouldn't have been a huge leap to figure out why.
I have an app in which the app bundle contains an image file (I mean that the file is dragged into XCode and appears in "Other Sources"), and I am using code like:
[[NSBundle mainBundle] pathForResource:#"Auto" ofType:#"jpg"]
to get a path to the image.
I found that when running on a device (iPod Touch), the name is case-sensitive, so that if the file is "Auto" and I use "AUTO", the poath returned is "file://(null)". However on the simulator, if I use "AUTO", it works the same as if I use "Auto".
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug. Do the more experienced users out there think that it is, and that I should report it to Apple?
Thanks.
The iOS-Filesystem is case-sensitive, whereas the OSX-Filesystem the Simulator uses isn't.
You have to be very careful with this, I've shot myself in the foot with this more than once.
This has more to do with NS/CFBundle itself than it does with the underlying file-system:
Directly from Bundle Programming Guide: The Bundle Search Pattern:
Important: The bundle interfaces consider case when searching for resource files in the bundle directory. This case-sensitive search occurs even on file systems (such as HFS+) that are not case sensitive when it comes to file names.
You should always, always be assuming case-sensitivity. Well, perhaps a better way to express that is to say, never assume Case-insensitive-while-case-preserving (which is what HFS+ is). In the not-so-distant future, case-sensitive HFS+ could become the default format for Mac OS X. (In general, it would be preferred over the current case-preserving HFS+, but if Apple were to switch it now, there would likely be hundreds of thousands of apps that would break because of developers who made assumptions they shouldn't have. The iPhone is a clear example of the preference for case-sensitive HFS+. With no legacy programs to worry about, the iPhone has always been case-sensitive).
You are editing your code and resource names right now, so take the time to assure they match.
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug.
In general, this does not necessarily indicate a bug.
Do the more experienced users out there think that it is, and that I should report it to Apple?
Yes. But the bug has nothing to do with the device at all. Specifically, the bug is simply "Simulator file paths are not case-sensitive". If you can reproduce this in a "sandbox" project, do so, and submit it along with your bug report.