Visit our friends over at The App Show! Steve and Dave produce a weekly show shining a light on the iPhone 2.0 software and the applications being developed by the amazing development community for the iPhone SDK!
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.
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.
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.
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.
@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.
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.
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?
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.
Multiple XIB how-to
? Well, either that or could you point me were to read to better understand it all?
Multiple XIM how-to
Linear Mode
