Re: [iPhone 3.0; XCode 3.1.3] Question about when views are available for manipulation.
Re: [iPhone 3.0; XCode 3.1.3] Question about when views are available for manipulation.
- Subject: Re: [iPhone 3.0; XCode 3.1.3] Question about when views are available for manipulation.
- From: "Henry McGilton (Boulevardier)" <email@hidden>
- Date: Sun, 9 Aug 2009 22:02:43 -0700
On Aug 8, 2009, at 1:23 AM, Brian Bruinewoud wrote:
Hi,
I'm a little confused about how this code works:
MyController *myController = [[ myController alloc ]
initWithNibName: @"myView" bundle: nil ];
[[ self navigationController ] pushViewController:
myController animated: YES ];
myController.myProperty = itsValue;
[ myController release ];
I always see the view set-up code (in this case
"myController.myProperty = itsValue") after the view has been
displayed. It makes more sense to me to set up the view before
calling pushViewController but this doesn't work. For example, if
myProperty has a non-synthesized setter that expects IBOutlets to be
bound it will be disappointed as they'll still be nil at this point.
So, my questions are:
Why doesn't initWithNibName create and bind all the IBOutlets before
it returns?
Because --- as Kyle Sluder stated --- laziness is a virtue, in
operating systems and in
programmers (but only if the latter use their laziness
effectively) . . .
The iPhone programming frameworks have a very simple set of design
concepts for displaying
data to the user of an iPhone application:
o present data in single screens
o each screen of presentable data is represented by a single UIView,
which may have many associated sub-views (which fact is largely
irrelevant)
o that single screen / single UIView is created and managed by a
UIViewController
Initialisation of a UIViewController is done in one of two ways
(skipping over details like the
different ways to initialise Navigation Controllers or Table View
Controllers):
MyViewController *aController = [[MyViewController alloc]
init];
or
MyViewController *aController = [[MyViewController alloc]
initWithNibName: @"MyViewNib" bundle: nil];
In both of these cases, all you have done is to allocate and
initialise a View Controller. That's it.
No further work is being done behind the scenes by the View Controller.
In the first simple alloc-init style, the design assumption is that
the View Controller will fabricate
its managed view 'manually' *when the View Controller is asked to do
so* by referencing its view property.
In the second, initWithNibName style, the design assumption is that
initWithNibName tells
the newly allocated View Controller the name of the NIB that it *will*
load (in the future)
*when the View Controller is asked to do so* by referencing its view
property.
So, . . .
Is the view guaranteed to be visible after pushViewController returns?
Absolutely not. All you have done by invoking pushViewController
is to push a
View Controller onto the Navigation Controller's stack . . .
Or is it still animating on another thread?
The question is meaningless . . .
Or is the request to display the view merely queued for the next
loop through the RunLoop?
Likewise . . .
There's no need to bring threads and runloops into the picture (other
than the regular old runloop
and the main thread where all this activity is likely taking
place). There is a very very simple
sequence that's followed from application launch through to display of
the initial screen by even
the most complex iPhone applications.
Given you have been talking about Navigation Controllers, the process
of obtaining screens / views you
can interact with programmatically starts when some other part of the
program (maybe your application
delegate or maybe some other View Controller) asks that Navigation
Controller to supply its view and to place
that view onto the window in some fashion.
After that, the Navigation Controller will then ask the View
Controller at the top of the Navigation stack
for *its* view, and then the View Controller your were asking about
earlier will go through the correct
rituals to produce a screen / view of (one hopes) useful data for the
end user.
Similar situation with the call to makeKeyAndVisible - I've seen
samples of applicationDidFinishLaunching where makeKeyAndVisible is
called and then set up is done to the main window's view.
I (and I am sure many others) would be highly interested to see these
sample codes to which
you refer. In general, if you make the window visible first and
then load up your initial screen
and add it to the window, the user will see a (possibly unpleasant)
'flash' as the new stuff is added.
A more user-friendly approach is to (quickly) load the initial UI, add
it to the window, and then
display the window.
I hope this has clarified some of the issues of View Controllers and
Views . . .
Cheers,
. . . . . . . . Henry
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden