Advertise Books Events Forum News Social Networking Support Us

sdkIQ for iPhone
($4.99)

Shape Up
($0.99)

Your First iPhone App
($1.99)

iVidCam Free
(free)

Kid Art
($0.99)

iPUBQUIZ
(£1.19)

ArtStudio
($3.99)

Want your application or service advertised on iPhone Dev SDK?

Go Back   iPhone Dev SDK Forum > iPhone SDK Development Forums > iPhone SDK Tutorials

Reply
 
LinkBack Thread Tools Display Modes
Old 08-02-2008, 10:07 AM   #1 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default Multiple XIB how-to

I created this screen-cast yesterday to help out those who have been wondering how to use multiple XIB files in their projects. The link is below, and don't hesitate to let me know what you think. The video was recorded in 720p and was converted into MP4. You should be able to view it full screen without too much distortion.

Chris asked me to come back and embed the videos in these pages. But I didn't realize until I did it that the embedded versions weren't HiDef. However, you can click the link below the video to be taken to vimeo.com and you can view it in HiDef from there, or you can click the download link and download a HiDef version to your computer. All the videos except for this one are 75-ish meg in size.


iPhone Tutorial - Multiple XIB files from Nick Myers on Vimeo.
Download HiDef Version to your computer

Last edited by myersn024; 09-04-2008 at 09:51 AM.
myersn024 is offline   Reply With Quote
Old 08-05-2008, 05:50 PM   #2 (permalink)
New Member
 
Join Date: Aug 2008
Posts: 6
Default

I think the implementation you showed in the video may not be the best example of good MVC (Model-View-Controller) design pattern practice. I am no pro either, but I dont think you should be accessing the application delegate from a UIView subclass, this sort of thing should probably handled by a controller object, such as your UIViewController subclasses. then they need to be hooked up in IB accordingly.

Thanks for the tutorial, I did learn a lot and I appreciate it.
aoberoi is offline   Reply With Quote
Old 08-05-2008, 10:17 PM   #3 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

I see your point, but I don't see how you can get around having a lot of extra fluff in your programs if you make your UIViews access their view controllers to access data that the view controllers get from the delegate. The "proper" implementation also makes for more work. I'm a big believer in the idea that the easier you make something, the better.

Then again, I always got counted off on my programming assignments when I was in college because I wouldn't do things the way they were "supposed" to be done. I had several assignments where I lost points for not following the assignment, only to have them added back on for thinking outside the box....not that this is the same type of situation, but the code works and is rather minimal. In the end, do it however you're comfortable.

Thanks for the compliments and constructive criticism.
myersn024 is offline   Reply With Quote
Old 08-06-2008, 01:59 AM   #4 (permalink)
Hello
 
Join Date: May 2008
Posts: 48
Default

I really liked how you used the delegate in this tutorial, thanks for this. Like others I would have probably used the view controller for most of the stuff, but I think whenever I have the opportunity I will use the delegate now.
Ilyace is offline   Reply With Quote
Old 08-06-2008, 03:55 PM   #5 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

@aoberoi: Not to be a stick in the mud over your comments, but I went back and looked over Apple's example code for table views and their samples store the content array in the delegate and access them the same way that I do it in the tutorial. In the end, it all comes down to being able to access your content from anywhere in your program. If you store it in a view controller instead of the delegate, then you're still going to have to access across classes regardless of your implementation. Therefore, the delegate makes the most sense.
myersn024 is offline   Reply With Quote
Old 08-07-2008, 01:56 AM   #6 (permalink)
New Member
 
Join Date: Aug 2008
Posts: 6
Default

Oh I agree completely that the application delegate is implemented correctly.

My difference of opinion (and thats all it is) is where the methods such as sayHi and tellDelegateToFlipView should be implemented. I think there should be outlets for these methods in View Controller classes. These classes typically implement the functionality of items placed in the Views. To communicate with data used by the whole application, yes it makes sense to go to the app delegate.

