IS it work UICollictionview in IOS 5 error Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named NSLayoutConstraint'
UICollectionView is not directly available in IOS5.
However there is a nice open source control for adding UICollectionView support in IOS5. Its called PSCollectionView and you can find it here: PSTCollectionView
It is a drop in library that emulates UICollectionView on IOS5 and passes through on IOS6. Very nice and works very well.
best of luck.
Check Availability of UICollectionView
Availability Available in iOS 6.0 and later.
You can go with PSCollectionView
In fact the problem probably isn't due to UICollectionView not being available in iOS5. It looks as though you're using constraints in Interface Builder. It is that that's causing the problem.
So, two things:
Use something like PSTCollectionView to add UICollectionView support in iOS5
Switch off constraints and revert to using "springs and struts" to resize/relocate your subviews
Related
"viewWillAppear" not call in xcode 4.5 with iphone 4.3 simulator, but if it runs in iPhone 5.0 or iPhone 6.0 simulator, this method will be called.
why? and what can i do if i want to do something when the view of an controller will appear in ios 4.3?
I think it may be related to the "View Controller Abusing". Check if your container view controller is used correctly. You can refer to this post for detail.
Based on your comments, the problem appears to be the lack of container view controllers in iOS 4. As of 5+ you're explicitly meant to be able to add the view of any controller into the view of any other* and that will generate the appropriate view[Will/Did]Appear, along with all the other newer messages — viewDidLayoutSubviews, etc.
In 4 you weren't explicitly allowed to build container view controllers and there's no deliberate, specific backwards link that connects a view back to its controller.
As a result, when you add the navigation controller to your view it doesn't get viewDidAppear. Because it doesn't know that its view has appeared, it doesn't tell any of the controllers it contains that their views have appeared.
Probably the best you're going to be able to do is to hack around that by (i) checking if you're operating under iOS 4; and (ii) if so, posting artificial viewWillAppear/viewDidAppear/viewWillDisappear/viewDidDisappear to your contained controllers.
Based on personal experience, iOS 4 (at least in 4.3) does actually implement addChildViewController: but not to do what the later, documented version does. So despite it not being an entirely accurate functionality check I tend to use if([self respondsToSelector:#selector(presentingViewController)]) to determine whether I need to propagate these messages manually.
[*] and you should also call addChildViewController: to make sure all messages move correctly in all directions
My app is working very fine on iPhone and Simulator with iOS 6, but when i try to run on iPhone/Simulator with iOS 5 the app crashes
The error is:
Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named NSLayoutConstraint'
I'm not using Autolayout on Interface Builder Document.
Could anyone help me?
Autolayout is not checked
make sure you have unselected use autolayout in interfacebuild
You've been burned. NSLayoutConstraint only exists on iOS 6. You have to check to see if it's there, and if it's not, you have to do something else.
I'm using a custom class for my UIViews, which I am controlling some configuration by using User Defined Runtime Attributes. This works fine when using storyboards, but when I use the same technique within a xib, my custom view class generates a bad access when trying to read the attribute.
As with User Defined Runtime Attributes in IB for iPhone not working I had to set the .xib IB version to 4.2 so it would compile. Is this just not supported?
According to the other post, it's not supported by iOS. Maybe it is with iOS 5's storyboards, but it doesn't seem to be for xibs.
I am building a universal app that uses a UISplitViewController for the iPad, and should work on any 3.0 device such as a 1st gen iPhone/iPod touch too. The trouble is that despite the fact that I am not actually creating any instances of UISplitViewController while the app is running on an iPhone, I still get the dreaded
dyld: Symbol not found: _OBJC_CLASS_$_UISplitViewController
Referenced from: /var/mobile/Applications/.....
Expected in: /System/Library/Frameworks/UIKit.framework/UIKit
errors in console when attempting to run on a 1st gen iPod touch. Everything works fine on iOS 4 devices though. I'm guessing the problem is that I have subclassed UISplitViewController and it chokes when reading "#interface SplitControl : UISplitViewController {" line from a .h file.
The only reason I subclassed it is to override shouldAutorotateToInterfaceOrientation method. I am doing my whole app programmatically with no IB. Would it help if I used IB to create that SplitViewController and tell it to support all orientations?
Is there a way to override shouldAutorotateToInterfaceOrientation without subclassing the controller? Any other way to hide UISplitViewController from pre-3.2 devices?
All you need to do is link UIKit.framework weakly. In General settings for your target, in the list of "Linked Libraries" change the type for UIKit.framework to "Weak" instead of "Required".
I had my app perfectly working on iPhone OS 2.2.1 but now I am trying to make it work on iPhone OS 3.0.
And my application crushes, apparently because of having a UINavigationController in UITabBarController.
I get the following error:
'NSInternalInconsistencyException', reason:
'Changing the delegate of a tab bar managed by a tab bar controller is not allowed.'
And I have no idea why does it happen and how to fix it.
Any help will be appreciated.
Having a a UINavigationController in each tab is perfectly fine. The problem you are experiencing is tied, apparently, to a wrong use of delegates. However, without the involved source code it is difficult to tell you where the problem lies.