I was reading a blog to better understanding the purpose of making a project for sublime (or any editor):
When you save your code as a project you end up with two files. The
first is the project file which contains references to folders for
your project, project based settings and build commands for your
project. The second file is the workspace. This is simply a file that
tracks what layout you're currently using and what files you have open
in each pane. Using the workspace file means that you can switch to
another project, do some work and then switchback to your original
project knowing that the layout and files you had open will be
restored back to the state you left them in. Handy.
So seems like there's 2 reasons? 1. is to save settings and 2. is to save the current layout of the files and folders you have already opened? I see reason 2 to be nice, but not really super important. What are some of the settings in reason 1 that's important to keep in between projects? What is a build command?
You might simply have to follow different coding standards for different customers, e.g. indentation rules, so its handy that you can set these rules on a per project basis.
A build system let's you run or compile code directly from Sublime Text.
Related
I'm developing an iOS app with some other students of my class. One of them created our Xcode project and set up all the folders (groups) we need. These folders also appear in his finder. When pushing everything the folders are not visible in our repo. When I pull it, everything in Xcode is fine, all the folders are there (which also says the pbxproj-file). BUT in my finder none of these folders are there.
This is how it looks like
How can we also put the folders in Git, so that they are visible in our repo and the files are in them?
Edit: The below is the question I thought you were asking, but the image you added suggests a different problem. I would first make sure you're actually looking at the same directory. Cmd-rightclick the project in the navigation bar and make sure it's the folder you think it is. This is a surprisingly common mistake.
I would then make sure you haven't referenced external folders or put things in a strange place. Select a folder and open the right-hand sidebar (Cmd-Opt-1), and check the path. It is very common when you drag things into a project, or rearrange a project by dragging, to accidentally create absolute path references to locations outside your project.
Xcode has traditionally used groups rather than folders to organize files. Groups are a virtual structure, purely in Xcode. Most of the files are put into a single physical directory.
(Whether this is good or bad is a matter of taste. I've long preferred having most files in one directory to make reorganizing the structure easier, and to make it easier to write scripts that search or process all the source code. But over the years, and particularly moving to Git from Perforce and SVN, and especially with the rise of GitHub, I've grown to prefer the folders, and that seems to be the direction Apple is moving towards as well.)
In recent versions, Xcode has moved towards supporting folders directly.
You can see the difference in Xcode. This is a group without a folder:
This is a group with a folder:
Note the lower-left corner of the icon.
You can make folders from the local menu, either by right-clicking an existing folder/group, or by selecting files you would like to move into a folder and right-clicking:
I don't believe there's any shortcut to convert all existing groups into folders. You'll have to restructure. But as you create new things, make sure to create folders if you want those.
It's better to maintain relevant folder structure as mentioned by #Rob Napier so that when you modularise/move files in xcode the files are moved to the corresponding folder structure and they are in sync with the file system.
Right click on any one of the file(under view/vm) and -> click show in finder to check the absolute path of the file.
Background
I'm porting a small Windows application to iOS using XCode 6.2 as both the IDE and build platform. I have a workspace created, which I'm using to compile and build all the projects. I currently build every project except the actual iOS app as a dynamic library, and then embed it in the final app package on deployment.
The Problem
I'm currently hard coding relative paths in the projects. Stuff like ../../shared-headers - I really don't like doing this as I have to figure out this path per project, and I'd prefer to use something like props files in Visual Studio, which would let me do something like $(SHARED_HEADERS) in projects.
This makes the projects easier to maintain, and any dependency extremely obvious. It also makes it much easier to move projects when the need arises. What is the preferred method to do this in XCode?
EDIT: I'd like to stick with a Visual Studio-ish include structure. While Copying headers is a good way to manage some of the complexity, I do not prefer this method because it will add time to the build, and developers from Windows will not be expecting this.
I too was looking for the same thing, and i've just found it! using an xcconfig file!
Create a .xcconfig file either from xcode's file menu or just a simple text file, and add your entires like so:
PATH_TO_SOME_SDK = Volumes/DEV/Project
SOME_DEFINITION = 7
once you add that file to the project, you can add it (or different ones) to each configuration in the project's info panel under "Configuration".
the definitions along with their values will then appear in the project's build settings under "User-Defined", and will change dynamically as the value in the file changes.
you can then use the values in any other build setting like any other environment variable or macro:
$(PATH_TO_SOME_SDK)
for more info:
https://nshipster.com/xcconfig
https://medium.com/better-programming/working-with-xcode-configuration-files-398cfbe02b64
https://help.apple.com/xcode/#/dev745c5c974
better late than never...
:-)
I'm a Java developer, and a new comer to ios development. In learning phrase, I try to download some sample projects (include from small one to medium one) for reading how often they do work in an ios project. As I see, often, they put all source file into one folder (include header file, source file, .storyboard file, xib file ...) and I see this will make your project become messy.
So, I come here to ask a question that. Should we put source code in separate folders base on their usage, to make project less messy, right ? For example, all custom core data model class files should put into Model folder. All View file (such as .storyboard, .xib file ...) should put into View folder. All Controller file should put into Controller folder ...
If you often do this, please tell me your experience, how you folder your code ? And does XCode support virtual folders (that in XCode IDE you see source code in folders, but in hard drive, they're just same).
Thanks :)
Xcode differs from Eclipse and Android Studio in maintaining a separate project-level division of resources into folders that need have no correlation whatsoever to the file system. Given that the lack of namespaces usually leads people to be very relaxed about what formally is and is not a 'package', it's a real wild west out there.
I tend to keep things organised by mental package — model, view, controller at the top level, e.g. maybe web services, persistent store under model, etc. But even then command+shift+O and type a symbol or class name is by far the easiest way to navigate a project.
Others might argue that keeping things flat is better because then you don't have to keep the file system layout in sync manually and open-by-symbol plus the class browser obviate the need for stringent organisation, presenting a hierarchical relationship without the need to get either the disk or the workspace into agreement.
You first have to make the difference between folders and groups. Folders are used to organize contents on your filesystem whereas groups are used to organize contents within your Xcode project. You can think of groups as virtual folders. I personally prefer to keep a flat structure on the filesystem and organize everything using groups. This way is slightly more straight forward to include header files and it doesn't force you to maintain both the filesystem structure and the xcode structure.
In you Project you ca do any GROUPS you want to make simple and clean your project, like my screen:
Is easy and simple and you have two ways:
1) in your project right click in to right column then select NewGroup
2) drag and drop your folder in to a column to create a folder reference:
this only if you want integrate in your project a root with inside files PHP, HTML, ASP and more, but attention because after you distribute your app, if a people open .app file they found inside your REFERENCE FOLDER with all your clear code.
I think this is it ;)
Folders makes your code and its management easily, like we have packages in Java that we use to accumulate some common classes and its supporting class files.
In the same way we can use folders to manage our classes in XCode.
However its not necessary, varies from developer to developer as well as the complexity of code.
Happy Coding. :)
The approach you are discussing about is correct.
As far as folder in code is considered. If you create folder within Xcode and dividing the codes based on folders. Than all the classes will exist together on hard disk. But if you create folders within the project using finder and than adding the folder than codes will be saved to their respective folders.
Hope it will help you. Happy coding :)
I thought it would be interesting to attempt building multiple apps using the same code base, where the only differentiating data is held in a few plists. For example, one plist holds some theme info - a few key/values to drive the color scheme used in the app. I'll call the original version of this theme.plist.
I soon learned that I should create multiple targets in my project, and have been able to add these successfully. Each one, via it's own appname-info.plist, has a different name and bundle id - it's neat seeing all three on my home screen without any real extra work.
But right now they are all identical. I haven't figured out how to use a different set of data for each one.
My first thought was to have some folder for each target - each with its own theme plist named theme.plist - and somehow distribute each target with a different folder. But researching that idea doesn't get me much google juice.
So what about multiple theme files? Ok, so far that looks better - I can create an app1-theme.plist and 'app2-theme.plist' with different values for the same keys in each. And Xcode even lets me use some flags to say which targets should include each resource.
But I don't know how to load the appropriate plist at runtime. I need to examine something (the bundle ID?) and then assign the appropriate name of the theme plist to something (what)?
It seems like this might have something to with #ifdef, whatever that might be...?
Can someone explain how I should be looking to accomplish this? Am I on the right track? I'm happy to put some reading time in but I don't even know what to look up yet.
You are just about there. Xcode supports having multiple files with the same name in a project, one way you can do this by storing them in different folders within your project folder.
Unfortunately at this point Xcode won't give you a lot of help, so open your project in the Finder, create one subfolder for each of your apps, in those folders place a copy of the plist. Now add each copy in turn to your project, making sure you add each to just one of your targets.
You might want to create a group in Xcode called, say, "Theme files", to keep them altogether.
HTH
What you are trying to do is trivial. If you select a file from your project, and bring up the "File Inspector" in the utilities area (Press Command option 1) you should see a section "Target membership". Each target in your project will be listed, with a checkbox next to it. If you check the checkbox for a file and target, that file is built into that target. Un-check the checkbox for a file and target and that file is not copied over to the specified target (you may need to run a clean, and delete the app from the target device, to get rid of files that used to be included but that you have un-checked. Xcode generally won't automatically remove things that used to be included.
You could create a directory in your bundle and teach your app to scan that directory for plist files. Then include a different set of files in that directory for each target and each target app's behavior will change.
I've got a relatively large Xcode project that produces a single app. However, I have many clients/customers who require deep customization and branding of said app. These configurations include different graphics, a few different interfaces and implementations, and, perhaps most importantly, .xcconfig files.
My Xcode project has a dedicated group that points to a particular client's customization folder on disk, so by opening the Xcode project and building, you get a build of the single app with the current client's customizations. To switch to another client, I change where that group points to on disk. (I also change and switch-back the xcconfig "Based On" settings in the project's Info pane to reload the full xcconfig inheritance; Simply changing the group containing one or more xcconfig files doesn't reload this!) This has worked great for 100+ clients. It's a little tedious to switch this folder every time you need to build the app for a different client and ensure the xcconfig is correct, but it works.
Now I'm in the process of automating builds via the command line, and running into troubles. The quick and dirty solution to pointing the aforementioned Xcode group at a different customization folder was to copy the ProjectName.xcodeproj/project.pbxproj file to ProjectName.xcodeproj/project-template.pbxproj and put placeholders inside this file that can be grepped and replaced with the name and path of the desired customization folder. Then, temporarily overwrite project.pbxproj with the modified project-template.pbxproj, and build to get the correct app.
As you've probably observed, the project.pbxproj was duplicated and modified, and will therefore get out of sync as developers modify the original and forget to also update the template. And besides, I shouldn't really be messing with pbxproj files in this fashion anyway -- that's Xcode's private stuff.
So, is there a better way to tell Xcode about a folder full of resources, code, and config files perhaps during the Build Phase with a script or environment variable, rather than at the project group level? The most complicated bit seems to be the xcconfig chain, since each client has their own xcconfig file that inherits from the single app's Debug, Development, and Distribution xcconfig files.
Sorry for the long-windedness of this question, but it's a little complicated! Any suggestions would be greatly appreciated!
I think you would way better off using the targets feature in Xcode. Have one project and the resources of every clients in that project.
You can then duplicate the target you already have (right-click on your target, by selecting the project file in Xcode's Project Navigator).
All your targets will be compiled with the same code. You just need to change the resources in Build Phases > Copy Bundle Resources to have different app created for each target. No need to look at Xcode's internal files.
You can even change the code in your source files by adding a preprocessor macro in your build options (something like FIRST_CLIENT=1) and then look for these definition in your file with #if FIRST_CLIENT.
I have a project set-up like this and it works pretty well :