Multiple XIB how-to

[myersn024]

Yeah, I don't use interface builder much any more unless I have to. It's so much easier to do things in code.

[Abel]

Its faster too since the NIB files need not be parsed and inflated into objects.

Originally Posted by myersn024

Yeah, I don't use interface builder much any more unless I have to. It's so much easier to do things in code.

[myersn024]

Yeah, the drawRect function can be a PITA sometimes. However, I still use IB to prototype my interfaces. Then I'll just get each object's frame info from the Inspector window and use that for all my drawing.

[Abel]

I still use IB as it makes it easier for developers to find what they are looking for but ye there are so advantages to doing it in code. I wouldn't discourage the use of Interface Builder unless your app has certain exceptional needs.

Originally Posted by myersn024

Yeah, the drawRect function can be a PITA sometimes. However, I still use IB to prototype my interfaces. Then I'll just get each object's frame info from the Inspector window and use that for all my drawing.

[backwardselvis]

I am really enjoying this thread, keep up the great tutorials and conversation.

[Abel]

You know someone is doing something right when you can start a 3 page debate as to where da heck to stick the code into. Haha.

Originally Posted by backwardselvis

I am really enjoying this thread, keep up the great tutorials and conversation.

[finalcut]

hi there,
nice tutorial and nice conversations too
So i'm actually new to the iphone sdk and i'm still at the stage of watching vids trying to get the grip of the whole procedure..So i wanted to ask i couple of things that i believe are in context with the thread.
In the case where the app has a lot of views if i get it correctly the pattern is that you have your view class ,the view controller class and the app delegate lies behind of all.It seems to me that the delegate has the role of the main controller ,switching and handling different views. So in the particular example couldn't the delegate just set the text color of the label at the view so that the view wouldn't have to access the delegate..it wouldnt need to be aware of its existence..it would just draw with whatever color value it's variable has..Also instead of the view explicitly calling the delegate method for flipping is there a way to notify the delegate of the event and then the delegate according to it's logic would decide what it should be done?I'm trying to make the analogy from web programming where the view(browser)would call a php file for example(controller) , the controller would then access whatever data it needs and display another view after setting the data this view needs..So i guess my main question is what's the clean way to hand over control to the delegate instead of getting it's singleton instance and explicitly calling a method..

[myersn024]

The delegate isn't really a "controller". The app delegate is just a class that responds to certain messages sent from the application to the notification center. IMO, it also provides a place to store data that multiple classes may need access to. That being said, you could have the app delegate set the initial color of the text field when it sets up the initial view, but after that you'd want any changes to be made by the view controller.

As for sending notifications to the app delegate to tell it to do something, that's totally possible, yet more trouble than it's worth to use actual notifications through the notification center. The more practical option is to have all your view's actions be sent to it's view controller. Then the view controller would call the method on the app delegate.

I really do need to re-do this tutorial, or at least just the source code so that it does things the proper way. At the time, I was trying to make it easy to understand, and it seems that I've done just the opposite.

[finalcut]

thnks for the reply i think things start to be more clear .So the the clean way would again be to make the view controller communicate with the delagate and have in the delagegate the core logic of view transitions right ?Can you please elaborate a bit more on the notifications center so to notify the delecate?i'm not aware of it

[Abel]

Well your tutorial addressed the point you intended which is (to my understanding) to teach programming. Teaching programming and teaching programming paradigms are two very different things. In fact, most people won't notice the proper order of things or why it is useful to follow paradigms until they start on a big project and they repeat the word "F*ck!" more than 5 times. It is only then that people will begin to look at their thought process and look into ways to solve the problem and avoiding it from reoccurring. You can make a tutorial that follows the proper programming paradigm but new programmers won't notice the difference they just see it as code. The reason Im emphasizing on writing tutorials that follow programming paradigms is that when these people do come into this problems they will look at code in tutorials to see what the "proper" way of organizing things is, it is then that they will be mislead and the tutorial that once helped them will become their enemy. Awesome thread and tutorial overall;

