Re: Learning the Interface Builder
Re: Learning the Interface Builder
- Subject: Re: Learning the Interface Builder
- From: Conrad Shultz <email@hidden>
- Date: Thu, 03 Nov 2011 18:46:13 -0700
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
_______________________________________________
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