I am trying to set up a UIPageViewController that swipes through three very different views. I need to have a UICollectionView, a UITableView, then another UICollectionView with a different format. Can anyone clarify, whether this is possible or not? I have been searching for the last couple days and have not found a definitive answer. I am not asking for someone to solve this for me, I simply want to know if I should give up and just go with a different approach.
Yes, it is possible.
From the UIPageViewController Class Reference:
A page view controller lets the user navigate between pages of content,
where each page is managed by its own view controller object.
You need to have a viewController for each page. I recommend you read here: https://developer.apple.com/library/ios/documentation/uikit/reference/UIPageViewControllerClassReferenceClassRef/UIPageViewControllerClassReference.html
You certainly can. The UIPageViewController is made to display different view controllers.
Try it for yourself, it's not that hard. You'll need to implement a UIPageViewControllerDataSource to return your different UIViewControllers, but that's about it.
Yes, you can have different views inside a UIPageViewController. That is the first line in Apple documentation of UIPageViewController
https://developer.apple.com/library/ios/documentation/uikit/reference/UIPageViewControllerClassReferenceClassRef/UIPageViewControllerClassReference.html
A page view controller lets the user navigate between pages of content,
where each page is managed by its own view controller object.
Below is method is used to set the view controllers to be displayed.
setViewControllers:direction:animated:completion:
For tutorials/sample-code, you can go through below:
https://developer.apple.com/library/ios/samplecode/MyImagePicker/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010135
http://www.appcoda.com/uipageviewcontroller-storyboard-tutorial/
Go through these links and then start coding your requirements. You will be good to go then.
Related
I'm just getting back into iOS development after a year or so away and am looking for a way to have a single view above or below a UITabViewController view. The idea is to have one ad view that is used throughout the app instead of one on each tab. The constant reinitializing of the ad view seems like it would be a lot of overhead so having one persist throughout would seem to be more effective.
I've searched for this but not found much of anything so even a useful link would be appreciated.
Thanks in advance,
Jason
I see several approaches here:
Since you are setting up your view hierarchy in your application's delegate, I'd suggest creating a separate UIViewController and managing it from your app delegate. That way you can show/hide it in the main UIWindow, without having to do much work.
You can subclass UITabBarController and show the ad in the visible view controller. This is more work, but your app architecture is arguably cleaner, because your app delegate doesn't get cluttered with ad-related code.
Another option is to look into a UIViewController category, where you can manage add related code. Not necessarily the cleanest, but it keeps the ads out of both your app delegate, and your tab bar controller. (You'd add the ad view as a category property via runtime level calls and associate objects, but that gets messy.)
I'd probably go with the first approach if it were me, but I could argue for either of the other two approaches, since an ad view doesn't really necessitate it's own view controller.
How about create a parent view controller and each view controller inherits from that parent view controller? Parent view controller has a ad view or table view, so every child view controller will has those two view as well.
Okay, after spending some time trying to create and manage a customer view controller for this I stumbled on the Container View Controller capability Apple added in iOS 5. I have no need to support iOS 4 or earlier so this works good for me. There's a good description of it here (unfortunately the author never wrote part 2 with a tutorial):
Container View Controller description
And a decent tutorial is available here:
Container View Controller tutorial
Between the two of these I was able to create a good setup with an AdViewController and BodyViewController (TabBarController) contained in a Container View Controller. This gives me all the capabilities I need (at least so far).
Till now, I've been using controller or controllers like UITabbarController, or UINavigation controller to manage the UiviewController hierarchy. however, in the current project, i've been presented with a situation where my friends are recommending that I do away with controller of controllers and instead instantiate sub-UIViewControllers within the RootViewController and keep them as attributes. My question is whether this is a good practice MVC wise and memory management wise? (this is for iOS 5.0 with ARC)
The project requires a screen to have a header, main content area, and footer. the header and footer present dynamic content, but are the same for all screens but in the main content area, different screens can be presented either transitioning in from the right (like navigation controller would do it) or would appear modally.
I've tried to stick to MVC with one ViewController managing one view hierarchy... the above seems to go against it, but it seems to help in the situation.. so is this the right way to go or am I missing some other more optimal way?? Pls help
Thanks for your help in advance..
Why even have to have references to the view controllers themselves if you can just keep a reference to the view they manage? Sure it breaks MVC, but I love being able to divide reusable interface classes and then simply add their view's as subviews. It works, so long as you are smart about the whole thing. Is there anything specific about this pattern you'd like help with?
Go through this blog..Hope it helps you,
http://borkwarellc.wordpress.com/2010/07/22/qff-kitchen-mvc-part-1/
I started to explore the UISplitViewController class with a new master detail project in XCode, and I would like to replace the detail view's content with another UIViewControllers. I wrote it in this way (self is the detail viewcontroller and controller is the uiviewcontroller which I want to replace the first one with):
self.view = controller.view;
My question is: is it a proper way, will Apple accept it? If it is not, how could I do it better?
I am also building an iPad app with Master - Detail View Controllers in a UIIntelligentSplitViewController. As UISplitViewController doesn't support well while changing to different orientations, using UIIntelligentSplitViewController solves the issue with orientation change. See more here.
I have read on one of apple documentation and also a in best practices that we should use Only one MasterView and DetailView Controllers in entire app, and write code in such a way that all data are loaded in these two views according to the object selected.
But loading all data in same detail view might be a lot of code. So, I am also in search for answer for efficiently writing code to load in same detail view controller. However currently I am implementing only two views to show net data.
If there is any other efficient way to accomplish it, please do mention. Thanks.
You could replace the detail view controller where it is setup in your app delegate "didFinishLaunchingWithOptionsMethod". Your method would probably also work but is creating unnecessary overhead. The auto generated code they provide default's to a navigation controller on the left and a view controller on the right but you can change that to whatever you need. I have a project where I have two navigation controllers.
I am trying to use a UIPageViewController to create a book app. Each page currently has its own viewcontroller and Nib and has its own set of unique features. I am not using Storyboarding since there are over 40 pages to the book app.
I have had a hard time finding out how to use NIBS (with their view controllers) with UIPageViewController. The UIPageViewController will switch to the desired viewcontroller/NIB, but will then not respond to any of the UIPageViewController gestures.
Is there an example of using the UIPageViewController with NIBs that might help?
Any thoughts? Thanks for your help!
This was a very nice tutorial: http://www.techotopia.com/index.php/Implementing_a_Page_based_iOS_5_iPhone_Application_using_UIPageViewController
As an added bonus, it deals with Xcode 4.2 details, like de-selecting storyboard on project creation.
My guess is that you forgot to retain your UIPageViewController object. That happened to me the very first time too! The result is that the initial page(s) display but you don't get gestures, because the page view controller no longer exists. Stuff the page view controller into an instance variable with a strong/retain policy right after you obtain it.
Yes. You can use nibs with UIPageViewController. Without storyboarding. See this:
http://www.ioslearner.com/implementing-uipageviewcontroller-programatically-without-storyboarding/
I have a design question. I have a scroll view that I want to use as a means of navigation. I.e. the user can slide between screens. At present, I am creating view controllers and putting their views directly on the scroll view:
aViewController.view.frame=CGRectMake(0,0,320,200);
[self.myScrollView addSubview:[aViewController view]]
Etc, for all 3 view controllers.
I know this isn't best practice. But I can't think of any other way of doing it. Ideally I would like to get the same behaviour as a navigation controller except the fact that I'll be using a scroll view. Any help would be greatly appreciated.
You have to be aware that this breaks certain UIViewController behaviors because these child view controllers do not get informed about interface rotation events and their viewWill/Did(Dis)Appear: methods will not work.
The alternative (until iOS 4.x at least) is to not use UIViewController subclasses for these subviews. You could easily create your own custom controller class (derived from NSObject) to manage a child view.
It's debatable whether that approach makes it easier overall, though.
I'm guessing what you're trying to achieve is something similar to this app?
http://itunes.apple.com/us/app/fanhattan-for-ipad/id436928538?mt=8
This app works in the same manner, using a scroll view for navigation. You can analyze that app, you'd get some ideas from it, i'm sure.