Progress HUD not shown: iOS 8

Question

Progress HUD not shown: iOS 8

foffux opened this issue 9 years ago · 71 comments

Hello
Unfortunately I found out a regression in the progress HUD. Everything is working fine under iOS 7, but under iOS 8 I cannot see the progress HUD displayed and what I get in my output window is:

2015-02-26 12:00:09.407 Angel[6336:100953] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x792c4740 H:[UIImageView:0x792cf380(-50)]>",
"<NSLayoutConstraint:0x792d6890 H:[UILabel:0x792c8480'Loading...']-(20)-| (Names: '|':UIImageView:0x792cf380 )>",
"<NSLayoutConstraint:0x792df990 H:|-(20)-[UILabel:0x792c8480'Loading...'] (Names: '|':UIImageView:0x792cf380 )>"
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x792d6890 H:[UILabel:0x792c8480'Loading...']-(20)-| (Names: '|':UIImageView:0x792cf380 )>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2015-02-26 12:00:09.407 Angel[6336:100953] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x792c4740 H:[UIImageView:0x792cf380(-50)]>"
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x792c4740 H:[UIImageView:0x792cf380(-50)]>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.

The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

I tried to move

[KVNProgress setConfiguration:[self customKVNProgressUIConfiguration:_deviceScreenSize]];
    [KVNProgress showWithStatus:NSLocalizedString(@"Loading...", nil)];

in "viewDidAppear" method instead of in "viewDidLoad" method. The first time I am able to display the progress HUD, but from the second one I get the same "warning message" in the output window and I was not able to see the progress HUD.

Could you try to fix it?

Thank you very much.

kevin-hirsch commented 9 years ago

Thanks!

Answer 1 · 2015-02-16T21:49:13.000Z

Hello @foffux, can you show me the KVNProgressConfiguration you use exactly? So I can try reproduce it and fix it.

Answer 2 · 2015-02-16T23:25:33.000Z

here also.. i've implemented it on a other uiview loaded at runtime. when i init kvn it says 'Unable to simultaneously satisfy constraints.' ... maybe you should do a version without autolayout? if something is not so correct it messes up all the things and kvn wont show up.

Answer 3 · 2015-02-17T08:39:55.000Z

Hello Kevin.
I think @justvanbloom could be right, in fact today with same code with same test, I cannot reproduce that issue anymore, even my self...
My

KVNProgressConfiguration

is really a basic one:

- (KVNProgressConfiguration *)customKVNProgressUIConfiguration:(NSInteger)deviceScreenSize
{
    KVNProgressConfiguration *configuration = [[KVNProgressConfiguration alloc] init];

    CGFloat circleSize;
    CGFloat statusFont;
    CGFloat lineWidth;
    if (deviceScreenSize == SCREEN_SIZE_IPAD_CLASSIC) {
        circleSize = 220.0f;
        statusFont = 30.0f;
        lineWidth = 2.0f;
    } else {
        circleSize = 110.0f;
        statusFont = 15.0f;
        lineWidth = 1.0f;
    }

    // See the documentation of KVNProgressConfiguration
    configuration.statusColor = [UIColor whiteColor];
    configuration.statusFont = [UIFont fontWithName:@"Play-Bold" size:statusFont];
    configuration.circleStrokeForegroundColor = [UIColor whiteColor];
    configuration.circleStrokeBackgroundColor = [UIColor colorWithWhite:1.0f alpha:0.3f];
    configuration.circleFillBackgroundColor = [UIColor colorWithWhite:1.0f alpha:0.1f];
    configuration.backgroundFillColor = [UIColor colorWithRed:0.173f green:0.263f blue:0.856f alpha:0.9f];
    configuration.backgroundTintColor = [UIColor colorWithRed:43/255.0f green:183/255.0f blue:185/255.0f alpha:1.0f];
    configuration.successColor = [UIColor whiteColor];
    configuration.errorColor = [UIColor whiteColor];
    configuration.circleSize = circleSize;
    configuration.lineWidth = lineWidth;

    return configuration;
}

Also for me: maybe you should do a version without auto layout? Or at least think about it?

Thank you very much.

Answer 4 · 2015-02-18T02:42:05.000Z

HA! its magic! ok.
so it's gone! it was a faulty autolayout issue by me. opened in xcode beta (latest) and i saw the broken things. sry. for all others: use masonry pod to get rid of..
close ?

Answer 5 · 2015-02-18T07:50:24.000Z

Hello @justvanbloom, what did you do to make this issue go away?
Is it related to Xcode 6.3 beta, or to Masonry pod?

Thanks for the enlightenment!

Answer 6 · 2015-02-18T07:59:13.000Z

I do not think it is due to Xcode 6.3 beta because I am not using it but
standard release. So I think it is Masonry pod, even if I do not know what
it is exactly.
I have to check.
Thank you anyway.

2015-02-18 8:50 GMT+01:00 Kevin Hirsch notifications@github.com:

Hello @justvanbloom https://github.com/justvanbloom, what did you do to
make this issue go away?
Is it related to Xcode 6.3 beta, or to Masonry pod?

Thanks for the enlightenment!

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

Answer 7 · 2015-02-18T08:02:25.000Z

So do we agree on closing this issue?

Answer 8 · 2015-02-18T08:05:01.000Z

If I was you I would wait. Let me try that Masonry pod. Then I will tell
you and after that you will close it.
Thank you.

2015-02-18 9:02 GMT+01:00 Kevin Hirsch notifications@github.com:

So do we agree on closing this issue?

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

Answer 9 · 2015-02-18T08:05:37.000Z

Okay, I wait for your review then, thanks a lot ! 👍

Answer 10 · 2015-02-18T08:10:59.000Z

hello @justvanbloom: could you please let us know how to use masonry pod tougher with KVNProgress?
Because, in my project, I am not using auto layout at all. So I cannot understand if this issue is related to KVNProgress that uses auto layout and so it must use it with masonry pod (in this case, how), or something else.
Can you get what I told? Is it clear?
Thank you.

Answer 11 · 2015-02-18T15:00:06.000Z

Ok. So ist easy. Make a broken autolayout element in storyboard, after this view is displayed, kvn wont show normally. I'll make a pull these days. Just for be sure :)

Answer 12 · 2015-02-18T17:41:40.000Z

