New to Swift. I've seen many tutorials on using PageViewController, but they always have the Page View taking up the whole screen.
I'm trying to implement a Page View functionality in only PART of my app, not the entire screen, so that other "static" elements (e.g. a ToolBar) can remain. Something that would look kinda like this...
https://imgur.com/9wM1vll --- (Need more rep. before embedding images)
...where swiping will cause different images to appear as seen in various PageViewController tutorials (e.g. http://www.appcoda.com/uipageviewcontroller-storyboard-tutorial/).
When I start with a Single View Application, I go to Storyboard and try to drag a "Page View Controller" from the Object Library into the ViewController frame, it just "bounces back", i.e. it won't let me add the Page View Controller.
Now, if I add the Page View Controller to the white space around the other View Controller, then this gets back to the tutorials where the PageViewController takes up the entire screen and I don't want that.
How does one achieve this?
Thanks.
Sorry if this is a dupe but I have tried & failed to find anything that answers my question directly. The closest are Implement PageViewController in TableViewController details or Adding a UIPageViewController to a subview, subview only shows edge of pageContentview, but these are not similar enough for me to comprehend, plus they're in Objective C which I've not yet learned.
When I start with a Single View Application, I go to Storyboard and try to drag a "Page View Controller" from the Object Library into the ViewController frame, it just "bounces back", i.e. it won't let me add the Page View Controller.
A page view controller is a view controller. Thus, to make its view occupy only part of the screen, you must obey the rules for view controllers in general: you need a custom parent view controller, and the page view controller must be its child view controller — and you must do the elaborate dance that this entails when you create the child and put its view into the interface.
To get the storyboard to do the dance for you, use a Container View and hook it by its embed segue to the page view controller:
(Still, in my opinion it is always better to learn to do the dance manually, in code, yourself.)
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.
So here is the problem I am trying to solve.
In each viewController I am trying to insert ads and the actual control elements. I finished couple of tutorial on raywenderlinch.com to understand that how people professionally put ads in their app. They used UIViews to have two views under mainview of view controller. So I completely understood that one subview hold the ads and another is holding actual app contents. if Ad is loaded take up the screen or else let other view have all available area.
After I came back to xcode I started coding the way I learned there. but when I was dropping UIView on storyboard, I saw containerView, which I think was not present when the tutorial was written.
So I am here to ask about the both approach and their pros and cons.
So basically its UIView vs ContainerView. Which way I should do, and why ?
Any help would be greatly appreciated.
You use UIView when you already have a view and you do not need to have a dedicated view controller to build and handle interactions within it.
From the UIView help page:
UIView object claims a rectangular region of its enclosing superview (its parent in the view hierarchy) and is responsible for all drawing in that region ...
Simplified structure:
YourViewController ---(has)---> UIView
You use UIContainerView when you need to embed another view controller in the one that you already have. The embedded view controller is in charge of returning a view for the region that the UIViewContainer occupies. Therefore, your UIContainerView knows which view controller to use to render UIView inside the region it occupies.
From the UIContainerView help page:
Container View defines a region within a view controller's view subgraph that can include a child view controller.
Simplified structure:
YourViewController ---(has)---> SubViewController ---(has)---> UIView
That SubViewController returns a view and handles its events.
As an alternative answer, you can also consider the use case instead of the technical differences. For example: Why use a container view?
A common use for container views is to reuse (share) a view, directly in the storyboard. Previously, reusing a view required creating a separate "xib" file, and programmatically adding that view when the view controller was loaded.
The above image is from this extremely simple, easy to follow guide that walks you through how to setup a container view that is shared between 2+ view controllers.
A few other thoughts on when to use it:
A navigation bar is part of a UINavigationController, which is a container view controller. So, if you wanted to build a custom alternative, you'd probably use a container view.
A container might help anytime that you want to temporarily show a complex view on top of your current VC but can't/don't want to present another VC modally. This approach still allows you to build that temporary view in interface builder, to setup auto layout constraints for it, etc
I also found a guide explaining that there's a way to switch out different container views based on the situation, allowing your VC to have sub-sections which are very dynamic, yet without having to build those sub-sections programmatically. A picture, from that guide, exhibiting what I'm referring to:
Hopefully this helps people who are trying to figure out when a container view applies to them. If you have other example use cases, please edit/add them or leave them in the comments!
If you see in detail these container view of UIView class type. To get the insights of why we need containerView you should see below portion
In most ways, a container view controller is just like a content view controller. It manages views and content, coordinates with other objects in your app, and responds to events in the responder chain. Before designing a container controller, you should already be familiar with designing content view controllers. The design questions in “Creating Custom Content View Controllers” also apply when creating containers.
for more detail about container view goto link
But before you begin you should have an understanding of
and also you can check this tutorial for how to use container view.
Thus you can go for both the approaches.
Hope this will help you. happy coding :)
Our app has some upper view, that is visible all the time.
This bar has a UITextField, UIButtons, side scroller, and segment control, and they are dynamic.
When you hit them, the view behind them(full screen) is changing.
I was thinking about navigation control, or tab bar, but seems that they can't have a text field and a scroller on them.
So my main thought was to create some COSTUM view of my own.
Question is , how can I create a view in storyboard, and add it as a constant view, than create some other views(+viewcontrollers) that will be changed according to that upper bar?
I want to create 5 views in storyboard, and switch between them according to the bar.
Sounds like a job for a containment view controller to me. I've used technique many times to both create a set of static controls on the screen which you describe and inject reusable content into an app in several locations.
The basic concept is:
Setup you Heads Up Display(HUD) with all the UI you want (this will be your base UIViewController).
Create a UIView in it and call it your contentView or something of the like. This is where all your dynamic content will appear.
Then your backing view controller adds another UIViewController as a child and tell it to show it's view in the contentView you specified.
Your view controller continues to remove and add children putting their content into the contentView as needed.
If you are unfamiliar with the technique there are many tutorials(by NSCookbook) of do a web search for "view controller containment tutorial". There is also a good WWDC (2011) video introducing the concept Session 102 - Implementing UIViewController Containment.
Note: I'm not talking about custom view controller transition effects which can be done by using a custom view controllers it's the iOS 5+ API.
I'm talking about transitioning to another view controller, where a view from the presently displayed view controller is animated to the view controller to be presented's view.
EXAMPLE
-you have friendsViewController which displays a list of the current users friends. Each table view cell has a profile picture and name.
-click on a cell, all other cells fade away and the name and picture animate to the top. At this point, UserProfileViewComtroller is displayed.
THEORIES
-I could easily do this by combining the two view controllers, but UserProfileViewComtroller can be launched from other parts of the app.
-if the UserProfileViewControllers view is instantiated, I could convert the coordinates using UIViews methods
I feel like there is a more appropriate/cleaner solution here which is why I'm asking the community for help :)
It seems to me that what you want is exactly about view controllers transition, since you want to do 'something' that would look to the user as if you took a view from old VC and moved it to the new VC.
Then you're in luck, as you're allowed to move a UIView from one view controller to another using [superview addSubview:view] as part of the transition you want to do.
This can be done on any iOS version, although it's easier now as in iOS 7 there's a delegate you write (see <UIViewControllerAnimatedTransitioning> reference) which has access to both VC's view hierarchies and can change them at will (move one view, fade other views) during transition period.
Also, making your new view controller during the transition transparent (or using old controller's snapshot) will help you hide the fact that VC changed.
Not so much an answer but a technique that might inspire a solution. I did an app that had need for a custom transition like this. The original app arranged itself then took a snapshot, so at the last moment the user is looking at an image. The second viewController was created, given coordinates etc, and the image, then shown immediately. It put the image into its view (subview with same bounds).
At this point the second vc has complete control, and can fade in some other content etc. the reverse was more or less as the start - the image is used, swapped, used removed to uncover the real view content.
Note that this took a bit of time to get it working with no glitches etc.
EDIT: if you are concerned in turning the whole original view into an image, then modify the technique. For instance, in the original view, fade all other content to black but the cell, then snapshot the one cell. The second view will start with an all black background, and place the cell image over top it, then go from there.
EDIT2: As mentioned in the comments, you of course push the second view with no animation, so it happens instantaneously. By setting a small image on the second vc, with an agreed upon background, you can quickly "pass the baton" so to speak and let the second controller go to work quickly and seamlessly.
I'm keeping on developing an iPhone app (rigth now native one) and I would need to use a common "header" for all views but I don't want/need a UINavigationBar and prefer much more have a common "partial view". It will have some actions to perform but always the same ones (showing notifications panel, basically). It should be something like you can see in the screenshots.
I don't need (I feel) delegation because the controller's view can handle notifications and show them when user clicked the customize button.
I don't mind to use a Nib o make the view hardcoded but I'm not sure how I must make an instance of the view or the controller that handles it within each app tab (I'm using UITabBar as navigation control).
From my point of view it doesn't exist a way to get a common controller to call wherever needed; you just can use some method to present new controller as modal o push it out and I think that is not what I'm looking for.
Any idea is welcome. Thanks
Create a custom view controller with 2 subviews. Subview 1 is the header. Subview 2 is the container view where child view controllers are displayed (your tab bar controller in this case).
Your custom view controller could be the delegate of the tab bar controller if you want, so it can be notified when the tabs change and update anything on the header view.
Well, finally is have used the solution I found on the link http://patientprogrammer.wordpress.com/2012/03/12/re-usable-subviews-in-ios/
I have created a Nib with a view controller and then, in the main window I have added two view, the top one subclasses the view controller for the Nib view and it is rendered automatically when app is launched without a single line of code within "main" controller. See the screenshots for more detail:
Thank you very much for your help