tags:

views:

370

answers:

3

I have a library that programmatically constructs a UIView that exhibits my custom behavior. This library could be dropped into many different applications at different places in the view hierarchy. Under certain circumstances the view needs to "expand" to fill the screen real estate. I am currently doing this by having my code walk the view hierarchy until I find a view with no parent, constructing a new view and inserting it as a subview of that found view, and then performing an animated transition between the two. Exiting that new view is merely a matter of hiding it, which restores the previous state.

I have two questions.

  1. Is there a better way to do this? (In particular, I don't really like traversing the view hierarchy like that.)
  2. What bad things can happen with this approach? One thing that could go wrong, for example, is that the view that previously was on display doesn't know that this has happened and therefore might behave erratically. (This could be solved by inventing a delegation protocol for this behavior or using an existing protocol that I am currently unaware of.)

The goal here, obviously, is for the containing application/view/controller to be required to do as little as possible, short of creating a rectangle and constructing my view's controller.

+1  A: 

Why not just call presentModalViewController? By default this animates onto the screen from the bottom, but you can prevent this by passing NO as the animation option and then controlling your own.

This is the designed way for a view/controller/app to temporarily surrender control of the UI to another module.

Andrew Grant
The short answer is that I didn't know about it. :-) Will take a look. Thanks.
ddoughty
glad to help! :)
Andrew Grant
My view is small. Imagine it's an ad banner or something similar. It wants to slide in a view which takes over the screen. When I use presentModalViewController the modal view takes the screen real estate of my view, not of the entire screen, which leads me to think it's not appropriate here.
ddoughty
+1  A: 

Andrew, I would assume he's not doing that because he doesn't want the slide-up animation.

The top-level view is a UIWindow; you can get the key (current) window by calling [UIApplication sharedApplication].keyWindow. (Nearly all apps have only one window.) Other than that, walking up the view hierarchy is perfectly legitimate.

EDIT: I just noticed that UIView has a window property that will get you straight to the view's window, so you don't need to walk the hierarchy after all.

As for bad things happening, I can't really think of any, unless some other part of the app decides to add or delete the key window's direct subviews. Another possible issue might be if a text field is the first responder when you add your view; the keyboard might stay on top of your view.

Brent Royal-Gordon
you can easily skip the canned animation and roll your own though.
Andrew Grant
Both of these answers are accurate. As noted in the comment above there are still issues with using the modal view controller in my case.
ddoughty
A: 

ddoughty,

I made a youtube tutorial showing how to make views expand and shrink like in the facebook iPhone app.

Hope it can be of some help: How to make expanding/shrinking views on iPhone SDK

Adam

Adam