Ok I will wait for your pull then to see if this issue had been solved.
Kevin, me too I want to make a pull. It is a simple change I need and I
guess it could be helpful. I have never done before. How am I suppose to do
that? Thank you.

Il mercoledì 18 febbraio 2015, JustVanBlooM <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> ha scritto:

Ok. So ist easy. Make a broken autolayout element in storyboard, after
this view is displayed, kvn wont show normally. I'll make a pull these
days. Just for be sure :)

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

Answer 13 · 2015-02-18T18:41:13.000Z

@justvanbloom:

I'll make a pull these days

You mean you'll make a pull of last Masonry commits to be sure this issue is fixed?

Answer 14 · 2015-02-20T17:46:21.000Z

Hello guys.
Any news about that pull that would fix this issue?
I am testing it on my real device and as soon as something goes wrong this controller is not shown anymore. iPhone 5s with iOS 8 is the device.
If it cannot be fixed, I have unfortunately to swap on another progress hud.
I look forward to a positive answer.
Thank you so much

Answer 15 · 2015-02-20T17:55:18.000Z

@foffux:
Same here. I thought i had fixed but its still not fixed. Can you post a log what goes wrong? Is it also a nslayout issue before?

Answer 16 · 2015-02-20T20:23:22.000Z

I will try to reproduce it.
I do not think in the we.
As soon as I can anyway and let you know
Thank you

Answer 17 · 2015-02-23T09:32:39.000Z

any news on this?

Answer 18 · 2015-02-23T13:08:58.000Z

Here I am.
I cannot write you directly from inside github, I do not know how...

What I can see testing it directly in my reals device, but just with iOS 8,
is the following:

2015-02-23 14:00:02.999 Angel[346:34741] Unable to simultaneously satisfy
constraints.

Probably at least one of the constraints in the following list is one you
don't want. Try this: (1) look at each constraint and try to figure out
which you don't expect; (2) find the code that added the unwanted
constraint or constraints and fix it. (Note: If you're seeing
NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the
documentation for the UIView property
translatesAutoresizingMaskIntoConstraints) *

(

"<NSLayoutConstraint:0x174487990 H:[UIImageView:0x1741fcd00(-50)]>",*
"<NSLayoutConstraint:0x174487210
H:[UILabel:0x1356938b0'Loading...']-(20)-| (Names:
'|':UIImageView:0x1741fcd00 )>",*
"<NSLayoutConstraint:0x1744873f0
H:|-(20)-[UILabel:0x1356938b0'Loading...'] (Names:
'|':UIImageView:0x1741fcd00 )>"*

)

*Will attempt to recover by breaking constraint *

<NSLayoutConstraint:0x174487210 H:[UILabel:0x1356938b0'Loading...']-(20)-|
(Names: '|':UIImageView:0x1741fcd00 )>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to
catch this in the debugger.

The methods in the UIConstraintBasedLayoutDebugging category on UIView
listed in <UIKit/UIView.h> may also be helpful.

2015-02-23 14:00:03.000 Angel[346:34741] Unable to simultaneously satisfy
constraints.

Probably at least one of the constraints in the following list is one you
don't want. Try this: (1) look at each constraint and try to figure out
which you don't expect; (2) find the code that added the unwanted
constraint or constraints and fix it. (Note: If you're seeing
NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the
documentation for the UIView property
translatesAutoresizingMaskIntoConstraints) *

(

"<NSLayoutConstraint:0x174487990 H:[UIImageView:0x1741fcd00(-50)]>"*

)

*Will attempt to recover by breaking constraint *

<NSLayoutConstraint:0x174487990 H:[UIImageView:0x1741fcd00(-50)]>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to
catch this in the debugger.

The methods in the UIConstraintBasedLayoutDebugging category on UIView
listed in <UIKit/UIView.h> may also be helpful.

I hope this can help to understand how to fix this problem.

Let me know.

2015-02-23 10:32 GMT+01:00 JustVanBlooM notifications@github.com:

any news on this?

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

Answer 19 · 2015-02-23T17:10:41.000Z

Yep. Exactly this is it. So it seems autolayout is broken..

@kevin ?

Answer 20 · 2015-02-24T08:44:55.000Z

Sorry for yesterday. I wasn't available.
So, to be clear, it is just an auto layout issue on iOS 8 that has nothing to do with another library like Masonry and it happens every time you show the KVNProgress HUD, no matter when in the app lifetime. Am I right ?
And, when you talk about iOS 8, you mean 8.0+ or a newer version ?
I will take a look at it, see if I can see what's wrong with the constraints.

Answer 21 · 2015-02-24T08:55:43.000Z

Hello guys:
yes is an auto layout issue on iOS 8, anyway every logs I retrieved I have already attached them to this issue so you can have a look at them.
I am using iOS 8.1.2.
It does not happen every time but very often. In iOS 7 no issue at all, never. Yes, no matter when in the app lifetime.
Okay thank you very much, because I really need this controller and I would keep using it.

Answer 22 · 2015-02-24T10:09:35.000Z

Thank you for the details! I will check that tonight (GMT+1) ;)

Answer 23 · 2015-02-24T10:12:03.000Z

Okay, have a nice chase... :-)
Let me know if you need something, I would be able to close this issue in a few time.

Answer 24 · 2015-02-24T15:55:38.000Z

Great! i will also use this controller for a few projects. Ofc including Acknowledgments in AppSettings / info!

Answer 25 · 2015-02-24T22:39:12.000Z

It seems that there is a problem coming from the width constraint on the contentView:

NSLayoutConstraint: @"H:[UIImageView(-50)]"

It shouldn't be -50. It should be a positive number.

I was not able to reproduce the bug using Simulator iPhone 5 and 6 on iOS 8.1 and my own iPhone 6 device on iOS 8.1.3 using Xcode 6.1.1 (6A2008a). I tested all orientations also.

@foffux, can you precise some things for me, please:

The Xcode version you are using
The KVNProgress version you are using
The device you tested/reproduced the bug on (Simulator, iPhone 5, ...)
The orientation you tested/reproduced the bug with

Thanks for the details.

Answer 26 · 2015-02-25T00:48:50.000Z

Xcode Version 6.1.1 (6A2008a)
iPhone 6 and 6 Plus
KVNProgress latest from pods
Portrait..

