if ([self respondsToSelector:#selector(dismissViewControllerAnimated:completion:)])
{[[self presentingViewController] dismissViewControllerAnimated:YES completion:nil];} //post-iOS6.0
else {[self dismissModalViewControllerAnimated:YES];} //pre-iOS6.0
I'm doing the responds to selector (above) code to handle deprecated methods. That way my app is compatible with older versions of iOS, but I'm getting warnings in my code stating: "'dismissModalViewControllerAnimated:' is deprecated: first deprecated in iOS 6.0"
I personally don't like any warning in my code, but more importantly, I read somewhere that apple will complain about warnings in your code.
1) Will Apple complain about warnings in your code?
2) Am I handling deprecated methods correctly?
3) Is there way to turn deprecated method method warnings off?
Apple is unaware of any compile-time warnings you receive with your code.
Yes, you are handling this practice correctly. Clearly, in this case, you only need to go through this effort if you're supporting iOS prior to 5.0. But, in general, the technique for testing whether a method can be invoked and then calling the appropriate rendition is absolutely correct.
If you want to turn off the warning, you would simply temporarily suppress the warning and then turn it back on afterwards using the appropriate #pragma syntax:
if ([self respondsToSelector:#selector(dismissViewControllerAnimated:completion:)])
{
//post-iOS6.0
[self dismissViewControllerAnimated:YES completion:nil];
}
else
{
// pre-iOS6.0
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
[self dismissModalViewControllerAnimated:YES];
#pragma clang diagnostic pop
}
By the way, if you want to know what the -W code is for your particular warning, go to your Log Navigator, select the recent build that included the warning, and expand the log, and you'll see it there:
Also note that while you could suppress the warning like I've illustrated above, in practice, you rarely need to do so. Using your example, if your project's iOS deployment target was 4.3, you wouldn't get the warning. And if your deployment target was 6.0 or higher, you'd get that warning, but then again, you probably wouldn't need this conditional code to call dismissModalViewControllerAnimated because effective iOS 5.0, you can always use dismissViewControllerAnimated.
The only time that you'd need to suppress this warning in your code is if you have source code, to be included in projects in the future, for which you don't know what the deployment target will be. Using your example, if you don't know whether the above code will be included in a project with a 4.3 deployment target or a 5.0+ deployment target. In that case, this syntax is quite useful. But, then again, I you could also use conditional checks on __IPHONE_OS_VERSION_MIN_REQUIRED, e.g.:
#if __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_5_0
if ([self respondsToSelector:#selector(dismissViewControllerAnimated:completion:)])
{
//post-iOS5.0
[self dismissViewControllerAnimated:YES completion:nil];
}
else
{
// pre-iOS5.0
[self dismissModalViewControllerAnimated:YES];
}
#else
[self dismissViewControllerAnimated:YES completion:nil];
#endif
No
You should use the most recent methods unless you are specifically trying to support old iOS versions, then you should use the method you outlined above. "A method identified as deprecated has been superseded and may become unsupported in the future."
If you change the deployment target in your application target to 5.0, the deprecated warnings for iOS 5 not will be show as errors.
If you are really interested in backwards compatibility, there is a great tutorial by Ray Wenderlich here
Yes Many warnings are of present and dismiss view modally to fix that Replace:
in ios 6 these are:-
[self dismissViewControllerAnimated:NO completion:nil];
[self presentViewController:vc animated:NO completion:nil];
Related
So, i have some places where things are only available after a certain version. One example is some new NFC stuff i've introduced in my app:
#property(nonatomic, retain) NFCNDEFReaderSession *nfcSession;
I also have it in methods, where i get it even though i check for class availability, for example:
if ([NFCNDEFReaderSession class]){
my app works fine, but i get an xcode warning saying
NFCNDEFReaderSession is partial: introduced in iOS 11.0
I have looked around but haven't found a way to tell the compiler that it's fine and get rid of the warning.
Pointers much appreciated!
Add NS_AVAILABLE_IOS(11.0) to the end of the method name. For example:
- (BOOL)tableView:(UITableView *)tableView canHandleDropSession:(id<UIDropSession>)session NS_AVAILABLE_IOS(11.0) {
}
Method calls can be wrapped in the following to silence the new API warning
if (#available(iOS 11.0, *)) {}
You can silence specific warnings on parts of your code by adding Clang “pragmas” around it. In this case:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunguarded-availability"
// your code
#pragma clang diagnostic pop
Documentation: https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas
To silence the warning, change the target's "Other warning flags" to either:
-Wno-partial-availability
-Wno-unguarded-availability
You can also turn off Unguarded availability in the project settings. If you're using Cocoapods, it's now on by default in the Pods project.
I was stuck with an orientation issue in iPad for all versions. My app is designed in such a way that it supports from ios 6 till ios 8.
According to apple since willAnimateRotationToInterfaceOrientation: is DEPRECATED from ios8, i used viewWillTransitionToSize: for ios8.
When hit with issue, my first solution was providing macros to decide the version as either ios 8 or below and perform the functions accordingly.
#ifdef __IPHONE_8_0
// Works on >= version 8.0
- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator
{
[super viewWillTransitionToSize:size withTransitionCoordinator:coordinator];
// my code go here for ios 8
}
#else
// Works on < version 8.0
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation duration:(NSTimeInterval)duration
{
// my code go here when version is below 8.0
}
#endif
I also checked and run it.. I received the output as expected.
But it was said that the code was wrong.. as i am trying to turn version checking into a compile-time decision. The version checking must be a RUNTIME decision. both the ios7 and ios8 code must BOTH be compiled into the executable.
So changed the function as below without any version check:
-(void)viewWillLayoutSubviews
{
[super viewWillLayoutSubviews];
// my code go here without any version check
}
I'm hardly unable to understand the line "both the ios7 and ios8 code must BOTH be compiled into the executable." - what this really mean.
Wish to know why i shouldn't provide compile-time decision?
Also if i want to do it... without using notification.. is there any way through which i can able to handle by calling these functions at runtime with version check?
Kindly let me have the comments on this.
I've written an app specifically for iOS7, and am now attempting to make it work for iOS6.
I'd really like a setting to enable warnings which highlight lines of code which won't work on iOS6. i.e. any calls to code which ONLY work on iOS7.
That way I can immediately identify any lines of code which I need to attend to before catching them during debugging.
Does this even exist?
There is two option to deal with this.
Use MJGAvailability, a drop in header file and it will make warnings if a selector is "too new".
Buy Delpoymate, it can scan your Xcode project and show you any incompatible calls.
If you use an older Xcode next to the newest, than use this snippet:
if ([self respondsToSelector:#selector(newSelector)]){
#if __IPHONE_7_0
[self newSelector];
#endif
} else {
[self oldSelector];
}
There is no way of getting a warning to appear and even if there was how would the IDE now that you would have done something to handle it like the below
if([myObject respondsToSelect:#selector(myiOS7SelectorOnly)]) {
[myObject myiOS7SelectorOnly];
}
It works the other way if you where developing an app for iOS7 and you used a deprecated method that iOS7 API doesn't use any more it would give you a warning but not the other way you will have to wait for it to turn around and crash and throw an unrecognised selector exception.
At some point I had 2 Xcode installed - Xcode 4 and Xcode 5. Xcode 4 did not have API for ios7 and it was showing all incompatibilities.
But I don't know where can you find XCode4 now and will it still show errors in ios7 code or not?
At least you can try this way.
My app supports both iOS 6 and iOS 7. I am using some methods that are available from iOS7 only (like suspend) but are not available in iOS6. However, i am using proper branching for iOS6 and iOS7 (putting conditions accordingly). However, i am getting warning when i am using the suspend method.
This is my method:
-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
UIApplication *app = [UIApplication sharedApplication];
if([app respondsToSelector:#selector(suspend)])
{
[app performSelector:#selector(suspend)];
[NSThread sleepForTimeInterval:1.0];
}
exit(0);
}
The warning is
"Undeclared Selector 'suspend'"
There are several things wrong with the code you posted.
There is no public method named suspend for UIApplication. You appear to be attempting to call a private API. The compiler complains because it can't find a method named suspend (because there isn't a public one to be found). And as a side note, this will most likely result in your app being rejected by Apple.
NEVER sleep on the main thread. Very bad.
Never call exit. It's not allowed.
As the discussion showed that what you really want to do is to prevent the user from installing the app on iPod touch, I'll add an answer to that question:
The way to stop the app from being installed on certain devices is to use the UIRequiredDeviceCapabilities in you app's plist.
According to this list it seems the magnetometer is as close as you'll get to a perfect solution. It is supported in all iPhones and iPads except iPad1 and it is not supported by any of the iPod touch iterations...
The warning is issued because none of the imported header file declare a method matching the selector 'suspend'.
suspend is a private API.
You might be able to suppress the warning by creating a category definition of UIApplication and declare the suspend function, otherwise you can suppress it with a -warc flag, but you'll have to find the right warning name.
maybe like this:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundefined-selector"
//your warning causing code here
#pragma diagnostic pop
-OOOOR-
Try this solution : How to get rid of the 'undeclared selector' warning
I update the project, which was written under iOS5. Now do support only iOS7.
The project has check:
if ([TWRequest class]) {
...
}
XCODE says "TWRequest is deprecated: first deprecated in iOS 6.0". I know I should use Social.framework.
Therefore, the question whether it makes sense to update these checks, or you can simply remove it? Indeed, in the iOS still supported by default Social.framework?