UITextField.autocorrectType issue in iOS 7 - ios7

This is occurring with existing apps running on iOS7 and also with apps compiled in XCode 5.0.
I have recently inherited two iOS apps that were built using the Three20 framework. I realize that this framework is no longer supported, and do eventually want to switch these apps to a different framework. I am trying to simply get them to run under iOS7 before making an infrastructure changes.
The apps use a text field which inherits from a Three20 class, ultimately deriving from UITextField.
The inheritance chain is:
MyAppPickerTextField
TTPickerTextField
TTSearchTextField
UITextField
The apps are crashing when the initWithFrame method of MyAppPickerTextField is called, with the following exception:
* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[MyAppPickerTextField setAutocorrectionType:]: unrecognized selector sent to instance 0xd1c6c30'
It appears that somewhere in the inheritance MyAppPickerTextField is losing UITextInputTraits, which UITextField implements.
I've tried to implement UITextField at all levels of the inheritance chain with no results.
Could it be that the instance of MyAppPickerTextField is getting deleted before that gets called?
Thanks

Related

Automatic frameworks linking doesn't work

Today I learned that #import statement actually can help to link frameworks automatically.
Okay, I created a project, added a WebView. It was throwing me an error that WebView is undefined. Okay, I wrote #import WebKit — and the error was gone and all the WebView methods were available to me.
...I ran the application and it crashed with
*** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: '*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (WebView)'
Then I've added the WebKit.framework manually and... it worked. So what's the point of this #import statement? The automatic linking is turned on...
import imports headers. Thus, the name WebView becomes defined, along with the methods and other stuff in WebKit, and your code can compile. Linking links code - the code in which WebView actually lives and breathes and has its being - and so your code can run.
Normally, if you import a framework using #import, both things happen. You can compile your code because of the import, and you can run the code in the framework because the import also performs automatic linking.
But you are instantiating a WebView from a nib. Therefore you also have to link explicitly or you'll crash when the nib loads. The same is true if you were to use a MapView in a nib — you'd need to link MapKit explicitly or you'd crash when the nib loads.

"Message" is not a subclass of NSManagedObject error

I received a "Message" is not a subclass of NSManagedObject error after trying to click on a button in my app. The app compiles just fine and I can use every other part of my app. The interesting thing is that it runs just fine in iOS7 but crashes in iOS6. I have read to prefix my entity but since it is called in about 50 classes I am checking to see if there is a different solution. I am also curious why it works in iOS7 but not iOS6. Also If I delete the MessageUI.framework it works on iOS6 and iOS7.
I discovered that if I use the default on the CONFIGURATIONS/Default (Class is the same as the Entity name: my image example of "WebResource" that I would get an exception
reason: '"WebResource" is not a subclass of NSManagedObject.'
at statement:
WebResource *entry = [NSEntityDescription insertNewObjectForEntityForName:#"WebResource" inManagedObjectContext:mymanagedObjectContext];
but all works fine if i change the Class to "NSManagedObject". I do not know why the default is not "NSManagedObject" :(
It seems some names just don't work for entities: Message, WebResource, BluetoothDevice (as of iOS 11).
Renaming the entity and associated class solved it for me.

NSInvalidUnarchiveOperationException: Could not instantiate class named NSLayoutConstraint

I am very new to this. I followed Apple's tutorial step by step for the iPhone project "HelloWorld". I ran it in the iPhone 5.0 simulator and it crashed:
2012-11-02 14:46:06.782 HelloWorld[9880:c07] * Terminating app due
to uncaught
exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate
class named NSLayoutConstraint'
* First throw call stack:
(0x14a2052 0xea2d0a 0x144aa78 0x144a9e9 0x32f7d7 0x32f9af 0x32f6b7 0x23036d 0xd7e2c 0xd83a9 0xd85cb 0x38a73 0x38ce2 0x38ea8 0x3fd9a
0x10be6 0x118a6 0x20743 0x211f8 0x14aa9 0x138cfa9 0x14761c5 0x13db022
0x13d990a 0x13d8db4 0x13d8ccb 0x112a7 0x12a9b 0x1fed 0x1f15 0x1)
terminate called throwing an exception(lldb)
Can someone please tell me what went wrong? I'm using Xcode 4.5.
By default, when you create a new iOS project in Xcode 4.5, your storyboard or XIB is set to use Autolayout, which is a new feature in iOS 6.0. The NSLayoutConstraint class is part of the Autolayout system, and it doesn't exist in older versions of iOS.
If you want to deploy your app to an older version of iOS, you need to change your storyboard or XIB to not use Autolayout. It's a checkbox in the File Inspector:
Your Xib file (Interface builder file) contains AutoLayout elements, which iOS 5 does not support.
In Xcode, go to your .xib file(s), and for each one, turn off AutoLayout. There should be a checkbox on the left hand side saying "Use AutoLayout", uncheck it and try again. (This is under the first tab in the left hand side inspector, when you have File's owner) selected.
I stumbled into this error when I was working on an older project I wanted to update. I had selected the "Use Autolayout" checkbox to start working with constraints, but had forgotten to update my Deployment Target setting to iOS 6.
You need to run it in iPhone 6.0 simulator. Your error:
* Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named NSLayoutConstraint' *
Suggests that you are using autolayout, which only works on iOS 6.

iOS5 Stable App Crashing in iOS4.3 Simulator

i am getting an NSInvalidArgumentException with reason: -[UITapGestureRecognizer initWithCoder:]: unrecognized selector sent to instance
my understanding was that UITapGestureRecognizers were supported in ios4.x?
is it possible to load a different xib file for sub ios5 versions?
As #mit3z states in his comment on the original question, iOS 4.3 supports this feature only when setup up manually with code. It is not supported with Interface Builder.
Apple would have saved us all grief over this if they simply added this as a build-time warning.
I think you have a NSCoding compliant object that is deallocated before the crash. The UITapGestureRecognizer is allocated at its address and when the disappeared object (but not its reference) tries to call initWithCoder on itself, it actually calls this method on your gestureRecognizer instead.
Then your problem comes from that deallocated object but not from your gestureRecognizer.
Be sure to retain all your IBOutlet properties.

handleGetURLEvent:withReplyEvent: in AppDelegate obscured by KVO?

i'm seeing a weird issue trying to add custom URL support to my Mac app. i've defined the URL(s) in Info.plist, and when i navigate to them my app gets launched (or, if running, activated), but then, regardless of whether my app delegate implements handleGetURLEvent:withReplyEvent: or not, i see a couple of the following messages in the debug output:
+[NSKVONotifying_MyAppDelegate handleGetURLEvent:withReplyEvent:]: unrecognized selector sent to class 0x1d096e0
Apparently, NSKVONotifying_MyAppDelegate is a wrapper created by KVO for my real delegate (called MyAppDelegate), and that seems to obscure my implementation of handleGetURLEvent:withReplyEvent:, which never gets called. AFAICT, nothing in my app uses KVO on the delegate, and i'm running out of ideas as to what could be causing this.
any suggestions?
turns out the KVO thing was a red herring. the method needs to be static, as careful reading of the error message (or docs) would have made clear, while i had an instance method (as one would expect, for delegate methods? weird API design choice).