Same :) ok. so its just this?

Answer 27 · 2015-02-25T07:05:37.000Z

Xcode: same version you used if I ma not wrong. I have to check.
Kvnprogress: latest from cocoa pods
Device: iPhone 5 s, iOS 8.1.2
Orientation: just portrait

Pay attention: it does not happen every time. But when happens then it won't show anymore.
It happens more often in the device than in the simulator. But always with iOS 8 not in iOS 7.
When happens in the console you can see logs I attached.

Question: if you think problem is what you highlighted, give me a debug version with traces on, I will test it for you. Okay?

Thanks

Inviato da iPhone

Il giorno 24/feb/2015, alle ore 23:39, Kevin Hirsch notifications@github.com ha scritto:

It seems that there is a problem coming from the width constraint on the contentView:

NSLayoutConstraint: @"H:[UIImageView(-50)]"
It shouldn't be -50. It should be a positive number.

I was not able to reproduce the bug using Simulator iPhone 5 and 6 on iOS 8.1 and my own iPhone 6 device on iOS 8.1.3 using Xcode 6.1.1 (6A2008a). I tested all orientations also.

@foffux, can you precise some things for me, please:

The Xcode version you are using
The KVNProgress version you are using
The device you tested/reproduced the bug on (Simulator, iPhone 5, ...)
The orientation you tested/reproduced the bug with
Thanks for the details.

—
Reply to this email directly or view it on GitHub.

Answer 28 · 2015-02-25T08:09:21.000Z

Strange, I am not able to reproduce it. If you want to debug it, I created a branch invisible-hud. Just checkout the branch and change use the KVNPRogress.m file to have the logs. Thanks!

Answer 29 · 2015-02-25T15:51:53.000Z

Here I am.
I am able to reproduce this bug systematically, at least in my project.
Here you are logs you inserted:

2015-04-01 12:02:09.109 Angel[5591:104643] ===== SHOWING HUD
2015-04-01 12:02:09.412 Angel[5591:104643] ===== SHOWING HUD
2015-04-01 12:02:09.413 Angel[5591:104643] ==== SETTING UI
2015-04-01 12:02:09.413 Angel[5591:104643] ===== SETTING BASE CONSTRAINTS
2015-04-01 12:02:09.413 Angel[5591:104643] = bounds: {{0, 0}, {0, 0}}
2015-04-01 12:02:09.413 Angel[5591:104643] = statusInset: 10.000000
2015-04-01 12:02:09.413 Angel[5591:104643] = fullScreen: 0
2015-04-01 12:02:09.414 Angel[5591:104643] = contentWidth: -50.000000
2015-04-01 12:02:09.414 Angel[5591:104643] ===== FINISH SETTING BASE CONSTRAINTS
2015-04-01 12:02:09.414 Angel[5591:104643] ==== FINISH SETTING UI
2015-04-01 12:02:09.415 Angel[5591:104643] ===== FINISH SHOWING HUD
2015-04-01 12:02:11.569 Angel[5591:104643] ==== DISMISSING HUD
2015-04-01 12:02:11.975 Angel[5591:104643] ==== FINISH DISMISSING HUD

Issue seems to be exactly in the place you talked about:
2015-04-01 12:02:09.414 Angel[5591:104643] = contentWidth: -50.000000

Another occurrence, maybe this log can help you more:

2015-04-01 12:01:28.499 Angel[5591:104643] ===== SHOWING HUD
2015-04-01 12:01:28.500 Angel[5591:104643] ===== ADDING TO SUPERVIEW: <UIWindow: 0x7c1503d0; frame = (0 0; 0 0); hidden = YES; gestureRecognizers = <NSArray: 0x7c11b200>; layer = <UIWindowLayer: 0x7c146da0>>
2015-04-01 12:01:28.501 Angel[5591:104643] ===== FINISH ADDING TO SUPERVIEW: <UIWindow: 0x7c1503d0; frame = (0 0; 0 0); hidden = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x7c11b200>; layer = <UIWindowLayer: 0x7c146da0>>
2015-04-01 12:01:28.501 Angel[5591:104643] ==== SETTING UI
2015-04-01 12:01:28.501 Angel[5591:104643] ===== SETTING BASE CONSTRAINTS
2015-04-01 12:01:28.501 Angel[5591:104643] = bounds: {{0, 0}, {0, 0}}
2015-04-01 12:01:28.501 Angel[5591:104643] = statusInset: 10.000000
2015-04-01 12:01:28.501 Angel[5591:104643] = fullScreen: 0
2015-04-01 12:01:28.501 Angel[5591:104643] = contentWidth: -50.000000
2015-04-01 12:01:28.506 Angel[5591:104643] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7c16f870 H:[UIImageView:0x7c16cd30(-50)]>",
"<NSLayoutConstraint:0x7c1a05e0 H:[UILabel:0x7c1bf210'Comunicazione avvenuta']-(20)-| (Names: '|':UIImageView:0x7c16cd30 )>",
"<NSLayoutConstraint:0x7c1a0640 H:|-(20)-[UILabel:0x7c1bf210'Comunicazione avvenuta'] (Names: '|':UIImageView:0x7c16cd30 )>"
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7c1a05e0 H:[UILabel:0x7c1bf210'Comunicazione avvenuta']-(20)-| (Names: '|':UIImageView:0x7c16cd30 )>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2015-04-01 12:01:28.507 Angel[5591:104643] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7c16f870 H:[UIImageView:0x7c16cd30(-50)]>"
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7c16f870 H:[UIImageView:0x7c16cd30(-50)]>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2015-04-01 12:01:28.507 Angel[5591:104643] ===== FINISH SETTING BASE CONSTRAINTS
2015-04-01 12:01:28.535 Angel[5591:104643] ===== UPDATING BACKGROUND CONSTRAINTS
2015-04-01 12:01:28.535 Angel[5591:104643] = fullScreen: 0
2015-04-01 12:01:28.535 Angel[5591:104643] = status: Lotteria...
2015-04-01 12:01:28.535 Angel[5591:104643] = contentViewWidth: -50.000000
2015-04-01 12:01:28.536 Angel[5591:104643] ===== FINISH UPDATING BACKGROUND CONSTRAINTS
2015-04-01 12:01:28.536 Angel[5591:104643] ==== FINISH SETTING UI
2015-04-01 12:01:28.536 Angel[5591:104643] ===== FINISH SHOWING HUD

