I am using a custom header cell, and while it works correctly in ios8, when I try it on an ios9 device the table calls dequeueReusableHeaderFooterViewWithIdentifier but it doesn't call the initWithFrame (or any init function that I tried) function, and so I just get a blank space for a header file.
Is there a change in how dequeueReusableHeaderFooterViewWithIdentifier works in ios9 that I should be awear of?
Thanks
I had the same problem with a subclass of UITableViewHeaderFooterView. Changing from initWithFrame to initWithReuseIdentifier solved the problem for me.
I could observe the following different behavior under iOS 8 and 9:
Under iOS 8
initWithReuseIdentifier: gets called first then
initWithFrame:
whereas under iOS 9
only
initWithReuseIdentifier:
gets called
Related
I have an static UITableView with grouped cells, and an outlet for an UIImageView in the first group and I try to set its image on viewDidLoad like this
- (void)viewDidLoad {
[super viewDidLoad];
self.productImageView.image = [UIImage imageNamed:#"someImage"];
}
I found the productImageView (UIImageView) is nil but only on iOS7 (7.1.2), as far as I knew, it shouldn't be nil after viewDidLoad
Can anyone tell me why this is the only outlet is not loading from my storyboard?
Moving your code to the viewWillAppear will likely fix your issue, but that's not really the optimal solution. What if you add a call to [self.tableView reloadData]; before you set the image to make sure that the tableView is initialized?
Well, I found the reason
I made the ViewController in a different storyboard, Xcode 6, with the new format for storyboards and different devices, but actually, our project is as old as Xcode 5 and we still use those storyboards, when I made copy & paste of the ViewController from the new storyboard to the old one, it should work because we are used to this, and it does with iOS8, but I noticed the view is shown like this in the view inspector
http://i.stack.imgur.com/ticT5.png (can't post images yet)
Seems like the image and its constraints are disabled and deleting the element, adding a new one seems to solve the problem for iOS7 and still work with iOS8
when reading objc.io's 5th issue on UICollectionView + UIKit Dynamics , the 2nd section talked about 'Tiling your Dynamic Behaviors for Performance (related source code)', what confuse me is prepareLayout method is continuously called, but -shouldInvalidateLayoutForBoundsChange: still returns NO, and nowhere called invalidateLayout. shouldn't it just called once ?
I came across a similar issue myself when testing an iOS7 UICollectionViewFlowLayout on an iOS6 device. On an iOS7 device prepareLayout is only called once, but on an iOS6 device it is called when layoutSubviews is trigged by it's parent UIScrollView.
To fix this issue I changed my UICollectionViewFlowLayout class to UICollectionViewLayout. There seems to be a layout issues with UICollectionViewFlowLayout in this case.
Is there a problem with adding a UITableView as a subview of aUIView? I had a line of code that was working for months, and recently broke after I updated XCode to 4.6.3. Long story short, I was returning TableViewTwo as a subview of a UIView as a footer of TableViewOne. Please don't ask me why this is necessary, it is just convenient for what I am doing. Well, the app would always crash on the simulator, but not on the device. It would give me a bizarre error and an opaque call stack. The error said unrecognized selector(numberOfSections)sent to instance. Yes, the selector was numberOfSections and not the numberOfSectionsInTableView in the UITableViewDataSource. Well, when I returned the UITableViewTwo as UITableViewOne's footer..everything started working. Does anyone know if there is a problem with adding a UITableView as a subview of a UIView? For more information - see this SO Post(link)
I am really getting tired of this:
I have a simple UIView called statesComboxBox. I have connected it on the IB using interface builder. I run the following line inside viewDidAppear method and it prints out zero.
NSLog(#"%f",self.statesComboBox.frame.size.width);
I am lost.. completely lost!
NOTE:
I am using Storyboards with Auto Layouts in iOS 6
I am working on an iOS SDK 4 project with ARC enabled.
My class MyTextView (derived from UITextView with UITextViewDelegate protocol) implements the following static method:
+ (void)showInViewController:(UIViewController*)viewController
{
MyTextView *textEdit = [[MyTextView alloc] init];
textEdit.delegate = textEdit;
[viewController.view addSubview:textEdit];
// Show the keyboard
[textEdit becomeFirstResponder];
}
In one of my view controllers I call the following:
[MyTextView showInViewController:self]
This crashes with warning: Unable to restore previously selected frame. on becomeFirstResponder. Looks like some stack related crash because of some cycle. I am fairly new to ARC. The delegate property of UITextView is defined as assign (shouldn't ARC interpret that as weak?). I know this approach is rather strange memory-wise. However, I wanted to know if ARC can handle things like that. Obviously it can't. Any idea what might be the problem and how to solve it?
I don't think it has anything to do with the ARC and memory management, but just a more fundamental problem that a UITextView cannot be a delegate of itself. It gets locked in a loop. Put a logging message in textViewDidChangeSelection and you'll see it gets repeatedly invoked. Not a memory issue, methinks, but rather just a logic issue with UITextView delegates. Even if you don't do your problematic showInViewController but just create a standard UITextView subclass and try to set its delegate to itself, you'll see the same curious behavior.
old post, but here is the answer:
http://www.cocoabuilder.com/archive/cocoa/282093-uitextview-as-its-own-delegate-infinite-loop-on-keyboard-select.html
or here aswell
self.delegate = self; what's wrong in doing that?