Originally Posted by myersn024

The delegate isn't really a "controller". The app delegate is just a class that responds to certain messages sent from the application to the notification center. IMO, it also provides a place to store data that multiple classes may need access to. That being said, you could have the app delegate set the initial color of the text field when it sets up the initial view, but after that you'd want any changes to be made by the view controller.

As for sending notifications to the app delegate to tell it to do something, that's totally possible, yet more trouble than it's worth to use actual notifications through the notification center. The more practical option is to have all your view's actions be sent to it's view controller. Then the view controller would call the method on the app delegate.

I really do need to re-do this tutorial, or at least just the source code so that it does things the proper way. At the time, I was trying to make it easy to understand, and it seems that I've done just the opposite.

[myersn024]

This discussion has inspired me to go ahead and rewrite the source code for this tutorial this afternoon. I'm not going to re-do the video since that'll take quite a while, and most of the people that are asking about best-practices understand enough of what's going on to notice the differences. As much as I hate commenting code, I'll do it just for you guys.

I'll post the new source when I get home and get it finished, but I'm going to leave the original there to go along with the tutorial, as well.

@finalcut: The notification center is a way that different classes can pass notifications, along with smallish amounts of data, around without having to directly connect another class. Believe it or not, you're already using parts of it and you didn't even know it. The best way I can describe it is like this. In your app delegate implementation file there's a method called applicationDidFinishLaunching: (UIApplication *)application that runs once the applications finishes launching. However, this method isn't called automatically. When an app delegate is initialized, it registers itself with the notification center (see class reference for NSNotificationCenter) and asks the notification center to call it's applicationDidFinishLaunching when it receives a message from the UIApplication instance saying that it finished launching. So, once you launch your application, it'll do whatever it needs to do to launch. Once it's done, it sends a notification to the notification center saying, "Hey, I finished launching." The notification center then goes, "Oh, I was supposed to let the app delegate know when I got this message." It then looks to see which method to call on the app delegate, and calls it.

The same thing happens with all the app delegate protocol methods.

[backwardselvis]

Originally Posted by Abel

...until they start on a big project and they repeat the word "F*ck!" more than 5 times.

I can still remember quite clearly when this occurred. One of programming's hardest but most needed lessons.

[Abel]

Haha,
well props on donating your time and effort to programming education. While I do agree the people asking about best practices do know what they are asking about, I believe that MOST new programmers (just starting to program) (correct me if Im just assuming this, it was the way it happened with me when I started programming 6 years ago) will not really care about best practices yet nor understand why we should use them.

Originally Posted by myersn024

This discussion has inspired me to go ahead and rewrite the source code for this tutorial this afternoon. I'm not going to re-do the video since that'll take quite a while, and most of the people that are asking about best-practices understand enough of what's going on to notice the differences. As much as I hate commenting code, I'll do it just for you guys.

I'll post the new source when I get home and get it finished, but I'm going to leave the original there to go along with the tutorial, as well.

[Abel]

Worst of all is something you can't learn from books. Its like that thing in every career/job that you learn the hard way when the cold concrete slams against your face.

Originally Posted by backwardselvis

I can still remember quite clearly when this occurred. One of programming's hardest but most needed lessons.

[myersn024]

Originally Posted by Abel

Haha,
well props on donating your time and effort to programming education. While I do agree the people asking about best practices do know what they are asking about, I believe that MOST new programmers (just starting to program) (correct me if Im just assuming this, it was the way it happened with me when I started programming 6 years ago) will not really care about best practices yet nor understand why we should use them.

Exactly. The bad thing is that it's taken me 15 years of bit-bashing to come to the realization that standards were thought up for a reason. Back when I first started writing code, I thought, "Why should I do that when it works this way?" Now I understand

[myersn024]

Here's the updated code as promised, complete with comments and everything.