Hope this can help you solving this blocking issue.

Thank you.

Answer 30 · 2015-02-25T16:08:17.000Z

Thank you very much! The problem is now obvious:

bounds: {{0, 0}, {0, 0}}

This is not normal. I will look at it tomorrow ;)

Answer 31 · 2015-02-25T16:21:03.000Z

Ah okay, of course:

bounds: {{0, 0}, {0, 0}}

is not a good value...:-)
Perfect.
I will look forward to seeing what was the actual problem.
Thank you.

Answer 32 · 2015-02-25T16:24:27.000Z

Ah! Digging into it later..

Answer 33 · 2015-02-27T08:10:29.000Z

Hello guys
Any good news?
Think you

Answer 34 · 2015-02-27T08:21:11.000Z

In the method addToView: the constraints are set to the key window if displaying in fullscreen. Maybe the problem here is that your projects are not using auto layout. Can you confirm that, @foffux & @justvanbloom?

Answer 35 · 2015-02-27T08:33:34.000Z

I use autolayout in xib based things and mixed in code something with, something absolute positioned.. Well, just check in view.bounds for 0,0,0,0 on creation?

Answer 36 · 2015-02-27T08:34:52.000Z

Absolutely, I am not using auto layout in all my projects and I do not want to use them, at least at the moment. So if your controller could work also without auto layout it should be very nice and helpful.
Thank you very much and let us know how it proceeds.

Answer 37 · 2015-02-27T09:04:29.000Z

@foffux: I don't want to remove auto layout from my project but I will do a new commit tonight (GMT+1) with a fix. You will be able to test it and tell me if it solves your problem ;)

Answer 38 · 2015-02-27T09:08:31.000Z

Okay okay no problem at all with auto layout. The only thing I am interested in is that I am able to use your controller. Just that.
No problem with testing your fixing commit, but unfortunately I am not at home untill next tuesday. So I will test it on that day. I do not know if in the meantime @justvanbloom can test it too. Anyway, as soon as I will come back home I will test it.
Thank you.

Answer 39 · 2015-02-27T09:10:19.000Z

@foffux: no problem!

Answer 40 · 2015-02-27T09:12:40.000Z

Can test it asap:)

Answer 41 · 2015-02-27T09:13:52.000Z

ok great
see you soon then with this issue closed, I hope

Answer 42 · 2015-02-28T07:16:19.000Z

I made a new commit to try to fix this issue. You can test it by pulling branch invisible-hud.
I also add a new log just after:

===== ADDING TO SUPERVIEW:

to check that the superview bounds are correct:

= superview bounds:

Hopes it solves the problem. Keep me updated. Thanks!

Answer 43 · 2015-02-28T18:32:59.000Z

hmm.. current state:

===== SHOWING HUD
2015-02-28 19:29:36.606 -beta1[487:68980] ===== ADDING TO SUPERVIEW: <UIWindow: 0x156d0db40; frame = (0 0; 0 0); hidden = YES; gestureRecognizers = <NSArray: 0x174441ce0>; layer = <UIWindowLayer: 0x17442bf40>>
2015-02-28 19:29:36.606 -beta1[487:68980] = superview bounds: {{0, 0}, {0, 0}}
2015-02-28 19:29:36.611 -beta1[487:68980] ===== FINISH ADDING TO SUPERVIEW: <UIWindow: 0x156d0db40; frame = (0 0; 0 0); hidden = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x174441ce0>; layer = <UIWindowLayer: 0x17442bf40>>
2015-02-28 19:29:36.612 -beta1[487:68980] ==== SETTING UI
2015-02-28 19:29:36.613 -beta1[487:68980] ===== SETTING BASE CONSTRAINTS
2015-02-28 19:29:36.614 -beta1[487:68980] = bounds: {{0, 0}, {0, 0}}
2015-02-28 19:29:36.614 -beta1[487:68980] = statusInset: 10.000000
2015-02-28 19:29:36.615 -beta1[487:68980] = fullScreen: 0
2015-02-28 19:29:36.616 -beta1[487:68980] = contentWidth: -50.000000
2015-02-28 19:29:36.618 -beta1[487:68980] Unable to simultaneously satisfy constraints.
(

"<NSLayoutConstraint:0x174489ab0 UIImageView:0x156d7da80.width == -50>",
"<NSLayoutConstraint:0x174489790 UIImageView:0x156d7da80.trailing == UILabel:0x156d7dbc0.trailing + 20>",
"<NSLayoutConstraint:0x17448a690 UILabel:0x156d7dbc0.leading == UIImageView:0x156d7da80.leading + 20>"

)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x174489790 UIImageView:0x156d7da80.trailing == UILabel:0x156d7dbc0.trailing + 20>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.

The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

2015-02-28 19:29:36.621 -beta1[487:68980] Unable to simultaneously satisfy constraints.

Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)

(

"<NSLayoutConstraint:0x174489ab0 UIImageView:0x156d7da80.width == -50>"

)

Will attempt to recover by breaking constraint

<NSLayoutConstraint:0x174489ab0 UIImageView:0x156d7da80.width == -50>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.

Answer 44 · 2015-02-28T18:36:18.000Z

why this? before i have a broken constraint added to uiview.. and if its there it wont show.
2015-02-28 19:29:36.606 -beta1[487:68980] = superview bounds: {{0, 0}, {0, 0}}
i've added KVN AFTER the broken constraint from the other view is shoed.. if it gets added before there is no probelm showing KVN.
So simply checking superview bounds for nil eg. {{0, 0}, {0, 0}} and grad uiapplication mainscreen size should solve it or?

Answer 45 · 2015-02-28T18:46:37.000Z

so the fix is:
superview = [UIApplication sharedApplication].keyWindow;
if (!superview) {
superview = [[UIApplication sharedApplication].windows objectAtIndex:0];
}
in

(void)addToView:(UIView *)superview
{
#warning fix
superview = [UIApplication sharedApplication].keyWindow;
if (!superview) {
superview = [[UIApplication sharedApplication].windows objectAtIndex:0];
}

NSLog(@"===== ADDING TO SUPERVIEW: %@", superview);

Answer 46 · 2015-02-28T18:47:36.000Z

Will attempt to recover by breaking constraint

<NSLayoutConstraint:0x1742896f0 UILabel:0x13fd12b80.width == 217>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.

The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

2015-02-28 19:45:15.220 beta1[493:71552] -[MasterViewController hideSettingsView] [Line 3176] hide

2015-02-28 19:45:15.473 beta1[493:71552] __40-[MasterViewController hideSettingsView]_block_invoke1563 [Line 3191] Animation finished

2015-02-28 19:45:19.942 beta1[493:71552] -[MasterViewController icloudsync:] [Line 3298] icloud sync

2015-02-28 19:45:19.956 beta1[493:71552] ===== SHOWING HUD

2015-02-28 19:45:19.958 beta1[493:71552] ===== ADDING TO SUPERVIEW: <UIWindow: 0x13fe0b2b0; frame = (0 0; 414 736); autoresize = W+H; gestureRecognizers = <NSArray: 0x17024b880>; layer = <UIWindowLayer: 0x170220f20>>

2015-02-28 19:45:19.958 beta1[493:71552] = superview bounds: {{0, 0}, {413.99999999999994, 736.00000000000011}}

2015-02-28 19:45:19.965 beta1[493:71552] ===== FINISH ADDING TO SUPERVIEW: <UIWindow: 0x13fe0b2b0; frame = (0 0; 414 736); autoresize = W+H; gestureRecognizers = <NSArray: 0x17024b880>; layer = <UIWindowLayer: 0x170220f20>>

2015-02-28 19:45:19.966 beta1[493:71552] ==== SETTING UI

2015-02-28 19:45:19.966 beta1[493:71552] ===== SETTING BASE CONSTRAINTS

2015-02-28 19:45:19.967 beta1[493:71552] = bounds: {{0, 0}, {413.99999999999994, 736.00000000000011}}

Answer 47 · 2015-03-01T09:36:35.000Z

Hello guys
So if I can understand, the state of art is that this issue is still there. Right?
@kevin: any news after latest comments made in your fix?
Thank you

Answer 48 · 2015-03-01T14:31:03.000Z

@foffux: temporally fix: search -(void)addToView

Insert fix

-(void)addToView:(UIView *)superview
{
#warning fix
superview = [UIApplication sharedApplication].keyWindow;
if (!superview) {
superview = [[UIApplication sharedApplication].windows objectAtIndex:0];
}
#warning fix

Answer 49 · 2015-03-01T17:29:12.000Z

Okay thank you I will try as soon as I will come back home. Should this fix the issue? Have you already try it?

Answer 50 · 2015-03-01T17:48:15.000Z

Jep. This fixed it.

Answer 51 · 2015-03-01T18:40:57.000Z

@justvanbloom: when adding the full screen HUD, it is calling:

- (void)addToCurrentWindow
{
    UIWindow *currentWindow = nil;

    NSEnumerator *frontToBackWindows = [[[UIApplication sharedApplication] windows] reverseObjectEnumerator];

    for (UIWindow *window in frontToBackWindows) {
        if (window.windowLevel == UIWindowLevelNormal) {
            currentWindow = window;
            break;
        }
    }

    if (self.superview != currentWindow) {
        [self addToView:currentWindow];
    }
}

So changing the way to get the current window to yours should resolve the problem:

- (void)addToCurrentWindow
{
    UIWindow *currentWindow = [UIApplication sharedApplication].keyWindow;

    if (!currentWindow) {
        NSEnumerator *frontToBackWindows = [[[UIApplication sharedApplication] windows] reverseObjectEnumerator];

        for (UIWindow *window in frontToBackWindows) {
            if (window.windowLevel == UIWindowLevelNormal) {
                currentWindow = window;
                break;
            }
        }
    }

    if (self.superview != currentWindow) {
        [self addToView:currentWindow];
    }
}

Do you agree? Can I make a new commit with these modifications so you can check that everything works correctly?

Answer 52 · 2015-03-01T18:53:51.000Z

ah! yep. but to get top window on superview i call
[[UIApplication sharedApplication].windows objectAtIndex:0] ..

let me know

Answer 53 · 2015-03-01T20:08:15.000Z

I think doing the for through all windows is better instead of [[UIApplication sharedApplication].windows objectAtIndex:0] but I will put a new commit with my code above so you will be able to test it and validate that it works, okay for you?

Answer 54 · 2015-03-03T01:19:34.000Z

[[UIApplication sharedApplication].windows objectAtIndex:0] is topview.. ok wayne! both works! great.

(close?)

Answer 55 · 2015-03-03T09:52:13.000Z

Great!
@foffux: can you confirm this works for you too?
I will merge it to develop and make a new cocoa pods version tomorrow night ;)

Answer 56 · 2015-03-03T11:25:01.000Z

Hello
I can test if today in the afternoon.
Can you tell what exactly I have to take it to test the state of art?
Thank you

Inviato da iPhone

Il giorno 03/mar/2015, alle ore 09:52, Kevin Hirsch notifications@github.com ha scritto:

Great!
@foffux: can you confirm this works for you too?
I will merge it to develop and make a new cocoa pods version tomorrow night ;)

—
Reply to this email directly or view it on GitHub.

Answer 57 · 2015-03-03T13:24:42.000Z

@foffux: You just have to pull the invisible-hud branch and change the source file KVNProgress.m in your project by the one from invisible-hud branch and test ;)

Answer 58 · 2015-03-03T21:18:00.000Z

Hello
I was testing your latest fixes.
It is not simple to explain, but the very latest fix (6139b95) I do not think is a good fix for every situation. In particular, I can see in some situation that the HUD is first shown but suddenly it disappears and it is not good at all. But in some other situation this does not happen.
In my opinion this could happen when another view is shown in the same time (at about) or immediately after, like alert view or ADS.
Instead, with just this fix and without the latest one:

// Fix for non autolayout project
self.frame = superview.bounds;

I can see everything is okay. Tomorrow I will make some other tests. But could you please explain me the latest fix (6139b95) and think about what I told about other view shown (alert, ADS), and also think about do not commit fix 6139b95 but just the line of code I highlighted above?
Thank you very much.

P.S.
But after HUD is dismissed, is current window status reestablished as it was before? Because when also ADS is displayed in my opinion something mess up the current window status and after HUD is dismissed ADS, for example, cannot be show at least until a new banner is loaded.
This is what I have seen, I tell you just to add some more information.

Answer 59 · 2015-03-04T22:30:38.000Z

Hello @foffux,

You are right, I think that displaying UIAlertView is adding a UIWindow with the alert view inside and this window is set as the keyWindow with a window.windowLevel == UIWindowLevelAlert.
So displaying KVNProgress too quick after displaying an alert view is adding the HUD to the alert view window and this is not correct.

@justvanbloom: I'm wondering, where do you call KVNProgress in your code? How is it possible that

NSEnumerator *frontToBackWindows = [[[UIApplication sharedApplication] windows] reverseObjectEnumerator];

for (UIWindow *window in frontToBackWindows) {
    if (window.windowLevel == UIWindowLevelNormal) {
        currentWindow = window;
        break;
    }
 }

is not working for you and that your logs prints ===== ADDING TO SUPERVIEW: ; layer = > like ; layer = > was a view not set where the layer equals nothing.

What I have in the log looks like this: ===== ADDING TO SUPERVIEW: <UIWindow: 0x7fad40c997e0; frame = (0 0; 375 667); gestureRecognizers = <NSArray: 0x7fad40c9a170>; layer = <UIWindowLayer: 0x7fad40c96a10>>

Answer 60 · 2015-03-05T14:51:44.000Z

Hello Kevin.
So, your advice, if I can understand, is to keep all your current fixes in
invisible-hud and pay attention to not call KVNProgress too quick when
alert view is still present. Am I right?
I will try it, hoping to solve my problems.
I will let you know as soon as possible.
Thank you.

2015-03-04 23:30 GMT+01:00 Kevin Hirsch notifications@github.com:

Hello @foffux https://github.com/foffux,

You are right, I think that displaying UIAlertView is adding a UIWindow
with the alert view inside and this window is set as the keyWindow with a window.windowLevel
== UIWindowLevelAlert.
So displaying KVNProgress too quick after displaying an alert view is
adding the HUD to the alert view window and this is not correct.
@justvanbloom https://github.com/justvanbloom: I'm wondering, where do
you call KVNProgress in your code? How is it possible that

NSEnumerator *frontToBackWindows = [[[UIApplication sharedApplication] windows] reverseObjectEnumerator];
for (UIWindow *window in frontToBackWindows) {
if (window.windowLevel == UIWindowLevelNormal) {
currentWindow = window;
break;
}
}

is not working for you and that your logs prints ===== ADDING TO
SUPERVIEW: ; layer = > like ; layer = > was a view not set where the layer
equals nothing.

What I have in the log looks like this: ===== ADDING TO SUPERVIEW:
<UIWindow: 0x7fad40c997e0; frame = (0 0; 375 667); gestureRecognizers =
<NSArray: 0x7fad40c9a170>; layer = <UIWindowLayer: 0x7fad40c96a10>>

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

Answer 61 · 2015-03-05T17:26:48.000Z

@foffux, what I am saying is that I think I should undo commit 6139b95 because it is indeed messing with alert views but I want to be sure to resolve @justvanbloom's problem who needs commit 6139b95.

@justvanbloom, any news for my comment above?

Answer 62 · 2015-03-06T06:39:57.000Z

Ah okay kevin. But then, we have not solved the main problem yet because even if I told you with just the fix related to setting bounds it è was disappeared, in fact this is not true because unfortunately I can see the same issue with the same debug traces dispyed. So do we need to restart the chase?
Let me know guys.

Inviato da iPhone

Il giorno 05/mar/2015, alle ore 18:26, Kevin Hirsch notifications@github.com ha scritto:

@foffux, what I am saying is that I think I should undo commit 6139b95 because it is indeed messing with alert views but I want to be sure to resolve @justvanbloom's problem who needs commit 6139b95.

@justvanbloom, any news for my comment above?

—
Reply to this email directly or view it on GitHub.

Answer 63 · 2015-03-06T08:06:17.000Z

Well, besides my fix worked for fullscreen. I'll make later a fix for controller in uiview as kevin mentioned my pull request wont fix this.
Stay tuned.

Von meinem iPhone gesendet

Am 06.03.2015 um 07:39 schrieb foffux notifications@github.com:

Ah okay kevin. But then, we have not solved the main problem yet because even if I told you with just the fix related to setting bounds it è was disappeared, in fact this is not true because unfortunately I can see the same issue with the same debug traces dispyed. So do we need to restart the chase?
Let me know guys.

Inviato da iPhone

Il giorno 05/mar/2015, alle ore 18:26, Kevin Hirsch notifications@github.com ha scritto:

@foffux, what I am saying is that I think I should undo commit 6139b95 because it is indeed messing with alert views but I want to be sure to resolve @justvanbloom's problem who needs commit 6139b95.

@justvanbloom, any news for my comment above?

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

Answer 64 · 2015-03-06T08:22:17.000Z

@foffux: If you still have the problem, can you put here the logs you have in your console please?

Answer 65 · 2015-03-06T16:25:22.000Z

Hello Kevin.
I tested more in depth my app. Here you are my conclusions.
All fixes you did in

 invisible-hud

are good because now I can see HUD in almost every scenarios with good logs. Take a look below:

 2015-03-16 12:00:10.917 Angel[3432:116073] ===== SHOWING HUD
