I want to overlap view over the another view. I don't want to add it as a subView. The new view should be added with following rect size (280,400) on the super view of size (320,460).
Can any one suggest me the right way for doing this.
Thanks in advance
You can do this by use of UIAnimations, replacing one view with the other.
You could add both view as subviews of a superview. And the superviews view controller handles the show and hide of the subviews.
Im not completely sure what you mean, but i will try...
Overlapping == Changing "z-index"
You can use the following to bring your view above the other views it shares its hierarchy with.
[yourview.superview bringSubviewToFront:yourview];
Overlapping == adding to the superview
Then this should do the trick.
UIView *yourview = ???
yourview.frame = CGRectMake(?,?,280,400);
[self.view.superview addSubview:yourview];
Any UIView or variation thereof can respond to the .superview. Its a global "where the heck am I ?"
If you want to go all the way to the uppermost layer, there is also :
[self.view.screen addSubview:yourview];
You can't get much higher than that ;]
Related
I need a UIScrollview to show some static content in my app. I have taken a UIScrollView through XIB and started adding some UIImageViews and textViews in to it. But after coming to the end of the scrollView the view is not exapanding anymore. I need more space so that I can add some more views below. Is there any way in which I can do this (through XIB and not through code).
I struggled a lot to get this done in a more elegant way then the solution described by Csabi.
It's really simple:
In your xib file just add a generic view which is not a subview of your viewController.view (i.e although this view is in your xib file, it is not a part of your viewController's view hierarchy.)
Then select this view and using size inspector set the width and height that suits your need. Add whatever objects you want to this view. Hook up this view to your viewController with an IBOutlet. (Let's call it IBOutlet UIView *myBigView).
in your viewController.view drag a ScrollView and adjust the size of the scroll view as you like. Hook this up to your viewController. (IBOutlet UIScrollView *scrollView)
Now it's super simple:
-(void) viewDidLoad{
[super viewDidLoad];
self.scrollView.contentSize = self.myBigView.bounds.size;
[self.scrollView addSubview:self.myBigView];
}
Yes it is you can define the height of the UIScrollView simply for example height:1800
now you get bigger UIScrollView then your view you can put your objects to scrollview, and if it is filled simply pull it upward and drag and drop other items when you are finished simply pull the scroll view to its position and you have it.
It is simple :)
Hope it helps
Ask if you have any other question
In my iPhone app, I have a view controller with two views (essentially, a front & back view). The front view is the main UIView, and the back view is a secondary UIView which is added as a subview using [self.view addSubview:backView] when showing the back and [backView removeFromSuperview] when hiding it. However, when the orientation changes, I have the following issue: the main UIView (frontView) rotates & all of its elements resize properly, but the secondary/subview UIView (backView) does not rotate & all of its elements do not resize properly. Does anyone have suggestions on how to make the secondary UIView autoresize properly according to the rules I have set in Interface Builder?
In the end, the solution I found was simply to separate my UIViews into separate UIViewControllers, and make sure that any views that I wanted to be able to rotate only had one UIView.
If I understand correctly, at the time of rotation 'backView' has been removed from it's superview, yeah? If so, that's the cause of the problem. The autoresize property determines how the view resizes relative to it's superview. If it doesn't have a superview it won't resize.
Perhaps using [backView setHidden:YES] instead of [backView removeFromSuperview] will be sufficient for your needs.
I had the same problem, here is how I fixed it based on imaginaryboy's
suggestions (thanks!)
Add the backview to the viewcontroller at viewDidLoad and hide it at the same time. Show it when needed, Hide it again. Set the resizing of the backview to UIViewAutoresizingFlexibleWidth in IB (or code I guess, I used IB)
Not that this is the same problem, but I found a similar problem when adding 2 subviews in my application:didFinishLaunchingWithOptions method. Since your reference above is using [self.view addSubview:view], I would understand that to mean that self is not your UIWindow. When adding an additional view controller to your App Delegate window (UIWindow), the second view controller will NOT receive any rotation events and will never rotate. Only the first view controller added to UIWindow will rotate. See:Technical Q&A QA1688 I believe this also affects views added after the first view where the first view is later removed from the superview.
I ended up following the suggestion I read elsewhere to use separate views for each orientation, thereby eliminating the need to worry about resizing behavior. As always, YMMV.
Or; if you want to avoid an additional controller, you can achieve the same effect by setting view.frame in willRotateToInterfaceOrientation:: like so
if(UIInterfaceOrientationIsLandscape([[UIApplication sharedApplication] statusBarOrientation])) ;//set stubborn view.frame for landscape orientation
else ; //set stubborn view.frame for portrait orientation
Although it feels like a hack; it's simple.
I am adding a UIScrollView as a subview to the controllers view. After that i am adding 2 views to the scroll view as the content view.
When I am printing the subviews of the scroll views using NSLog(#"Scroll View Subviews : %#", [scrollViewObj subviews]);
then it is displaying 4 subviews , 2 for the views added to the scroll view and it is automatically adding 2 image views ?
I cann't get why the image views are added as subviews to the UIScrollView ?
I am adding the Scroll view and 2 views to the scroll view using the interface builder.
thanks.
I bet those are used for the scroll indicators to the right and bottom of the view.
The two extra subviews are indeed for the scrollbars. You'll only see those in there if you opt to use anything other than the default scrollbars.
If you want to know the number of your own subviews, set the tag property on each one before adding it in (to a positive integer, for instance). That way you can walk the subviews and see which ones have a tag value > 0.
I'm sure UIScrollView has a bunch of child views that are part of how it functions. I wouldn't worry too much about it.
Is it possible to resize the UITableView on the RootController of a nav based app? When RootViewController.xib is opened in IB, there isn't a view. Just the UITableView. Clicking the inspector and then the little yellow ruler, frame height is grayed out. I'm adding a toolbar programmatically to the RootViewController:
[toolbar setFrame:rectArea];
That works fine but the bottom cell in the tableview is partially hidden because the tableview doesn't know about the toolbar.
The easiest way, is to adjust the contentInset (which is inherited from UIScrollView). Resizing by setting the frame can cause crazy drawing bugs in cells.
For example, if you are trying to resize a tableview for the keyboard, do something like this:
tableView.contentInset = UIEdgeInsetsMake(0.0, 0.0, 216.0, 0.0);
tableView.scrollIndicatorInsets = tableView.contentInset;
Hope that helps someone. This way worked best for me.
Yes, but you need to have a ViewController (not a UITableViewController) as the root controller for the nav, and wrap the actual UITableView in the UIViewControllers view.
You can still have the UIViewController conform to the UITableViewDelgate and Datasource protocols, and use all the same methods you have now in your UITableViewController.
P.S. you'll get more responses if you use the plain "iphone" tag.
You could also just set the Content and Scroller inset of the tableview
I encountered a similar issue when attempting to display the detail controller by itself, see: http://vimeo.com/13054813
The issue is that the SplitView controller applies its own transform to the sub-controllers, taking them out of the orientation detection loop, which blows goats and seems incredibly 'hackish' for built-in classes. (The video illustrates what happens when you make the detail view the root view, then add it back to the split view and make the split view root while in landscape; you get double rotation of the detail view.)
Unfortunately I've again run into these transformation issues while attempting to resize a SplitViewController's detail sub-view in response to the keyboard appearing/disappearing. In portrait, all works fine, in landscape it's fscked.
Yes, adjust the contentInset and scrollIndicatorInsets are the convenient way to resize the UITableView.
As the answer of Sam Soffes posted, I succeed resize UITableView in UITableViewController for the bottom UIToolbar.
I have just started learning objective-C and the iphone sdk and I have a question that I hope someone can help shed some light on.
What is the difference in the following:
self.view = someView;
and
[self.view addSubView: someView];
Say for example, in a simple app, where we have only one controller and one container view (has a few image subviews).
What is the difference between the two statements? The reason that I'm asking is because I was tinkering around in some sample code and I noticed the view was being initialized with images as subviews like so:
if (self = [super initWithFrame:CGRectZero])
{
//adds some images as subviews here
}
As I understand it the initWithFrame: CGRectZero, creates a frame with size at [0,0,0,0] (essentially invisible).
When I directly set the view with
self.view = someView;
I notice the view actually displays the image. But when I add the view to as a subview of controller's 'default' view, it doesn't. So basically my question is, whats going on behind the scenes? Why is the first method "resizing" the frame and the second one not doing the same thing.
What you see on the screen of your iPhone is almost always a hierarchy of views.
When you look at, say, your inbox in Mail, you're seeing a bunch of views. There's a big containing view.[1] Within that, there's a navigation bar view, a table view, and a toolbar view. Within the navigation bar view, there's a button view on each side and a label view in the middle. Inside the table view, there are a bunch of table cell views, and each of those cells has several label views. The toolbar has five button views. I could go further and talk about the views inside those buttons and so on, but I'm sure you get the idea.
The view above any given view is its superview; the views below it are its subviews. So a table cell view has a table view as its superview and a bunch of label views as its subviews. The top view, the one that has all the other views inside it, is called the root view.
Each view has its own drawing surface. The rectangle formed by that drawing surface is called the frame. The frame of a view is relative to the frame of its containing view. So if one of our table cell's label subviews has its frame at (0,0), that means it will be in the table cell's top left corner, even if the cell is halfway down the screen.
When you're writing a view controller, self.view is that root view I mentioned earlier; all the other views are subviews of that one (or subviews of its subviews, etc.). One of the features of a view controller is that it automatically resizes its self.view to fit the screen. (The available area will be smaller in the middle of a phone call: the status bar is twice as high then, so there's less space for your app. It will also be smaller if your view controller is being managed by a navigation controller or tab bar controller, but that's a different story.) But just because you resize its root view doesn't mean that the root view's subviews will automatically resize. To do that, you need to set their autoresizing mask (a property which tells the view how it should react when its superview changes size):
someView.autoresizingMask = UIViewAutoresizingFlexibleWidth
| UIViewAutoresizingFlexibleHeight;
(There's a graphical way to set up the autoresizing mask in Interface Builder—click the ruler icon in the inspector window and look at the "Autosizing" section.)
Even that's not enough, though, if someView isn't the right size to start with. To do that, adjust its frame before you add it as a subview of self.view:
someView.frame = CGRectMake(
0, // all the way to the left
0, // all the way at the top
self.view.frame.size.width, // same width as the root view
self.view.frame.size.height, // same height too
);
So why would you ever use subviews if you have to do all this twiddling that the root view does for you? Simple: you can only have one root view, but one view is almost never enough for what you need to do. If you really need only one view, of course, you can just set it as the root view and go on your merry way, but chances are, things are more complicated than that.
[1] I'm simplifying a bit here, but that's fine for right now.
When you add a view as a subview, you need to make sure that you're actually adding to an existing view.
self.view = view sets the controller's view. Without this (either in code or done with a XIB) you'll never see anything as the controller has no view to show.
[self.view addSubView: someView] assumes that self.view is already set. If it doesn't, you're adding someview as a subview of nil, and it will never get seen.
Basically, think of self.view as the big container, and all the subviews are just pieces inside of it. If you don't need any subviews, setting self.view to a UIImageView or UIWebView is fine. If you do need subviews, you'll need a big, empty container view in which to put them.
In your case, I'm betting self.view is never set, and you're adding your image views to nil.
Setting the view controller "view" property only changes the view it is managing.
Adding a view as a subview of another view, actually adds the subview underneath the other view.
They are very different things, as one adjusts a view controller and the other alters a view hierarchy.
As a guess, the reason you didn't see anything the first way was the frame for the subview you were adding was CGRectZero (0 in size).