14:49 <aaronpk> workshop: Can I do this? "@property (nonatomic, assign) BOOL *canTwitter;"

14:50 <aaronpk> Trying to give a view a pointer to a boolean that exists in the view that pushed the second one

14:56 <workshop> hey

14:57 <aaronpk> hey there

14:57 <workshop> so i think you can do a pointer to a bool, sure

14:57 <workshop> as for a property, not sure, but dont' see why not

14:57 <workshop> as for design, it would be better to separate things

14:57 <workshop> the master vc shouldn't know about the pushed vc, and vice-versa

14:57 <workshop> even doing sub.parentViewController is iffy

14:57 <workshop> it should be generic

14:58 <workshop> so that later you can move either around

14:58 <workshop> it would more cocoa-esque to create a delegate protocol

14:58 <workshop> like MasterViewControllerDelegate

14:58 <workshop> or something

14:59 <aaronpk> ah yea, hmm

14:59 <workshop> with an optional method, - (BOOL)viewControllerSupportsTwitter

14:59 <aaronpk> that's probably overkill in this case

14:59 <workshop> yeah, it often is :-)

14:59 <aaronpk> i'm doing a twitter connect thing within the app

14:59 <workshop> it always feels lengthy, but generally is a win for futureproofing

14:59 <aaronpk> if the user hasn't yet connected their twitter account, a new screen with a web view comes up which allows them to do the oauth from the web

15:00 <aaronpk> then when the web view finishes, I need to signal to the previous screen that they can now tweet

15:00 <workshop> yeah i would give teh web view a delegate then

15:00 <workshop> so the master would be like, here's a web view, webview.delegate = self

15:00 <workshop> then it implements the callback method

15:00 <workshop> when the webview finishes, it does

15:01 <workshop> if self.delegate && self.delegate respondsToSelector...

15:01 <workshop> [self.delegate blahselector]

15:01 <workshop> that's the cleanest way

15:01 <aaronpk> oh true, I could make the delegate of the webview the previous screen instead of the new window

15:01 <workshop> yeah

15:01 <workshop> whatever needs the notification and/or details

15:02 <workshop> then any piece of the app can use that webview class similarly

15:02 <workshop> and if it doesn't need the callback, don't set a delegate for it

15:02 <workshop> or dont' implement the callback method

15:02 <aaronpk> neat, ok this isn't too bad

15:04 <aaronpk> what object type should the delegate be? id?

15:05 <aaronpk> ah nvm I've done this before apparently

15:06 <workshop> usually do id <NSObject, MyObjectDelegate> delegate

15:06 <workshop> id is good in general for delegates

15:06 <workshop> and the NSObject says it conforms to that protocol

15:06 <workshop> which is good if you are going to use respondsToSelector in the delegate

15:06 <workshop> err the object checking the delegate

15:06 <workshop> because that's part of the NSObject protocol

15:07 <aaronpk> ah

15:07 <workshop> but if you don't use that, it's usually:

15:07 <workshop> id <MyObjectDelegate> delegate

15:07 <workshop> then do an @property (nonatomic, assign) id <MyObjectDelegate>delegate

15:07 <workshop> never retain your delegate

15:08 <workshop> just check for existance, then method, then call it

15:08 <workshop> also, just fyi, in 6-7 years of cocoa i've never actually used a pointer to a bool

15:09 <aaronpk> haha

15:09 <workshop> pointer to objects, yes

15:09 <workshop> especially NSError

15:09 <workshop> and in other circumstances

15:10 <workshop> not saying it's bad, just don't see it

15:11 <aaronpk> seemed very "C" to me

15:11 <aaronpk> YES! it worked!

15:11 <aaronpk> awesome, thanks

15:12 <workshop> np