2015-03-16 12:00:10.918 Angel[3432:116073] ===== ADDING TO SUPERVIEW: <UIWindow: 0x7a76d600; frame = (0 0; 320 480); autoresize = W+H; gestureRecognizers = <NSArray: 0x7a76de10>; layer = <UIWindowLayer: 0x7a76d7b0>>
2015-03-16 12:00:10.918 Angel[3432:116073] = superview bounds: {{0, 0}, {320, 480}}
2015-03-16 12:00:10.919 Angel[3432:116073] ===== FINISH ADDING TO SUPERVIEW: <UIWindow: 0x7a76d600; frame = (0 0; 320 480); autoresize = W+H; gestureRecognizers = <NSArray: 0x7a76de10>; layer = <UIWindowLayer: 0x7a76d7b0>>
2015-03-16 12:00:10.920 Angel[3432:116073] ==== SETTING UI
2015-03-16 12:00:10.920 Angel[3432:116073] ===== SETTING BASE CONSTRAINTS
2015-03-16 12:00:10.920 Angel[3432:116073] = bounds: {{0, 0}, {320, 480}}
2015-03-16 12:00:10.920 Angel[3432:116073] = statusInset: 10.000000
2015-03-16 12:00:10.920 Angel[3432:116073] = fullScreen: 0
2015-03-16 12:00:10.921 Angel[3432:116073] = contentWidth: 270.000000
2015-03-16 12:00:10.921 Angel[3432:116073] ===== FINISH SETTING BASE CONSTRAINTS
2015-03-16 12:00:11.084 Angel[3432:116073] ===== UPDATING BACKGROUND CONSTRAINTS
2015-03-16 12:00:11.084 Angel[3432:116073] = fullScreen: 0
2015-03-16 12:00:11.085 Angel[3432:116073] = status: Lotteria...
2015-03-16 12:00:11.085 Angel[3432:116073] = contentViewWidth: 270.000000
2015-03-16 12:00:11.085 Angel[3432:116073] ===== FINISH UPDATING BACKGROUND CONSTRAINTS
2015-03-16 12:00:11.085 Angel[3432:116073] ==== FINISH SETTING UI
2015-03-16 12:00:11.085 Angel[3432:116073] ===== FINISH SHOWING HUD
2015-03-16 12:00:11.086 Angel[3432:116073] sendingDataToServer
2015-03-16 12:00:11.545 Angel[3432:116073] ===== SHOWING HUD
2015-03-16 12:00:11.856 Angel[3432:116073] ===== SHOWING HUD
2015-03-16 12:00:11.856 Angel[3432:116073] ==== SETTING UI
2015-03-16 12:00:11.857 Angel[3432:116073] ===== SETTING BASE CONSTRAINTS
2015-03-16 12:00:11.857 Angel[3432:116073] = bounds: {{0, 0}, {320, 480}}
2015-03-16 12:00:11.857 Angel[3432:116073] = statusInset: 10.000000
2015-03-16 12:00:11.857 Angel[3432:116073] = fullScreen: 0
2015-03-16 12:00:11.858 Angel[3432:116073] = contentWidth: 270.000000
2015-03-16 12:00:11.858 Angel[3432:116073] ===== FINISH SETTING BASE CONSTRAINTS
2015-03-16 12:00:11.859 Angel[3432:116073] ==== FINISH SETTING UI
2015-03-16 12:00:11.860 Angel[3432:116073] ===== FINISH SHOWING HUD
2015-03-16 12:00:14.039 Angel[3432:116073] ==== DISMISSING HUD
2015-03-16 12:00:14.444 Angel[3432:116073] ==== FINISH DISMISSING HUD

There is just a scenario where I can see problems, but I do not think related to same issue. This scenario is when I launch HUD after tapping an alert button. In this scenario the bad thing is that the HUD suddenly disappear before it had to. But also in this case your logs are good, take a look (iOS 8):

 2015-03-16 12:06:06.095 Angel[4795:151930] ===== SHOWING HUD
2015-03-16 12:06:10.165 Angel[4795:151930] ===== ADDING TO SUPERVIEW: <_UIAlertControllerShimPresenterWindow: 0x7c98d6a0; frame = (0 0; 320 480); opaque = NO; autoresize = W+H; gestureRecognizers = <NSArray: 0x7c9c3d30>; layer = <UIWindowLayer: 0x78f0c950>>
2015-03-16 12:06:10.166 Angel[4795:151930] = superview bounds: {{0, 0}, {320, 480}}
2015-03-16 12:06:10.167 Angel[4795:151930] ===== FINISH ADDING TO SUPERVIEW: <_UIAlertControllerShimPresenterWindow: 0x7c98d6a0; frame = (0 0; 320 480); opaque = NO; autoresize = W+H; gestureRecognizers = <NSArray: 0x7c9c3d30>; layer = <UIWindowLayer: 0x78f0c950>>
2015-03-16 12:06:10.167 Angel[4795:151930] ==== SETTING UI
2015-03-16 12:06:10.168 Angel[4795:151930] ===== SETTING BASE CONSTRAINTS
2015-03-16 12:06:10.168 Angel[4795:151930] = bounds: {{0, 0}, {320, 480}}
2015-03-16 12:06:10.168 Angel[4795:151930] = statusInset: 10.000000
2015-03-16 12:06:10.168 Angel[4795:151930] = fullScreen: 0
2015-03-16 12:06:10.168 Angel[4795:151930] = contentWidth: 270.000000
2015-03-16 12:06:10.169 Angel[4795:151930] ===== FINISH SETTING BASE CONSTRAINTS
2015-03-16 12:06:10.294 Angel[4795:151930] ===== UPDATING BACKGROUND CONSTRAINTS
2015-03-16 12:06:10.294 Angel[4795:151930] = fullScreen: 0
2015-03-16 12:06:10.294 Angel[4795:151930] = status: Lotteria...
2015-03-16 12:06:10.295 Angel[4795:151930] = contentViewWidth: 270.000000
2015-03-16 12:06:10.295 Angel[4795:151930] ===== FINISH UPDATING BACKGROUND CONSTRAINTS
2015-03-16 12:06:10.295 Angel[4795:151930] ==== FINISH SETTING UI
2015-03-16 12:06:10.295 Angel[4795:151930] ===== FINISH SHOWING HUD
2015-03-16 12:06:10.295 Angel[4795:151930] sendingDataToServer
2015-03-16 12:06:10.746 Angel[4795:151930] ===== SHOWING HUD
2015-03-16 12:06:11.073 Angel[4795:151930] ===== SHOWING HUD
2015-03-16 12:06:11.074 Angel[4795:151930] ==== SETTING UI
2015-03-16 12:06:11.074 Angel[4795:151930] ===== SETTING BASE CONSTRAINTS
2015-03-16 12:06:11.074 Angel[4795:151930] = bounds: {{0, 0}, {320, 480}}
2015-03-16 12:06:11.074 Angel[4795:151930] = statusInset: 10.000000
2015-03-16 12:06:11.075 Angel[4795:151930] = fullScreen: 0
2015-03-16 12:06:11.075 Angel[4795:151930] = contentWidth: 270.000000
2015-03-16 12:06:11.075 Angel[4795:151930] ===== FINISH SETTING BASE CONSTRAINTS
2015-03-16 12:06:11.075 Angel[4795:151930] ==== FINISH SETTING UI
2015-03-16 12:06:11.076 Angel[4795:151930] ===== FINISH SHOWING HUD
2015-03-16 12:06:13.275 Angel[4795:151930] ==== DISMISSING HUD
2015-03-16 12:06:13.677 Angel[4795:151930] ==== FINISH DISMISSING HUD