In this small example, an easy to understand method does have its obvious advantage. I am only commenting that in order to use the principles of the design pattern, technically the functionality of those buttons should be moved to a view controller. Otherwise, one might ask, why did I have to make a class file for the view controllers? I never used them right? Also, if it was implemented the way I suggested, there would be no need to make source files for either of the Views, and less source files to me means easier to understand.

Last edited by aoberoi; 10-14-2008 at 10:01 PM.
aoberoi is offline   Reply With Quote
Old 08-07-2008, 04:48 AM   #7 (permalink)
New Member
 
Join Date: Jul 2008
Posts: 60
Talking

I've just seen the video and I think it is great! I really like the way you coment your code and how you thought on doing the presentation in general. I'm just a beginer, but I feel I understand most of what you said.

Having said that, one thing I still don't quite understand is the MVC design pattern, and reading on your comments here, I feel quite lost. At the moment I'm just doing things so I get the apps working, but I keep feeling I'm not doing things correctly. The problem with this is when I come back in a few months, maybe it will be hard to read my code (not that I'm really going to do that, I hope I know much more than now). The point is that I think the understanding of the MVC is important for readability and reuse, specially if working with other people.

All of this is to say that if one day you feel bored, could you make a video on MVC ? Well, either that or could you point me were to read to better understand it all?

Thanks and keep up the good work!
jazzmic is offline   Reply With Quote
Old 08-07-2008, 07:49 AM   #8 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

Quote:
Originally Posted by aoberoi View Post
Oh I agree completely that the application delegate is implemented correctly.

My difference of opinion (and thats all it is) is where the methods such as sayHi and tellDelegateToFlipView should be implemented. I think there should be outlets for these methods in View Controller classes. These classes are typically implement the functionality of items placed in the Views. To communicate with data used by the whole application, yes it makes sense to go to the app delegate.

In this small example, an easy to understand method does have its obvious advantage. I am only commenting that in order to use the principles of the design pattern, technically the functionality of those buttons should be moved to a view controller. Otherwise, one might ask, why did I have to make a class file for the view controllers? I never used them right? Also, if it was implemented the way I suggested, there would be no need to make source files for either of the Views, and less source files to me means easier to understand.
Touché, sir....touché.
myersn024 is offline   Reply With Quote
Old 08-11-2008, 10:06 AM   #9 (permalink)
ZipZest.com
 
Join Date: Aug 2008
Posts: 43
Default

Thanks for the tutorial - its excellent!
mikeb is offline   Reply With Quote
Old 08-19-2008, 01:24 AM   #10 (permalink)
New Member
 
Join Date: Aug 2008
Posts: 1
Smile Multiple XIM how-to

Very Informative Video . Good for Beginners.

Nice work.

--Vinay Mehta
vinay.mehta is offline   Reply With Quote
Old 08-19-2008, 10:16 AM   #11 (permalink)
Registered Member
 
Join Date: Jul 2008
Posts: 177
Default

I have to agree with aoberoi .. the delegate was used correctly just that when you link a view to data you are making it less reusable. Apple states controllers should be the non reusable part of your program so you should separate a view from a views data, doing so will in turn (hopefully) make your view classes and model classes reusable.

Quote:
Originally Posted by aoberoi View Post
Oh I agree completely that the application delegate is implemented correctly.

My difference of opinion (and thats all it is) is where the methods such as sayHi and tellDelegateToFlipView should be implemented. I think there should be outlets for these methods in View Controller classes. These classes are typically implement the functionality of items placed in the Views. To communicate with data used by the whole application, yes it makes sense to go to the app delegate.

In this small example, an easy to understand method does have its obvious advantage. I am only commenting that in order to use the principles of the design pattern, technically the functionality of those buttons should be moved to a view controller. Otherwise, one might ask, why did I have to make a class file for the view controllers? I never used them right? Also, if it was implemented the way I suggested, there would be no need to make source files for either of the Views, and less source files to me means easier to understand.
Abel is offline   Reply With Quote
Old 08-19-2008, 02:24 PM   #12 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

