Just starting to poke around iPhone development. I am trying to add an external project/library to mine (specifically the ASIHTTPRequest, http://allseeing-i.com/ASIHTTPRequest/).
I am at a bit of a loss as to how I go about actually adding this dependency to my project. I come from a Visual Studio/C# world, and in Visual Studio I know I would "Add Existing Project" to my solution file and then add a reference to the new project to my own. Or, alternatively, reference the DLL directly if it is already built.
The ASIHttpRequest project is on GitHub, and provides full source code. I just don't have any idea about how to actually get this dependency into my own project. I tried "Project -> Add To Project", and just selected the folder ASIHTTPRequest extracted out into. I see it as a sub-folder to my project now... but get a ton of build errors. I removed everything but the .h and .m files from this subfolder, and now I don't get any build errors from those resources anymore, but trying to reference a ASIHTTPRequest object in my own project gives "undeclared" errors.
Am I missing something here? Can I not of these .h and .m files in subfolders?
You're on the right track. You just need to #import the ASIHTTPRequest header in the file where you want to use it. You do have to make sure you've met all the dependencies specified on the ASI site, but once you've done that, everything should work right by just doing an import like you've described. Once all that is set and everything is compiled, add this:
#import "ASIHTTPRequest.h"
to the top of the file where you want to use the library.
Related
I know something like this is already asked many times on SO, but I've tried everything (been at this for three hours now) and I still didn't find a solution. I'm quite new to xCode and I'm starting to work on a project that was originally created by somebody else.
So, I have a library project in my xcode (XS2Library) and now I would like to reference to that library in my other project (WaarBenJij). Building the Library succeeds and I reference to it by adding the LibXS2Library.a to the Project target's "Link Binary With Libraries".
Xcode doesn't give me any errors, so it looks like the library project is referenced appropriately. However, when I try to build my project I get the error that a class that resides in my library project cannot be found ("'XS2URLLoader.h' file not found").
Can anybody steer me in the right direction, maybe?
There's a sensible difference between the .a file, which is needed for linkage and contains the library source, and the .h file, which is needed to compile (and preprocess) and which contains the functions and classes declarations.
Here you included the .a file, which is required for a later step, but to use the library you also need to import the required .h files into your project.
The easier way is to simply put them in your project.
Or you can add the whole library as a subproject and as a dependency.
I'm really struggling to get this to work in xcode 4.
I have one project that I will reuse in many applications (networking) so I create a workspace and add my two projects. So far so good....
This is where it fails..
#import "JSONRequest.h"
For no apparent reason. It auto completes the file name of the header file. I thought this had something to do with the "scheme" (also new in xcode 4) so I've tried to add my networking target in the build phase. Changing order of them... set "Shared" under Manage schemes.. I've tried so many different combinations of the settings without any success.. And the error message is get is:
JSONRequest.h: No such file or directory
If you have a clue, please let me know.
You can add the header or source folder of your project you're referencing to your Header Search Paths.
Click on the target that's importing JSONRequest.h.
Click on Build Settings.
Enter "Header Search Paths" into the search box.
Double click on the value cell.
Click the + sign.
Set the path to the project you're referring. Let's say it's called JSONlib. The path is relative to the root of the referring project (the project that's using JSONlib). For example: ../JSONlib/src/headers/ or wherever it is that the .h file lives.
Click done.
Clean and then build.
You'll find more info about this problem in the apple developer forums. Best of luck.
What are you really trying to do?
If you have an entire Xcode project you intend to share between different products that usually suggests your project builds one or more targets (such as a framework, etc.). Therefore, your "shared" project should be able to build the framework on its own, irrespective of the workspace it's contained in, right?
Let's assume it's a framework. In most cases, Xcode can figure out the dependency by simply adding the framework product to the Link build phase of the (assumed) app using the framework. Done. Xcode should know to build the framework project's target first, since it's linked against when building the app project's target.
So your problem is likely just a matter of knowing where Xcode is looking to find files. Since projects within workspaces share that workspace's build folder, they can all "see" each other. But in the case of a framework, A simple import by file name won't cut it. You'd need:
#import <MyNetworkingFramework/MyNetworkingFramework.h>
Since you're including a specific header (JSONRequest.h) (which must be one of the public headers in the framework target's copy headers build phase), you'd need:
#import <MyNetworkingFramework/JSONRequest.h>
If your "shared" project is not a framework, you'll need to amend your question to include a more thorough description of your two projects and their targets.
This worked for me,
In build settings --> Header Search Path --> Add below entry
$(SRCROOT) and mark it as recursive. If above not worked you can also try following way, <path-of-other-project> and mark it as recursive. Hope this helps to you ! (You may require to clean or restart the workspace)
Sorry for the n00b question, but I have no more hair to pull. =(
I'm building my iOS project using XCode and have a reference to another XCode project, to make this work I also need to reference the bundle-file. The developer who built the project and bundle wanted to organize things and thus put all the images inside of this .bundle-file.
Now my question is this:
How do you add a file/resource to a .bundle file? -> http://grab.by/7p3Y
The file type of the bundle is: wrapper.plug-in -> http://grab.by/7p3W
The files I add by right-clicking and selecting add existing files all end up in the project not in the bundle resource.
Any kind of help will be most appreciated! Also an indication if this is common or a custom solution?
Best regards
Abeansits
Update:
As usual the problem was me, I'm blaming this on low sugar levels. =(
All you need to do is add a file to the bundle manually and it will show up in XCode.
As I wrote in the question, the solution is really simple. Just add the files you need inside the project to the bundle. Since the bundle is actually a folder, you can right click it an select show content. Anything you later add to the folder will show up in the project.
I guess this confused me since usually when you add resources to your project you need to do this through XCode.
I've followed this tutorial for setting up a static library with common classes from 3 projects we are working on.
It's pretty simple, create a new static library project on xcode, add the code there, a change some headers role from project to public. The tutorial says I should add my library folder to the header search paths recursively.
Is this the right way to go?
I mean, on my library project, I have files separated in folders like Global/, InfoScreen/, Additions/. I was trying to setup one LOKit.h file on the root folder, and inside that file #import everything I need to expose. So on my host project I don't need to add the folder recursively to the header search path, and would just #import "LOKit.h".
But I couldn't get this to work, the host project won't build complaining about all the classes I didn't add to LOKit.h, even though the library project builds.
So, my question is, what is the right way of exposing header files when I setup a Cocoa Touch Static Library project on xCode?
I ended up setting up a LOKit.h on the project root folder like this:
#import "Global/LOCommon.h"
#import "Additions/LOAdditions.h"
#import "View/LOCustomView1.h"
#import "View/LOCustomView2.h"
And on my host project I set the header search path variable to my library's root folder, without recursion. Whenever I need to, I just import LOKit.h.
I also included on this library project common libraries (like JSON, FBConnect and Reachabillity) that were shared across projects. This way I only need to update those libraries in one place, once.
When using static libraries I usually go one of the following two ways:
If I created the library myself and it is somewhat tightly coupled to the project which uses the lib, I usually create a source root for the library in the XCode settings. Then you can add the source root as a variable to the header paths recursively.
On the other hand, if the library is either not by me, or is maintained entirely separately from my project, I usually copy a version of the library plus the relevant headers to the project using it and reference those. This is a bit more cumbersome if you need constant updates, but does not break your application if something in the library changes.
I have some utility functions like:
void myVibratePhone()
{
AudioServicesPlaySystemSound (kSystemSoundID_Vibrate) ;
}
that I'd like to use across all my projects.
In C, I'd give each project the header file, and link in the .OBJ file (or perhaps create a library).
What is the Apple-approved recommended way to share code (cocoa and C primarily) among my apps? Would I need a framework for this? How would I go about creating one?
Also, since I'm using subversion for version control, if I use a framework, do I place the version of the framework that the app is using in the subversion repository for the project so that anyone who checks it out can build it straight away or make it a requirement that people check out a project + check out the utility functions also for a successful build of any project?
I don't plan on putting anything on the App Store at this time, but I don't want to do anything that will cause apple to not accept an app in any case.
I found this writeup about xcode 3.0 (I'm using Xcode 3.2.1):
How do I create a bundle of reusable code in Xcode?
I followed it, but am having one issue:
1) trouble finding my library .h file in the main project: I've tried both hardcoding it in the main projects .h file
#import "file://localhost/Users/piesia/Documents/My Utilities/MyUtilities.h"
as well as:
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "~/Documents/My Utilities/MyUtilities.h"
I've also tried updating Header search paths in the Project Build settings:
"/Users/piesia/Documents/My Utilities/**"
when using #import
After a lot of trying (and replacing %20 with space), I was only able to get the variants
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "../../My Utilities/MyUtilities.h"
but I'd prefer not to hard code the path if I can figure out a better way.
So, in closing, 1) is the writeup that I'm following the recommended way to do shared code in Xcode 2) is it recommended that I keep the shared files in a separate subversion repository from the main program and link and include it in as I'm doing now and 3) do you know what I'm doing wrong in my attempts at loading the shared header file? Would anything that I'm doing or not doing with shared code hurt my chances of getting approval if I ever decided to submit it to the App Store?
I agree with creating a static library to share the code.
To add the headers to the project you need to set the "User Header Search Paths" to the location of the .h files.
You then import the headers using something similar to:
#import "YourHeader.h"
You shouldn't need any additional path information in the import if the header search path is set correctly.
Oh this one is a bugger! - I think unfortunately the easiest way is to hardcode.
My team has dozens of reusable components in our products, many of them shared between Mac and iPhone. My experience in this is that most of the time it's much easier to just include the source code rather than to create a separate static library. The separate project for the library adds a lot of complexity and seldom provides much value. Here is how I usually approach it:
In subversion we have a directory tree like this:
/common
/Component1
/Component2
/Project1
/Project2
...
In Project1.xcodeproj, we just drag in "Existing files" from common into the tree (don't copy). Doing it this way avoids lots of overhead in managing another project. This does mean that changes to the common tree can break any of the projects. That means you need to recompile everything before committing (we use a top-level build script to check that you didn't break anything). The advantage of the static library is that you can stage this by upgrading the library for each project when it's ready. On the other hand, it means that you have to rev the library often and manage syncing it around. We've found that just sharing the code directly typically is much more effective.