I'm working with xcode and I have classes associated with other projects that I want to be included in new projects. I realize that the #import will do the job technically (although what should i do if it's out of the project root folder). But what do I do if I want to include the class "properly" --basically so i can double click and edit out of the main project window where you can see all your files and such.
I guess I'm just looking for the best and/or proper way to include/import (into the project) .h and .m files that I've already created outside of the current project I'm working on. Taking into consideration that I may want to modify the class from the original without subclassing. Hopefully this makes sense.
Thanks,
Nick
Xcode project file organization doesn't reflect the data files on disk. Files can be added to a project from anywhere in the file system. When you add the files, choosing not to copy the files to the current project's directory means that the original files are used. Selecting one of these files in Xcode for editing will alter the original file in that other project. When returning to that other project, Xcode will use the edited files in any further work.
This type of use can be quite handy while working on multiple projects with some shared code. Yet, it can also cause headaches for a versioning system.
Might be worth thinking about how to make the classes into a private framework - then you can import that as another dependency each time. Alternatively you could use a separate version control system location to store the shared classes and just check that out into the project folder.
Related
I am writing a very basic library in VB.NET
The library just contains classes and modules.
Now in built output I see this files
Application.Designer.vb
Application.myapp
AssemblyInfo.vb
Resources.Designer.vb
Resources.resx
Settings.Designer.vb
Settings.settings
Since I've seen other libraries with only AssemblyInfo.vb file, I was wondering if I can delete the rest.
What is the minimum of files I need here for the lib to work correctly, since I don't have any ressource or setting?
All the files you listed are necessary for a vb.net library project. And these files are generated (in My Project folder) when the project created not the build output files. So you need to keep all the files you listed in order to develop and build your project locally.
And for the files of build output, you can add these files in .gitignore.
When you create a project in VS, you select a predefined template that dictates what gets created. People often become accustomed to seeing the superfluous objects that a given template creates and assume that those objects are mandatory and must be there, However, much of it is not needed.
There is also the Empty Project template (the exact name of this template varies depending on the VS version used).
In VS2017, selection of the template would look like this:
This is a bare-bones project and the Solution Explorer will look like this:
As you can see, there are no pre-loaded references. You will need to add them yourself. About the only thing defined in this template is that you are using the VB language; This project starts out as a WinForm type, so go to the Project Properties->Application tab and change the "Application type" to "Class Library" since you want to create a library.
You may find it useful to start with an Empty Project and add the stuff you normally use and then export the project as new template (in VS2017: Project Menu->Export Template). For more on creating termplates, see: Creating Project and Item Templates
Edit: I just realized that I did not answer your real question about deleting the unused items. I just did a test case and deleted the items under MyProject. I received an error on deletion, but doing a clean/rebuild allowed me to proceed without issues. I would recommend that you backup the project before attempting this on an existing project, but I saw no long term issues in deleting unneeded objects from MyProject.
I would like to add into project some files that shouldn't be compiled. I mean mainly text files with for example notes, concepts, comments etc.
I realized that it is possible only at module level. But it is not very convenient. I'd rather prefer to keep them on project level. Is it possible in any way?
And if not:
I have another idea: to create special module, name it for example "other_stuff", do not create src directory and put files there. Is it ok? I'm afraid of potential compilation problems when one of modules is artificial, with no sources but still has sdk assigned (it is probably impossible to leave module without sdk assigned).
While generating artifacts you can add any file into your artifact. Also, in modules you can have folders not declared as source, and they will not be compiled.
There is code that I want to include in most of my projects. Things like AFNetworking, categories for CoreData and unit testing, etc.
It seems logical to include all of these in a static library, and then use it in each project. I've noticed though, that many third-party libraries (like AFNetworking, and it's predecessor ASIHTTP) are included in projects by copying over all of their source files and then manually linking the necessary libraries to the project target.
This seems to me like the easiest way. It took a fair amount of time to figure out how to include an existing static library into a project. Even after I knew how, it still seems like a pain to do it for every new project. Also, the header search paths that you specify are to a local directory with the static library's files. Wouldn't it be easier, and is there a way, to copy the static library's files into the project? This is the same idea as including the class files directly like most libraries seem to do already, but it would be more organized because everything would be lumped into one library project, instead of having class files everywhere and having to include every one of them.
Static libraries feel like they should be the right way to go. Make a library that can be used with all projects that includes classes that every project will need. Makes sense. I am just conflicted because it seems like the right way to go is to leave everything out of a 'formal' library, and just copy over all of the class files instead.
I guess I am just looking for what experienced developers find to be the best option.
I would be among the first to admit that the process of referencing a static library in Xcode is not entirely intuitive. However, using a static library is the best option, without a doubt.
The main reason is maintainability: when you copy source code of a library to many places, you must remember to update all of them to the latest code when you upgrade to the next version of the library. This may be a rather error-prone process, especially when the underlying library source changes significantly (e.g. new files are added, old files are renamed, etc.)
There's a halfway solution - make an XCode project that builds your static library from source and put that into a shared repository (ie.. git submodule etc) which is included from each project's main repository.
Each of your projects would include this submodule and project. Then they get the latest source code each time they pull that submodule. If you set this up as a build dependency it will build a static library the first time you build and then XCode is smart enough just to include it each subsequent build so you get the benefit of fast build times.
You also get the advantage of having the source right there for stepping though / debugging.
If it's in a separate XCode project and a new version of a library adds or removes a source file you would only need to change that shared project - all your individual projects wouldn't change at all.
What about using CocoaPods? This tool does exactly what you want in a declarative way: you have a file (Podfile) where you declare your dependencies, and the tool downloads all the dependencies and builds a static library that gets added to your project.
I would agree that static libraries feel like they might be the correct way to go for a number of reasons, but can also introduce some issues.
The positives would be creating an easy way to add a library to a project. Although not completely intuitive, it is rather trivial to add a static library to a project after one does it a few times. Add the files, add the search path, done. This could also be useful in certain source control situations. Also, updating a library may be easier.
I think the real problem here is for the open source community. By including, say AFNetworking, for example, as a static library, you lose all access to the implementation files. This is a great feature of including source rather than a library. It lets you change code to how you see fit, and hopefully give back.
I just banged my head for a while and figured out a solution, but I want to make sure that I'm doing things right and that I actually know what I'm doing (I'm pretty sure I never know what I'm doing :)
I have two projects that I've been working on, each offering different functionality. I want one project (A) to be able to use the functionality of the other (B). I tried going about it by creating a workspace and putting both projects into it, but I couldn't "see" project B's files from project A (autocomplete after #import did work, but it gave a compiler error). So I tried adding it as a "sub-project" and found the same. I figured this would be easy, but guess not.
What I ended up doing was creating a new project (C) as a "Cocoa Touch Static Library" project, and put my files from Project B into it. I built it.
I then went back to project A and added project C into it as a sub-project.
Then I added the path on the filesystem of project C into the User Header Search Paths setting under Build Settings of project A.
Then I added the .a file from Project C into the Link Binary with Libraries section of Project A.
Then it worked.
But honestly I have no idea what the meaning of a static library is.
Is all this necessary? Or is there an easier way to just integrate two projects (without me having to copy the files from one project to another)?
Thanks in advance!
Jon
You were on the right track with workspaces. What I do is have three projects in the workspace. One with no targets just to hold the generic classes. A second for my iOS target Project. And a third for mac. Keep the original files in the one with no target, then drag the files to the other two projects that creates references, so when you edit one it changes all three.
An iPad project I have been working on has become bloated with a huge number of files. The application is a prototype and we are considering ways to prevent this when we rewrite it.
One of the members of our team suggests dividing all of the components into separate Xcode projects which will be included in a master Xcode project.
Is this a good idea? What are the reasons, if any, to avoid dividing features/components/controls into separate Xcode projects?
You can add a subsidiary project file to a master project file in Xcode. Just choose "Add File" and add it. When Xcode builds the master it will build the subsidiary as well if needed.
I use a similar system. I often break a project into sub projects just so I can focus on and enforce encapsulation. I write the data model first, then add the app delegate, then specific UI elements. I add each project to the next in turn. This also allows me to go back and change things without as much risk of breaking.
Really, a properly designed objective-c app should be easy to decompose into multiple project. Ideally, all the components are so encapsulate that they don't need any others save the data model.
We have put some of the code in its own project, building a framework which we link against at some of the other projects. It's sometimes annoying that you won't see the implementation files of the framework code right away in another project (by cmd+clicking or cmd+shift+D, or whatever you do normally to navigate). Xcode will only show you the header, you'll have to open the other project and find your file there manually. Not a big deal, but if you look up the code often, it will bother you.
A real problem is that you change the scope of some operations. Stuff like "Find in project" will work on a different file set, which might not be what you want sometimes (trying to find where this method is called / key is used in your whole code, or something); well, there remains Finder / find, so it might be okay. Refactoring is not - all the renaming stuff just breaks, as it will change only the code of the current project, but not of projects referencing this one. If you change interfaces often, better avoid splitting up the project.
A good thing is that you will get less conflicts on your .xcodeproj files (if stored in a shared repository) as someone removing a file from project X won't create a conflict with someone else adding a target on project Y, which where previously the same .xcodeproj (not exactly sure this is a conflict case, but there definitely are some).
Now with Xcode4 you can create a workspace and add all your projects there. Only for documentation purpose :)
To view and modify subproject implementation files, you should add the sub projects directly into the main project.
1 step - Drag and drop the .xcode project files to main project.
2 step - Go to main project TARGETS - > Build Phases. Add subproject target in Target Dependencies. You can also add binary files in Link Binary With Libraries.
3 step - Add subproject source path to main projects header search path.
Go to main project - > Build Settings - > Header Search Paths (e.g $(SRCROOT)/../CoconutKit-master/CoconutKit/Sources )
An Xcode project can have any number of build targets within it, and you can arbitrarily group source files into folders. What makes you think that multiple projects are necessary?