The header in CLLLocationManager has this line:
- (void)startMonitoringForRegion:(CLRegion *)region
desiredAccuracy:(CLLocationAccuracy)accuracy __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_NA, __MAC_NA,__IPHONE_4_0, __IPHONE_6_0);
and in fact an app of mine using that reports a warning when compiling and archiving. Notwithstanding the Apple documentation still includes it hinting to no obsolescence. Even a web search for the problem returns no hit. What is the matter? Do I risk to lose this functionality with some users?
Apples docs say this is deprecated and you should use startMonitoringForRegion: instead
The risk is the same as any deprecated method, it will eventually be removed so its better to remove it from your code where you can (the new method only exists in iOS 6+ so you still need to use the old one in older version)
Related
Let's say I have a Xcode project with the deployment target of 8.0 and iOS 10 got released. The app gets build and released - the deployment target stays the same.
My questions are:
Do the newly added deprecations impact the stability of the app for a device running iOS 10?
Do I have to adjust my implementations to get rid of the deprecated code even Xcode does not show me any warnings? (the warnings when I would set the deployment target to iOS 10)
Currently I only add if #available checks for deprecated code that Xcode shows as warnings.
Yes and no... Normally code is deprecated because it's no longer maintained, and or has known issues. Nothing should directly change for deprecated code between the time before it was deprecated and afterwards, so nothing should reduce stability etc. However, the fact that it is deprecated should make you keener to change it to the recommended replacement.
It should probably be noted that deprectaed methods tend to not disappear, despite that being the intention of deprecation. As the backwards compatibility would be broken, unless there are very serious security / privacy concerns, it's not likely a deprecated method would be removed.
It should also be noted that unlikely things happen with a greater frequency than one would expect ;)
"Deprecated" means it will disappear in a future version, so you should replace the code as soon as possible.
There are many deprecated methods that are trivial to replace, or almost trivial with the replacement having better functionality; in those cases you should replace the method now.
There are cases where there is non-trivial effort. Worse, there are some cases where a method may be deprecated in iOS 10 with a nice replacement method - which isn't available in iOS 8. In the first case, I'd replace it when you have some spare time, as soon as possible. In the latter case, I'd replace it as soon as I don't need to support anything where the replacement method is not available.
I'm writing a private pod. (I don't think this matters, but thought I should put in the full information).
It's a library used by a couple of apps that I'm writing.
I've recently created some new routines (which make some older routines obsolete). So, I thought I'd mark some of the older routines with a deprecated flag, like this:
- (void) myOldRoutine __attribute((deprecated("Use myNewRoutine instead")));
I'm expecting to get a warning when I compile, (just like other deprecation warnings I get). I'm just trying to add reminders to myself that I need to make newer calls in my client app.
However, instead of getting a warning, I'm getting an error.
I'm using other pods, some of which use older system APIs and always just generate warnings. Why does my use of this generate an error?
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 made a project with MonoTouch 5. After upgrading to MonoTouch 6 my UIViewControllers are not auto-rotating anymore. These are hosted inside a tabviewcontroller. I get this warning:
ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' overrides obsolete member `MonoTouch.UIKit.UIViewController.ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)'. Add the Obsolete attribute to ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' (CS0672)
But the method still gets called when I am debugging. The new ShouldAutorotate never gets called. Any ideas? Thanks!
There can be a few reasons. One of them is that you should be (if not already) setting the RootViewController in your AppDelegate (another link here). That was not required before iOS6.
Another one is starting to use the new iOS6 API, without keeping a fallback for earlier iOS versions. That would match your comment, i.e. works on 6.0 but not on 5.1.
Note that since you're still targeting iOS 5.x you can safely ignore the obsolete warnings. iOS 6 introduced new API to handle rotation but it will automagically fallback to the old API to keep compatibility with existing applications.
That also means that if you start using the new (iOS6 only) API then you'll need to handle the old API yourself or rotation won't work with iOS 5.x.
Honestly I think that's a testing nightmare - you're better off letting iOS handle this and keep a single code path to handle rotation. That why I strongly suggest you to keep using the older API until your deployment target minimal version becomes iOS 6.0.
I had the same issue after upgrading and I got the answer to my problem over here. Here is the heart of the problem, quoted from the link:
Application windows are expected to have a root view controller at the end of application launch
So if previously like me you have this in your FinishedLaunching(UIApplication app) method in main.cs:
window.AddSubview(mainVC.View);
Replace it with this:
window.RootViewController = mainVC;
That's it! Happy days! Rotation works again. :) At least it solved the problem for me.
I don't know whether this small thing causing the application to go wrong is Apple's fault or Monotouch/Xamarin's fault, but I think that the Xamarin team should do something about this. Surely this is something that could be detected and corrected at compile time?
Anyway. Hope this information saves other people the hours that this issue has cost me!
I'm implementing ShareKit in my app. Everything is working fine, but there are many warnings caused by the ShareKit files.
When I look into them it seems that they all relate to just a few issues:
ShareKit is using some deprecated items (mostly "font" related).
FBLOG2 - many times ShareKit calling this feature, but don't use it; so the warning is always: Expresion result unused
In FBRequest.m file there is a method called "(id)parseXMLResponse:(NSData*)data error:(NSError**)error". the warning I get is "Semantic Issue: Assigning to 'id' from incompatible type 'FBXMLHandler *'"
Can anyone direct me to how to solve these warnings?
OR... Does anyone know if Apple App Review rejects applications that carry these warnings (as I said, besides the fact that the warnings are being called, my app is working fine and all the ShareKit features I had implemented are functioning fine as well)?
Sharekit hasn't been updated by the authors in over a year. That being said, some things have changed since then (APIs updated, method deprecated, etc.) However, Sharekit should still work. If the warnings bother you (as they should), they shouldn't be very difficult to fix. If you need help, google the specific warnings.
For example, the font issue is just setFont has been deprecated in favor of cell.textLabel.font = ...