My question is simply the title. I don't understand that if I'm using respondsToSelector why is the code checks for actual implementation ?
I'm on iOS 6, XCode 4.6
I got the answer to my question:
So this has something to do with the theory than iOS or XCode version. Compiler at the time of compilation (of code) checks for the existence of method and since setSeparatorInset is not part of iOS 6.x it will not work b/c compilers don't check for 'if' clauses it simply compiles the code. 'if' clause will be evaluated at runtime. So I'm trying to call the method which isn't there simply BUT what I was trying to achieve is not wrong, it can be done and I can check for method of iOS 7 from code of iOS 6. What I have to do is
[tableView performSelector:#selector()];
This perform selector (is part of tableView) is executed at runtime and I'm not directly calling the method at compile time that's why this will work.
Related
I have an app with Firebase integration to connect analytics using cocoapods. It was working well without any yellow warnings for iOS 13, but when I installed the new cocoa pods for target iOS 14 and build the app I get 6 yellow warning messages
"XXXPods/GoogleUtilities/GoogleUtilities/Logger/GULLogger.m:130:20: This old-style function definition is not preceded by a prototype"
When I was looking for answers online, there are only few and pointing to Flutter. I don't have Flutter for this app and I don't think I will be needing one. Does anyone else have the same issue? How can this be silenced for iOS 14 please?
I can downgrade the pods to iOS 13 but the whole point was to update the version.
Thank you for any help/direction
So this is a new warning in Xcode 12.5 (I believe) for old C style functions declared in those SDKs or any old style code using that syntax.
What does it mean?
do-not-leave-the-parameter-list-of-a-function-blank---use-void
if a function declaration does not include arguments, as in
double atof();, that too is taken to mean that nothing is to be assumed about the arguments of atof; all parameter checking is turned off. This special meaning of the empty argument list is intended to permit older C programs to compile with new compilers. But it's a bad idea to use it with new programs. If the function takes arguments, declare them; if it takes no arguments, use void.
So this is how your function prototype should look:
int foo(void);
And this is how the function definition should be:
int foo(void)
{
...
<statements>
...
return 1;
}
One advantage of using the above, over int foo() type of declaration (ie. without using the keyword void), is that the compiler can detect the error if you call your function using an erroneous statement like foo(42). This kind of a function call statement would not cause any errors if you leave the parameter list blank. The error would pass silently, undetected and the code would still execute.
What can we do?
May be raise a ticket for Firebase SDK to address (if there is not one already).
How big of a problem is this?
Depends on the implementation details. Could be as simple as replacing () with (void) for all of these functions. Could be a little more involved as explained above otherwise.
Firebase team maintains the SDKs regularly and we should see a fix for this in an upcoming release soon.
Run pod update
Firebase fixed this issue in February after Xcode 12.5 was introduced github.com/google/GoogleUtilities/pull/8/files.
When I add a function as a target with #selector to a UIButton, I should mark it as #objc, and that's ok. But the problem is that every function and method that #objc function calls, must be Objective-C compliant, otherwise, app crashes.
For example, when I use Swift enum ( I declared that enum as #objc, too), it crashes with this error unrecognized selector sent to instance
Is it an expected behavior working with #Objc, or I am doing something wrong?
And if it is, is there a workaround or I should make everything called by #objc, objective-C compliant ( in some cases, I need to re-write a big bunch of code)?
#objc attribute makes your Swift API available in Objective-C & Objective-C runtime.
After Swift 4 version launched, Few inference cases of #objc removed. This means in few additional cases where before the #objc header was inferred by the Swift compiler, in Swift 4 not inferred.
So by this cases you can now understand what causes the issue & how to use the #objc.
Make sure you are using swift language version 4 or more updated. From targets -> Build settings find Swift Language version to see what version you are using.
I hope it helps.
After experimenting a lot with the code, I noticed that the problem was rising from saving a custom object to UserDefaults, without archiving it using NSKeyedArchiver.
I noticed strange behaviour during working with Swift projects. I can't explain it other than Swift sometimes calls wrong method. It is very rare and even adding blank lines to the code could lead that this error is gone.
Let me explain in screenshots what I mean, next I use CoreData example of SwiftDDP project that can be found on Github, but such issues I was able to see in my own projects.
Here we at Todos.swift:74 where you can see breakpoint, I expect that next call should be getId() method of MeteorClient class because it was already instantiated:
After Step Into as you can see the ping() of the same instance is called:
The next two steps into lead to EXC_BAD_ACCESS exception:
In my project I saw this issue fairly often before I stopped using singletons, so it could be related to Swift static memory usage or I don't understand something that is not surprising as I have little experience with multithreading and memory management.
My environment is:
AppCode OC-145.184.11
Xcode Version 7.2.1 (7C1002)
iOS 9.2 SDK
Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81)
NOTE: Here I use AppCode but the same behavior I was able see in Xcode, and even more if the same issue that reproduces in Xcode could not reproduce in AppCode and vice versa.
Would be thankful if someone can explain this strange behaviour to me.
Thanks!
This just happened on my team, using Swift 2.2. It's really incredibly strange. It's not a threading issue or an async problem, it was a very cut & dry use case. We called one instance method and another one above it got called. I deleted the method that was getting called, and then the one above THAT got called instead. Then I moved the method I was actually calling to a different location in the file, and it looked like multiple properties were getting called.
This is disturbing and worrisome, as now you feel you can't trust your code to run properly.
But we did "solve" it. We moved the method up to the code that was actually getting triggered, and after a little trial & error the right method got called. Not yet sure if this will manifest itself for other methods.
It'd be nice to be able to provide a simple project where this is happening, but it seems highly unlikely that it's possible, and I can't share a snap shot of my code base with Apple. It must be a perfect storm of something to cause a bug with Swift's run time.
I had a similar issue, I think. Couldn't see that the wrong function was being called, but breakpoints on the function that was being called were never hit, and I couldn't step into the function from where it was being called. I added a new function (I called it wtf) with the same parameter list and implementation, and that one worked as expected, so it must have been a weird linking issue in the Swift compiler.
Update: super-cleaning appeared to work (see below), but it doesn't. Looks like I'm leaving my wtf function in.
After super-cleaning the project, it looks like everything's working as expected again:
clean (cmd + shift + k)
clean build dir (cmd + opt + shift + k)
quit XCode
delete derived data (rm -rf ~/Library/Developer/Xcode/DerivedData/*)
FYI, in my case, the function I call is in a generic base class, called from a generic subclass, triggered by a specialized sub-sub-class. As we all know, the generics are still very buggy in the Swift compiler, so that's probably why I encountered this.
Do you have multiple threads running? Maybe a network thread?
I thought I had this issue too but then it turned out my one thread was doing something and because the other thread crashed it stopped the other thread at a random point. I only noticed this thread so it seemed like it crashed at a random #IBAction function.
When I switched to iPhone 6 simulator instead of iPhone 7, it seems to be working correctly now!
Our app was rejected from review because of a mysterious crash. After debugging I found that it was having this same issue - but only for the Release scheme!
So I went through every setting in Build Settings one by one to see if switching it to that of another scheme would fix the issue: changing ENABLE_TESTABILITY to true fixed it......
All of the questions I can find relating to viewWillRotate and iOS8 (this for an example) explain how the viewWill/DidRotateToInterfaceOrientation methods have been deprecated and should NOT be called on iOS8. However, I'm observing that it IS being called, in an app built using XCode 6.1 and running on the iOS 8.1 simulator. What black magicks are afoot?
In fact, from the call stack it looks like it's being called from viewWillTransitionToSize:withTransitionCoordinator, which is... I mean it's nice of iOS8 to decide that it wants to pander to my out-of-date code, but I'd rather it didn't go deviating from the spec whenever it feels like, thank you very much.
Has anyone seen something like this before, and have any idea why it could be happening?
If a method is deprecated that does not necessarily mean that the method will not be called. A feature can be deprecated because it has been superseded by some other functionality, and that may mean that it still works, just not reliably or in all cases.
I'm new to Objective-C/Xcode, so bear with me.
I'm trying to implement a TableView, where each cell contains another View, similar to the Master-Detail template. I'm following a book that teaches doing it from scratch (in other words, without the Interface Builder).
Things seemed to be going fine until I got to the viewDidLoad method:
-(void)viewDidLoad
{
[super viewDidLoad];
}
The book tells me to insert this code, right before the end curly brace:
[self.tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:CellIdent];
along with a static variable, before the #implementation:
static NSString *CellIdent = #"Cell";
However, here's my problem: when I try to type "registerClass", the UITableView class does not seem to contain that method. I followed this documentation: http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UITableView_Class/Reference/Reference.html#//apple_ref/occ/cl/UITableView which says that the method is indeed part of that class, but Xcode doesn't seem to recognize it. I wonder if it's a syntax problem, but I have not been able to find any part of the code that doesn't work (I even copy-pasted the same line of code from other tutorials, just to be sure).
If I had to guess, I'd say I'm somehow implementing the UITableView class wrong, but I haven't been able to figure out what the problem is. Help?
The precise error that is thrown is, "no visible #interface for 'UITableView' declares the selector 'registerClass:forCellReuseIdentifier' which keeps me from running the project. Although I searched for this error across the board and none seemed to relate to the problem I keep having.
Make sure you are using the most up-to-date version of Xcode and are targeting iOS 6.0 or above - this is a method that was added in iOS 6.0
Click on the project, then under Summary look for Deployment Target and check the version number.
registerClass:forCellReuseIdentifier: is available in iOS 6.0 or later, probably you select earlier iOS version as target in your application.
Always check witch iOS version methods belong to.