Re: IBOutlet to different classes, conditional build
Re: IBOutlet to different classes, conditional build
- Subject: Re: IBOutlet to different classes, conditional build
- From: WT <email@hidden>
- Date: Wed, 23 Feb 2011 22:21:19 -0300
>>> I have one project that outputs two binaries - one for the App Store (an
>>> app) and one for my own website version (a prefpane).
>>>
>>> All the classes are the same except for two:
>>>
>>> MyPrefPaneDelegate
>>>
>>> MyAppDelegate
>>>
>>> These are each in their respective apps.
>>>
>>> How can I build my shared classes so I can do:
>>>
>>> #ifdef RETAIL
>>> IBOutlet MyPrefPaneDelegate delegate
>>> #endif
>>>
>>> #ifdef APPSTORE
>>> IBOutlet MyAppDelegate delegate
>>> #endif
>>>
>>>
>>> It obviously compiles ok. But I have two nibs... One for the AppStore and
>>> one for the Retail version. My CommonClass is instantiated in both nibs, but
>>> in one case I need an outlet to point to a MyPrefPaneDelegate and in the
>>> other it needs to point to a MyAppDelegate
>
>> You can define a common superclass for both MyAppDelegate and MyPrefDelegate -
>> MyCommonAppDelegate - and use that as the type of the IBOutlet. You can then
>> #define convenience delegates for each actual case, so you'd have something
>> like:
>>
>> IBOutlet MyCommonAppDelegate* commonDelegate;
>>
>> and then
>>
>> #ifdef RETAIL
>> #define delegate ((MyPrefPaneDelegate*) commonDelegate)
>> #endif
>>
>> #ifdef APPSTORE
>> #define delegate ((MyAppDelegate*) commonDelegate)
>> #endif
>>
>> Your superclass can even have the common code or it could be just an empty
>> "marker" to give both concrete classes a common type. Either way, everywhere
>> else you may continue to use delegate and never have to use commonDelegate.
>> Its only appearance would be where the above appears and in the nibs.
>>
>> And if you can't conveniently define a common superclass for both, define an
>> empty protocol that they both implement, then use that to define the IBOutlet
>> instead.
>>
>> The point is, all you need is a common type for both classes.
>>
> I guess the other issue is that if I do it this way the retail version needs
> to have IBAction methods for Sparkle updating which I need to keep out of
> the AppStore version... So how can I set it up so that one nib can have a
> button linked to an IBAction (which is part of the delegate class), while
> the other nib has a mostly identical nib that does not have these
> outlet/actions?
>
> So when I define MyCommonAppDelegate in the nib, it should only have the
> "SparkleUpdate" IBAction in the retail version... So this code really sits
> in MyPrefPaneDelegate... But how do I get IB to realize this?
>
> I am really trying not to have any duplicated code here.
Easy.
If you use the superclass idea, have the action methods declared and defined in the superclass, with empty implementations. The concrete retail subclass overrides those implementations with what you're actually supposed to do. The concrete app subclass doesn't care. The retail nib has buttons that trigger those actions, the app nib doesn't use the actions at all.
If you go with the protocol idea, it's pretty much the same. Define your action methods in the protocol, with empty implementations in the app delegate class and actual useful implementations in the retail delegate class. Again, the retail nib has buttons that trigger those actions, but the app nib ignores them.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden