Re: Setting up a workspace with main app and bundles
Re: Setting up a workspace with main app and bundles
- Subject: Re: Setting up a workspace with main app and bundles
- From: David Mirabito <email@hidden>
- Date: Wed, 09 Nov 2011 09:34:43 +0000
Ah, I just found:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html
And it seems the recommendation (for the 'Abstract Base Classes'
method) is for me to DMBase.m/h in a framework that both the main app
and each plugin pull in.
And I should be putting them into a plugins subdir in the main app bundle.
Easy when you know how!
Thanks
-DavidM
On Wed, Nov 9, 2011 at 9:00 AM, David Mirabito <email@hidden> wrote:
> Hello,
>
> I have an OSX application which includes a base object DMBase and
> several subclasses: DMSubA, DMSubB, ...
> At runtime I get the Class of children dynamically via
> NSClassFromString(), alloc/init them and add to some collection that
> is displayed by a tree view and controller. This all works very
> nicely.
>
> What I'd like is to get setup so that new subclasses can be added via
> bundles. They don't need to be individually installable by the user,
> I'm happy for the bundle to either be present in the app's Resources
> directory or not.
> I believe I can walk the NSBundles in this resource directory, and
> call -classNamed: to find my actual subclass.
>
> Where I'm stuck is getting it all built. I've made a test workspace to
> test without all the app's baggage:
> New Workspace
> add Project ->CocoaApp: DaveApp. Here I created classes for DMBase and
> DMSubA. These still work.
> Add Project->CocoaBundle: DaveXXPlugin. Here I created only one class,
> DMSubXX which subclasses DMBase.
>
> I can add the bundle's Product to the 'bundle copy' phase of the app
> so that it (in theory?) will appear when I rebuild the main
> application.
>
> Where I'm stuck:
> 1. DMSubXX can't import DMBase.h so compilation fails.
> Unless I #import "../../DaveApp/DaveApp/DMBase.h". This feels pretty
> wrong. The workspace knows where the projects are, so I feel icky
> expressing their on-disk relative locations this way.
>
> 2. Even with the import hack, it won't link as the bundle cannot find
> _OBJC_METACLASS_$_DMBase.
> In retrospect I guess this is kind of expected.
>
> 3. I can't seem to add the bundle to a target dependancy of the app,
> so I'm not sure it will all 'just work' with building the bundle,
> copying to the app and staring it - with one click/cmd-R even if I can
> get the bundle properly compiled and linked.
>
> So I guess my question is:
> a) How do I setup XCode (4.2, Lion) to properly reflect what I'm trying to do
> or
> b) Is my approach (i.e. base class in the app and bundle/plugins
> provide a subclass) fundamentally broken, in which case my Q is how
> should I structure things?
>
> Thanks in advance!
> -DavidM
>
>
> PS: It probably doesn't change anything, but ...
> Each subclass also has a corresponding DMSubA.nib containing a view
> which is displayed for that object. So eventually the plugin will need
> to provide DMSubXX class which responds to -view and does the right
> thing. I expect bundleForClass will play a role in loading the NIB
> correctly and this will work once I get basic class loading
> functional.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden