Best way to import a pack or "system" of new classes?

Here's an Advanced question for Advanced developers.

So I've written a largish "subsystem". It is essentially a UIViewController called CleverViewController which is a UIViewController.

Now, there are a large number of supporting classes (about ten) that do the hard work: perform math functions, image processing, purely logical functions, build images or what have you with thousands of lines of code.

(To do this, I simply started a new XCode project / app "Scratchpad" which does little other than load and launch the CleverViewController. So currently it works as an app, which launches CleverViewController. The ten or so classes I mention that are part of the "subsystem" simply sit there in that project/app.)

So now, we will use CleverViewController, the new technology generally, in various apps. (Or perhaps friends would want to use it, etc.)

What's the best way to "do" this? Have I screwed everything up, and really it should just be ONE (pretty big) class rather than a dozen classes? (I could understand that then as I would simply add that new (big) class where needed, like adding any other class.)

Do I have to make a "framework" like the Apple frameworks? (If so, what the hell are they, how do you do it,开发者_JS百科 etc?!?)

In fact, do you just have to lamely include all of the dozen classes and that's that (obviously perhaps putting them in a grouped subfolder).

What about all the headers and so on? (Currently I just have the dozen includes in the pch file of the scratchpad project.)

Shouldn't it be easy to "maintain" this "subsystem" separately and so on?

I'm afraid I know nothing about this: if the answer is obvious, hit me over the head and let me know.

Thank you for any info on this !

Matthew if you see this ... I'm looking for your Framework link, I did not see it.

---

ideally, you'd create a dynamic library (which a framework would qualify as).

but apple's opted to prohibit this in iOS so the best way is to use a static library. then you create an xcodeproj with this lib and distribute that to your friends along with the source -- so they may assist in development ;)

with a static library, each executable would then copy the code (by statically linking) to their app. in osx, distributing objc classes is a nightmare (due to the flat namespace when the classes are loaded -- you get runtime class collisions).

all the client has to do to use this library is add the lib's xcodeproj to their app, configure it as a build dependency, then link. it's quite easy once you have the hang of it.

if possible, it's better to write these in c or c++ because the objc symbols and dependencies may not be stripped from the final executable - if they only use one class in the library, they'll still have to ship all classes.

good luck

EDIT

1) What is a static|dynamic library?

to be really brief in my description of a complex topic: they are reusable binaries. How they are used, linked, merged, loaded depends on the image type. In essence, you create a shared library by compiling a collection of source files which produces the library. Then you simply link your app to the library. This is a convenience in software development. If you did not link your app to Foundation.framework, then you'd need the source for NSString to use the class. So, it greatly simplifies software development by being able to organize, separate and reuse programs. It's also useful because your app may be improved when (for example) apple updates the OS (in turn updating the frameworks). These updates change the execution of your program - typically for the better, as bugs are fixed and performance enhancements are made.

For more details:

http://en.wikipedia.org/wiki/Static_library

http://en.wikipedia.org/wiki/Shared_library

2) You say "...create an xcodeproj with this lib..." ..how do I create the "lib"?

ok, the process is similar for iOS, but here's how to do it on OS X (I'm using Xcode 3.2.x here):

• select the menu item File>New Project
• in the project template chooser, select "Framework & Library"
• for a framework, choose "Cocoa Framework". note that the framework does not need to use Cocoa at all, it can be pure C or C++ - it's only a template, and you can alter the template's settings after your project has been saved.
• for a static library, choose "BSD C Library", then "static" from the popup below
• for a dynamic library, choose "BSD C Library", then "dynamic" from the popup below

again, many of the templates are practically identical apart from the extension of the generated implementation files and the libraries the target links to by default.

3) When you say "distributing objc classes is a nightmare" you mean e.g. if I literally just gave you two text files "Soften.m" and "Soften.h" ..?

What I meant in that case: distributing shared libraries which have objc classes or categories is a nightmare - in some contexts. The problem is that the objc symbols (any defined objc method or class) can collide during load. For example, 2 distinct classes from 2 separate shared libraries will collide when the libraries are loaded into a program.

This is not an issue with static libs - because the linker will abort. But this is a problem with dynamic loading because let's say you have a class called QTCaptureConnection and your app does not link to QTKit.framework (which also defines this objc class). If your app's plugin or any library that is loaded into the executable links to QTKit, then you'll have an objc load collision.

What this means is that only one class will load, and one class will be returned when you message [[QTCaptureConnection alloc] init] - one of the two dependencies will not be returned the class they expect. That means every class name and method of every binary image loaded into an executable must be unique. Most of the time, this is beyond your control. The most obvious case is developing plugins. If you're developing plugins, that also means you have to rename every class reused by every plugin you distribute, or distribute a shared library for the shared classes - which is not an option in many cases.

4) ".. add the lib's xcodeproj to their app" - how do you literally do that?

you drag the xcodeproj from Finder into an open project in Xcode, like you would do with a header file (but you don't copy the file or add it to a target). Then Xcode updates the references, adds the project's symbols (e.g., class names, functions), and you'll be able to configure the targets of the project you dragged in as dependencies, and be able to link to the project's libraries.

5) c/++ understood, but not practicable here (I don't think)

It depends on what the library does. There's ultimately no c++ or objc feature that cannot be approximated using C alone. Sooo... you can often implement what you need using C or C++. The problem gets out of control because an app may want a small feature from several different libraries, while each library may be a few MB. so all these libraries can add (as an example) 20 MB to the final app. If the symbols could be stripped, then the client (using the library) would only pay for what he/she called (in binary size). So the 19 MB of unused stuff could be removed from the final app (and a bunch of other issues could be avoided too).

6) what the hell are Apple's "Framework" thingies (UIKit, CoreGraphics, etc etc) - how's that fit in here?

one of the biggest limitations with typical shared libraries is that they would only include one binary image (just the complied code). so, people came up with tons of ways to merge other things they wanted/needed to distribute into the binary which were dependencies of the library. examples include graphics/images or text based files.

frameworks are cool because they function as dynamic libraries, but they are also directory structures. using a framework, you can just copy the image, pdf, nib file, etc that is used by the library.

if you're using a static library, the client (reusing the library) would have to manually add every resource to the copy files build phase of their app, make sure they exist, and keep them in sync as the app and libraries mature. with a framework, much of those dependencies are removed. Take a peek at all the stuff in /System/Library/Frameworks/AppKit.framework/ - it includes a binary (including the implementation of a ton of objc classes), a ton of localized images, nib files, localized string files, header files, and other important data.