Message disclaimer: I don't pretend to know it all, and my advice probably isn't the best. Coding is one of my hobbies, and I've been doing it for around 15 years. I try to make my code easy for me to understand since I'm the one that maintains it and uses the final product. If you like your way better or think I'm full of crap, then that's your prerogative. I fully realize that all the message thus far in this thread have been constructive criticism, and I'm not angry or trying to be defensive about anything. I'm just posing my point of view and trying to help others that may be having trouble figuring out things that I know how to do.

I'm going to toss this out there just for the sake of asking....no other reason at all......

Has anyone here ever really reused a view for anything other than what they designed it for? I totally understand the concept, but I don't see how it can be actually applied (not to say that it can't, but I'm sure you understand what I'm saying...or maybe you don't LOL).

And as a side note to noobs, my advice is don't get too caught up in coding standards right off the bat. Try to do things the right way, but don't be afraid to "break the rules" if you need/want/have to; just try not to develop too many bad habits along the way.
myersn024 is offline   Reply With Quote
Old 08-19-2008, 02:55 PM   #13 (permalink)
Registered Member
 
Join Date: Jul 2008
Posts: 177
Default

Haha, I totally see where you are coming from its just that then these people go out there getting software development jobs and when they quit or get fired we're forced to reuse un-reusable code. Also I do agree that sometimes you shouldn't do things because thats the way you are "supposed" to. About the 3rd paragraph ye I've reused tons of view code thru my projects. Example: you write a view with 2 side buttons, one to view the next image and one for the previous... if you set the view to display images in an images array that is in the delegate then your view can only display images from that specific app. HOWEVER: if you make the view have a delegate object that it can ask for how many images are in the array and the images in an increasing order then you can easily reuse the view thru multiple projects that need to display data in that manner.

Sorry If I wrote too much and once again Im not saying you don't know what you are doing or anything along those lines Im just simply stating how such design isn't very reusable (from my point of view) so that others won't run into common problems when they are working on a big project.

Also ye n00bs shouln't get caught up on coding standards because they'll just end up pondering for hours on end if they are doing things right. With time and having to rewrite identical views to some you've previously written they will learn what it takes to write reusable code and understand the standards.

Quote:
Originally Posted by myersn024 View Post
Message disclaimer: I don't pretend to know it all, and my advice probably isn't the best. Coding is one of my hobbies, and I've been doing it for around 15 years. I try to make my code easy for me to understand since I'm the one that maintains it and uses the final product. If you like your way better or think I'm full of crap, then that's your prerogative. I fully realize that all the message thus far in this thread have been constructive criticism, and I'm not angry or trying to be defensive about anything. I'm just posing my point of view and trying to help others that may be having trouble figuring out things that I know how to do.

I'm going to toss this out there just for the sake of asking....no other reason at all......

Has anyone here ever really reused a view for anything other than what they designed it for? I totally understand the concept, but I don't see how it can be actually applied (not to say that it can't, but I'm sure you understand what I'm saying...or maybe you don't LOL).

And as a side note to noobs, my advice is don't get too caught up in coding standards right off the bat. Try to do things the right way, but don't be afraid to "break the rules" if you need/want/have to; just try not to develop too many bad habits along the way.

Last edited by Abel; 08-19-2008 at 02:58 PM.
Abel is offline   Reply With Quote
Old 08-19-2008, 03:06 PM   #14 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

I'm sure coding standards were created by people who were forced to figure out someone else's coding style LOL!
myersn024 is offline   Reply With Quote
Old 08-19-2008, 03:14 PM   #15 (permalink)
Registered Member
 
Join Date: Jul 2008
Posts: 177
Default

Oh thats exactly why they were created

put it this way tho:
you get hired by a company working on a huge x86 emulator.. theres over a million lines of code and all the
class files are labelled along the lines of:
"Class1.m" and the variables inside it go along these lines:
Code:
int a, b, c;
char *str1 = "hello world";
char *str = "blah";
BOOL flag;
and imagine you had to read thru all 300 class files so you can know which file to focus on to implement the feature your boss told you to add. How many days do you think it would take you to go thru all the code and find what you are looking for as compared to a project that has good naming conventions, reusable classes, etc ?


Also in the case of apple.. if they made their table views not be reusable we would all be doomed and would have to write our own table view classes.. wouldn't that suck ? =P

Overall if you are the only one who will be working with your code and you know where everything is at and you feel you'll remember where everything is 2 years from now then get crazy with it as long as you release your product on time.

Quote:
Originally Posted by myersn024 View Post
I'm sure coding standards were created by people who were forced to figure out someone else's coding style LOL!

Last edited by Abel; 08-19-2008 at 03:22 PM.
Abel is offline   Reply With Quote
Old 08-21-2008, 06:15 AM   #16 (permalink)
New Member
 
Join Date: Aug 2008
Posts: 6
Default

So.... for the sake of patterns, show me how to do this app correctly with MVC.

This code scared me away:
Code:
TwoViewAppAppDelegate *mainDelegate = (TwoViewAppAppDelegate *)[[UIApplication sharedApplication] delegate];
Lets do this via ViewControllers.

The MainView should have the controller TwoViewAppViewController.
The TwoViewAppViewController should have 2 methods: sayHi, flipView?
Code:
#import 

@interface TwoViewAppViewController : UIViewController {
	IBOutlet UILabel *theLabel;
}

@property (nonatomic, retain) UILabel *theLabel;

-(void) sayHi: (id) sender;
-(void) flipView: (id) sender;

@end
Inside flipView:sender we call the delegate, which is TwoViewAppAppDelegate? How do we reach the TwoViewAppAppDelegate?
I'm confused.
cDima is offline   Reply With Quote
Old 08-21-2008, 08:14 AM   #17 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

If you're wanting to reach the delegate from inside one of your view controllers, then you're going to have to get over being scared of that one line of code. That's how you get the singleton instance of the delegate so you can send messages to it or retrieve data from it.

Say you have a method in your app delegate called flipToBack, and you want to call it from one of your view controllers...this is how you'd do it.

Code:
TwoViewAppAppDelegate *mainDelegate = (TwoViewAppAppDelegate *)[[UIApplication sharedApplication] delegate];
[mainDelegate flipToBack];
That one line of code that you said you were scared of is what makes what you're wanting to do possible. All it does is get a pointer to the instance of your app delegate class. Did you even watch the video, or did you just look at the source? I thought I explained what that line of code did sufficiently.
myersn024 is offline   Reply With Quote
Old 08-21-2008, 11:45 AM   #18 (permalink)
New Member
 
Join Date: Aug 2008
Posts: 6
Default

I watched the video, implemented it, I get what you are doing. I'd give you a medal for doing it too.

I may have exaggerated a bit, but let me explain why I don't like that line. The view or view controller in MVC shoudn't know about the TwoViewAppAppDelegate, right?
Because it will never be reusable.

Lets take the UITextView, for example. To send messages UP the view hierarchy, as I understand it, the UITextView defines a prototype called UITextViewDelegate, and a public property called delegate. I believe this is the proper way to create view controllers that send signals to their parents. Right?

So the MVC way of doing that code is:
- define a prototype for the specific ViewController;
- after creating the ViewController in the app delegate, hook the TwoViewAppViewController.delegate to "self" (the app delegate);
- and in the app delegate, implement the prototype;

then from the ViewController you can do this code:

Code:
- (void) someMethod {
    if ([delegate respondsToSelector: @selector(flipToBack)]) {
          [delegate flipToBack]; // do something appropriate
    }
}
...or not? =)
I'm new in all of this, and come from a C# background. Maybe I'm implementing event-based development to make it more familiar.
cDima is offline   Reply With Quote
Old 08-21-2008, 02:44 PM   #19 (permalink)
Tutorial Author
 
Join Date: May 2008
Posts: 315
Default

