There are many questions like mine both in Objective-c and Swift that ask how to lock a UIToolbar to the top of a UITableViewController, and I will add to that list. However, my question is unanswered by the others. I need to lock it to the top of the view controller so that it is not considered a cell by the program, and so it doesn't move down, but is locked at the top instead.
All other answers that I found want me to either
(a) Embed the UITableViewController in a UINavigationViewController
or
(b) To use a UIViewController with a UITableView inside it
I do not want to do either one of these.
I want to keep a UITableViewController––not to replace it with a UIViewController and UITableView––and I do not want to use a UINavigationViewController––I am trying to not do that because it causes a plethora of issues in the rest of the app (which can be fixed but I don't want to have to do that).
What you are asking for is not reasonably possible.
The root view of UITableViewController is a UIScrollView. Every view you add as a subview in a UITavleViewController must be part of that scrollview and thus will scroll with it.
To make it work you must take one of the options you mentioned (moving to a UIViewController with a table view as a subview is likely to cause the least disruption in your app).
There are a couple of unreasonable solutions I can think of:
- implement the scrollviewDidScroll delegate method in you UITableViewController and constantly reposition tour toolbar within the scrollview to make it appear to always be at the top (the toolbar will probably jitter around and look terrible)
- create a new UIWindow on top of your entire app that hold the toolbar (don't do this, it is a terrible idea).
Related
(I have read other questions and answers on this topic, but most are very old and do not relate to iOS 9 or 10.)
The app design calls for the top half of the display to always contain the same content. (An image being edited by the user.)
The bottom half of the display needs a UITableView. When a UITableViewCell is tapped, the bottom section needs to transition to a new UIViewController with slide-on animation, similar to how UINavigationController push segues work.
Problem: only the bottom view needs to transition to the new view controller(s), and back again. The upper half of the view hierarchy needs to remain unaffected. For this reason, I can't place everything inside a UINavigationController, and I can't have a UINavigationBar at the top of the screen.
Question: what approach should I take in such a situation, where I need only one UIView hierarchy to transition in push-segue fashion, but not anything else? Thanks.
Edited with Solution
Solution follows, for those following along at home.
Yes, you can actually use a UINavigationController for the bottom half.
If you are using Storyboards, the easiest way to do this is to use a container view for each part of the screen which you then can embed a UIViewController in for the top part and a UINavigationController in for the bottom part. If you are doing this programmatically, just add the view controllers as child view controllers to your app's initial view controller (see this answer for more info) which is essentially what the Storyboard will do for you automatically when using a container view.
As a child view controller, the UINavigationController will act independently from the top UIViewController and should behave as expected.
I recommend the programatic approach for the following reasons:
It helps you understand the inner workings of child/parent view controllers much better which will likely save you a significant amount of debugging time down the line.
It makes adding/removing/swapping child view controllers as simple as a few lines of code. Trying to do this with Storyboards is notoriously hacky and cumbersome.
It's much easier to keep track of changes using GIT (most mid-size/larger companies actually prohibit Storyboards for this very reason)
If you want change in part of the screen you can use container view. For details refer Swift - How to link two view controllers into one container view and switch between them using segmented control?
You can use multiple view in one view controller and can give animation like push or pop to show or hide it.
Second approach is you can use Container View which will give exact effect like navigation stack.
I have a view controller with multiple UIViews on it, made in two different ways, all sitting in a scrollview. The top one was added through storyboard, and was done so to make it easier to style and work with segues. The others are more of a newsfeed post type deal, and are dynamic, so they are programmatically added. When I travel to another ViewController from this one, and I'm not scrolled all the way to the top I find that when I return, my storyboard added view is moved up, and almost out of the screen.
How do I fix this? I feel like it has something to do with the scrollView or the fact that it was added in storyboard, since the other views dont move, just this one.
I'm fairly new to iOS development and I want to make something like the attached screenshot.
I've read the nested UINavigationControllers is not a good idea, if not impossible, so I'm more than willing to accept ideas on how to implement what I want.
On my second screen there are two views I want to switch back and forth between (NOT using gestures and push animated), while maintaining a static header and footer.
The only way I know how to do a push segue is with a UINavigationController, hence why I see the need for nested ones.
How do I implement this? I thought that in my second UIViewController I could programmatically create a UINavigationController and add it to self.view, but I ended up doing this:
self.subNavigationController = [UINavigationController alloc] initWithRootViewController:[someVC alloc] init]];
[self.view addSubview: self.subNavigationController.view]
But that only adds the view of self.subNavigationController to self.view, not self.subNavigationController itself.
Like I said, I could easily be way off base on how I should be handling it, any advice is appreciated.
OK, if I've got this right then what you want is an app where you can navigate between different views (like any other app).
This will use a UINavigationController (lets call this "nav1") and this is the bit that you're OK with.
However, you also want a view that will have a static navigation bar. i.e. as far as nav1 is concerned this is only a single part of the navigation through the app. It also wants to have two potential views in there. (the map and the table view) and it will have a static bar along the bottom too (in IB this is a ToolBar I think). Lets call this the "mapAndTableViewController".
You haven't said exactly how this works but you don't want swipe gestures between them. So I'm guessing you will have a button or something to swap between them?
Something like this...
http://www.youtube.com/watch?v=eg6vWGh67zk&feature=youtube_gdata_player
The way I've done this is to use a single view controller with a scroll view. On the scrollview set scrolling disabled and set paging enabled. This sounds odd but this removes the touch scrolling from the scrollview while still allowing code access.
Now, in the mapAndTableViewController you populate the left and the right hand side of the scroll view.
What you do here is now take the two view controllers... mapViewController and yourTableViewController and instantiate them. Then add the views of these controllers in to the scrollview left and right sides accordingly.
Essentially you will have THREE view controllers. One for the scroll view, one for the map view and one for the table view.
Without any further explanation from you I can't really help beyond this as I don't fully understand what it is you're trying to achieve.
Hope this helps...
In my view I am using a UITableView that is controlled by a UITableViewController on the top half of the screen. The remaining screen is used for a UIScrollView that contains a view that is controlled by the main UIViewController.
When I perform a pull down to refresh in the UITableViewController, (for some reason if the number of table entries is less than or greater than the initial load value, the UIScrollView in the main UIViewController's frame gets changed to the screensize...
Essentially it breaks my paging unless I reset the scrollview back to the intialized size...
I have no idea why this happens as the UIScrollView is not used in the UITableViewController. The only scrollview that is used in the UITableViewController is the UITableView's to handle pull down to refresh...
Does anyone know why the main UIScrollView's contentSize gets changed randomly when it shouldn't even been accessible from the UITableViewController class?
Thanks
Just tried it here, and I can't duplicate your experience. I'm guessing you have an unexpected or inconsistent view/controller hierarchy? Look at the controller of the table and scroll views' common superview. Anything fishy there? Remember: view controllers manage sets of views. Container view controllers manage other view controllers and have special rules (see: The View Controller Programming Guide, esp. -addChildViewController:, etc.).
I'd suggest opening a blank project and trying to recreate the problem in its simplest possible form. If it's magically fixed, what's different? If it's still giving you trouble, send us a link so we can see the details of how you have things wired.
Here is a screenshot of a view that I have right on my device.
The design issue that I am having here is that the top part of the screen is always going to be static - as far as its placement. The rest of the screen are a row of buttons added to this view programmatically. The arrows represent the idea that you could swipe in 4 directions(from top, from bottom, from left and from right) which would animate a new view onto the screen. This view is the same instance as the view before it. In fact all these views are the same instance but the buttons will be different.( i dont want to get too specific here.)
My design right now calls for pre-loading the views ahead of time. The data for each button for each view will be in core data. I will not know ahead of time how many views there are. One view might just have a view to the right that you can swipe in from the right and that view might have a top and bottom arrow - that would allow you to swipe from bottom or top that would be another view(same UIView subclass). So basically a tree of views.
I guess I am trying to figure out my options. A NavigationController is not really what i want because i have no need for a navigation bar, although in my mind it makes sense that i would have an array of view controllers here each with its view property pointing to each view that is allocated and then as i swipe i would bring in the appropriate view by using the view controller index.(through some animation code)
Another possible option would be UIScrollView but that seems cumbersome and may not be what i would really want.
One of the easiest setups would be to create a XIB file that would consist the top part of the screen and on the bottom an empty UIView that i would programmatically populate with the buttons(and their unique data). The problem that I am havign with this is, is how would i swap the views this way. I guess i could make the rootViewcontroller the first viewcontroller instance with the first view and then swap them.
I guess I am wanting to see if anyone had any questions or suggestions to come up with the easiest(most modular) approach to swiping in different views. Is using an array of view controllers the way to go?
A couple of thoughts:
This screams custom container view controller to me (if iOS 5 and above). See Creating Custom Container View Controllers in the View Controller Programming Guide for iOS.
You talked about using UISwipeGestureRecognizer. You could always contemplate UIPanGestureRecognizer, too. It's nice to have continuous gestures. Think about reading a book where the page swipe tracks your finger, but you can stop and go back, mid gesture. Sure, start with swipe gestures for now, but if your UX lends itself to it, you can always contemplate continuous gestures in the future.
You said that you're planning on "pre-loading the views ahead of time". Generally, given the limited memory capacity of mobile devices, you'd want to be more conservative than that. Maybe load the current view, and the four ones that you're likely to go to in each of the four directions (so that you can present them instantaneously), but leave it at that. Once you go to one of the four possible destinations, then go ahead and release the ones that are not reachable from the current one and tee up the ones that are.
One Xib is enough for you (for this part of your app anyway).
Don't use a UINavigation Controller. The NavController metaphor is one of a stack of cards. You don't have that data structure.
The general idea is one ViewController for one screenful of stuff. If you feel the need for two viewControllers (one for the top part, one for the bottom part) then you are going to have to look at custom container controllers, to ensure that the contained controllers receive their instance methods correctly (viewDidLoad, viewWillAppear, etc). An example container controller managing a pair of viewControllers is the iPad splitViewController. But I don't think you need to do this.
I suggest placing a scrollView on the lower half of the screen and using that to manage your data views. If the upper part of the screen also needs to change (under other conditions) you could even have two scrollViews, one up top, the other below. They can be paged, and contain views that are the exact size of the respective screen portion. They can share their single containing viewController as a common location for their delegate methods.
I can't really help you with more detail, as I don't have a precise enough idea what you want to achieve. Perhaps you should try and implement it one of these ways and come back here with more questions as your ideas become concrete. Start out with the simplest idea (eg scrollView inside a single viewController), only chuck it out when you find you have to break it!
update
following your comments, I do think a scrollView might work for you. I think that managing a stack of view controllers with a custom container controller (as Rob suggests) could get overcomplicated. You will have to create your own custom container controller, the pre-existing ones such as UINavigationController are not appropriate for your data strucure (from what I can gather anyway).
You won't need to manage tons of UIViews, in fact you only need 5 - one for the onscreen portion of the scrollView, one for the screen immediately left and right, and similarly for the immediate one above and below. You can reuse these views as you swipe, much the way that tableViews reuse their cells. The rest of it will be about manipulating your data so the right content is arranged in the views as they come onscreen.
See my answer to this question for some more ideas on this: UICollectionView horizontal continuous loop