Re: IBOutlet to different classes, conditional build
Re: IBOutlet to different classes, conditional build
- Subject: Re: IBOutlet to different classes, conditional build
- From: Trygve Inda <email@hidden>
- Date: Thu, 24 Feb 2011 02:05:19 +0000
- Thread-topic: IBOutlet to different classes, conditional build
>>>> 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.
>
So if the superclass has
-(IBAction)doSparkleStuff:(id)sender
And this supercalss is instantiated in the nib, won't this appear in the nib
somewhere even if it does not hook to the action? I can't have it that way
(at last if I want to call the methods anything containing "sparkle".
T
_______________________________________________
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