NSBundle folder not found on device, but works in simulator - objective-c

I'm having a really weird problem with the iPad app I'm writing. On startup I want to copy a folder containing a few other folders (that are empty) from the application bundle to the Documents directory. The folder to be copied, called 'flds' (all lowercase), was added to the Xcode 4 project using 'Create folder references for any added folders', and I have checked that it is actually part of the .app file after compiling. (And that it doesn't exist already when attempting to copy.)
I've tried getting to the 'flds' folder using either one of these calls (they all work):
[[[NSBundle mainBundle] bundleURL] URLByAppendingPathComponent:#"flds"]
[[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:#"flds"]
[[NSBundle mainBundle] pathForResource:#"flds" ofType:#""]
Then copying using NSFileManager's copyItemAtPath:toPath:error: method (or the URL equivalent when using URL instead of path string).
All of these strategies work perfectly in the iPad Simulator and on the iPad device, with the following exception: When I (successfully) build for Ad Hoc distribution, drag the .app and the .mobileprovision into iTunes, sync and then run the app on the device, the system no longer thinks the 'flds' folder exists! I've been trying to examine this for many hours, with no luck. Again, I'm perfectly sure it works both in the simulator and on the device running from Xcode, but not when synced via iTunes.
Ideas?
I discovered that the following call gets the folder path successfully also after syncing the iPad app via iTunes:
[[NSBundle mainBundle] pathForResource:#"flds" ofType:nil inDirectory:nil]
However, when I use this path to copy the folder to its new location in the Documents directory, only the folder itself and the .txt file in it (which I put in there as a test, it's not really supposed to be there) gets copied, and not the 6-7 empty subfolders. Again, the same pattern shows itself: Works as expected both on simulator and device running from Xcode ('flds' folder with 'test.txt' and empty subfolders are copied successfully), but not when synced via iTunes (only 'flds' folder with 'test.txt' are copied, not subfolders). Is this really the intended behaviour of copyItemAtPath:toPath:error:? And why would it behave differently after syncing via iTunes?

In the end I figured out that copyItemAtPath:toPath:error: wouldn't copy empty folders, even though I think it's supposed to. And again, this behaviour only occured after syncing the app to the iPad via iTunes (when running from Xcode it did copy empty folders). My solution for the time being is to simply put a dummy text file in each subfolder, so that they're not empty anymore.

Related

Access XML file in project bundle in Xcode 6.3.2

I am trying to load an XML file in Xcode. The file is supposed to be loaded when the app is started, and updated with data to be saved for future use.
I dragged the file in the "Supporting Files" folder in Xcode, and I can see a copy of the file in the project subdirectory:
/Users/Alex/Documents/ObjectiveC projects/myProject/myProject
The code I am using to access the file is:
// Search for files in bundle
_path = [[NSBundle mainBundle] pathForResource:#"profile" ofType:#"xml"];
NSLog(#"myFile path: %#", _path);
However, when I run the app the _path is set to some other directory:
myFile path: /Users/Alex/Library/Developer/CoreSimulator/Devices
/8F2AD2A7-4875-47C9-9AB8-852339AF31A0/data/Containers/Bundle/Application
/7D9A4A78-A7CB-40E5-8CC7-6B8EE2143D2E/myProject.app/profile.xml
Also, it looks like I cannot write to this file. The content is the same if I restart the app. This is happening regardless if I run the app in the Simulator or the device.
It almost looks like I am accessing some version of the file that was cashed in the bundle when I ran the up for the first time.
It turns out that the files in the bundle are read only. This was discussed in other posts: File write with [NSBundle mainBundle] fails
I obtained what I need by copying the file to a new file when the app is initialized the first time it runs, and then use the new file as read/write file.

Modify plist file in xcode

I developed an application that has a Data.plist file, created by me.
The idea is that by UISwitch Data.plist, which works in the simulator iPhone Xcode, amend does not work on an actual device.
Why is that ?
How I can make it work?
Stay tuned to your answer,
Greetings.
Your bundle is read-only on a device.
The best solution would be to load your plist, save it in a directory of your chosing using the NSFileManager, and then work with the file in that directory.
Your plist inside the bundle would ONLY be used the very first time your user uses the app, as a blueprint if you will, and then you would work with the .plist you saved in the documents directory.
This small code snippet will explain how to copy a file from your bundle safely. He uses it with a database but it's really the same for any kind of file.

data file location on iPad

I've been teaching myself over the last couple of weeks by typing in programs from the iPad books I bought (Backlin's, SAM's, Apps for Dummies, etc.) and YouTube tutorials. Still, there are a couple of things I haven't grasped intuitively. Do you mind helping me out?
I got a program working that saves and retrieves names and phone numbers from pList files. I looked on the Mac's HD and couldn't find the file (Contacts.plist), even though the program was working. I finally discovered it at
~/Library/Application Support/iPhone Simulator
I'm not sure why Finder didn't locate it. My own app needs to load a data file when it starts (questions and answers, for example). Do I write a program to create the Q & A file, (I could modify that phone program to do that) then copy the file into the simulator's virtual directory for my own app? Or do I copy that file into the XCODE Resources folder? Would the data files then travel with the finished executable program?
Sorry to sound so clueless. Thanks for any info. -Rob
If you want to deliver a file with your finished application, you must add it to your Xcode project. It doesn't matter whether you place it under Resources or in another group in Xcode as Xcode will by default copy all non-code files that are in your project into your finished app bundle.
To access this file from your code, you need to retrieve its path:
NSString *fullPathToContactsFile = [[NSBundle mainBundle] pathForResource:#"Contacts" ofType:#"plist"];
Note that unlike on the iOS Simulator, your app bundle on the device is read only, so if you want your app to make changes to the file, you cannot save it in the bundle itself. In that case, your app should copy the file from your bundle to your app's Documents or Library directory on first launch and then open/save it from/to that location.

Why currentDirectoryPath return different result under IDE and without it?

I have a strange trouble using below code
NSString * pth = [[[NSFileManager defaultManager] currentDirectoryPath] copy];
If that code runs under IDE it works fine, and i have pth like that
/Users/user/Desktop/iShutdown/build/Release
But if i run that code without IDE simply launching my standalone app
i see in log that pth is only contains "/"
Why? how to get same result in standalone mode?
The initial working directory will depend on how the application is launched and you should never make any assumptions about what this will be. For Finder launches it will typically be / as you have seen, while for Xcode launches it will usually be the same directory as the executable (although you can change this in the settings for the executable). There are various other ways of launching an app though, e.g. from the command line, so the initial working directory can be pretty much anything the user wants it to be.
If you just want to find some specific file which resides at a specific location relative to your app, e.g. a data file that your app needs, then you should just get the path to your application bundle and use that, not the working directory.

Working Directory in Objective-C and Xcode: debug mode vs. executable

I am writing a program in Objective-C using Xcode. My program creates a file as follows:
[#"" writeToFile:fileName atomically:YES encoding:NSUTF8StringEncoding error:NULL];
I would like the file to be created in the same directory as the executable. When I run the program from Xcode, the file is created in the debug directory as expected.
However, when I run the .app file, the file is created in the root directory. How can I get the program to create a file in the directory where the .app file is located.
Thanks a lot.
EDIT: This is a MacOS application
EDIT2: Well, it seems that I shouldn't be writing to the .app directory. Thanks bbum and Paul R. What is the proper way to do it? To be more concrete, here's what I am doing: each time the user clicks a button in the application, a piece of hardware connected to a serial port will send a bunch data which will be written to a new file. This can happen any number of times while the application is running, so numerous files may be created. I would like them all created in the same folder.
You must never make any assumptions about the initial working directory for your application, as this will depend on what method was used to launch it (e.g. Finder, Terminal (via open), Xcode, gdb, third party utility, etc). You should use an appropriate API to find a suitable directory to store temporary files or user-specific files or whatever it is you need to do. This should never be within the app's bundle and never at a path that is relative to the initial working directory.
You do not want the file to be created inside the .app wrapper. That is never the right answer; your application may easily be installed somewhere where the current user does not have write access to the YourApp.app wrapper.
(For example, my main user account is non-admin and all applications are installed admin-write-only. If an app ever fails to work because it can't write to its app wrapper, the app goes in the trash.)
See this question for an outline of where files should be stored. Depends on the role of the file.