I'm trying to cast this statement:
[self handError:noConnectionError];
basically, this statement is in a class, which is not the app delegate, but is the .m file of a view, specifically a view after uitableview, which contains its own uiviewtable.
The warning that statement gives me is that the error produced may not be apparent to the UIView (view control container).
That's the objective-c compiler telling you that the method is not declared in the interface for the class. Add the method declaration to the .h file and the warning should go away.
Also, if you want the method to be private, you can extend the interface in the .m file with a category like
#interface NTItemList (PrivateMethods)
- (void)handleError:(NSError *)error;
#end
This has the added benifit of not cluttering your class declaration.
This has nothing to do with casting as far as I can tell. It would appear that your class does not implement handleError:, which is required if you want to send it that message.
Related
I may be in compiler hell right here.
I'm implementing a Snapshot test in Swift, calling a property on an Objective-C VC, but that property is a class, written in Swift, bridged in.
In MyViewController.h:
#class TextEntryView;
#interface MyViewController: AbstractTextEntryViewController
#property (nonatomic, strong) TextEntryView *textEntryView;
#end
In TextEntryView.swift:
#objc(TextEntryView) class TextEntryView: UIView
And in my test, I'm trying to call
vc.textEntryView where vc is of type MyViewController and I'm getting the error:
value of type MyViewController has no member textEntryView
My bridging headers look good. If I add an NSString property to the .h file above, I'm able to reference it in the test. Also, when I command-click on MyViewController in my test, it takes me to the .h file rather than the .swift generated version of that file (which seems like a symptom of this problem).
I may be pushing Xcode 8 beyond its limits.
You need to make sure you import your app at the top of the source file for your test. For example, if your app is called MyApp, insert at the top of the test file:
import MyApp
If I leave out the import, I get the same behavior you are seeing. Additionally, as long as the import is there, you shouldn't have to bother with bridging headers for the unit test.
Have you tried to import to Test Target ?
Since you already imported the Xcode-generated header file for your Swift code into Objective-C .m file.
Please also remove #objc annotation from TextEntryView class since it's a subclass of UIView thus accessible and usable in Objective-C. keeping the annotation #objc may cause a side effect.
To be accessible and usable in Objective-C, a Swift class must be a
descendant of an Objective-C class or it must be marked #objc.
a simple case of "side-effect" is when a (swift) UIViewController subclass is marked #objc and used as custom subclass in storyBoard:
instantiateViewControllerWithIdentifier will instantiate a UViewController instead of the subclass we set in the storyBoard.
with error Unknown class _TtC10AbcdViewController in Interface Builder file
Recently I was studying the possibility of creating multiple classes in only one file, for this I created a class of UIViewController with a .xib file, the structure of the file is as follows:
MyFristViewController.h
#import <UIKit/UIKit.h>
#interface MyFristViewController : UIViewController
#end
#interface MySecondViewController : UIViewController
#end
MyFristViewController.m
#implementation MyFristViewController
- (void)viewDidLoad {
[super viewDidLoad];
NSLog(#"Frist View Loaded");
}
#end
#implementation MySecondViewController
- (void)viewDidLoad {
[super viewDidLoad];
NSLog(#"Second View Loaded");
}
#end
My doubt is: How does the system know that is to perform the methods contained in the class called 'MyFristViewController'?
I already tried to modify the custom class in interface builder, tried to change the position of the classes in the file and the system continues running only the existing methods inside the 'MyFristViewController' class why?
How does the system know that is to perform the methods contained in the class called 'MyFristViewController'?
The filenames are irrelevant. When looking at a class, for the most part, the code between #implementation <#ClassName#> and #end is used.
Additional customization of classes can be added through categories and class extensions. These can also be specified in the same file, or different files, because (again) the filenames are irrelevant.
Generally, you should have one class per file to make it easy to read and find your code. See How many classes should a programmer put in one file? for additional discussion.
My doubt is: How does the system know that is to perform the methods contained in the class called 'MyFristViewController'?
Because the methods are in the #implementation block of MyFristViewController.
I already tried to modify the custom class in interface builder, tried to change the position of the classes in the file and the system continues running only the existing methods inside the 'MyFristViewController' class why?
Probably because you've linked them to the methods in first #interface section in your header file. Control-drag to the actual method you want to bind to. It's not clear what problem you're actually seeing.
That said, this is a terrible idea. Put each view controller in its own file. It'll work in one file, but it will create lots of confusion, as you're seeing.
I have worked on projects that define multiple classes in a single file. I loathe this practice. I find it very disorienting and I waste a lot of time searching for where the classes are defined/implemented.
I would advise you not to do this. It ends up being very confusing.
This question already has answers here:
Is it possible to make the -init method private in Objective-C?
(9 answers)
how to block a superclass method to be called to a subclass
(5 answers)
Closed 9 years ago.
Suppose you have a UIView subclass. You define an init method "myInitWithFrame: ... andWhatNot:...". You know you won't be using the init method inherited from UIView ever and your custom init method does some vital custom initialising so that you want to force client classes to never use the inherited initWithFrame method.
Is it possible to hide the standard initWithFrame method that was inherited from UIView?
Actually, you can get compile-time warnings about calling a method on a subclass. Use the __attribute((deprecated)) attribute. If you want people to use -initWithPizza: instead of -initWithFrame:, do this:
#interface MyView : UIView
- (id)initWithPizza:(MyPizza *)pizza;
#end
#interface MyView (Deprecations)
- (id)initWithFrame:(CGRect)frame __attribute((deprecated("Use initWithPizza: instead")));
#end
Putting the -initWithFrame: declaration in a separate category is necessary to avoid Xcode complaining that you declared the method in the header but didn't implement it. Since you're just inheriting it from the superclass, that's fine; you don't have to implement it at all. But if you want to implement it to throw an exception, or call through to -initWithPizza: with a default argument, that's fine.
Of course, this won't stop UIKit from calling -initWithFrame: if it was already going to do so. But if you can guarantee that won't happen, then you're fine.
Actually, you CAN restrict with a subclass. You can override whichever methods you want to block in your subclass's .h file. You can make initWithFrame unavailable by placing the following in your .h file.
- (id) initWithFrame:(CGRect) frame __attribute__((unavailable("message")));
This will make the initWithFrame: method unavailable to anyone using your subclass.
To keep other code form calling this method, you can further restrict by putting this in your .m file.
- (id) initWithFrame:(CGRect) frame
{
return nil;
}
No. You can't prevent the users of your subclass from calling the methods of a superclass. You could override them and throw an exception inside, but that would just produce a broken subclass.
Remember that inheritance works as an "is a" extension, that is, instances of your subclasses should behave normally in any context that doesn't know about this particular subclass but knows about its superclass. It's only in places that have explicit knowledge about your subclass that you can benefit from adding extra initialization and other methods.
For example, UIKit has no knowledge of your subclass. So if you want to make your UIView subclass available from a NIB, you need to use the initialization methods that will be called by the NIB loading system, namely initWithCoder:. You can simply call your own initialization methods inside initWithCoder:. But if there are any additional parameters you would like to pass to the init method, you'll have to provide a way to configure them after initialization.
Whenever I create a UI object such as UITextField programmatically, I do this:
txt.delegate = self;
A compiler warning appears and asks me to add UITextFieldDelegate in the .h file.
I noticed though that it makes no difference with or without, the code works fine either way.
But the compiler warning disappears. Why is this?
You don't actually need to set the delegate property on your objects unless you are actually using the delegate methods. For example, if you need to know when the UITextField is about to begin editing. If you don't need to know when these things occur, you don't need to set the delegate.
Looking at it the other way, if you make your class conform to a delegate method (by adding <SomeClassDelegate> in the .h file), and then forget to implement required delegate methods, you'll get a warning from the compiler, and a crash when the app runs (and sends a required delegate message to your object).
To answer your question about not adding UITextFieldDelegate to your .h file, imagine your friend is looking for a French translator. You find a foreign looking man and introduce him. Your friend asks "But can he speak French?" You reply "I don't know". This is your warning.
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.