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.
Related
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];
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 would like to update my app to support the downloading of PDF documents, but am worried primarily about 2 things:
1: that the user will attempt to use my app to download non-PDF, or virus-riddled items.
2: that said virus riddled-items could infect the device.
I may just be paranoid, as I assume the sandbox would prevent most malware from escaping and screwing with the OS, Kernel or the Lower Level Processes but you can never be too sure. So my question is twofold: How can I (at least mostly) guarantee the download of only PDF's and do it as securely as possible.
(P.S. the download will be done through any generic website in a webView, not a server seeing as I shudder at the thought of web development).
Based on ozdrgnaDiies' answer, I have found this sample code; which I will be modifying to suit my needs, thank you. http://iphoneincubator.com/blog/server-communication/how-to-download-a-file-only-if-it-has-been-updated
From what I've gathered from your question, I assume you want to check if the file you are downloading is a pdf and not anything else? If so, you could check the header of the file to verify it is a pdf.
Example, the first thing in every .pdf (That I have myself) is:
%PDF-*.*
Where *.* is a version(?) number. For example, 1.2, 1.3, 1.5, etc.
Therefore, reading the first 5 characters from a downloaded pdf should result in "%PDF-", otherwise it is not a pdf.
As more examples, the first thing in a jpeg image is:
ﾘ・
And for an .exe it's:
MZ・
etc
iOS apps are sandboxed. Meaning, anything you do within the app should only affect your app. Unless you attempt to somehow run the downloaded content (which I believe is against the rules for the App Store). The only thing left would be maliciously crafted PDFs…
I personally don't think it would be a big issue.
This is a multi-part question to SO folks before I engage more with core team.
Summary: On OS X, pdfs should be created using quartz, not postscript. Files are smaller, anti-aliased better, OS fonts including opentype are readily available, encoding is less painful, overall I think it’s a better device. On other platforms, it would be reasonable to use cairo, again a more modern pdf-writing device.
Consider the behavior of the png() device. Although it is allegedly slated to move out of x11.R, it handles c("cairo", "Xlib", "quartz") with a default (options("bitmapType")) set by zzz.R (quartz if capabilities("aqua"), cairo if available, Xlib otherwise). PDF needs to behave the same way, so that in Sweave (or babel or whatever) my pdf figures can be generated using the appropriate device.
My Sweave png patch works because png() takes care of getting the device option. An earlier version of the patch (which I still use) flips the device in Sweave, but I was smacked down for this and I know it’s sort of the wrong the place to do it.
There’s some alias cairo_pdf() (also in x11.R) that probably should not be there, shouldn’t that be merged into a device-switching pdf() ?
One approach is to add option "pdfType", which in turn I think should probably be more general – there is already a default device, it’s just that pdf() ignores it! I’m especially wary of introducing new global options because they are more likely to be rejected by core.
I don't think you'd need to implement a device driver. Mostly it sounds like you want to alias pdf() so that it calls quartz() or cairo() as appropriate. The quartz() device already supports PDF output to a file (among others) on OS X.
For your own personal use (I doubt this would find its way into core) you could just alias pdf() to take the appropriate action on each of your platforms and bring it in as a package or in your Rprofile.
pdf.orig = pdf
pdf = function(...) {
// Insert code here
}
Cloud App has this neat feature wherein it automatically uploads new screenshots as they are added to the Desktop. Any ideas how this is done?
You can do similar things yourself without much in the way of programming. In OSX, you can configure "Folder Actions" to run a script, for example, when a new item appears in a folder, including the Desktop. You can then use the script to do whatever you want with the new files.
This article at TUAW includes an example of uploading files to a web server when they hit a particular folder.
So, basically, the answer is "Folder Actions", or "something's keeping an eye on the folder and sending notifications", at some level. Whether Cloud App uses Folder Actions or watches the folder itself at a lower level, using FSEvents/NSWorkspace, or the kqueue mechanisms (for which there's a nice wrapper class called UKKQueue, if I remember correctly -- don't know how current my knowledge is on that one though!) is another matter...
You could implement this at several different levels, depending on the outcome you want, how you want to design whatever it is you're actually doing, and even what kind of filesystem you're targeting. Fundamentally, in Cocoa/Objective C, I think you probably want to start looking at FSEvents.
Once you've got notifications of the file changes, I'd probably use something like ConnectionKit to do the uploading -- any library at all, really, that means you don't have to bother with the sockets level yourself -- but again, there's a lot of different ways.
Depends, really, what level you're looking to solve the problem at, and whether you want to build something for other people or get something working for yourself. If I just wanted to bash something together for myself, I could probably have something cobbled together using Coda's Transmit app, and Folder Actions, or maybe Hazel, and a minimal bit of Applescript, in a half-hour at most, that would do the job well enough for me...
I am not sure what you are asking for exactly. If you are asking for a way to take a screenshot programmatically in MacOSX, I suggest you have a look at the "screencapture" command (in the terminal, type "man screencapture" for doc).
If you want to do it the "hard" way, you should look at this.