views:

57

answers:

1

I have an idea about an application that I want to build and Im new to iPhone/iPad development (but not new to development in other languages/frameworks such as .NET and Java). I want to layout some views on the screen so that they animate (slide in) from different directions into their places.

The question is about the strucuture of the application, if I have say 4 rectanglular areas on the screen that contain business data, such as contacts (name, photo, etc...) and they all take up different widths of the screen (say the first contact takes up one row of the screen, but the next 2 take up half the width of the next row each, and so on).

Should I create a custom view for the different sized contact views, (i.e. LargeCustomView and SmallCustomView, and any other special type that I make) or should it all be one type, say, CustomerDetailsView which could be stretched to fit at design time?

Also, if there were, say, 3 different instances of the same custom view on the one screen, are there 3 instances of the view controller also? Im a little confused about powering the data behind a view, can someone shed some light on this for me? Do I just set the properties (say an instance variable ContactForView) on the view controller for each instance?

Thanks for any help you can give

Cheers,

Mark

+1  A: 

Should I create a custom view for the different sized contact views, (i.e. LargeCustomView and SmallCustomView, and any other special type that I make) or should it all be one type, say, CustomerDetailsView which could be stretched to fit at design time?

I think only you can answer that question. If UIView autoresizing masks are enough to accomondate both layouts, you should probably go for just one class. If that's not enough, you can either override layoutSubviews to account for different sizes or perhaps go with a common superclass to contain the logic and two subclasses to do the different layouts.

Also, if there were, say, 3 different instances of the same custom view on the one screen, are there 3 instances of the view controller also?

Because of the way UIViewControllers work, Apple generally recommends not having more than one view controller per screen. From the docs:

You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller.

Otherwise, things like device rotation can get tricky as a view controller that is not full screen should probably react differently to such events and Apple's UIViewController is not written to do that. However, nobody stops you from writing your own view controllers (derived from NSObject, not from UIViewController) so that's what I would recommend: if the view is quite complex, write a custom controller class for it but stick to one UIViewController per screen.

Ole Begemann
Thanks Ole, so in terms of logically grouping view elements so that they form separate sections on the screen, you would just recommend building it using the standard view controls, but in one nib?
Mark
Not necessarily. It's entirely up to you. If you have duplication that can be reduced by creating a common subview from a NIB, do that. NIBs are not tied to view controllers.
Ole Begemann
ahhh, I see, so you could in fact create many NIB files that contain the different collections of controls, but contain and manage them all within the main view controller, that about right? BTW, I know a lot of this design level stuff is subjective, but you never know what sort of unofficial standards there exist in a new framework
Mark