A quick rundown: the program functions much the same way as before. There are two XIB files, each associated with their own view controller subclass. There are not any UIView subclasses; all the view layout is handled with Interface Builder and the views are connected to the view outlets of their respective view controllers. Updating the color choice still means hitting the say hi button to get the color to update for red and green. Pressing the blue button will update immediately since it uses the notification center to get the message to update.......that's right folks, just for fun, and for those that are interested, I threw in some NSNotificationCenter stuff. I think most will find this code a bit more MVC compliant.

Two XIBs MVC-compliant code

[Abel]

You nailed it. You have the MVC model implemented as should be. The rest of the code can be written in many different ways and it would still be correct but either way now everything is expandable Good job.

Originally Posted by myersn024

Here's the updated code as promised, complete with comments and everything.

A quick rundown: the program functions much the same way as before. There are two XIB files, each associated with their own view controller subclass. There are not any UIView subclasses; all the view layout is handled with Interface Builder and the views are connected to the view outlets of their respective view controllers. Updating the color choice still means hitting the say hi button to get the color to update for red and green. Pressing the blue button will update immediately since it uses the notification center to get the message to update.......that's right folks, just for fun, and for those that are interested, I threw in some NSNotificationCenter stuff. I think most will find this code a bit more MVC compliant.

Two XIBs MVC-compliant code

[backwardselvis]

Good job Billy!

[dalef84]

Well, I'm not going to upload it again, but you still have a problem with metrics in those nibs.

After reading this thread's comments, I started using nibs only for layout. It's more work, but at least doesn't give me any headaches

Thanks for keeping the thread up!

PS: Hehe, you forgot to delete the build folder

[myersn024]

Originally Posted by dalef84

Well, I'm not going to upload it again, but you still have a problem with metrics in those nibs.

I'm not sure I know what you mean. You mind elaborating?

[dalef84]

Originally Posted by myersn024

I'm not sure I know what you mean. You mind elaborating?

I modified and uploaded your code a few replies before (look in page 3). The status bar covers anything the first 20 pixels of your views.

(This is because, as you don't have a UIViewController in your xibs, you can't handle the metrics each ViewController has.)

[Abel]

Haha. Stop giving the man a hard time. The code do what it was programmed to do (in this case to not give a crap about metrics). It is no longer misinforming anyone, if you feel like making it better then recode and re-upload variations. =]

Originally Posted by dalef84

I modified and uploaded your code a few replies before (look in page 3). The status bar covers anything the first 20 pixels of your views.

(This is because, as you don't have a UIViewController in your xibs, you can't handle the metrics each ViewController has.)

[Goran]

good tutorial

[jamesbrannan]

I'm not done yet, couldn't you do something simple like this in the firstviewcontroller? (Sorry, my own names not the tutorial's)

- (void) viewDidAppear:(BOOL) animated
{
	NSLog(@"First view appeared.");
	TourDeControlsAppDelegate *md = (TourDeControlsAppDelegate *)
                                    ([[UIApplication sharedApplication] delegate]);
	NSLog(@"changeTheString called. %@", md.theString);
}

So, in the Second nib, you call a method in secondviewcontroller that changes a property in the delegate, then, the next time the first view becomes visible, you initialize its value with the value in the delegate like the above code. I know that it works with NSLog at least, I'm now going to try setting labels etc. after I put the brats to sleep...maybe a tutorial is in order, as my precondition is that I must use IB as the starting point for all my endeavors...

[jamesbrannan]

Works fine....

Starting with the Tab Bar Application Template...

First View in MainXib uses FirstViewController
Add a label in mainxib and set an outlet in firstviewcontroller.
Change Second xib's view to use it's own SecondviewController
Ensure the #@$@% TabBar, tabs in mainxib point to correct controllers
Have secondcontroller have an action that sets a value in delegate.
Create a button on secondview that when clicked calls that action. Be sure the action changes the value in the delegate.
When firstviewcontroller loads the view, have it change the outlet's value to the value in the delegate.

This is pretty standard MVC isn't it? It's so easy, and is a solution that is easily accomplished with the IB's tab bar project template, that I definitly think it's worth a tutorial.

I downloaded a screen movie capture program, so I'll work on it this week.

James