On Dec 22, 2009, at 11:01 AM, Matt Neuburg wrote:
> On Tue, 22 Dec 2009 12:51:35 -0500, "Eric E. Dolecki" <edole...@gmail.com>
> said:
>> I have a view which controls it's UI when rotated. However, if there is a
>> subView in place, it rotates and I'd like to control it's UI too. In my
>> subView the willAnimateRotationToInterfaceOrientation doesn't get fired. I
>> set up the shouldAutorotateToInterfaceOrientation. Does my main view need to
>> call something in my subView to get this to work? I'd think the subView
>> would get the event too but it doesn't.
>
> This sounds like a good time for the view to post an NSNotification. The
> subview can then respond to it. m.
Sounds like overkill --- swatting mosquitoes with sledgehammers.
A potentially better way to approach this is to look at the different roles and
responsibilities of View Controllers and Views, and gain a clearer understanding
of which class of objects does which job . . .
Think of a View Controller as a View *Manager*. The dominant paradigm for
presenting screens of content to users on the iPhone platform consists of a
View Controller managing a single enclosing View which, including all of
its sub-views, represents that screen of content.
In general, try to have your UIViews perform just two responsibilities.
First,
and by far the most important, is drawing their content. Second is acting as
a container into which other Views may be added as sub-views. A very
distant third (which is why I said 'two' even though it makes me look as if I
can't count) is handling events, which task is frequently better managed in the
View Controller.
The View Controller implements methods to manage rotation, so
doing the work of View hierarchy layout and sub-view re-positioning and
re-sizing in the View Controller makes more sense than pushing the
job down into the sub-views.
If the View Controller knows about its view's sub-views, it will then know
about their positions and sizes, and can perform simple re-positioning
and re-sizing to accomplish the job.
Finally, please try to use naming schemes where names of objects
bear at least a passing resemblance to what those objects actually are. I
refer to the line of code that reads:
myInfoView = [[InfoViewController alloc]
The code leads one to believe that the class named InfoViewController is a
sub-class of UIViewController. The variable name myInfoView leads one
to believe on casual inspection (and without adequate context) that the variable
references something that's a sub-class of UIView. Which is it ? List
readers,
many of whom are trying to help, would be less confused if reasonable naming
schemes were employed. The statement in an earlier message:
My subView is a view controller too.
Can not possibly be the case. A sub-view implies it's a UIView, and a UIView
can not be a UIViewController --- the two classes are on different branches of
the
class hierarchy, and neither of them even define protocols that the other
could adopt . . .
We had a thread on this list a couple of months ago where even some of
the more high-powered members of the list had tied themselves in knots and
were arguing at cross purposes because a poster asking for help had allocated
a UIImageView but called it an image . . . If you're asking for help, please
try to
write code readable and understandable by other busy people . . .
Cheers,
. . . . . . . . Henry
iPhone App Developer Education --- visit www.nonatomic-retain.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