From what I've gathered from reading Apple's documentation is that the controllers are supposed to be the non-reusable part of the code. Based on that, the views shouldn't talk directly to the delegate; they should pass messages to their controllers and the controllers, in turn, pass messages to the delegate. However, no where in their documentation do they talk about how to handle delegates in the MVC schemata. My personal interpretation it is that the delegate is there for the controllers to use for, among other things, a shared resource. I base that assumption on the fact that I haven't ran across another class type for iPhone programming that has a singleton instance that can easily be accessed without creating the singleton yourself.

I think that everyone is in agreement that the view methods telling the delegate to flip views should lie in the controllers. After reading all this discussion, I've decided that I should probably re-do the tutorial to show proper MVC based design.

Last edited by myersn024; 08-21-2008 at 02:47 PM.
myersn024 is offline   Reply With Quote
Old 08-21-2008, 04:11 PM   #20 (permalink)
Registered Member
 
Join Date: Jul 2008
Posts: 177
Default

Actually the view controllers are allowed access to w.e the heck they want, when using MVC we simply care about having reusable models and views. Heck if you make a reusable controller then many props to you but thats barely ever possible unless you are working on doing something very generic. The view however shouldn't have direct access to the delegate, any info it needs to display or deal with should be passed to it by its view controller.

Quote:
Originally Posted by cDima View Post
I watched the video, implemented it, I get what you are doing. I'd give you a medal for doing it too.

I may have exaggerated a bit, but let me explain why I don't like that line. The view or view controller in MVC shoudn't know about the TwoViewAppAppDelegate, right?
Because it will never be reusable.

Lets take the UITextView, for example. To send messages UP the view hierarchy, as I understand it, the UITextView defines a prototype called UITextViewDelegate, and a public property called delegate. I believe this is the proper way to create view controllers that send signals to their parents. Right?

So the MVC way of doing that code is:
- define a prototype for the specific ViewController;
- after creating the ViewController in the app delegate, hook the TwoViewAppViewController.delegate to "self" (the app delegate);
- and in the app delegate, implement the prototype;

then from the ViewController you can do this code:

Code:
- (void) someMethod {
    if ([delegate respondsToSelector: @selector(flipToBack)]) {
          [delegate flipToBack]; // do something appropriate
    }
}
...or not? =)
I'm new in all of this, and come from a C# background. Maybe I'm implementing event-based development to make it more familiar.
Abel is offline   Reply With Quote
Old 08-28-2008, 02:13 PM   #21 (permalink)
New Member
 
Join Date: Aug 2008
Posts: 40
Default Great discussion on views, controllers and app delegate

Thanks for providing the discussion/debate over the proper separation of the code. This is one piece of the iPhone puzzle I'm still not crystal clear on: should all view state be handled through the app delegate? I think the answer is yes.

