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.
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.
I'm new to iOS programming and being the organizational freak that I am, I'd like to have a good clean structure for everything I am working on.
Should I create real folders to represent the groups that I have created in Xcode and organize my code that way?
Should I rename the groups I have now to any other names?
I am going to be needing an API, where should I put it?
Here's my current layout:
This project is open source: https://github.com/kirkouimet/enzyme
It's really up to you. It's sort of subjective, but usually Xcode's project templates provide a good start. Generally, I prefer Groups over literal folder references with the exception of the first couple of root-level directories.
Here's the typical file-system structure for my projects:
And here's what my Xcode project structure typically looks like:
this is a great storyboard tutorial series. not sure if it will answer all your organizational questions, but still a good place to start:
storyboarding tutorial series
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.
I've got a collection of HTML documentation that I'd like to add to my solution in Visual Studio. It's just a collection of files -- there are no build steps.
What's the best way to add this to my solution? In the past I've used a C# class library project and disabled it in Build Configuration, but this felt wrong.
A "Makefile project" doesn't work, because it doesn't support nested folders.
I don't really want to use Solution Folders, because they're not real filesystem folders. This makes them harder to work with. Solution Folders are great when your solution has a large number of projects in it, but I don't think they're great for managing more than a couple of loose files.
How do others do this?
You can put them in solution folder
Right click on solution and select Add->Add existing item - it will create solution folder automatically. You can add solution folder manually via Add->New solution folder
I would recommend simply adding them directly under the solution (or rather under a Documentation folder under the solution). The context menu for the solution title in Solution Explorer gives options to create solution folders and add references to solution files.
Given that you don't want to use solution folders, I see absolutely no point of including them in your solution then. Any method you could use would be rather contrived. It is quite common simply to have a Documentation folder in the root directory of your solution that is not referenced in any way by the solution/project files. (If you like, you can then mirror the directory structure of Documentation using Solution Files.)
I always put a .Documentation folder in each project that I am making the documentation for. It's not as elegant as having a single location for the solution, but it also makes it so that as I use different projects in different solutions and have the documents follow their projects. At compile time I have the build system put all the documentation together in one folder.
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.