I have the task to design a application that has a main view which is always visible (it has a button on it's bottom side, and when pressed a image displays on top of all views), and a set of TableControllerView's that should appear under it, and the user needs to be able to navigate through them.
I know that you can embed a view inside another, but you cannot refer more than one view to it. The current way I'm trying to do now load one TableViewController inside the embed view, and when the user clicks the cell I manually load the other controller and add it as a child of the main view, which is the RootViewController. The problem with this approach is that the navigation bar gets stuck using the root view controller, so I have to manipulate the main navigation items on each subview transition, and second is that the frame for the second view I load is coming as it had full size, making some cells be under the main view button. This way doesn't uses segues for transition, so it makes the storyboard kinda useless.
I was thinking into using a TabViewController with it's tab hidden, but wanted to ask here for a better solution.
As you discovered, a TableViewController likes to fill up the whole screen (except navigation bars, tab bars, status bar, etc. which are official Cocoa Touch GUIs). When you want a table view to fill only part of the screen, you are supposed to use a UITableView but not a UITableViewController. You set your custom view controller object (subclass of UIViewController, not UITableViewController) as the table view delegate and data source. You will need to duplicate part of the functionality of UITableViewController in your custom view controller, but it's not a lot more than you have to do already to supply the data.
You should probably follow the standard design pattern and have separate view controller objects for each of the "pages" the user can navigate to. You just have a main button and image on each of them. But I could imagine why that might not give you exactly the effect you want.
Related
I am trying to create a two ViewController solution where a modal view controller is presented over a UICollectionView while allowing the user to interact with the CollectionView. In this case, it is like an advanced picker, allowing the user to choose items that will populate the properties in the modal view before saving a record.
I have a presentation controller setup to present the view how and where I want, allowing full visibility to the parent view. Nothing I have tried will allow the user to interact with (scroll, tap, etc) the UIController view.
In view debugging, I see a UITransitionView that has a frame equal to the full screen. (see image) I suspect that this is the culprit. Is this even possible in iOS?
The whole point of a modal view controller is that it takes over the screen and demands that the user respond to it before doing anything else. It puts your program into a "mode" that must be dismissed before the user can go on. That is the core reason for being of a modal dialog.
If you can interact with the view controller underneath the the top view controller is no longer a modal.
What you are trying to do is wrong from a human interface standpoint, and not supported by the application framework. You need to rethink your design.
Edit:
Top-level view controllers are not designed to share the screen. If you want another view controller to cover part of the screen while the user can still interact with the view controller underneath then you should use a container view as #МаксудДаудов suggests in his answer.
I would probably put a container view on top of the rest of my view controller's content, control-drag an embed segue to the child view controller I want to display, add an outlet to the container view, and then hide the container view.
When you want to display the "picker", you could then un-hide the container view, which would reveal the child view inside and let the user interact with it, while still being able to interact with the other components in your main view controller.
There is no way allowing presented full screen view controller to interact view controller under that. Instead , add your second view controller at containercontroller at some part of first, and change first VCs collection view frame accordingly, to be able see all the list. Doing this, you will have two view controllers working together
I have an application with a drop down menu as the titleView of my NavigationController. When a user selects an item of the drop down menu, the entire view should switch contents, however, the NavigationBar should remain the same. The NavigationBar should not have to reload any data and the titleView should remain a drop down menu.
The original view upon opening the app:
The view upon touching the dropdown menu:
I currently see a few ways of going about this:
Set up a UIViewController for each option, perform the segue, and reload the data.
Why this is bad: I will have to set up a segue identifier for each ViewController, meaning if I have 15 options in my drop down menu, I will have 210 segue identifiers laying around. I will also have to reload all of my NavigationBar data.
Why this is good: I will have a clear area to set up each individual view.
Programmatically add and remove UIButtons, UILabels, and UIWhatevers as I need them.
Why this is bad: This will create a lot of code inside just one ViewController and things could get difficult to debug.
Why this is good: The NavigationBar never gets reloaded.
Add a container and embed a unique ViewController for each item as I need it.
Why this is bad: All of my work would still be in the main ViewController and I'd have to manage the logic of the embedded ViewController inside one Controller.
Why this is good: The NavigationBar never gets reloaded.
A completely different method suggested by someone else because I don't know the most efficient way of doing this.
So, in conclusion, what is the most efficient way to maintain state of my NavigationBar when switching my main content in my View?
Option 3 is the best out of the three you listed. Options 1 and 2 will get more and more complicated the more view controllers you want to add. Compare that to UINavigationController, UITabBarController, or UIPageViewController which do not need to be more complicated in order to handle 10 screens vs. 100 screens.
I would suggest creating a custom container view controller (Apple's Reference)
I see 2 immediate approaches to implementing this:
Subclassing UIViewController - this is how Apple's container view controllers are implemented
Subclass UITabBarController - I have done this successfully, subclassing UITabBarController to show a custom tab bar at the top instead of along the bottom.
I have this problem and I can't seem to find the answer so I asked here. I need to overlap 2 UIViewControllers. It is in a navigation controller. Each Controllers is using xib files as view since I am not using storyboard. It needs to be overlapped since the first controller is on live feed and I cannot afford to use a screenshot for background to make the live feed stay on while the user is navigating on the second controller. Any Ideas?
try content views doc tutorial
and the VC which you want to overlap, you will not keep it in you navigation stack, you will have to make overlapping VC, child of the VC on which you want to present it, after making child you will add child VC's view as a subview to parent's view. in that way both view controllers will appear to be overlapping
I'm trying to create a tabbed application with navigation elements inside the tab bar, as seen in the picture below (the red bar) using Swift/XCode 6.2. Basically those three icons in the middle will direct the user to different view controllers. The other two icons would be context-based. For example, on a table view page you would see the menu icon and add new icon as seen in the image. However, clicking on a row would change the menu icon to a back icon, and the add icon to something else.
That's the general idea, but I'm having a very hard time implementing something even close to this. The first issue is that whenever I embed a view in a Tab Bar Controller, I can't move the tab bar to the top. However, when I create a custom UITabView in a View Controller, Control + Click and dragging a Tab Bar Item to another view doesn't create a segue. I haven't even begun to tackle having the navigation elements inside the bar.
I guess what I'm asking is just for a little guidance on what route to take to tackle this. I'm assuming I can't use a Tab Bar Controller or Navigation Controller because it doesn't seem like I can customize them all that much. So custom Tab Bar and Navigation Bars, and then implemnt the segues and button changes programmatically?
Thanks.
I will try to guide you from an architectural perspective (so you won't find much code below).
Using a UITabBarController
In order to achieve what you are suggesting, you are right you cannot use a UITabBarController straight away, among several reasons, the most immediate one is that they are meant to be always at the bottom and you want it in top (check Apple's docs). The good news is that probably you don't need it!
Note: If you still want to go with a UITabBarController for whatever reason, please see #Matt's answer.
Using a UINavigationController
You can use a UINavigationController to solve this task, since the UINavigationBar of a UINavigationController can be customized. There are multiple ways on how you can organize your view's hierarchy to achieve what you propose, but let me elaborate one option:
To customize a UINavigationBar's to add buttons, you just need to set its navigationItem's title view:
// Assuming viewWithTopButtons is a view containing the 3 top buttons
self.navigationItem.titleView = viewWithTopButtons
To add the burger menu functionality on a UINavigationController you can find several posts on how to do it and infinite frameworks you can use. Check this other SO Question for a more detailed answer (e.g. MMDrawerController, ECSlidingViewController to mention a couple).
About organizing your view hierarchy, it really depends on if when the user taps one of the main top buttons, it will always go to the first view controller in the new section or if you want to bring him back to the last view in the section where he was.
3.1 Switching sections displays the first view of the new section
Your app's UIWindow will have a single UINavigationController on top of the hierarchy. Then each of the 3 top buttons, when tapped, will change the root view controller of the UINavigationController.
Then, when the user changes section, the current navigation hierarchy is discarded by setting the new section view controller as the UINavigationController root view controller.
self.navigationController = [sectionFirstViewController]
3.2 Switching sections displays the last displayed view in the new section
This will require a slightly modified version of the above, where your each of your sections will have its own UINavigationController, so you can always keep a navigation hierarchy per section.
Then, when the user taps one of the top buttons to switch section, instead of changing as previously described, you will change the UIWindowroot view controller to the new section's UINavigationController.
window.rootViewController = sectionNavigationController
Using a custom implementation
Of course, the last and also very valid option would be that you implement yourself your own component to achieve your requirements. This is probably the option requiring the biggest effort in exchange of the highest customizability.
Choosing this option is definitely not recommend to less experienced developers.
I'd like to take a stab at this--I think it is possible to use a tab bar controller here.
Your topmost-level view controller will be a UITabBarController with a hidden UITabBar.
Each tab is contained in a UINavigationController.
All view controllers in the navigation controller will be a subclass of a view controller (say, SwitchableViewController).
In SwitchableViewController's viewDidLoad, you set the navigation item's title view (i.e. whatever's at the center; self.navigationItem.titleView) to be the view that holds the three center buttons. Could be a UISegmentedControl, or a custom view.
Whenever you tap on any of the buttons, you change the topmost UITabBarController's selected index to the view controller you want to show.
Issues you may encounter:
Table views inside tabs will have a scrollIndicatorOffset at the bottom even if the tab bar is hidden.
Solution: Play around with the automaticallyAdjustsScrollViewInsets of the tab bar controller, or the inner view controller. https://stackoverflow.com/a/29264073/855680
Your title view will be animated every time you push a new view controller in the navigation stack.
Solution: Take a look at creating a custom transition animation for the UINavigationController.
I understand that view controllers help control multiple views in an application, but I have trouble understanding when to use them.
If I have an application with a main page, several views with a "hierarchy" structure, and an about page not connected with the hierarchy, what files should my application have? An appdelegate, navigation controller and view controller? More than one view controller? Just a navigation controller?
Also, should they all be contained in one .xib file, or multiple .xib files?
Any help would be greatly appreciated.
Thanks.
A good habit is to have a UIViewController for each page you want to show. If I get the structure of your app you should have a main page (with many other UIViews inside it) and another page (about page). If that's true I suggest two UIViewControllers.
The UINavigationController is a subclass of UIViewController that lets you "navigate" among the pages. It's not strictly necessary but suggested (you can also implement your self a custom navigation system, but it's easier to exploit the one Apple offers you). Another navigation system is the one based on UITabBarController, if you want to take a look.
Assuming I get the structure of your app you should need two .xib file, one for each page you have.
The app delegate is conceptually different from a view controller, you'll have just a single app delegate, automatically created by Xcode (you can, of course, modify it to fit your needs).
Each "screenful of content" (Apple uses this term) should be handled by it's UIViewController or more likely a subclass of it. The point of view controller is to handle view appearing or disappearing (going on/offscreen), device rotation, memory management, navigating to other view controllers and so on. If you are creating your UI with IB, then each of those view controllers would most likely have it's own .xib file.
Each view controller has one view (it's view property) that acts as main view for each "screenful of content" to which you then add your subviews.
UINavigationController and UITabBarcontroller are there to help you control the hierarchy of your app. They only act as containers for other view controllers and don't contain any UI except navigation bar or tab bar. Using tab bar controller you can have multiple view controllers which act exactly like browser tabs. Using navigation controller you can have a stack-like navigation where new view controllers are pushed from right to left and are popped from left to right when user goes back to previous view controller. You can even have a view controller inside navigation controller inside a tab bar controller.
If you don't want to use tab bar or navigation controller, you can navigate through your view controllers by presenting them modally using presentModalViewController:animated: and dismissing by dismissModalViewControllerAnimated:. If you send YES for animated parameter of these methods, you will get an animation specified by the modalTransitionStyle property of view controller being presented or dismissed. Possible animations are slide in from bottom (default), horizontal flip of entire screen, fade in/out and half-page curl.
There are also some Apple-provided subclasses of UIViewController that help you setup your UI quicker like UITableViewController which is basically a view controller that contains a table as it's main view and conforms to 'UITableViewdataSourceanddelegate` protocols which are required to define how each cell looks and what it contains.
On iPad there is one additional container controller UISplitViewController and one additional way to present new view controllers using UIPopover.