I have opened a project from Github, which has blue folders in its file structure.
As far as I understand this is a physical folder reference rather than just a means of grouping files together which might just lay around loosely on your hard drive.
So my question: When do you use those blue folders over the "normal" Group, what are its advantages and drawbacks and how do you create them in Xcode?
If you use blue folder references for your resources these folders will also be created inside your application bundle, while resource files in groups will simply be copied to your mainBundle's root directory.
When folder structure is managed outside of XCode (for example, a cross-platform project which has project files for different versions of XCode, Visual Studio and other IDEs, all using mostly the same directory tree), you normally want folder references. Otherwise one would have to recreate every project file every time folder structure changes.
Related
So this might be outright stupid question, but I found no answer looking on the internet or fiddling with different buttons.
Say you have a project with several physical folders which contain different source files. Now you've decided that you'll create a new folder and move parts of three old ones in there.
In order to do so, I had to do the following:
Go into my project folder via explorer and create a new folder
Manually move all the desired files into that folder
Return to code blocks and remove all the moved files from the project
Re-add all the removed files by selecting the whole new folder when adding existing files
Manually going through code and modifying all affected include directives to point to the proper path
It would be much simpler if you could right-click a folder, create a new nested folder and just drag-and-drop files to where you want them while code blocks would move them on disk and correct the includes for me.
It's the way that Eclipse does it for Java. Is there similar functionality for code blocks, maybe a plugin?
In Xcode, what is the difference between a folder and a group? Are these interchangeable terms or is there a subtle difference?
Groups
With groups, Xcode stores in the project a reference to each individual file.
Folders
Folder references are simpler. You can spot a folder reference because it shows up in blue instead of yellow.
There are two types of folders in Xcode: groups and folder references.
You can use groups to organize files in your project without affecting
their structure on the actual file system. This is great for code,
because you’re only going to be working with your code in Xcode. On
the other hand, groups aren’t very good for resource files.
On any reasonably complicated project, you’ll usually be dealing with
dozens – if not hundreds – of asset files, and those assets will need
to be modified and manipulated from outside of Xcode, either by you or
a designer. Putting all of your resource files in one flat folder is a
recipe for disaster. This is where folder references come in. They
allow you to organize your files into folders on your file system and
keep that same folder structure in Xcode.
Reference
A folder in Xcode represents a folder in the file system.
A group in Xcode is a "fake" folder which does NOT represent a folder in the file system.
It is common to use a combination of groups and folders for a given Xcode project.
Xcode behavior (starting with v9) has changed and groups are now actual folders on-disk.
I found that Xcode 9.2 has two versions of group when you create a group. One is group the other is group without folder. The first one also creates folder in your file system, the second one doesn't.
I was following a tutorial and it had me drag a nested folder with a number of autogenerated Swift files with public classes and structs. I missed that I was supposed to click the "Create groups" and not "Create folder references". When I added the folders/paths using the incorrect 'folder ref', my other scripts did not see these public objects. When I did it the right way, added them using 'groups', then they were recognized in other scripts. I think this is in keeping with TheNitram's comment, that 'group' adds to the root ...
When I import my project from Github, I have two folders which appear in Xcode with a blue color, but all the other folders are yellow. What's going on?
Blue is used to represent a "Folder Reference".
A clear description of what these are and when to use them comes from http://struct.ca/2010/xcode-folder-references/
There are two types of folders in Xcode: groups and folder references.
You can use groups to organize files in your project without affecting
their structure on the actual file system. This is great for code,
because you’re only going to be working with your code in Xcode. On
the other hand, groups aren’t very good for resource files.
On any reasonably complicated project, you’ll usually be dealing with
dozens – if not hundreds – of asset files, and those assets will need
to be modified and manipulated from outside of Xcode, either by you or
a designer. Putting all of your resource files in one flat folder is a
recipe for disaster. This is where folder references come in. They
allow you to organize your files into folders on your file system and
keep that same folder structure in Xcode.
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
I've been recently researching how I can manage source files in a project or multiple projects. I've read that Xcode has a built-in support for using svn, and will support git as well, both of which I found to be very useful.
The one thing I couldn't understand clearly is about Source Trees described in Xcode Project Management Guide. Here is my theory, but as I couldn't really verify this from anywhere (as far as I could tell), I would really like if someone could say what I'm missing, if any.
A Source Tree in Xcode preferences is more like a root of a source tree, which is a folder in my local file system.
I can use any files in any of my Xcode projects, even if the files are not in the project folders, if I can specify the files' location related to one of my source trees.
Now someone has the same project folder that is synchronized with mine. She has all files in the project folder, but the files referenced by a relative location to the source tree may exist out of the project folder.
But she has a source tree, with the same Setting Name to mine, (but absolutely in a different folder in her local file system), and if she has the file in the same relative location, then her Xcode can access the file without a problem.
So is this correct, and we use source trees because it enables us collaborating with files outside the project folder?
And even if the files outside the project folder is referenced by a relative path to the project folder itself (not to a source tree), if these files are all managed by SVN so they exist in the same relative location to the project folder in everyone's environments, then I wouldn't need source trees, right?
I never think I am an expert of Xcode, but it seems your question hasn't been answered for a while, so maybe it's worth commenting what I could say:
What you described is pretty much about it. Think is as an environmental variable of an operating system. Typically in a build system made by Autotools, for example, files are referenced by relative paths, such as $PROJECT_HOME/src/common/error.cpp. It doesn't matter where $PROJECT_HOME is in each user's local file system, as long as files are accessible by their relative paths to the user's $PROJECT_HOME directory.
And yes, you don't need to use source tree if the entire folder hierarchy used for a project is referenced by relative paths to the project home and somehow it is certain that everyone has the same files in the same location (for example, because a version control repository contains every files in a chunk as you said).
However, I think it's the best to keep all files in the project home folder, unless they are used across multiple projects, and therefore your version control repository only contains a single root directory (the project home) for your project. If there are files that are best to be shared by multiple projects, then I would have a separate repository for those files. In this case all of your coworkers must use the same protocol, say, having a source tree with the same setting name and put all project homes retrieved from your version control server directly under the source tree (so files outside a project home can be referenced in relation to the source tree for all programmers).
The most of my answer is kind of rephrasing what you already described, but that's how I use the source trees feature in Xcode myself. Maybe others can tell you more about it.