Sorry if this has been answered before but all my searches do not return anything related to this.
Is there a way to collect all the files referenced in a project and save them in the procject folder automatically? Rather that having links to places where you may accidentally delete the files.
Thanks,
Eds
Xcode doesn't have a particular feature to support this, but when you add items to your Xcode project it does give you the option to copy those items to the project directory. Otherwise you need to manually copy the items to a common location.
What do you mean collect all the files? Do you mean your external files or class files. Your external files like images or audio/video files should be added into Resources directory, it does not matter where is the root directory of these files. Then, you can access with their name in the project.
Related
When doing iOS programming, it is interesting that in Xcode (4.3.2), we can create groups, such as a group call Images, and add files to it (either as a link or choose "Copy items into group's folder"). So it looks like a real folder in the navigator, and it even mentions "copy into ... group's folder", but in fact there is no folder. All added files are in the same location as the .m and .h files.
Why would we want Groups, but not real folder? Is there advantage of Groups over the use of a folder?
This is a pet peeve of mine.
I recommend, making the folder in your file system, where you have your project files, then drag that folder into Xcode where you want the group. It will act like any other group, but now be linked to the folder on the file system. Adding files to that group in Xcode now adds them to the folder in the file system.
Much cleaner way of working and helps when locating files in big projects. Keeps git cleaner too.
Update for Xcode 9:
Once you have the groups in Xcode matching the directory structure on disk, moving a file from one group to another in Xcode will now move the file correctly on disk to match.
Note: In Xcode 10, the default behavior now creates a linked folder when you create a new group. The information below still applies otherwise.
The recommended way to organize files is via groups, because it's more flexible than creating directories, and allows you to create complex file hierarchies while maintaining a totally different file hierarchy on the file system. It's simply an organization tool. That said, it is possible to turn groups into folder references, or create them initially as folder references.
Furthermore, using groups instead of folder references gives you greater flexibility if you need to change where things are in the file system - say you have a common folder of code that you use in a bunch of different projects. Groups allow you to organize the files inside of projects as if they were in the projects, while still maintaining one copy of the code in a central location. And yes, you can do this with folder references as well, but groups are much more flexible if you later want to add other things to the same group but don't want them to be added to that common folder.
If you want to link a group to a folder, click on the group in the project file tree and hit command+option+1. Below the drop down that'll say something like "Path: Relative to Group" on the right, there's a little white square with a grey border around it kinda icon next to the word "none". Clicking on this and then selecting/creating a folder will bind the group to the folder.
Furthermore, when you drag a folder into Xcode, it will ask you if you want it to be a group or a folder reference:
There is a Command Line Tool - "synx"
available in github that do exactly what you need.
It reorganizes Xcode project folder in finder to match Xcode groups in project.
You can find it here:
https://github.com/venmo/synx
UPDATE: XCode 9 supports this feature by default. So, no need to use other tools anymore!
I want to have two files with the same name in different folders in a xcode project. These files are actually code files and not any resource files. How can I achieve this?
Thanks
Pankaj
Well if there .h/.m files you can't have them in the same project, even if they are in different directories.
C does not support namespaces, so every class has to have an unique name.
You can add, but when you load it, the system will pick the first one available.
So, really it will not work the way you expect.
I'm new to iPhone development and I'm still getting familiar with the Mac dev environment, including Xcode. I want to add some 3rd party code to my iPhone project, but when I add the "existing files" to my Xcode project, I'm presented with a dialog box that has far too many options that I don't understand and, as such, my project isn't working. When I #import headerfilename.h, I get a build error that reads headerfilename.h: No such file or directory.
alt text http://joecrotchett.com/images/misc/fileadd.jpg
Can anyone explain to me what all these options mean or give me a link to some documentation that can? I'm having a hard time finding anything in Apple's docs.
Which options do I want to choose to add existing source code files to my Xcode project? I should note that the source code files that I'm trying to add are located in my project/Classes/frameworkname/ directory.
After they're added, do I need to reference this new code directory in my project settings anywhere (i.e. some kind of header file directory variable)?
Thanks so much!
Update: I found the following answers/responses on the apple dev forums that were very useful and helped me fix my issue...
To make it simple :
- if you do not check the copy option, the file stay where it is.
- if you check it, it is copied in your project folders In the first case
(what it seems you are doing) you need
to tell the compiler that the header
files are in another directory :
- project info -> build -> search paths -> User Header Search Path : add
the directory from where you took the
header file Hope this will help
You have discovered the most confusing
dialog box that ever came out of
Cupertino. Six years of Xcode, and
this thing still is partly a mystery
to me. To even get that far, I had to
make many test projects to try and
reverse-engineer what this thing does.
The "Copy" box means that it will copy
the files as they are right now, into
the project. If this box is not
checked, then it just references those
files during a build and copies them
as they are at THAT time. For source
code, you want the Copy box checked.
The "relative to" is a total mystery
to me and I can't help you with that.
I usually leave it however it is
already set. Does it mean relative to
where they are on disk, or the
arrangement in Xcode, or in the
bundle? Who knows. The last 2 radio
buttons SEEM to mean that it will
either re-create the folder structure
of the folder you are adding, or just
put "fake" folders in Xcode that point
to the real folders. This is probably
your problem - you are adding source
code that is not all at the top level,
and when it goes to find it, it does
not re-create the hierarchy. Others
can supply a better way, hopefully,
but what I would do is put all of the
source in one folder and add that,
using the Copy box. Then in Xcode you
can make whatever bogus folders you
want and put the source file names in
those fake folders.
This is from the Xcode user guide:
"The project navigator shows projects, groups, folders, and files:
The project or projects in your workspace window are the highest level
of the hierarchy in the project navigator. Open the project’s
disclosure triangle to see the groups, folders, and files in the
project. Select the project to display the project editor, where you
can view and edit project and target settings.
A group appears in the project navigator as a yellow folder icon. The
group does not represent a folder on disk. Although you can organize
your project in Xcode to reflect the organization of files on disk,
moving files into and out of groups does not affect the content of the
folders on disk, and moving files on disk into and out of folders does
not affect the content of the groups in the project navigator.
A folder is a reference to a folder on disk and appears in the project
navigator as a blue folder icon. The contents of the folder in the
project navigator reflect the contents of the folder on disk. It’s
important to note, however, that the files that appear in a folder
icon in the project navigator are not part of your project unless you
have added them to the project explicitly (in which case they appear
directly under the project or in a group, as well as in the folder).
You can view and edit the files in a folder, but to move files in and
out of the folder you must use the Finder.
A file in the project navigator is a reference to a file on disk."
I think usually the default option is the best one. If you want to add into some group, you can tick on the "Copy Item to Destination group"
You don't have to change any project settings after adding
And if you want to add the whole framework code, please choose add existing framework
Copy items into destination group's
folder (if needed)
Well, only if you want it to copy the files. If you are happy with their existing location and don't want it to copy them, don't select it (that's what I do).
Reference Type:
A total mystery to me
Text Encoding
Self explanatory
Recursively create groups for any
added folders Create Folder References
for any added folders
Leave this as the default and then organize the folders in your Xcode project any way you want.
Add to targets
If you add an additional target to your project, e.g. for iPhone vs. iPad versions, then not noticing that it has by default added the files to just one of them (at random?) can cause headaches.
Also, make sure you add the new header directory to your search paths in Project Settings > Build > Search paths. I think that's what's causing your problem.
Hope this helps, I remember how confusing this was to me at first.
If you want to add an Framwork Bundle, just add is as one. Add -> Existing Frameworks
I have some resources (zipped) that needs to be shipped with my iphone application. When the app launches for the first time, this zipped file needs to be moved/copied to the Documents folder and unzip it there. User can then add more files to this path from the application. Can someone please suggest how can I achieve this?
Thanks!
Based on your comment above:
The reason I want to add a compressed
resource because there are multiple
files. If I don't compress then I'll
need to move files individually. I'll
also need to maintain a list of files
somewhere so that I can read the file
name and then move them. I thought
zipping and unzipping was a simpler
solution.
You could add all the files to a folder in your bundle. When the app launches for the first time use fast enumeration to run through the folder and what ever it finds in that folder, it copies into the Documents folder. Handling folders within folders is slightly more complex (add recursion maybe). This way you don't have to worry about zip or tar, nor to keep a directory of files to install.
Just place the folder of files you want into Xcode's resources folder and tell it to import as a folder not as a group. That way the files get installed in your resources inside a folder instead of just as individual files all over the place.
EDIT:
Better yet, do what I say about putting all the files you want in one folder, add to your project, but not as a "Group", and then at first launch use:
[[NSFileManager defaultManager] copyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error];
and it will copy your whole directory from one place to another. EASY!
Add the libz.dylib Framework to your project, and include Deusty's NSData gzip category which will give you compression/decompression methods.
While this is available by using the libz.dylib, it really is unnecessary as it save you little (if any) space. You application bundle is already compressed when being transferred to the phone. Compression on top of compression usually yields little additional compression.
Try it out yourself. You may find that shipping your app with unzipped contents may take up just as much space as zipped contents.
In the process of localizing my app, I have about 50 resources (mostly xibs) that need to be localized. I know how to add a localization for each file, but it's a pretty time consuming process to open the info panel and add the localization for each file.
Is there any way to select multiple files and add a localization to each of them in one shot?
Edit to add: Is this a place where AppleGlot or iLocalize can help? I haven't yet looked at those tools.
Just create a directory for the language you are localizing for if it isn't already there (e.g. "en.lproj") and copy all the files there. Then go into xcode and add the newly copied files to your project.
Have you tried using ibtool? This tool, which runs from the Terminal, can list the classes or objects in a nib files and can also dump the localizable strings into a plist.
I haven't tried this tool though, but you can find more info by typing "man ibtool" in the Terminal.
Selecting multiple files in the left/navigator pane and then adding localizations via the right/utility pane is supposed to work, but doesn't. I filed bug #9276560 against Xcode 4.0.1.
If you need to support a lot of languages, this can help:
Click on file #n
Add one localization
Repeat steps 1 and 2 for all files
Click on the project in the left/navigator section
In the project info pane, add localizations
What that does is add every previously localized file to the new language(s). You'll still have to add 50 files separately, but at least you won't have to perform 50 operations times the number of languages. In my case, that saved me several hundred steps.
The answer is in the other post here
In essence, you have to create xx.lproj directories for all your languages.
Then copy all localized files to their respective directories.
Now your lproj dirs should have the files with the same name (but with different localized contents).
Then you add all files from all dirs into Xcode.
Xcode will assign them to appropriate locales based on the lproj dirs where they reside.