I've got an app that worked OK in iOS 4 but is having several problems in iOS 5 because of the tab bar related changes. In a couple of cases I have a UINavigationController with no buttons and a UITableView as the root view. The UINavigationBar background header image is fairly tall, and as a result the top row of the table is getting hidden. I need to somehow move the root view controller origin down about 40 pixels.
I've tried setting the nav bar height -- this just hides more of the table as I increase its height.
I've tried setting the origin of the root view controller's view -- this seems to be ignored.
I'm kind of running out of ideas.
Anyone know how to push the origin of the table view down?
Well, after scanning through all the superclass methods about 6 times I finally realized that a UITableViewController has a UITableView which is a subclass of UIScrollView, and UIScrollView has the inset property. Setting the top inset (which is, oddly, in points) provides padding above the start of the table.
The scroll view still wants to display the table scrolled up with the first row hidden behind the header, but doing scrollRectToVisible: fixes that.
Related
I have a child View Controller within a Container View that hosts a vertically-scrolling UITableView. Tapping a Button expands a separate View that covers the UITableView in the child View Controller. This new View contains a vertically-scrolling Scroll View. No matter what UITableView settings I change, I am unable to scroll the Scroll View unless I remove the UITableView entirely.
I am currently porting my fully-developed Android application to IOS, and my experience with Android Studio leads me to believe that this is an issue with the UITableView stealing focus from the Scroll View.
In short, how may I temporarily remove focus from the background UITableView to allow the overlaid Scroll View to scroll?
With Scroll Views up until this point, I have been setting the bottom -> Superview constraint to priority: 249 since I was having issues setting the contentSize. For some reason, having a Table View in the background disables this effect. My guess is that this happens because the Table View is forcing the Superview to anchor based on its own constraints, and therefore the Scroll View can no longer adjust based on low-priority constraints. Changing the Equal Height parameter of the Scroll View -> Superview to a proportional relation (x2) has temporarily addressed the problem.
I have a simple 1 screen app, with 1 View.. the view contains
a button, an textbox and a button across the top
A segmented controller across the bottom
and a MapView in between.
In portrait mode all is right with the world.. So I decided to begin to allow Orientation change...
in IB all views and elements and even the root window have autoResizeSubviews set
in My AppDelegate and my viewController I have also programatically added SetAutoResizeSubviews to yes explicitely I have set the autoResizingMask in the Root Window and the View Controller to FlexibleWidht | Flexibile Height
I have added the shouldAutorotateToInterfaceOrientation in my ViewController to always return true.
Yet, it doesn't work.. Or should I say it doesn't rotate properly.. in both portrait modes everything looks great, but both landscape modes, things don't get laid out or resized properly.. Basically all I see is the mapview, and its size gets slightly wider, but not much than the portrait mode, and it doesn't fill up the screen top to bottom.. all other interface elements with the exception of one button are invisible and it appears on TOP of the mapview.. as thought it just happened to be layed out over the view by coincidence than any design.
Anyone have any ideas what I am missing, or why?
Thanks in advance
You say "I have set the autoResizingMask in the Root Window and the View Controller" but that is a red herring. It is the buttons, the text box, the segmented controller, and the map view that have to have the correct autoresizingMask. If this view is being designed in the nib, you can set the values there and then turn the orientation right there in the nib and see what happens.
If you are unable to work out good autoresizingMask values for all those interface elements, implement didRotateFromInterfaceOrientation and perform the layout alterations in code when called upon to do so.
In a UINavigationController I have a UITableView. I use a settings-button to allow users changing some table settings.
When the settings-button is tapped I push a new view onto the navigation stack.
This new view has the following view structure
-> UIView1 411 x 320 px (backgroundColor supposed to be transparent) !!!!
-->> UIView2 270 x 300 px (backgroundColor grey)
--->>> Screen elements
My problem is that I want UIView1 to be transparent so that the information behind is still visible. All my attempts, such as
setting the bg color to transparent
changing the alpha value
removing the Opaque indicator
have failed so far.
Any clues? most appreciated!
UINavigationController is not designed to allow "buried" view controllers to still be showing under the current visible view controller. (The iOS framework can actually unload the views of view controllers on the nav stack that aren't the current top item!)
So if you try to do it, it just won't work, or you'll have problems. (Same goes for modal view controllers on the iPhone -- even if you make the background transparent, the view you're pushing on top of will disappear.)
If you really want the old UI to still be visible underneath, consider presenting your new entire UI as a UIView placed over the current view (i.e. do [existingView addSubview:myNewView]).
iPhone Interface Builder question: Does anybody know how to add a small UIView over a ScrollView yet the image should stay still? Basically I already have a full image (320 x 480) over the Scroll, so the image scrolls, but now I need to add a AdMob View (320 x 48) on top of them. The problem is after i build and run, the ad scrolls as well. How do you make it stay still?
Thank you!
Not sure if this is how you've done it in your code, but if you've added the AdMob view as a subview of the scroller, then it will scroll.
It should not scroll if you add it as a subview elsewhere, either the superview of the scroller or the window itself.
I admit though that I generally do not use Interface Builder and would generally handle this programmatically, but I hope this helps.
Just place the AdMob view at the same hierarchical level of the ScrollView but being in front. Then when the Ad is available, set adMobView.hidden=NO, when it is not available set adMobView.hidden=YES. Essentially the hierarchy is:
RootView -
|---- UIScrollView
|----- any UIView (to be scrolled)
|---- AdMobView --> not subview of ScrollView but subview of RootView
Of course when the Ad is visible you will not be able to tap on it to scroll, unless you subclass it to pass the tap to next level in hierarchy. But probably you have not this problem thanks to the reduced size of the Ad (48) with respect to the entire scrollView (480).
Once again, I'm almost entirely sure this is something dumb that I'm doing, but I've been banging my head against this one for hours & am getting nowhere.
I'm trying to restructure the view hierarchy of my app. I need to be able to detect user interface orientation changes globally in order to correctly rotate a "Loading" view displayed when the app is downloading content. (device orientation changes seem to fire at different times, causing the view that needs to respond to these events to rotate sporadically).
The app previously added a UINavigationController's view to the main window. I modified the hierarchy to add the view of a UIViewController subclass to the main window, and added the view of the UINavigationController to the subclass's view. The UIViewController subclass manages the display & rotation of the "Loading" subview, and I was expecting the rest of the app to continue behaving normally, as inserting one extra empty view into the hierarchy didn't feel like I was changing too much.
My initial problem was the positioning of the UINavigationController - it was 20 pixels too low, resulting in a gap between the status bar and the navigation bar, and cutting off the bottom 20 pixels of the tab bar. I was able to adjust this by setting the frame property of the UINavigationController's view to the bounds property of the UIViewController's view, which corrected the position.
However, now I'm stuck with a 20-pixel-high dark "overlay" on top of my navigation bar. If I were to guess, I'd say it was black with 50% opacity. Touch events on this bar don't work (e.g. if I try to tap the "Back" button through the overlay, nothing happens). The fact that the height is equal to that of the status bar hasn't escaped me, but I'm at a total loss as to what could be causing it.
I hate feeling this stupid, so if anyone has any insight into this problem, you'd really make my day. Thanks in advance!
OK, a few things pop out from your post.
My initial problem was the positioning of the
UINavigationController - it was 20
pixels too low
This makes me believe it is related to your new problem.
I was able to adjust this by setting
the frame property of the
UINavigationController's view to the
bounds property of the
UIViewController's view
This sounds like the view it was loaded onto was offset 20 pixels, and when you set it to the bounds, it repositioned it on the windows view space.
Touch events on this bar don't work
(e.g. if I try to tap the "Back"
button through the overlay, nothing
happens)
This is the big thing. If touch events aren't being sent to the view, then what that means is that the OS doesn't see a view where you are pressing (or rather the view you want it to), so that view doesn't get the message to do something.
From what you have said, I believe your problem is with your base view controller that you just added. Try redoing the frame on, making it conform to where you want. Then take out the code you put in to set the navigation controllers frame. The navigation controller should fit to the view you added too, and once you have that main view where it needs to be (20 pixels higher apparently), then everything should work.