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.
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 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......
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)
I suspect that the answer is 'no' - but perhaps I'm missing something in the api...
I'm aware of the constant UIButtonTypes for UIButton:
http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIButton_Class/UIButton/UIButton.html
But I've also seen Apple use the exclamation badge within their apps, for example, the Reminders app:
Does anyone know if that button/badge is available?
Or am I making my own?
As I commented, you won't be able to use this button directly.
I don't think you can point to any source to say this, but from my own experience, I never found this button.
But, what you can do, is create or find the button's image. The second option is the easiest one ;)
I found this, giving you all iOS' images (iOS 4.3, but still good) : All stock iOS 4.3 UI Images.
Or you may use directly these normal/selected retina images (comming from the above link) :
And the non-retina versions :
Quick note, you may want to use this button very carefully. As it is a system image, you must use it the way iOS uses it. If you try to use it in an unappropriate context, your app may get rejected by Apple.
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!