iPad Programming Tutorial

  • Hi All,

    Does anyone know of a resource that helps understand how to NOT use interface builder for developing applications?

    I am trying to create a iPad SplitView application and I dont quite understand if I want to put code to create additional interface elements in: - (void)configureView or - (void)viewDidLoad

    Say I wanted to add a UITextView and display it.

    Wouldn't I do something like:

    CGRect bounds = [[UIScreen mainScreen] applicationFrame];

    UITextView *theTextView = [[UITextView alloc] initWithFrame:bounds];
    [theTextView setContentView:theTextView];
    [theTextView makeKeyAndOrderFront:nil];
    [theTextView makeFirstResponder:theTextView];

    [theTextView show];

    But I dont know if it displays, I was thinking that maybe this is something to do with that fact the project uses Interface Builder and I dont want to.

    -ML
  • I can't stress enough how much better it is to use IB.

    Having said that, a view created entirely programmatically is done in -loadView. You must implement that in your view controller subclass.

    If you do load a NIB but want to create additional views, do that in viewDidLoad.

    --
    Rick

    On Apr 25, 2010, at 19:01:49, ML wrote:

    > Hi All,
    >
    > Does anyone know of a resource that helps understand how to NOT use interface builder for developing applications?
    >
    > I am trying to create a iPad SplitView application and I dont quite understand if I want to put code to create additional interface elements in: - (void)configureView or - (void)viewDidLoad
    >
    > Say I wanted to add a UITextView and display it.
    >
    > Wouldn't I do something like:
    >
    > CGRect bounds = [[UIScreen mainScreen] applicationFrame];
    >
    > UITextView *theTextView = [[UITextView alloc] initWithFrame:bounds];
    > [theTextView setContentView:theTextView];
    > [theTextView makeKeyAndOrderFront:nil];
    > [theTextView makeFirstResponder:theTextView];
    >
    > [theTextView show];
    >
    > But I dont know if it displays, I was thinking that maybe this is something to do with that fact the project uses Interface Builder and I dont want to.
    >
    > -ML
  • I'm going to have to agree with Rick, IB is the way to go.
  • How about a good book that explains what IB does, how to set delegates, first responders, connect things up, etc

    I think that misunderstanding prevents me from using IB as much as I really should.

    ----- Original Message -----
    From: "Matt Moriarity" <matt.moriarity+<ml...>
    To: "Rick Mann" <rmann...>
    Cc: "ML" <mailinglists...>, "Cocoa-Dev List" <cocoa-dev...>
    Sent: Monday, April 26, 2010 7:44:34 AM
    Subject: Re: iPad Programming Tutorial

    I'm going to have to agree with Rick, IB is the way to go.
  • On Apr 26, 2010, at 8:15 AM, ML wrote:

    >
    > How about a good book that explains what IB does, how to set delegates, first responders, connect things up, etc
    >
    > I think that misunderstanding prevents me from using IB as much as I really should.
    >
    > ----- Original Message -----
    > From: "Matt Moriarity" <matt.moriarity+<ml...>
    > To: "Rick Mann" <rmann...>
    > Cc: "ML" <mailinglists...>, "Cocoa-Dev List" <cocoa-dev...>
    > Sent: Monday, April 26, 2010 7:44:34 AM
    > Subject: Re: iPad Programming Tutorial
    >
    > I'm going to have to agree with Rick, IB is the way to go.

    I have avoided IB because I find its operation peculiar and its terminology abstract. When I create objects in code I have a much firmer idea of where they are, when they come into existence and what I can do with them. IB is yet another language to master. and you still have to write a fair amount of custom code.
  • On 26 Apr 2010, at 17:49, David Rowland wrote:

    > On Apr 26, 2010, at 8:15 AM, ML wrote:
    >
    >>
    >> How about a good book that explains what IB does, how to set
    >> delegates, first responders, connect things up, etc
    >>
    >> I think that misunderstanding prevents me from using IB as much as
    >> I really should.
    ...
    >> I'm going to have to agree with Rick, IB is the way to go.
    >
    > I have avoided IB because I find its operation peculiar and its
    > terminology abstract. When I create objects in code I have a much
    > firmer idea of where they are, when they come into existence and
    > what I can do with them. IB is yet another language to master. and
    > you still have to write a fair amount of custom code.

    One more reason to follow the advice above. And: Apple's documentation
    clearly states the how, where, when, what, etc. of objects created via
    Interface Builder. Read the fine manual! May be, you will recognize
    that IB is not a language but a tool -- it's easier to get a grip --,
    and that you do not have to write a fair amount of custom code. In
    your current situation you just don't know, you only assume.

    Klaus
  • On Apr 26, 2010, at 8:15 AM, ML wrote:

    >
    > How about a good book that explains what IB does, how to set delegates, first responders, connect things up, etc

    Here is an example of making a (simple) iPhone project all in code:

            http://www.trilithon.com/download/CodeOnly.zip

    There is a Cocoa Resource Programming Gude that covers Interface Builder issues.

    Setting delegates is done i the same way as making connections between any other pair of
    objects.  You control-drag a connection from the object that should have the reference (pointer)
    to the object being referenced ( pointed at).

    In general, you hardly ever need to play with the responder chain.

    Connecting things together is as I described above in the context of delegates.

    > I think that misunderstanding prevents me from using IB as much as I really should.

    An Interface Builder document (xib/nib) is simply a box full of serialised (freeze-dried, pickled, embalmed, archived, choose your metaphor)
    objects, with connections between them in such a way that they (should, at least) form a complete object graph.

    Objects in the XIB and on the design surface during design and construction time are live objects,
    exactly the same as if you had created them programatically.    When you change attributes using
    Interface Builder's Attributes Inspector, Interface Builder is sending messages to those objects, just
    as if you had programatically sent those messages from code.  So in the end, there is nothing really magic
    about Interface Builder.

    At application run time, when the time comes to load the NIB using the Bundle Loader, the
    important tasks that the loading process performs are (1) unarchiving the archived objects into memory
    to form an object graph, and (2) using the information provided in File's Owner plus the already instantiated
    'owner' object in the existing application's object graph to join the two object graphs together.

    There are various (opinionated) factions on the subject of whether or not to use Interface Builder.
    The choice is entirely yours.

    That said, if and when the time cones to locali[sz]e your application, you will suddenly discover that
    Interface Builder can and will save you tons of otherwise laborious drudge work.

    I live to a certain degree in both camps.    Doing a iPhone Tab Bar application via Interface Builder
    I find to be laborious, error-prone, and klunky.    But instead of writing loads of code, I write an XML
    description of the starting architecture in a plist, and dynamically instantiate everything at launch time
    in a fairly compact loop.

    In applications where I need a lot of fiddly and finicky layout, I use Interface Builder for what it's good at.

        Cheers,
            . . . . . . . .    Henry
  • On Apr 26, 2010, at 8:49 AM, David Rowland wrote:

    >
    > On Apr 26, 2010, at 8:15 AM, ML wrote:
    >
    >>
    >> How about a good book that explains what IB does, how to set delegates, first responders, connect things up, etc
    >>
    >> I think that misunderstanding prevents me from using IB as much as I really should.
    >>
    >> ----- Original Message -----
    >> From: "Matt Moriarity" <matt.moriarity+<ml...>
    >> To: "Rick Mann" <rmann...>
    >> Cc: "ML" <mailinglists...>, "Cocoa-Dev List" <cocoa-dev...>
    >> Sent: Monday, April 26, 2010 7:44:34 AM
    >> Subject: Re: iPad Programming Tutorial
    >>
    >> I'm going to have to agree with Rick, IB is the way to go.
    >
    > I have avoided IB because I find its operation peculiar and its terminology abstract. When I create objects in code I have a much firmer idea of where they are, when they come into existence and what I can do with them. IB is yet another language to master. and you still have to write a fair amount of custom code.

    See my previous post on the subject.

    I have found that in general, the one aspect of Interface Builder that baffles people the most is that it does not 'Write Code'.
    People accustomed to IDEs such as Cafe or JBuilder et al keep insisting on 'seeing the code'.    To me, I  could care less.
    When I'm trying to build the flight deck  of a starship, I don't have the time to investigate and peruse the detailed metallurgical characteristics
    of the fasteners . . .

    After that, File's Owner provides its own trouble, I suspect simply because the name is/was an unfortunate choice.
    Maybe Nib's Owner might have been better.  But File's Owner is easier to come to grips with when you realise that
    it's simply a connector of sorts to join two object graphs together.

        Cheers,
            . . . . . . . .    Henry
  • On Apr 25, 2010, at 7:01 PM, ML wrote:

    > Does anyone know of a resource that helps understand how to NOT use interface builder for developing applications?

    Some variant of this question pops up here every now and then. Quoting from a post of my own:

    "Interface Builder is a fundamental part of Cocoa development, not simply a shortcut for newbies or a way to get started quickly. Anyone who thinks developing without Interface Builder is a purer path to Cocoa development has already missed the point."

    _murat
previous month april 2010 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today