In iOS 7, instead:

2015-03-16 12:00:09.272 Angel[5146:60b] ===== SHOWING HUD
2015-03-16 12:00:09.273 Angel[5146:60b] ===== ADDING TO SUPERVIEW: <_UIModalItemHostingWindow: 0x7b6de790; frame = (0 0; 320 480); gestureRecognizers = <NSArray: 0x7b6dec90>; layer = <UIWindowLayer: 0x7b6de910>>
2015-03-16 12:00:09.273 Angel[5146:60b] = superview bounds: {{0, 0}, {320, 480}}
2015-03-16 12:00:09.276 Angel[5146:60b] ===== FINISH ADDING TO SUPERVIEW: <_UIModalItemHostingWindow: 0x7b6de790; frame = (0 0; 320 480); autoresize = W+H; gestureRecognizers = <NSArray: 0x7b6dec90>; layer = <UIWindowLayer: 0x7b6de910>>
2015-03-16 12:00:09.277 Angel[5146:60b] ==== SETTING UI
2015-03-16 12:00:09.277 Angel[5146:60b] ===== SETTING BASE CONSTRAINTS
2015-03-16 12:00:09.278 Angel[5146:60b] = bounds: {{0, 0}, {320, 480}}
2015-03-16 12:00:09.278 Angel[5146:60b] = statusInset: 10.000000
2015-03-16 12:00:09.279 Angel[5146:60b] = fullScreen: 0
2015-03-16 12:00:09.279 Angel[5146:60b] = contentWidth: 270.000000
2015-03-16 12:00:09.279 Angel[5146:60b] ===== FINISH SETTING BASE CONSTRAINTS
2015-03-16 12:00:09.361 Angel[5146:60b] ===== UPDATING BACKGROUND CONSTRAINTS
2015-03-16 12:00:09.361 Angel[5146:60b] = fullScreen: 0
2015-03-16 12:00:09.362 Angel[5146:60b] = status: Lotteria...
2015-03-16 12:00:09.362 Angel[5146:60b] = contentViewWidth: 270.000000
2015-03-16 12:00:09.362 Angel[5146:60b] ===== FINISH UPDATING BACKGROUND CONSTRAINTS
2015-03-16 12:00:09.362 Angel[5146:60b] ==== FINISH SETTING UI
2015-03-16 12:00:09.362 Angel[5146:60b] ===== FINISH SHOWING HUD
2015-03-16 12:00:09.363 Angel[5146:60b] sendingDataToServer
2015-03-16 12:00:12.995 Angel[5146:60b] MOPUB: MoPub HTML banner did load
2015-03-16 12:00:13.053 Angel[5146:60b] ===== SHOWING HUD

I do not see anything wrong. Do you agree? I thought it could be caused by the fact that I was not updated my alert view to new alert view controller, but it happened also in iOS 7...

In my opinion, you could merge what you did in the master (also with my pull request) and from that, we can start to analyze also this problem. Certainly, latest code is much more usable than before and even if there is this kind of problem is not a big issue, at least at the moment.

This is what I think.
What do you think? @kevin-hirsch, @justvanbloom: do you agree?

Answer 66 · 2015-03-06T17:46:18.000Z

@foffux, everything seems great except for the window the KVNProgress is added on, on iOS 8:

_UIAlertControllerShimPresenterWindow

and on iOS 7:

_UIModalItemHostingWindow

Do you have the same logs with the same windows without code from commit 6139b95?

Also, when are you calling KVNProgress after a UIAlertView: alertView:clickedButtonAtIndex: or alertView:willDismissWithButtonIndex:?
You should call it in the alertView:didDismissWithButtonIndex: to be sure your alert is completely dismissed before showing KVNProgress ;)

Answer 67 · 2015-03-07T14:20:19.000Z

Yes yes yes yes
You definitively did it!!!
My terrible mistake on uialert view. Now launching hud after dismiss,
everything works like a charm.
Take a look at attached files.
I think you can close this issue and also merge invisible-hud branch,
without traces. Also my old pull request, so that I can get the same
current and working environment.
Thank you so much.

Inviato da iPhone

Il giorno 06/mar/2015, alle ore 18:46, Kevin Hirsch <
notifications@github.com> ha scritto:

@foffux https://github.com/foffux, everything seems great except for the
window the KVNProgress is added on, on iOS 8:

_UIAlertControllerShimPresenterWindow

and on iOS 7:

_UIModalItemHostingWindow

Do you have the same logs with the same windows without code from commit
6139b95
6139b95
?

Also, when are you calling KVNProgress after a UIAlertView:
alertView:clickedButtonAtIndex: or alertView:willDismissWithButtonIndex:?
You should call it in the alertView:didDismissWithButtonIndex: to be sure
your alert is completely dismissed before showing KVNProgress ;)

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

Answer 68 · 2015-03-07T19:05:53.000Z

@foffux: Great! I'm glad it fixes your problem :)
I will merge invisible-hud tommorow and create a new pod version ;)

You are talking about your old pull request, which one is it and what do you want me to do?

Answer 69 · 2015-03-08T07:54:03.000Z

Okay perfect. I will be waiting for it.
Just talking about that pull that let you choose the alpha background tint color value, but I think you have already merge it. Am I right?
Thank you for everything.

Inviato da iPad

Il giorno 07/mar/2015, alle ore 20:05, Kevin Hirsch notifications@github.com ha scritto:

@foffux: Great! I'm glad it fixes your problem :)
I will merge invisible-hud tommorow and create a new pod version ;)

You are talking about your old pull request, which one is it and what do you want me to do?

—
Reply to this email directly or view it on GitHub.

Answer 70 · 2015-03-08T10:25:59.000Z

Yes I have merged it already, good idea by the way! 👍