When my app exits, then runs again, it should restore its state and appear as it did before (not all apps HAVE to do this, but I believe it's the suggested behavior). In this case, the app delegate is responsible for restoring the data and presenting the appropriate view.

If any data were stored in the view (scroll position, perhaps the view has two modes, or some subview is either displayed or hidden), a mechanism would need to be invented to save/restore this data: either the app delegate would know about the data (perhaps as just a blob of view data), or the view would be told to save/restore its own data.

In this case, we're talking about MVC, but at two layers. There's the app data - then there's the view data. When I'm looking at an email PDF attachment, close the app, then restart mail, I get a view of my attachment scrolled to the exact place I was before. When I am in the middle of authoring an email, close the app, then restart main, I get a view with the cursor in the right place of the body of the message, but the scrolling isn't necessarily the same. So this piece of the view state isn't persisted.

Comments?

Last edited by TheFury; 08-28-2008 at 02:15 PM.
TheFury is offline   Reply With Quote
Old 08-28-2008, 02:43 PM   #22 (permalink)
Registered Member
 
Join Date: Jul 2008
Posts: 177
Default

No, view state should be handled by the view controller. In VERY SMALL applications this could be the delegate.
Most complex applications that deal with tons of views would have various view controllers.

View states such as scroll position should be restored by the view controller and saved by it too. The view should only have some kind of accessor
method to determine at what point the view was scrolled to. A scroll view would have a method such as currentScrollPoint or some other accessor to access
the area where it is scrolled.

I hope all that made sense.

Quote:
Originally Posted by TheFury View Post
Thanks for providing the discussion/debate over the proper separation of the code. This is one piece of the iPhone puzzle I'm still not crystal clear on: should all view state be handled through the app delegate? I think the answer is yes.

When my app exits, then runs again, it should restore its state and appear as it did before (not all apps HAVE to do this, but I believe it's the suggested behavior). In this case, the app delegate is responsible for restoring the data and presenting the appropriate view.

If any data were stored in the view (scroll position, perhaps the view has two modes, or some subview is either displayed or hidden), a mechanism would need to be invented to save/restore this data: either the app delegate would know about the data (perhaps as just a blob of view data), or the view would be told to save/restore its own data.

In this case, we're talking about MVC, but at two layers. There's the app data - then there's the view data. When I'm looking at an email PDF attachment, close the app, then restart mail, I get a view of my attachment scrolled to the exact place I was before. When I am in the middle of authoring an email, close the app, then restart main, I get a view with the cursor in the right place of the body of the message, but the scrolling isn't necessarily the same. So this piece of the view state isn't persisted.

Comments?

Last edited by Abel; 08-28-2008 at 02:47 PM.
Abel is offline   Reply With Quote
Old 09-02-2008, 09:07 AM   #23 (permalink)
Registered Member
 
Join Date: Sep 2008
Posts: 5
Default

Quote:
Originally Posted by myersn024 View Post
After reading all this discussion, I've decided that I should probably re-do the tutorial to show proper MVC based design.
Please...
Or could you at least create and upload a project with the proper MVC based design? It would a big help.

Thank you very much for the original tutorial, i learned a lot, and the this thread is very informative.

Thank you.
hcosta is offline   Reply With Quote
Old 09-05-2008, 09:00 AM   #24 (permalink)
New Member
 
Join Date: Sep 2008
Posts: 4
Default

I have a question. How do you solve the problem with simulated metrics, when having separate .xib files?

As you can see, I've uploaded your sample[1] with a minor modification: I added a label at the top of the screen in your settings view. This label gets covered later by the status bar.

I've been having this problem for quite a while, and the only solution I've found (so far) is NOT to use IBuilder...

[1]

TwoViewApp has a problem with StatusBar
dalef84 is offline   Reply With Quote
Old 09-05-2008, 02:22 PM   #25 (permalink)
Registered Member
 
Join Date: Jul 2008
Posts: 177
Default

It seems like all IB does is tell the view what size frame to use. IB however (for me, at least) has never removed the status bar. Usually I remove it programmatically.

Quote:
Originally Posted by dalef84 View Post
I have a question. How do you solve the problem with simulated metrics, when having separate .xib files?

As you can see, I've uploaded your sample[1] with a minor modification: I added a label at the top of the screen in your settings view. This label gets covered later by the status bar.

I've been having this problem for quite a while, and the only solution I've found (so far) is NOT to use IBuilder...

[1]

TwoViewApp has a problem with StatusBar
Abel is offline   Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On
Trackbacks are On
Pingbacks are On
Refbacks are On


Enter the iPhone App Challenge!  Win $500!
» Advertisements
» Online Users: 256
15 members and 241 guests
acerola, adison, bravetarget, Breshi, Dracor, falcon76, irish_kiwi, iSdkDev, jordanclark1993, LemonMeringue, ltgbau, pereorra, rahulvyas, refreshe, SirGeraint
Most users ever online was 779, 05-11-2009 at 09:55 AM.
» Stats
Members: 24,226
Threads: 39,006
Posts: 171,093
Top Poster: smasher (2,570)
Welcome to our newest member, mellisakelien54
Powered by vBadvanced CMPS v3.1.0

All times are GMT -5. The time now is 02:18 AM.
Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0