I am relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for example, at the moment, all of my images are at the top level directory and it makes things look messy. I rather would've liked, for example, to have an images/ folder and then sub-folders within that to store images for certain things, like tab-bar/ icons. Is this possible? Or is it convention to just keep everything in the top level directory?
Someone in the #iphonedev channel at freenode told me something about the build process rule or something, it just seemed too complicated I figured I shouldn't bother, and that most people just kept things at their root directory considering the complexity of the solution. Perhaps it isn't all that complicated though, I just felt it should be easier.
For example I would also like to have a sub-folder for my views, like views/ that stores all of my nib files; currently they are all in the top level directory. And the same goes for my property lists.
I would appreciate it if you could tell me what the convention is, I doubt it is to just store everything in the top level directory. And I'm referring to the actual file system, not simply creating 'virtual folders' in Xcode to organize things, because the top level directory of my project will still be a mess. And if it is possible to organize things better, I would appreciate any detailed help on how to accomplish it.
I think I have heard that in the final build, the entire file structure gets squashed to the root directory. I don't mind so much about that, I just want things to be organized while I am working on my project. I think this is where that 'build rule' thing comes in, but I'm not sure how or what to do.
Here's a little more explanation of Graham's suggestion:
Create an images directory
Create an images Group in Xcode
Right-click the group and Get Info
"Choose..." to set the group's directory to be your images directory
Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)
This will work for anything you put in that group (NIBs, etc).
For imageNamed:, you just give the base name.
My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.
Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.
The accepted answer didn't work for me in Xcode 4.3.2. Looks like they removed the "Get info" menu option. Instead I did this:
Created the directory on disk where I wanted it.
Went to the file menu
Right clicked on the group I wanted to add to
Selected "Add Files to PROJECTNAME"
Added the files from the directory I created in (1)
Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.
In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.
Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).
You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.
But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.
My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.
It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.
Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.
Related
I'm learning Visual Studio 2015 Community. I'm a seasoned programmer, but new to VS, and the file representation is confusing me. I've created a solution, and added an existing project. VS is showing me all project files (In my case a C++ project, so .c, .cpp, and .h files) on one tree level in Solution Explorer.
In contrast, if I open said project in something like Sublime Text, VS Code, notepad++, or the like, I see the proper directory structure as it sits on the disk drive; as one would see it in File Explorer/Finder or ls/dir in a terminal.
I have done my homework before I posted, and in the following thread, #Andrey states:
I am afraid there is no such concept in MSVS like "directory
structure". Moreover, MSVS doesn't really need it because it uses flat
projects and hierarchies are based on project level, not on the
file/directory level.
As there is no such thing - you can't have it neither automatically
nor manually. MSVS has solution folders which is quite different thing
and there isn't much sense in expressing real folders as solution
folders.
Visual Studio as Code Browser : How to preserve the directory structure?
Is this true? There is much meaning in the arrangement of files, and the flat representation in VS makes a project harder to understand; file location in the directory structure are important. Is there a way to view the proper directory structure in VS?
In my situation, I'm working with Quickfix, which supports multiple versions (4.0, 4.1, 4.2, etc.). Each of these have different classes and files with the same name.
As you can see from the screen shots below, they are all neatly arranged in different folders on disk, but VS's representation of these files is immensely confusing:
I found the answer given by #Paul Easter in the thread below to very helpful in understanding this "quirk," which is really a "feature." A different concept of project structure is at work:
But as for the reason you do not want solution folders to behave like
"physical" folders is because your solution layout may not necessarily
use the same convention as your source control layout. Solution
folders allow you to customize the hierarchy of your projects so that
you can group projects and items together any way you like, and then
decide you don't like it and change it again without having to go
through the nightmare of moving source control items around and
irritating the rest of your team.
Visual Studio Solutions Folder as real Folders
Is this a good idea? I can see where some people would like it, as it allows them to arrange project files as they wish. At this point, I dislike it; I'm sure in part because it is new to me, but also for these two reasons:
1. In an organized project, the directory hierarchy is not arbitrary; the Principal Engineer arranges files in a certain way for good reasons.
2. It adds a layer of abstraction between the VS file representation and the operating system structure. I like direct access to the files that I'm working on; with the VS system, I feel oddly and eerily disconnected from the underlying files in VS. I must admit a fear that this layer has its anomalies, and will cause problems for me.
It's an unusual design decision to make the project structure separate from the actual folder structure you see in Finder.
All the good projects I've followed (Stripe, React, Dropbox etc.) all seem to mirror their structures. It seems like a waste of time to ensure that the structures match.
Why did Apple make this decision?
I believe it is manytimes required, not to follow the same folder structure in your finder and code structure.
This gives you a lot of flexibility.
We can, however, keep the same structur using "Create folder references", while adding file/folder/resources.
Refer this screenshot.
Basically, I want one of my folders to appear above the other folders as a type of "special folder", similar to how Properties has it's own special place even though it's a folder, same with App_Data, etc.
Is this possible?
By default, Visual Studio doesn't support adding special project folders. The Properties folder is hard-coded to behave the way that it does.
However, anything is possible with code. You could build an extension to do this, but it wouldn't be simple. You'd probably need to mess around with the IVsHierarchy or even implement a project subtype.
Basically, I want one of my folders to
appear above the other folders as a
type of "special folder", similar to
how Properties has it's own special
place even though it's a folder, same
with App_Data, etc.
Is this possible?
Yes:
Do it manually through the IDE
Write your own script to
generate/modify your *.sln/*.vcproj
For (1) "manual" on solutions in the IDE: Solution Explorer, right-click on Solution node==>Add==>New Solution Folder.
While typically the folders are sorted alphabetically (I'd insert a leading underscore to force your special folder to the top), solution folders inserted manually on my MSVS2008 leave the new folder "at the top", even though it should have bumped down when alphabetically sorted. However, folders under a Project (which are called "Filters") are always sorted alphabetically, and added similarly from the right-click, and then you can modify their "filter properties" with file name globs for what you want in there (e.g., add a filter glob for "*.MY_EXTENSION1;*.MY_EXTENSION2").
We chose (2), and we generate our own *.sln and *.vcproj, adding our own folders/filters. I've not seen any utilities on the web to help with that (so we had to write our own). The formats are not too hard to reverse engineer, but it's largely undocumented XML, so you have to experiment. There are only a couple good web articles explaining what's in the file, like this one:
http://tim.oreilly.com/pub/a/dotnet/excerpt/vshacks_chap1/index.html?page=4
On the "bright side", the files are only XML, so in developing our scripts we merely made changes through the IDE, saved, and compared the "diffs" for what change we want. Those changes are what our scripts insert when we modify our files. So, if you modify the file manually, you can similarly just "diff" the file to see what changed, and make your own script. (IMHO, this is the fastest and easiest route, since tools generally do not exist to manipulate these files.)
Tools like CMake and QMake generate *.vcproj/*.sln, but don't really do the folder customization thing like you're talking. However, we look at their output too, because, "there's more than one way to do things" in these files, and the files seem to have many undocumented features for doing different clever things that somehow these tools have "discovered" (so you can try to copy their generated output).
We found the .NET APIs to work with these files as too much work, and not really designed for that type of manipulation, but YMMV.
VS 2012 has a feature that I just found, and it solved this problem for me. It may not be new to VS.
Create a folder under the project with a leading "_" (to get it sorted first).
On the folder's properties set "Namespace Provider" to false.
VS (or ReSharper?) code analysis then does not complain that "the namespace does not match file location", which was the source of irritation for me that would otherwise have kept me from going this route.
Although there is no easy way to add Custom Folder, there is an easy way to "steal" Properties custom folder.
Add a regular folder to the project. For example MyCustomerFolder.
Open proj file xml. Find line
<AppDesignerFolder>Properties</AppDesignerFolder>
replace with
<AppDesignerFolder>MyCustomFolder</AppDesignerFolder>
Reload the project.
Now you've got a custom folder, that will always stick to the top.
I’m looking into the special folders which have enumerations, such as the LocalApplicationData. On my Windows 7 machine I’ve seen what’s there, and first I see several sub-folders that are GUID’s. I’ve no idea what they are, and presume them to be something that Microsoft puts in for whatever.
Next I see folders named after various companies, like Adobe, Apple, Citrix, Microsoft, etc. However, when I go into each of these sub-folders I’ll see more sub-folders, e.g. under Adobe I see sub-folders named Acrobat, Color, Reader 9.3 and Updater6. So when I go to re-write our application, do I adopt a similar structure, something like \OurCompany\App1, \OurCompany\App2, etc.? Or can we just put all of our various applications data into \OurCompany? What I’m asking for is what is standard procedure, or best practice?
If your company only makes one product and there is only going to be one version of it, then the structure doesn't matter - but it is better to plan for a more positive outcome :)
As you have seen from the other companies/products you have installed, having a folder structure that includes the company name, product name, and possibly version will all help to avoid clashes. You could avoid using folders and just use some file name convention, but you may find that you need multiple files in the future and it is simpler to start off with folders. They don't cost much.
As for the question of whether to include the version number or not, the key issue is whether it makes sense to have multiple versions of the same product co-existing at the same time. Not all products need this and some apps will upgrade the settings or have code to read data in the old format. Bear in mind that for data under the roaming area (ApplicationData not LocalApplicationData) may be visible to different versions of the same application installed on different machines.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.