Progress HUD not shown: iOS 8

[foffux]

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]

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

[justvanbloom]

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.

[foffux]

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.

[justvanbloom]

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 ?

[kevin-hirsch]

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!

[foffux]

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 [email protected]:

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)
.

[kevin-hirsch]

So do we agree on closing this issue?

[foffux]

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 [email protected]:

So do we agree on closing this issue?

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

[kevin-hirsch]

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

[foffux]

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.

[justvanbloom]

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 :)

[foffux]

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 <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> 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)
.

[kevin-hirsch]

@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?

[foffux]

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

[justvanbloom]

@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?

[foffux]

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

[justvanbloom]

any news on this?

[foffux]

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 [email protected]:

any news on this?

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

[justvanbloom]

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

@kevin ?

[kevin-hirsch]

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.

[foffux]

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.

[kevin-hirsch]

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

[foffux]

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

[kevin-hirsch]

Thanks!

[justvanbloom]

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

[kevin-hirsch]

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.

[justvanbloom]

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

Same :) ok. so its just this?

[foffux]

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 [email protected] 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.

[justvanbloom]

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?

[justvanbloom]

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);

[justvanbloom]

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}}

[foffux]

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

[justvanbloom]

@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

[foffux]

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

[justvanbloom]

Jep. This fixed it.

[kevin-hirsch]

@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?

[justvanbloom]

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

let me know

[kevin-hirsch]

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?

[justvanbloom]

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

(close?)

[kevin-hirsch]

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 ;)

[foffux]

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 [email protected] 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.

[kevin-hirsch]

@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 ;)

[foffux]

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.

[kevin-hirsch]

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>>

[foffux]

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 [email protected]:

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)
.

[kevin-hirsch]

@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?

[foffux]

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 [email protected] 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.

[justvanbloom]

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 [email protected]:

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 [email protected] 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.

[kevin-hirsch]

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

[foffux]

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?

[kevin-hirsch]

@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 ;)

[foffux]

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 <
[email protected]> 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)
.

[kevin-hirsch]

@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?

[foffux]

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 [email protected] 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.

[kevin-hirsch]

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