Re: Learning the Interface Builder
Re: Learning the Interface Builder
- Subject: Re: Learning the Interface Builder
- From: Amanda Rains <email@hidden>
- Date: Fri, 04 Nov 2011 17:10:16 -0700
Thanks Conrad.
I'll be browsing the Cocoa Link you posted.
I've rummaged around in the online documentation and found that I can Option-Double-Click a language element to pull up a concise view of its documentation like its abstract, declaration, parameters, returns, sample code etc all with clickable links.
I've seen a reference to the debugger's "po" (print object) in Hillegass's book but have yet to utilize this. Will look into this.
Breaking and looking to see if objects are really nil ... didn't know I could do that or should that during debugging.
I have seen many mentions of Objective-C ability to send messages to nil.
FYI: I read all of your feedback and appreciate it. It does help clear the fog.
Amanda
On Nov 3, 2011, at 6:46 PM, Conrad Shultz wrote:
> On 11/2/11 7:40 PM, Amanda Rains wrote:
>> Understood... I'll probably keep using Xcode 3 for a little longer.
>
> Ditto to everything everyone else has already said about Xcode 3 vs. 4.
>
>> Becoming "well grounded" is my goal. I wasn't aware of the Cocoa-dev
>> list - I joined. Until just now I wasn't perceiving the difference
>> between Xcode and Cocoa. My purpose is to write programs that run on
>> the Mac and utilize Unix Clearly Xcode is a development environment
>> while Cocoa is a Framework.
>
> Exactly. However, since this was up to now a point of confusion, you
> would probably benefit from reading the Cocoa Fundamentals Guide
> (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html).
>
> Much of it you can breeze through since you have already presumably
> covered the basics of things like message sending in Hillegass, and you
> have prior experience with GUI programming. However, it covers in an
> intermediate level of detail some of the issues I suspect pose
> challenges for you during your transition from tutorial to
> experimentation. In particular, the "Communicating with Objects"
> section will help sharpen your focus on the relationship between IB and
> the underlying objects.
>
>> With regard to mechanics I understand how to open a connection panel
>> and can Ctrl-Drag between panels and elements such as a Window or an
>> AppController. There is possibly more mechanics to learn but at the
>> moment I don't know what they might be.
>
> OK, so you're not really in need of an Interface Builder tutorial per
> se. Ctrl-dragging covers most of what you will need to learn (with the
> new layout constraint additions in 10.7 making up much of the remainder,
> but you'll get to those later).
>
>> In the paragraph just above I am trying to point out that I am able
>> to learn from my mistakes by isolating them - then studying what is
>> wrong - making corrections to my code that lead to success - and thus
>> improving on my internal knowledge model of how to write effective
>> Object-C code. Sorry that wasn't made clear.
>>
>> Yes I am saying I do not know how to use the IB to produce an
>> effective Interface AND I don't know enough to even know how to
>> isolate my IB mistakes to learn from them.
>
> It sounds like you are off to a good start. Remember that you can work
> with IB-created objects just the same as those created in code. If you
> have a table view in IB referenced by an IBOutlet called tableView, you
> can, for example, in GDB or LLDB do things like:
>
> po tableView
> po [tableView delegate]
>
> Very useful for hunting down missing connections. A great many bugs
> early on will likely owe to sending messages to nil, perfectly valid in
> Objective-C. So if things aren't happening as expected, and you aren't
> getting any warnings or errors, breaking and making sure objects aren't
> nil will often quickly reveal oversights in IB.
>
> On a related note, something that I don't think is covered in
> Hillegass/3rd due to its age is the use of the Clang static analyzer.
> Running Build & Analyze in Xcode can help locate and stomp out a variety
> of common mistakes, particularly memory errors. Use it!
>
>> Thanks for the acknowledgement, I have experience developing UI's on
>> other platforms and have built MVC's
>
> I gathered as much, and to be clear when I referred to "beginner" in my
> previous message I meant with regard to this development environment,
> not programming in general. I came to the platform with experience
> primarily in server-side web development, so you'll probably have an
> overall easier transition than I did!
>
>> At the moment I find writing code easier than using the IB BUT I
>> think it prudent I learn the IB since it appears to be a very
>> powerful and fast tool. I have gone through some examples where the
>> connections were programmed in rather produced by the IB.
>
> Good. The key thing to remember is that IB is, in effect, writing code
> for you. When you Ctrl-drag from a table view to an app controller to
> set the table view's delegate method, that's the same as writing:
>
> [tableView setDelegate:appController];
>
> So when you are trying to debug things in IB, look to the class docs.
> Anything listed as a @property is likely exposed in IB (you could also
> verify this directly by looking in the class header). In AppKit (less
> so in UIKit), @property declarations may not be explicit, so you will
> have to infer that if there is a -delegate and -setDelegate: method
> listed, those are potential IB outlet candidates.
>
>> Well I think its a bit of both actually. AND I will post a zipped
>> project now that I know I can do this.
>
> Just remember that the list drops attachments, so you will need to post
> a URL.
>
>> Thanks for taking the time to consider what I wrote and writing back.
>
> Of course. I remember going through this learning curve and am happy to
> help others in any way I can.
>
>
> --
> Conrad Shultz
>
> Synthetiq Solutions
> www.synthetiqsolutions.com
>
Amanda Rains
email@hidden
This message was generated on my Mac.
_______________________________________________
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