I am trying to create a segue/transition between two View Controllers that "slides" to the next View Controller. What I mean by "slide" is that it only moves as much as the translation of a pan gesture(similar to Snapchat). If you could help me with this or just point me in the right direction, that would be great.
That effect is achieved using custom interactive transitions, which were introduced in iOS7. Here are a few tutorials to check out:
See Custom Transitions Using View Controllers. https://developer.apple.com/videos/wwdc/2013/
http://www.thinkandbuild.it/ios7-custom-transitions/
http://objectivetoast.com/2014/04/14/interactive-transitions/
http://www.teehanlax.com/blog/custom-uiviewcontroller-transitions/
This one gives many examples of the effects that can be achieved. http://www.appcoda.com/custom-view-controller-transitions-tutorial/
When I was implementing this I found that, for reusability, it was best to have one subclass of UIPercentDrivenInteractiveTransition (which we'll call TransitionManager) that implemented the protocols UIViewControllerTransitioningDelegate, UINavigationControllerDelegate and UIViewControllerAnimatedTransitioning.
- Then, if you need to present a UIViewController modally with your custom transition: in prepareForSegue set:
destinationViewController.modalPresentationStyle = .Custom
destinationViewController.transitioningDelegate = TransitionManager()
- If you're using a UINavigationController it's even easier, all you need to do it set the UINavigationController's delegate to your TransitionManager.
Hopefully that should start to make some sense once you've gone through the tutorials.
Related
What is the best implementation of a tableview in Model View Controller?
I'm developing my app without storyboard, all programmatically .
Is it possible to implement a TableView in a UIView? I tried it, but If I implement the TableView in a view, when the controller recives a button action, I can't modify or access to the tableView of the View...
After that, I tried to implement the tableView in a ViewController and it works perfectly, but I don't know if this is a good implementation because I found the same problem when I wanted to implement a TextView/TextField with a Piker, for example.
My goal was to had a clean code of viewController with a views and controllers (of buttons etc) and now I find myself with a uiviewController with the view and multiples components when I wanted the components were in the corresponding views.
Thank you very much!
It is all possible, and the problems you are running into are not because of it being something that you should not do, but that it is something that inherently works slightly differently than before. To answer your question directly, I would implement the tableView as the modal view controller directly, either as a UITableViewController or a UIViewController that inherits the table views delegate and datasource (this method being chosen if you don't want the table view to use up the entirety of the modal view controller's space).
TableViews are simple to use, but understanding every detail of how they work will make you far stronger and able to use them in any of these scenarios. I am not going to write you a guide on their use, butcontinue studying them before you declare that anything "can not be done".
Knowing what classes to implement the delegate methods becomes very important during these different scenarios. It is often easiest to use textfields delegate's implementation in UITableViewCell's subclass rather than in the UIViewController they are in. This allows for a more modular creation.
I find that working with the storyboard allows for a much quicker learning curve, and also a time saver. The one excuse I will give you for working without a storyboard is if you have an extremely slow computer.
Since iOS7 we can create custom transition from view controller to view controller using UIViewControllerTransitioningDelegate which allows fine grained transitions.
viewController.transitioningDelegate = transitioningDelegate;
I discovered that when using storyboard we already had the opportunity to create custom transitions using a custom UIStoryboardSegue but it seems the only way to implement custom transition with a storyboard.
How can I implement a transition delegate while using storyboard ?
Check http://www.teehanlax.com/blog/custom-uiviewcontroller-transitions/.
The idea is to use - prepareForSegue: to set the transitioningDelegate and the modalPresentationStyleto UIModalPresentationCustom. Then your transitioning delegate will have to take care of the transition.
Check out the following example:
https://github.com/soleares/SOLPresentingFun
It's an implementation of the sample code for WWDC Session 218: Custom Transitions Using View Controllers. It uses storyboards.
Simple question, I've done a decent amount of exploration around custom navigation / transitions between UIViewControllers and am unclear about the following:
I'm looking for behavior similar to what UIPageViewController provides (non stack-based navigation forward and backwards through "pages" of content). But I want to be able to customize the transitions, and I want the transitions to be interactive linked to a custom UIPanGestureRecognizer.
It seems like the UIViewControllerInteractiveTransitioning protocol provides some of what I want (interactivity, custom transitions). But because transitions are invoked solely with presentViewController:animated: and dismissViewControllerAnimated: it seems like it's built exclusively for use with stack-based navigation (ie UINavigationController, UITabBarController, modal presentation). Ie it doesn't seem like it'll play nice with something like UIPageViewController.
If I use UIViewController containment to build a custom container similar to UIPageViewController (see in progress demo here) can I integrate the UIViewControllerInteractiveTransitioning protocol into this to drive the transitions? Or do I need to roll those on my own (currently I have a rough manual implementation of interactive transitions)?
I do a lot of custom animations in my apps that most developers shy away from because I use a lot of UIViewControlloer Containment in my work.
It's the simplest way to get the transitions that you're looking for.
Here's how I would go about it:
Create a base view controller; lets call it MainViewController. It will have references to all of the other view controllers and hold the logic for the transitions. It should also follow a protocol we'll define as ViewXControllerDelegate.
Create your other view controllers; lets call them View1Controller, View2Controller, View3Controller. Add an instance of each of them as private properties of MainViewController. In the init method of MainViewController, instantiate them and add their views as subviews of MainViewController's view. Should look something like this:
self.v1c = [[View1Controller alloc]init];
[self addChildViewController:self.v1c];
[self.v1c didMoveToParentViewController:self];
//Setup each subview so that its frame makes it off screen or
//On screen depending on the app state and where you want each
//subview to animate to/from
[self.view addSubview:self.v1c.view];
....
Setup up a UIPanGestureRecognizer in each of your ViewXControllers that has its target and selector set to the parent view controller (MainViewController).
Handle all logic in your MainViewController class where you take the distance swiped, application state, the locations of each of the views into account (using helper properties in the ViewXControllers like "inactiveFrame" or "activeFrame" where the animation between them happens based on the percentage of movement that's occurred in the pan gesture.
I have implemented Facebook type left Slide Bar layout in my first view of iphone app. Now, I want to implement this throughout all view controllers (screens) in application, means irrespective of the view the left slide bar should appear on clicking the menu button at the top in all views.
My app contains 25-30 viewcontrollers and my slide bar layout should appear in all views..
Can anyone suggest, how can I include above FB Layout in all views
Thanks in advance
Ramu
Simple, The one view controller in which you have implemented the FB layout and is working. Make it the base class on top of UIViewController. And as for the rest of all the ViewControllers, inherit them from the MasterClass that you just created. Doing this will make the swipe gesture that brings forth the slide bar available to all of your 30 view controllers.
EDIT
Lets see, we have UIViewController, now first of all you create a UIViewController's subclass: say FBViewController ..In this FBViewController you implement the FBLayout such that the swipe and all is working ..on it ..test your app first using only this FBViewController as rootViewController and check all the functionalities.Once everything is working fine, grow on it. What I mean is this.
Say you are creating a Tabbed application, where all the three tabs are supposed to have the same FBLayout style. Then do these steps.
Create FBViewController, it inherits from UIViewController (using UIViewController subclass template, also check the generate XIB button) also have an XIB for it FBViewController.XIB (fully implement FBLayout in it. This will be your base class)
Then Create three more ViewController classes (FirstViewController, SecondViewController, ThirdViewController) again from the UIViewController subclass template, but for these three dont check the generate XIB button. these three will use the XIB of the base class FBViewController (If you are wondering how, then go to step 3 :))
Go to header file of FirstViewController class you created, there you can see #interface FirstViewController: UIViewController replace it with #interface FirstViewController: FBViewController, but before it import FBViewController.h to the header file. Repeat the same for the Other two classes- SecondViewController, ThirdViewController. Since these three will inherit from FBViewController. In their viewDidLoad [super viewDidLoad] will load FBViewController and generate the view. after [super viewDidLoad]; line you can implement ur own methods.
In the three classes just change the initWithNibName method to change the tab bar name and title.
In appDelegate go to didFinishLaunching method and put these three view controller in a tabBarController, set the tabBarController as rootViewController.
And we are done. If your FBViewController is working fine. You will see that all the three classes behave the same way. Thanx to the power of Inheritance.
Cheers, play a bit, have fun.
I had the same problem. I was using a facebook-style menu, and needed it in all view controllers.
You can use a Container Controller. A Container Controller can have the base layout, which I defined in a nib, containing a navigation bar and a bar button item to toggle the menu, and then add child view controllers and remove them as you need them. That way, you can throw whatever view controller you need to the container controller and it will display it.
You can also add gesture control to slide open/close the menu easily.
You will have to make the Container controller your self, it is not standard. I think it is better solution than inheritance, since if you use inheritance you can't make a for example UITableViewController, all your controllers will be of the type of yuor master class. Of course, you can fix this anyway with delegates.
It may sound a bit tricky, but see this tutorial which I used: http://www.cocoanetics.com/2012/04/containing-viewcontrollers/
It wasn't accutally that hard.
EDIT: You can just use a UINavigationController as well. Just set the base view controller to the view controller you want to display, and you can prevent it adding the back button etc to the nav bar by overriding the default methods. Make a UINavigationController as rootNavigationController. Might be simpler.
I'd highly recommend using an open source solution that handles all the edge cases for you - it's both the easiest, most robust and most maintainable (since the community will keep it up to date fro you). ViewDeck seems to be the most popular solution though I have also had success with PPRevealSideViewController. They both provide a very robust implementation that would take a long time to do yourself (e.g. you can optionally enable swipe on the navigation bar or even content area to open the menu). Furthermore they separate the sliding logic and the revealed menu (which can be any view controller you like, but most likely a table view controller) out of your other view controllers. That way any viewcontroller can have a side menu without duplicating any code - separation of concern is great :)
You can make a SharedInstance for SideView class. I am doing same thing for iAD to show throught-out the application.
Please see the the link of iAdSuite ,In which the BannerViewController is SharedInstance so they are easily used for all View Controller
http://developer.apple.com/library/ios/#samplecode/iAdSuite/Listings/TabbedBanner_TabbedBanner_BannerViewController_m.html
I have always sort of wondered when to use a UIView vs. a UIViewController on the iPhone.
I understand that you shouldn't use a UIViewController unless it's a full-screen view, but what other guidelines are there?
For example, I want to build a modal overlay - a screen that will slide into place over the current screen. If this modal overlay is full-screen, should it be a UIViewController? The last time I built something like this, I subclassed UIViewController, but now I wonder if that was correct.
From Apple's View Controller Programming Guide for iOS:
"The most important role of a view controller is to manage a hierarchy of views. Every view controller has a single root view that encloses all of the view controller’s content. To that root view, you add the views you need to display your content."
Also:
"There are two types of view controllers:
Content view controllers manage a discrete piece of your app’s content and are the main type of view controller that you create.
Container view controllers collect information from other view controllers (known as child view controllers) and present it in a way that facilitates navigation or presents the content of those view controllers differently.
Most apps are a mixture of both types of view controllers."
This is a great question.
My basic rule of thumb. Is that every major 'page' of an application gets it's own view controller. What I mean by that is that during the wire framing stage of application design, everything that exists as its own entity will eventually be managed by its own View Controller. If there is a modal screen that slides over an existing screen, I will consider that to be a separate 'page' and give it its own view controller. If there is a view that overlays and existing page (such as a loading screen or help popup.) I would treat those differently, implement them as UIView subclasses and keep the logic in that 'pages' view controller. It the popup has behavior I will communicate back to that pages View Controller using the delegate pattern.
I hope this helps. It is very much a philosophical and architectural question and much could be written about it.
I use UIViewController whenever a view is full screen and either has outlets/actions and/or subviews.
Put everything on a screen into a UIViewController until the view controller starts to have too much code, then break out the screen into multiple UIViewControllers contained by one master view controller...
To put that into context of your answer, make a view controller for that modal overlay. It will have one anyway if you are using a nav controller to present it (and you probably should).
I have a somewhat different approach:
Override UIView if you plan to do custom drawing in drawRect. Otherwise, subclass UIViewController and use [self.view addSubview: blah] to add the components of the page.
There are a few other special cases, but that handles about 95% of the situations.
(You still will often need a UIViewController with a custom UIView. But it's common to have a custom UIViewController with no corresponding custom UIView.)
Is the thing that slides in a self contained screen? I mean, does it directly interact with the parent? If so, make it a UIView, if not, probably recommend a UIViewController.
A UIView is part of the UIViewController see the view property of UIViewController for this. As you pointed out correctly UIViewController manages a complete screen and there should be only one visible UIViewController at a time. But in most cases you will have more UIViews or subclasses of UIView visible on the screen.
The example you gave would be a correct use in most cases. As you may have noticed you will get a lot of functionality when subclassing the UIViewController. Animating the appearance and dismissal of the UIViewController would be one of them.
As marcc pointed out if the thing you want to slide in is not a self contained screen you would be better off using a UIView.
As a conclusion I would say that if you want to use the functionality that comes with subclassing UIViewController than go for it make it a UIViewController. Otherwise a UIView might be better.
The itunes U Standford class has a great lecture on UIViewControllers I would recommend watching it, because it has a lot of information regarding UIViewControllers in general.
If you are familiar with the MVC pattern, then you should be able to understand the difference between UIVIew and UIViewController. To make a simple statement, UIView is for rendering UI elements on screen. UIView is the superclass of pretty much all Cocoa Touch UI elements. Those elements do not know what information they are supposed to display, what they should do when a user clicks a button, what happens when an async network request is completed and so on. UIViewController is for all that and more. The view controller is responsible for placing the UI elements in the correct locations on screen, setting the contents of the UI elements, handling button presses and other user inputs, updating the model when needed etc.
Conceptually, a single UIViewController controls the contents of the whole screen in an iPhone App and that is why it is often easy to think of things in terms of view controllers. If you need a view where the user can select ingredients for a food recipe, you'll need a UIViewController for that. I made this distinction for myself because coming from a Java background I wasn't used to the framework enforcing MVC. I would think of things in terms of UIViews, and start implementing them that way and then run into all sorts of trouble because of that. If you are going to stick to UIKit for your App, then the workflow Apple has made for you is: for each separate view in your App, create a UIViewController subclass and then use Interface Builder to place the UI elements and to create connections for buttons etc. It works wonders, saves a ton of time and lets you concentrate on making your App function well.
I use UIViewController for showing View on full Screen.
For better control on custom view I prefer subclass of UIViewController instead of UIView, earlier I was using UIView for making custom sub class.