In general, I've heard its better to use composition than inheritance, but it's not always clear to me how to do that. I want to create some functionality that's common across all of my view controllers (I want to listen for an NSNotification, and call a method if it receives the notif).
My idea is to create a BaseViewController that each UIViewController extends from. I'd love to solve this any other way than inheritance for many reasons
Some view controllers extend UIViewController and some extend UITableViewController
If I write it in swift, objc view controllers can't subclass it
Normal reasons for comp over inheritance - easier to understand the behavior
My question is - how do I accomplish this without copy and pasting a ton of code into each viewcontroller? I could obviously insert a line into each view controllers viewDidLoad method, to add a listener, and into each view controllers delloc, but I'd really rather avoid this. Is there other techniques that could make this cleaner?
In Swift 2.0 you can use protocol with default method implementations. But in this case is inheritance the best approach for me.
According to me, it will be better to implement some functionality which is common across all ViewControllers by using Singleton Class.
Create a simple swift file having Singleton class in it and implement common functions in it which you want to access anywhere. Create a shared instance for that class and by using this shared instance, you can call any function in any ViewController of your application. So that you can reuse the code without copy-paste.
Related
I need to send an object (data) from a view controller (embedded in a navigation controller) to a class (or struct) which should manage this data.
How can I get a reference to this viewController from the class (which has no link of any kind (no segue), or better the struct) with the set of viewControllers in order to implement a delegation protocol?
I use swift, a storyboard, and I look for any pointer or documentation which could help me to understand how to address this problem. I'm a beginner and I am sorry if this question is far too trivial.
I just need a link to appropriate documentation, many thanks.
This answer might help you. You might wanna read up more on delegation pattern in iOS.
https://stackoverflow.com/a/42977875/2396199
Recently I've been looking into RESideMenu. What really piqued my interest was his 'UIViewController+RESideMenu.h/m'. It appears to me that this is a way to subclass a UIViewController. It includes IBActions and methods in it that are accessible from anything that inherits from UIViewController.
All of my attempts to replicate this have failed. Is there a special way to go about it?
Usually that sort of classname is used to denote a category. Instead of subclassing it adds additional methods and properties to a class. For more information see here: CustomizingExistingClasses
I'm currently trying to build my own Custom ContainerViewController.
I'm quite familiar with the iOS ViewController containment API (introduced in iOS 5) and the new iOS7 ViewController Transition API.
While implementing my container, i tried to utilize the same patterns UINavigationController and UITabBarController are using.
My Container is working well so far and using animated and interactive transitions properly.
The Problem is, i packed a huge amount of the logic into my UIViewController container subclass. It is conforming to <UIViewControllerContextTransitioning> and uses iVars to store all the values returned by that protocol's methods.
The animation and interaction logic is already separated in another class and third-parties are also able to provide their own transition using a delegate similar to UINavigationControllerDelegate and UITabBarControllerDelegate.
What I'm trying to do now is out-sourcing the UIViewControllerContextTransitioning to a separate class to create the same modularity Apple does for it's containerVCs.
Apple provides a UIViewControllerOneToOneTransitionContext (private API) for the id<UIViewControllerContextTransitioning> object handed to the UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning methods. So they are NOT using their UIViewController subclass for that. (That's what i do at the moment)
My current structure is in so far tempting to keep for me as when the transition logic calls [updateInteractiveTransition:], [completeTransition:], etc. on the context, these calls are made directly on my containerController which can then respond by updating other elements in it's view. (Like UINavigationController does when you call [updateInteractiveTransition:] and it's updating the content of the NavigationBar (cross-fade)).
Out-Sourcing the contexttransitioning logic in another class would mean:
Provide the viewControllers and frames, etc. which are hold in the stack of my container FROM the container TO the context object because the context needs to provide them to the transition logic.
Call transition-callbacks FROM the context object ON the container because the context object is the one receiving them from the transition logic.
As Apple uses this class-relationship, there must be some advantage about it, i guess.
Currently, i don't know if i should keep my implementation, or try to make it as modular as Apple-provided containers.
Also see this SO - Question where i asked the same thing. (More like an answer-question, sorry for that :/ )
While we're on the topic : Is it possible to make my container work with UIPercentDrivenInteractiveTransition ? The documentation says it cuts the animation executed by the transitionAnimator in keyframes and automagically "replays" the animated transition step by step, so i doubt it can be used with custom containers.
Thanks for your help !
Apple uses a lot of small classes conforming to certain protocols to hand over pieces of work. Divide and conquer. Have a look at for instance the way UITableView operates or collection view. They did split things into smallest chunks possible, and provided each one with some generic objects. These objects only conform to certain Protocols.
Do not force people to subclass.
Create protocols that classes fulfilling certain roles have to conform to.
Where you want to create ready to use objects that will perform certain actions - return id type of object, not a class object. That's the only way to keep things simple and flexible enough.
Apple does that even with NSObject, which is both a class and protocol.
When creating your own protocols, remember to make them conform to NSObject * protocol.
Your question is rather long, and does not ask any specific questions, so I hope this answers some of your concerns. If not, feel free to post one to response to this.
Okay, so my question itself states what i am asking.
I have a 3 view controllers. All the three of them are inheriting from a class (MainViewController).
Now what i want to ask is, is it possible in Objective C that suppose I have another class which has some variables and functions which i do not want to include in the MainViewController class, and pass this to one of the ViewControllers.
So if i number my view controllers, and let the other class be SecondClass.
1st, 2nd and 3rd ViewControllers inherit functions and variables from MainViewController.
If i want 2nd ViewController to inherit SecondClass also, then am i allowed to perform this kind of operation in Objective - C??
Objective-C is a single-inheritance language. Each class can inherit from exactly one superclass.
You can work around that with forwardingTargetForSelector: if you're absolute desperate but the neater and usually smarter thing is to compose functionality by saying that the second view controller owns an instance of SecondClass in addition to being a subclass of MainViewController.
You can see an example of Apple doing that in UIWebView. It isn't a subclass of UIScrollView but it uses a scroll view and exposes that instance (as of iOS 5) for outside actors via a property, scrollView.
Objective-C does not allow multiple inheritance. Check out this post for a great solution that uses composition.
Objective-C multiple inheritance
In objective C there is no support for multiple inheritance. Instead you can use either protocols or categories.
In addition you can use dynamic typing as well. Check out following link.
http://support.apple.com/kb/TA45894
I am going to have several uiimageview interactive sulasses that need a delegate. when each one of them is touched, the view controller must respond by changing something.
Is it good common practice to have one method , that is the delegate method get called by all of the uiimageview subclass instances?
The delegate will be the view controller.
Overall, is that good practice?
One method is better. This one will be a good option - (void)imageViewTouched:(UIImageView *)sender
You should follow DRY (Do not Repeat Yourself) principle and eliminate code duplcication in your app. So you should have separate methods if they have separate logic. You should have one method if the same type of logic executed for various senders.
Absolutely. Pass in the sender so you can make decisions based on who sent you the message (like tableView:cellForRowAtIndexPath:), and you have a good implementation of the delegation pattern.