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
Related
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.
I would like to distribute some classes as a Cocoapod. I intend to provide the following:
The classes themselves (a few UIView subclasses)
A small example application
I have been looking through some well established Github projects and it looks like there is no single established way to set up my project. Should I use a single workspace with multiple projects? One project and one simple folder (for the views)?
One (perhaps obvious) requirement - once the structure is in place and the pod is downloaded, the example application should not be included.
Perhaps there are some tutorials out there? I've spent a few hours looking around and making some attempts but I'm invariably hitting some obstacle or another.
For example: If I have one project and one folder in the workspace (which I copied from TTTAttributedLabel) I can't get the library classes into the compile sources without them duplicating themselves into the demo project.
Each attempt seemed to hit a similar snafu so I'm hoping there's a 'right' way to do this.
I found the following demo the simplest to reproduce: http://nilsou.com/blog/2013/07/21/how-to-open-source-objective-c-code/
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.
I'm tired of looking after a frame work for mvc implementation.
i want to build a good MVC based structure of my own that will serve me in my projects.
so here is my thinking I'd like to know what do you think.
first of all. here is the folder structure:
The folder structure
the Admin and the Site folders:
I assume that the controllers/views in the admin/site and are totally different one from each other,
so it is necessary that they will be in independent in each folder.
if the autoload in the admin or site folder will not find a view/controller in its folder he will look for it in the MVC folder
the model, which is the db layer can be inside the MVC folder because it is shared to the entire project.
a function like get_article_by_id can be used in the site and in the admin as well.
the MVC folder:
will hold the entire project models. and shared controllers/views.
the classes folder:
will be use as a framework folder, it will hold classes such as mailer,db that will implement php functions
How does that sound to you?
Part of the benefit of using a popular framework is that other people know it and can help you with it. If you write your own, only you know about it. There is an MVC framework in almost every language and lots of thought has gone into each one, which means you get the benefit of a lot of experience by selecting an existing one, rather than writing your own.
As long as you feel convenient with this structure - use it.
If you need to ask advice about whether your reinvention of the wheel is any good then it's probably not better then the wheels already in existence.
A wheel inventor that knows he has a better wheel wont need to ask advice.
I've seen a lot of different takes on this subject so I figured if there's a preferred way on this.
Is there any best practices on how to setup Visual Studio Projects and Solutions in regards to multiple solutions for the same solutions?
For example:
Let's say I have a task that calls for a web app, a console application, and a shared business logic library.
I have seen this situation in a 1, 2, and 3 solutions at some time in my career. This is a simple example; however, what if number of projects grows? Is there a line when to keep it in one or break it apart?
Indeed, there are some guidelines for this sort of setup on MSDN. I wrote a short summary in my answer to a similar question on StackOverflow.
I blogged about this back in 2007. The advice still holds:
http://mikehadlow.blogspot.com/2007/07/how-to-structure-visual-studio.html
The bottom line is that I should be able to get your code out of source control, open it in Visual Studio, hit F5 and everything should work.
Solutions are for the developer, in a particular situation. Projects (.CSPROJ for C-Sharp) are where the real compilation takes place.
Theoretically if there are 4 different projects, there could be 24 different combinations of those projects a developer may want to combine into solutions.
If you keep everything at a project level, you won't need to worry about how a developer has arranged their .SLN files
You can have multipe solutions, and each one can reference the projects that it cares about. Extending your example, your shared business logic library may have a corresponding unit test library. These two projects can be contained in one solution. At the same time, you may have another solution that contains the three projects that you mention, but in this case the unit test library isn't included.
My solutions typically consist of:
Web Application project
'Common' folder for base & common helper classes
'Include' folder
'Styles' folder
'Scripts' folder
'Images' folder
'UserControls' folder
Web Services project
Web Framework project
Business Tier project
Business Framework project
Data Access project
I like to include all projects for a certain task, in a solution. So based on the example you mention, I would have a solution containing the three projects that belong to the solution I was asked to do. That keeps all elements to complete a task together, I find this simplifies the inclusion of other elements required to solve the task at hand.