Cocoa mail archive
Re: Bypassing Interface Builder
FROM : Julius Guzy
DATE : Thu May 15 04:36:42 2008
On 15 May 2008, at 0:29, Graham Cox <graham.<email_removed>> wrote
>
>> I have no idea how the rest of you gained your expertise but working
>> on my own, even with the help of books and the internet it has been
>> an absolute nightmare.
>
> I imagine it can be hard without a structured approach to learning it
> - there's a lot there and without a guide it's impossible to know
> where to "jump in". I doubt that IB or Xcode is intuitive enough to
> guess.
I'm not sure it is the structured approach as such but rather the
existence of someone one can bounce one's ideas off and ask question
of that is needed.
IB is interesting as an Interface design problem.
One might think that because the interfaces are visual a "visual
programming" tool would be ideal.
It is ideal when it comes to lay out.
So what about the linking of outlets and actions?
A picture is worth a thousand words and frequently when having to
document code relating to operations involving geometry a diagram is
indispensable. However, maybe it is only useful as an object to
reference and not as a thing to be manipulated.
It seems reasonable to suppose that the inventors of IB had the
notion of an information flow and the idea that this could be modeled
using some kind of plumbing metaphor. And the parallels with
diagramatic notations like UML possibly are also in there.
It is possible however that programming is primarily a linguistic
symbol manipulation activity whereas drawing or manipulating bits of
plumbing is not,. This might then explain why the attempt to force a
visual, quasi "fix the u-bend" way of thinking onto a programming
task gives rise to difficulties. For me these disappeared as soon as
I realised that all I needed to do was to define the actual
interface parameters in the .h file! That said there is still a mass
of stuff there I have not even looked at.
>
> I recommend Aaron Hillegasse's book "Cocoa Programming for Mac OS
> X" (http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/
> 0321503619/ref=pd_lpo_k2_dp_k2a_3_txt?pf_rd_p=304485601&pf_rd_s=lpo-
> top-
> stripe-2&pf_rd_t=201&pf_rd_i=0201726831&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=
> 1BBG60H7AHDA15M6M1VJ
> )
>
> Personally I found using this book I could start writing useful code
> with Cocoa and IB after about a week (simple stuff, at that stage).
> That said, I did also attend a course at Apple Munich on Cocoa way
> back in 1997 not long after the NeXT merger, which involved running a
> very early version of the Yellow Box on Intel PCs - all a bit weird,
> but again, it was a structured introduction which was a good mix of
> actually using the tools like IB and lectures giving a glimpse of the
> potential. It was another 5 years before I looked at any of that
> again, so I'd forgotten the details but remembered some of the core
> concepts. Hillegass took me the rest of the way.
Simple code yes. But that's the thing. The way the book teaches makes
generalisation very difficult. It is possible that the diagrams
interrupt the flow of the description, the flow of one's thinking, so
it becomes difficult to see it all together in one's head.
Additionally and strangely the diagrams make it difficult to remember
precisley where in the book a particular piece of information is to
be found. The book is a brave attempt and lots of people seem to
swear by it but for me it just had me ripping my hair out.
>
> It might be worthwhile attending a course if you can find one - do
> Apple still run them? That can often cut through months of frustration
> trying to struggle on ones own.
Aye, if you have the dosh that's fine but I think the cost of courses
is likely to make one's eyes water.
>
>
>> and books like Cocoa Programming for Mac OSX and Vermont recipes
>> were very hard going. Perhaps it was their verbosity, or the
>> learning by rote
>
> I've already talked up this book, so I'm surprised you feel this way
> about it. It's not verbose, it's concise and clearly written.
The Hillglass does not have that many words but many of those there
are in my view superfluous - the text is to friendly by half.
O'Reilly in a nutshell would be my prefered format.
The vermont recipies ..... 700 + words, detours, explanaitions
everywhere - I'm a programmer, I have a grasp of the nature of
programming, of what programs look like. The fact that it takes 700
pages to describe something which to my mind ought to be
straightforward is a big indicator of things not being quite right.
For instance , The O'Reilly Java in Nutshell books, they're pretty
thick dense tomes and it took me three months to get a handle on the
api but I wan't screaming in frustration all the time.
Is it possible that the MVC model which emerged from that thick
german book (Design Patterns: Elements of Reusable Object-Oriented
Software - Gamma et al) and the whole notion of ready made templates
so to speak had not quite synthesised within people's minds
sufficiently to allow easy expression?
> You can
> choose to learn by rote or you can take the underlying concepts, ideas
> and principles and use those to explore other things more appropriate
> to the tasks you want to accomplish. This sort of exploration may not
> work for everybody, but it did for me. It's a little like doing
> science - the book gives you some theory, a selection of scattered
> facts, but you extrapolate from that to your own situation, test your
> understanding by testing new "what if" cases and thus gradually expand
> the theory and your own understanding. I personally feel that this is
> the point of these books - they are not intended to give you a
> tutorial for all of Cocoa, they show you a few pertinent examples and
> expect you to use some induction to extend that to other parts they
> don't specifically cover. I would imagine that reading Hillegasse from
> cover to cover and typing in every example would be extremely dull
> indeed, and I doubt you'd really absorb all that much. Instead, have a
> goal of your own and use the book as a reference to explore certain
> concepts then use your own project to try and apply them. Sure you'll
> make lots of mistakes, and from time to time there will be
> frustration, but those moments when you extrapolate from principle A
> and B to guess that C and D will happen - AND IT DOES! - will make it
> all worthwhile ;-)
I like theory too but clearly these two tomes work for some and not
for others.
By contrast the Kochan Programming in Objective-C, that's clear and
nice and easy to grasp, at least for me.
That book saved my life. Also the Scott Anguish et al Cocoa
Programming, and the Programming with Quartz book that's pretty good
stuff too. So there might be stylistic things at work here.
The question is interesting.
Julius
http://juliuspaintings.co.uk
DATE : Thu May 15 04:36:42 2008
On 15 May 2008, at 0:29, Graham Cox <graham.<email_removed>> wrote
>
>> I have no idea how the rest of you gained your expertise but working
>> on my own, even with the help of books and the internet it has been
>> an absolute nightmare.
>
> I imagine it can be hard without a structured approach to learning it
> - there's a lot there and without a guide it's impossible to know
> where to "jump in". I doubt that IB or Xcode is intuitive enough to
> guess.
I'm not sure it is the structured approach as such but rather the
existence of someone one can bounce one's ideas off and ask question
of that is needed.
IB is interesting as an Interface design problem.
One might think that because the interfaces are visual a "visual
programming" tool would be ideal.
It is ideal when it comes to lay out.
So what about the linking of outlets and actions?
A picture is worth a thousand words and frequently when having to
document code relating to operations involving geometry a diagram is
indispensable. However, maybe it is only useful as an object to
reference and not as a thing to be manipulated.
It seems reasonable to suppose that the inventors of IB had the
notion of an information flow and the idea that this could be modeled
using some kind of plumbing metaphor. And the parallels with
diagramatic notations like UML possibly are also in there.
It is possible however that programming is primarily a linguistic
symbol manipulation activity whereas drawing or manipulating bits of
plumbing is not,. This might then explain why the attempt to force a
visual, quasi "fix the u-bend" way of thinking onto a programming
task gives rise to difficulties. For me these disappeared as soon as
I realised that all I needed to do was to define the actual
interface parameters in the .h file! That said there is still a mass
of stuff there I have not even looked at.
>
> I recommend Aaron Hillegasse's book "Cocoa Programming for Mac OS
> X" (http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/
> 0321503619/ref=pd_lpo_k2_dp_k2a_3_txt?pf_rd_p=304485601&pf_rd_s=lpo-
> top-
> stripe-2&pf_rd_t=201&pf_rd_i=0201726831&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=
> 1BBG60H7AHDA15M6M1VJ
> )
>
> Personally I found using this book I could start writing useful code
> with Cocoa and IB after about a week (simple stuff, at that stage).
> That said, I did also attend a course at Apple Munich on Cocoa way
> back in 1997 not long after the NeXT merger, which involved running a
> very early version of the Yellow Box on Intel PCs - all a bit weird,
> but again, it was a structured introduction which was a good mix of
> actually using the tools like IB and lectures giving a glimpse of the
> potential. It was another 5 years before I looked at any of that
> again, so I'd forgotten the details but remembered some of the core
> concepts. Hillegass took me the rest of the way.
Simple code yes. But that's the thing. The way the book teaches makes
generalisation very difficult. It is possible that the diagrams
interrupt the flow of the description, the flow of one's thinking, so
it becomes difficult to see it all together in one's head.
Additionally and strangely the diagrams make it difficult to remember
precisley where in the book a particular piece of information is to
be found. The book is a brave attempt and lots of people seem to
swear by it but for me it just had me ripping my hair out.
>
> It might be worthwhile attending a course if you can find one - do
> Apple still run them? That can often cut through months of frustration
> trying to struggle on ones own.
Aye, if you have the dosh that's fine but I think the cost of courses
is likely to make one's eyes water.
>
>
>> and books like Cocoa Programming for Mac OSX and Vermont recipes
>> were very hard going. Perhaps it was their verbosity, or the
>> learning by rote
>
> I've already talked up this book, so I'm surprised you feel this way
> about it. It's not verbose, it's concise and clearly written.
The Hillglass does not have that many words but many of those there
are in my view superfluous - the text is to friendly by half.
O'Reilly in a nutshell would be my prefered format.
The vermont recipies ..... 700 + words, detours, explanaitions
everywhere - I'm a programmer, I have a grasp of the nature of
programming, of what programs look like. The fact that it takes 700
pages to describe something which to my mind ought to be
straightforward is a big indicator of things not being quite right.
For instance , The O'Reilly Java in Nutshell books, they're pretty
thick dense tomes and it took me three months to get a handle on the
api but I wan't screaming in frustration all the time.
Is it possible that the MVC model which emerged from that thick
german book (Design Patterns: Elements of Reusable Object-Oriented
Software - Gamma et al) and the whole notion of ready made templates
so to speak had not quite synthesised within people's minds
sufficiently to allow easy expression?
> You can
> choose to learn by rote or you can take the underlying concepts, ideas
> and principles and use those to explore other things more appropriate
> to the tasks you want to accomplish. This sort of exploration may not
> work for everybody, but it did for me. It's a little like doing
> science - the book gives you some theory, a selection of scattered
> facts, but you extrapolate from that to your own situation, test your
> understanding by testing new "what if" cases and thus gradually expand
> the theory and your own understanding. I personally feel that this is
> the point of these books - they are not intended to give you a
> tutorial for all of Cocoa, they show you a few pertinent examples and
> expect you to use some induction to extend that to other parts they
> don't specifically cover. I would imagine that reading Hillegasse from
> cover to cover and typing in every example would be extremely dull
> indeed, and I doubt you'd really absorb all that much. Instead, have a
> goal of your own and use the book as a reference to explore certain
> concepts then use your own project to try and apply them. Sure you'll
> make lots of mistakes, and from time to time there will be
> frustration, but those moments when you extrapolate from principle A
> and B to guess that C and D will happen - AND IT DOES! - will make it
> all worthwhile ;-)
I like theory too but clearly these two tomes work for some and not
for others.
By contrast the Kochan Programming in Objective-C, that's clear and
nice and easy to grasp, at least for me.
That book saved my life. Also the Scott Anguish et al Cocoa
Programming, and the Programming with Quartz book that's pretty good
stuff too. So there might be stylistic things at work here.
The question is interesting.
Julius
http://juliuspaintings.co.uk
