I'm running into a tricky glitch.
I've got a .xib, which was created by XCode when I created a new UIViewController subclass. It has quite a few elements, including some UIButtons, a bunch of UILabels, a small UIView with some other views inside it, and a UIImageView containing a mostly-transparent image.
In viewDidLoad, I set the background color of the UIImageView to a color using a pattern image.
When I display this view controller in the simulator or on my iPhone 4 (both running iOS 5.1), everything goes smoothly; the patterned background displays, all the interactions work, and so on.
When I test on iOS 4.3, however (either in the simulator or on my iPod Touch 2G), it appears that everything I'm trying to manipulate based on an outlet (e.g. [self.myBackgroundImageView setBackgroundColor...] or [self.mySegmentedControl setEnabled:NO]) just doesn't work at all.
The only even vaguely unusual thing I'm doing when the view gets presented is this, which makes it size properly in a popover:
- (void) viewWillAppear:(BOOL)animated {
CGSize size = CGSizeMake(320, 480); // size of view in popover
self.contentSizeForViewInPopover = size;
[super viewWillAppear:animated];
}
I really can't think of anything else that might be the problem. I've cleaned, rebuilt, all that stuff. Still no dice.
Has anyone else encountered this?
UPDATE per request by ott:
Added the following at the end of -viewDidLoad:
NSLog(#"self.myBackgroundImageView = %# | %#", [self.myBackgroundImageView description], [[self.myBackgroundImageView backgroundColor] description]);
...The output is:
self.myBackgroundImageView = <UIImageView: 0x6d48c80; frame = (0 0; 320 480); autoresize = RM+BM; userInteractionEnabled = NO; layer = <CALayer: 0x6d48b60>> | <UIImageView: 0x5f459b0; frame = (0 0; 320 480); autoresize = RM+BM; userInteractionEnabled = NO; layer = <CALayer: 0x5f45890>> // kCGColorSpaceModelPattern 1
So... not nil. Not sure what the story is here.
UPDATE 2:
It appears the disabling of a UISegmentedControl in iOS 4.3 doesn't dim its display, so that's what that part was about. As for the background pattern image: I can't find confirmation of this, but I'm starting to think it's a bug in iOS 4 that makes a background color using a pattern-image UIColor not display properly on a UIImageView. It works fine if I make the UIImageView have a clear background and put the pattern image UIColor as the background of the main view instead. If anyone comes up with a workaround, or confirmation that this is indeed an iOS 4 bug, it would be much appreciated.
Related
According to Crashlytics, this issue only on iOS 12, I can't to reproduce that.
There is an assumption that this is due to the toolbar for the keyboard, but what exactly the problem is is not clear.
Attempting to attach a window (<UITextEffectsWindow: 0x1380bfa00; frame = (0 0; 320 480); hidden = YES; layer = <UIWindowLayer: 0x2830cc5e0>>) to a screen with a nil FBSDisplayIdentity
I am using JSQMessageViewController and I am facing the issue (only in ios14) that i cant see media items like Images, Video and Audio in device though these views are generating debug view hierarchy. See below attached image:-
debug view hierarchy screenshot:
here is the description of UIImage inside collection view cell:
<UIImageView: 0x7fe7d6d95b30; frame = (20 8; 177 131); clipsToBounds = YES; opaque = NO; autoresize = RM+BM; userInteractionEnabled = NO; layer = <CALayer: 0x600001ce4ec0>>
here is the screenshot attached of screen:
You can see the view has generated space for image, but its not showing up!
Is anyone facing this issue? how can i solve this problem. This issue is occurring in iOS 14, it works perfectly in iOS 13.
You need to overwrite in JSQMessagesMediaViewBubbleImageMasker.m
method - (void)jsq_maskView:(UIView *)view withImage:(UIImage *)image and change line:
view.layer.mask = imageViewMask.layer;
to be
view.maskView = imageViewMask;
I suggest you to use category for that. For me that was solution.
I would like to suggest to change like as follows along with the Vladimir answer for backward compatibility:
if (#available(iOS 14.0, *)) {
view.maskView = imageViewMask;
} else {
view.layer.mask = imageViewMask.layer;
}
I'm creating a preview from something that people can configure in settings. They can choose a color in settings.
My view hierarchy:
Settings (Choose color for tree, and preview tree)
Choose color for tree (Here the user can choose for colors of the tree, with a save button)
I have an unwindSegue for my save button, that calls the setupCell method. But the background gradient layer of my UIView does not want to change.
Code:
- (IBAction)setupCellSegue:(UIStoryboardSegue *)segue{
[self setupCell];
}
-(void)setupCell{
//Corners
self.Preview.layer.cornerRadius = 25;
self.Preview.layer.masksToBounds = YES;
//Background
self.Preview.backgroundColor = [UIColor clearColor];
CAGradientLayer *grad = [CAGradientLayer layer];
grad.frame = self.Preview.bounds;
grad.colors = [[[Kleuren sharedInstance] kleurenArray] objectForKey:[standardDefaults objectForKey:#"Kleur"]];
[self.Preview.layer insertSublayer:grad atIndex:0];
//Text
self.optionOutlet.textColor = [Kleuren.sharedInstance.tekstKleurenArray objectForKey:[standardDefaults objectForKey:#"TekstKleur"]];
}
EDIT:
Here is the NSLog from my sublayers from the view. How can i replace the old CAGradientLayer with the new one? Tried this:
[self.Preview.layer replaceSublayer:0 with:grad];
(
"<CAGradientLayer: 0xcce9eb0>",
"<CALayer: 0xccef760>"
)
EDIT 2:
After trying some more, i've noticed that the CAGradientLayer is just added and added on top? Maybe this is the problem?
(
"<CAGradientLayer: 0x170220100>",
"<CAGradientLayer: 0x170220e20>",
"<CAGradientLayer: 0x170029f40>",
"<CALayer: 0x17803d960>"
)
EDIT 3:
View hierarchy, so the View that is highlighted in the screenshot is the one with the background.
EDIT 4:
Tried this: but now it doesn't have a CALayer anymore:
[[self.Preview layer] replaceSublayer:[[[self.Preview layer] sublayers] objectAtIndex:0] with:grad];
So I would get the following error:
2014-07-08 18:57:18.365 ///[3324:60b] View hierarchy unprepared for constraint.
Constraint: <NSIBPrototypingLayoutConstraint:0xe88e0b0 'IB auto generated at build time for view with fixed frame' UILabel:0xe88dae0.left == UIView:0xe88da50.left + 20>
Container hierarchy:
<UIView: 0xe88da50; frame = (59 54; 202 202); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0xe88dab0>>
| <CAGradientLayer: 0xe88cd50> (layer)
View not found in container hierarchy: <UILabel: 0xe88dae0; frame = (20 20; 162 162); text = 'Option'; clipsToBounds = YES; opaque = NO; autoresize = RM+BM; userInteractionEnabled = NO; layer = <CALayer: 0xe88db90>>
That view's superview: NO SUPERVIEW
So it seems to be that because the CALayer is deleted, the UILabel gives this error because it doesn't have a superview.
Try adding
[self.Preview.layer setNeedsDisplay];
after setupCell. This should redraw the layer
Not immediately sure what your issue is.
The first thing that jumped out at me is that in your first EDIT, you misused replaceSublayer:with:. See the documentation for that method for details, but basically you used an integer literal when you need to pass a CALayer - I'm surprised the compiler didn't complain. The declaration of that method is:
- (void)replaceSublayer:(CALayer *)oldLayer with:(CALayer *)newLayer
To use this method correctly, you'll want to hold onto a reference to the gradient layer. Maybe make a new property called grad and store it there. Later, when you want to replace it, pass self.grad into replaceSublayer:with: as oldLayer.
After you've fixed that, here are some things to check:
Are you sure setupCell gets called when you think it does? Set a breakpoint there to check.
Are you sure that when you recalculate the gradient layer, the colors have changed? Use a breakpoint to examine the value of grad.colors each time you pass through setupCell.
Found it, I've placed my CAGradientLayer *grad; in my implementation declaration between the {}
By placing the declaration in my implementation of my class. I could re-use the declaration, and not making a new instance each time by putting it in the setupCell.
#implementation class {
CAGradientLayer *grad
}
-(void)setupCell{
// Do stuff here with the gradient layer.
}
I do not know that this is the right explanation but it works. Was the last thing I came up on!
recently, I am making a custom UITableViewCell with animatable UIImageView to play animated GIF. During making it, I found that an animation is not shown after the cell was reused.
It seems that UIImageView is affected by [self prepareForReuse]. When I did debugging it, I could get the following information.
** before calling [super prepareForReuse] **
(lldb) po self.testImageView
<UIImageView: 0x1ab681c0; frame = (39 0; 78 61); opaque = NO; autoresize = W+H; userInteractionEnabled = NO; animations = { UIImageAnimation=<CAKeyframeAnimation: 0x1ab77870>; }; layer = <CALayer: 0x1ab68b60>> - (null)
** after calling [super prepareForReuse] **
(lldb) n
(lldb) po self.testImageView
<UIImageView: 0x1ab681c0; frame = (39 0; 78 61); opaque = NO; autoresize = W+H; userInteractionEnabled = NO; layer = <CALayer: 0x1ab68b60>> - (null)
As it show, "animations = { UIImageAnimation=; };" is removed.
Fortunately, I could work around that problem by making a new instance of UIImage and setting it to UIImageView again as a workaround. For doing this workaround, it's important to re-create an instance of UIImage not to reuse an instance which is already set to UIImageView.
Anyway, what I really want to know is why prepareForReuse method removes the information about an animation.
Please let me know an internal reuse logic of the method which is hidden.
Upon calling [super prepareForReuse], stopAnimation is called on self.testImageView. I think this is the right logic being used so that the cell can be reused. You just need to call the [self.testImageView startAnimation] method once the cell is prepared for reuse. You need not resort to the "workaround" method that you have mentioned.
Found a solution. I had to set the UIImageView's image property to nil in prepareForReuse(), before setting a new (or even the same) animated UIImage.
I have implemented a custom split view controller which — in principle — works quite well.
There is, however one aspect that does not work was expected and that is the resize-animation of the toolbar on iOS prior to version 5.1 — if present:
After subclassing UIToolbar to override its layoutSubviews method, animating changes to the width of my main-content area causes the toolbar-items to move as expected. The background of the toolbar — however — does not animate as expected.
Instead, its width changes to the new value immediately, causing the background to be shown while increasing the width.
Here are what I deem the relevant parts of the code I use — all pretty standard stuff, as little magic/hackery as possible:
// From the implementation of my Split Layout View Class:
- (void)setAuxiliaryViewHidden:(BOOL)hide animated:(BOOL)animated completion:(void (^)(BOOL isFinished))completion
{
auxiliaryViewHidden_ = hide;
if (!animated)
{
[self layoutSubviews];
if (completion)
completion(YES);
return;
}
// I've tried it with and without UIViewAnimationOptionsLayoutSubviews -- didn't change anything...
UIViewAnimationOptions easedRelayoutStartingFromCurrentState = UIViewAnimationOptionCurveEaseOut | UIViewAnimationOptionBeginFromCurrentState;
[UIView animateWithDuration:M_1_PI delay:0.0 options:easedRelayoutStartingFromCurrentState animations:^{
[self layoutSubviews];
} completion:completion];
}
- (void)layoutSubviews
{
[super layoutSubviews];
// tedious layout work to calculate the frames for the main- and auxiliary-content views
self.mainContentView.frame = mainContentFrame; // <= This currently has the toolbar, but...
self.auxiliaryContentView.frame = auxiliaryContentFrame; // ...this one could contain one, as well.
}
// The complete implementation of my UIToolbar class:
#implementation AnimatableToolbar
static CGFloat sThresholdSelectorMargin = 30.;
- (void)layoutSubviews
{
[super layoutSubviews];
// walk the subviews looking for the views that represent toolbar items
for (UIView *subview in self.subviews)
{
NSString *className = NSStringFromClass([subview class]);
if (![className hasPrefix:#"UIToolbar"]) // not a toolbar item view
continue;
if (![subview isKindOfClass:[UIControl class]]) // some other private class we don't want to f**k around with…
continue;
CGRect frame = [subview frame];
BOOL isLeftmostItem = frame.origin.x <= sThresholdSelectorMargin;
if (isLeftmostItem)
{
subview.autoresizingMask = UIViewAutoresizingFlexibleRightMargin;
continue;
}
BOOL isRightmostItem = (CGRectGetMaxX(self.bounds) - CGRectGetMaxX(frame)) <= sThresholdSelectorMargin;
if (!isRightmostItem)
{
subview.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin;
continue;
}
subview.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin;
}
}
#end
I’ve set the class of the toolbar in InterfaceBuilder and I know for a fact, that this code gets called and, like I said, on iOS 5.1 everything works just fine.
I have to support iOS starting version 4.2, though…
Any help/hints as to what I’m missing are greatly appreciated.
As far as I can see, your approach can only work on iOS SDK > 5. Indeed, iOS SDK 5 introduced the possibility of manipulating the UIToolbar background in an explicit way (see setBackgroundImage:forToolbarPosition:barMetrics and relative getter method).
In iOS SDK 4, an UIToolbar object has no _UIToolbarBackground subview, so you cannot move it around in your layoutSubviews implementation. To verify this, add a trace like this:
for (UIView *subview in self.subviews)
{
NSLog(#"FOUND SUBVIEW: %#", [subview description]);
run the code on both iOS 4 and 5 and you will see what I mean.
All in all, the solution to your problem lays in handling the background in two different ways under iOS 4 and iOS 5. Specifically, on iOS 4 you might give the following approach a try:
add a subview to your custom UIToolbar that acts as a background view:
[toolbar insertSubview:backgroundView atIndex:0];
set:
toolbar.backgroundColor = [UIColor clearColor];
so that the UIToolbar background color does not interfere;
in your layoutSubviews method animate around this background subview together with the others, like you are doing;
Of course, nothing prevents you from using this same background subview also for iOS 5, only thing you should beware is that at step 1, the subview should be inserted at index 1 (i.e, on top of the existing background).
Hope that this helps.
Since I think this is going to be useful for someone else, I’ll just drop my solution here for reference:
Per sergio’s suggestion, I inserted an additional UIImageView into the view hierarchy. But since I wanted this to work with the default toolbar styling, I needed to jump trough a few hoops:
The image needed to be dynamically generated whenever the tintColor changed.
On iOS 5.0.x the toolbar background is an additional view.
To resolve this I ended up…
Implementing +load to set a static BOOL on whether I need to do anything. (Parses -[UIDevice systemVersion] for version prior to 5.1).
Adding a (lazily loaded) property for the image view stretchableBackground. The view will be nilif my static flag is NO. Otherwise the view will be created having twice the width of [UIScreen mainScreen], offset to the left by half that width and resizable in height and right margin and inserted into the toolbar at index 0.
Overriding setTintColor:. Whenever this happens, I call through to super and __updateBackground.
Implemented a method __updateBackground that:
When the toolbar responds to backgroundImageForToolbarPosition:barMetrics: get the first subview that is not our stretchableBackground. Use the contents property of that view’s layer to populate the stretchableBackground’s image property and return.
If the toolbar doesn’t respond to that selector,
use CGBitmapContextCreate() to obtain a 32bit RGBA CGContextRef that is one pixel wide and as high as the toolbar multiplied by the screen’s scale. (Use kCGImageAlphaPremultipliedLast to work with the device RGB color space…)
Translate the CTM by that height and scale it by scale/-scale to transition from UIKit to CG-Coordinates and draw the view’s layer into that context. (If you fail to do this, your image will always be transparent blank…)
Create a UIImage from that context and set it as the stretchableBackground’s image.
Notice that this fix for iOS 5.0.x will not work as expected when using different background images for portrait and landscape or images that do not scale — although that can be tweaked by configuring the image view differently…