From Apples iADSuite tabbed example there is a variable defined with delegate.
UIViewController<BannerViewContainer> *_currentController;
later it's cast as such
_currentController = (UIViewController<BannerViewContainer> *)_tabBarController.selectedViewController;
Whats the significance of using "BannerViewContainer" in the declaration, how it relates to the later cast and what's happening under the covers here?
Regards
Jim
There's nothing to do with delegates here. BannerViewContainer is a protocol. (You might be confused because delegation is often defined via protocols.)
Declaring a variable or parameter with an angle-bracketed protocol name means that anything assigned to it must be an object which conforms to that protocol: if you try to pass an instance of UIViewController or some subclass thereof, you'll get a compiler warning unless that instance is of a UIViewController subclass which declares conformance to the BannerViewContainer protocol. (That is, you can pass an instance of FooViewController if its header file reads #interface FooViewController : UIViewController <BannerViewContainer>.)
The cast you see later follows the same pattern as many casts: it's a case where the programmer knows that the object he's assigning meets the requirements for that variable, but the reference he's using doesn't have a matching declaration. That is, the tab bar controller only knows that its selected view controller is a UIViewController (or any subclass thereof), but the programmer knows that the views he put into the tab bar are all UIViewController subclasses conforming to the BannerViewContainer protocol.
Related
I have a generic class:
class PaginatedTableViewController
<GenericElement, Source: PaginationDataSource
where Source.PaginatedGenericElement == GenericElement>:
UITableViewController
and another that I try to instantiate from storyboard:
class CandidatesTableViewController:
PaginatedTableViewController<Match, MatchPaginationDataSource>
I can't find CandidatesTableViewController in the storyboard Custom Class dropdown menu. If I force it then cast my controller in code, app crashes at runtime complaining my controller (that should be a CandidatesTableViewController instance) is in fact a UITableViewController instance.
Unknown class _TtC21MyProjectName29CandidatesTableViewController in
Interface Builder file.
Could not cast value of type
'UITableViewController' (0x1040917f8) to
'MyProjectName.CandidatesTableViewController' (0x1013a9890).
In my project this controller is embedded in another one that's why I cast it :
tableViewController = (segue.destinationViewController as! CandidatesTableViewController)
Does any one knows how to resolve this issue ?
Unfortunately, generic Swift classes are not visible to Objective-C code and also are not supported in Interface Builder (in storyboards and xibs). I find these two points closely related.
As a solution I would suggest you to use aggregation: do not make you view controller generic, but extract some logic to another (generic) class and use it inside your view controller.
It is possible if you manually load your generic VC into Objective-C runtime manually via the load() method i.e. call. PaginatedTableViewController.load() in your app delegate's init method. Idea from https://stackoverflow.com/a/43896830/671580
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
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 working on a delegate pattern for authorization in my app.
Most things i've seen before use something like:
#property (weak) id<Delegate> delegate;
Does that make it weaker than say
#property (weak) UIViewController<Delegate> *delegate;
I realize i am asking for any pointer in the first one and in the second I am expecting a typed pointer. But i only want my delegate to be a UIViewController or subclass.
Can anyone explain the differences and pros and cons?
But I only want my delegate to be a UIViewController or subclass.
Then go for the second way - the first one indicates that it can be any object that conforms to the <Delegate> protocol.
There are not real pros or cons. The contract is just different. One says "I don't care what class it is as long as it conforms to that protocol" and the other says "I want a subclass of UIViewController which also conforms to the protocol".
The only thing here is that the idea of the "delegate" pattern in Cocoa is generally to give the client of your API a way to create an object that will customize the behavior of one or several other components.
Since you want this property to be a view controller, the semantic is more than just a delegate so I would not call it a delegate but a xxxViewController with "xxx" being the actual functional relationship between your object and that view controller.
I am learning to program the iphone and I wanted to do some drawing. I followed some example code and subclassed the viewcontroller and it worked fine. Now as I wanted to expand the program I came upon a design question that I could use a little help on.
I subclass myviewcontroller with mynewview. If I have any code in the myviewcontroller how do I call or reference it in mynewview and vice versa? I am not sure if I am asking this right but I am trying to understand the relationship between the class and subclass.
Objective-C objects benefit from inheritance. All classes are subclasses of NSObject, therefore you can call init on any object. If you created a custom class and gave it a method doSomethingAwesome, you are free to then implement doSomethingAwesome in any subclass of your custom class. However, declaring a method in a subclass does not add that method to the superclass. As an aside, I rarely find myself subclass sing my own custom classes. I believe that it is encouraged to maintain what is called a shallow object hierarchy. Usually I subclass the stock cocoa classes, customize to my needs and if I need custom methods in more than one subclass I will declare a category on the superclass rather than relying on inheritance to provide my custom behavior
The messaging system in Objective-C is dynamic. Every object includes a struct with information that the runtime use for introspection. Here the runtime will find a list of methods the object is able to respond. So, let's say you message an instance like this:
[mynewview someMethod];
The runtime will first check the object information to trying to find some method that will be able to respond the message. If nothing is found, then will query the super class, and so on. In fact, the runtime is much more complex, and will give any object more opportunities to respond (that's the dynamic part. For instance, mynewview might not have any method called someMethod and yet, might be able to satisfy the call, but that's something you might not want to worry right now).
From a child class you can call the superclass implementation of a given method with the keyboard super, so if mynewview is a subclass of myviewcontroller you can call myviewcontroller implementation from mynewview with:
[super someMethod];
If someMethod is both present in myviewcontroller and in mynewview, the runtime will automatically only call the child implementation, you have to call the parent implementation (if you have to) from the child implementation.