I want to create an application core that connects to a webservice, downloads the data, parses it and then returns it to a view controller. This core would ideally handle requests from multiple controllers and abstract away a lot of repetitive code. Also, I want to potentially use this core for a mac os x application. Would these tasks be a good idea for a static library? Also, how do I add a static library to my iPhone App? Once the static library is added, how do I reference it (i.e. import statements, etc..)?
+3
A:
I want to create an application core that connects to a webservice, downloads the data, parses it and then returns it to a view controller. This core would ideally handle requests from multiple controllers and abstract away a lot of repetitive code. Also, I want to potentially use this core for a mac os x application. Would these tasks be a good idea for a static library?
Yes.
Also, how do I add a static library to my iPhone App?
Add the static library's target to your project, then add its build product to your iPhone app's target. When you start work on your Mac OS X app, add the library build product to that target as well.
Once the static library is added, how do I reference it (i.e. import statements, etc..)?
#import is a preprocessor directive; you use it on a header file during the preprocessing stage of the compile-source-files phase.
Compiling the source files produces object files, which the linker will fuse (link) together in the next phase. This phase also includes the linker linking in any static libraries.
You must have the library build product (from the library target) added in the Link Binaries phase of the application target in order to have the linker link the library into your application.
Peter Hosey
2009-07-28 01:16:19
thanks for your answer - i'm still a little confused, do I need import statements?? If so, do I just use the name of the file in the static library for the import statement??
zPesk
2009-07-28 01:20:57
You need an `#import` statement to import a header file. `#import` (which is a *preprocessor* directive) and libraries (which you give to the *linker*) have nothing directly to do with each other. The purpose of `#import` is to `#import` the header for an interface from the library (such as the interface for a class in the library) into the source file where you'll be using that interface.
Peter Hosey
2009-07-28 01:43:57
Simply put, the header contains declarations, and the library contains the actual implementations. You need to `#import` the declarations so that the compiler knows what code you'll be using; you need to link the library into your app so that your app has the code available at runtime.
Peter Hosey
2009-07-28 01:48:35
Maybe it would help to point to an existing example in the iPhone sample code? I haven't found one yet myself -- do you know of one?
Amagrammer
2009-07-28 02:01:09
For an open source example, you can look at what's been done in the Core Plot static library implementation: http://code.google.com/p/core-plot/ , additionally we have documentation on how to incorporate the library within applications: http://code.google.com/p/core-plot/wiki/UsingCorePlotInApplications
Brad Larson
2009-07-28 12:49:20
+1
A:
There's no really good reason I can think of to create a static library unless you want to distribute it without distributing source. You have to re-compile for each platform, so you might as well just add the library .h and .m files from a common location (e.g. don't copy the file into the projects when adding them. The "Add Existing File..." selection will allow you to deselect the checkbox labeled "Copy items into destination group's folder (if needed)" when you add). Then, any changes you make to the library files will be updated in both projects. Building a static library just adds another layer of complexity (additional targets, etc.) that is unnecessary (IMHO, sorry to disagree Peter ;-) .
Best Regards.
Matt Long
2009-07-28 07:24:35
The point of a library is that you do NOT want it to just silently go around changing itself - without warning - introducing new bugs, bringing back old bugs, etc.It's a strong version of the "encapsulation" idea, which partly inspired the creation of OOP.This is a horrific nightmare. Once you've spent days trying to debug why your app went from "working" to "broken" for no apparent reason, and eventually prove you changed NOTHING ... and then spent days wondering how that could possibly happen, and hating Xcode for not being able to clean properly ... you'll see the value of libraries :).
Adam
2009-11-01 13:42:47