strange visual bug

[andiaut]

When presenting a UIAlertView/UIActionSheet before applicationDidEnterBackground I get this strange visual bug after returning back into the app.

[rolandleth]

Are you running latest commit? Or version 1.1.0 via cocoa pods.

I don't really understand what you're doing, you're presenting an av/as as you enter background? Won't that be shown after you come back in foreground, behind the lock?

[andiaut]

Well I click on a button and it presents an UIActionSheet. With the UIActionSheet being presented I press the homebutton. After returning to the app the lockscreen in my app is being displayed like this

[rolandleth]

Oh, I understand. Already working on a fix, will come back when I have a (elegant) solution, since the current one is a bit choppy.

[andiaut]

Thanks a lot, that was really quick of you!

[rolandleth]

I just noticed (though obvious) it affects my app too, so thank you :)

[rolandleth]

Oh this is a tough one. AV and AS are presented in their own separate window and the keyWindow changes to this one while the AV/AS is on screen. And I don't know why adding a view to this window doesn't work as expected: it seems it gets delayed in being added as a subview, so if I add it when going to background, it won't be displayed until the app is back in the foreground and with a delay of another second or so; obviously the multitasking view isn't covered by anything either.
If I go ahead and add the view to the 'default' window it will appear behind the AV/AS and you won't be able to interact with it until the AV/AS is dismissed; not desired, of course.

Any ideas? :(

Edit: moving the logic from didEnterBackground to willResignActive isn't optimal either, since willResignActive gets triggered even if the user opens the multitasking then comes back to the app without actually leaving it completely and showing a lock screen in this scenario isn't ideal.

Update: tried moving it to willResignActive just to test it out and it behaves exactly the same: the app isn't covered in the multitasking view and when coming into foreground the lock screen view is added with a delay of 1+ seconds.

[andiaut]

Oh I see.. Well I tried all these things too and the only acceptable solution is dismissing the AV or AS when entering the background. But it's neither a good nor easy solution. Perhaps someone on stackoverflow.com can help us?

[rolandleth]

Yeah, I thought about dismissing the AV/AS too, but indeed it's not an elegant solution either. Nonetheless, it's the best unless we find something better. I will post a question on stackoverflow shortly.

Edit: there's another problem with this scenario: when coming back to foreground, even if positioned correctly (this part I fixed, wasn't hard) the lock screen covers the whole window, including the status bar, since AV/AS' window is on top of everything and I'd have to add the lock screen on top of that. So it your app shows the status bar, in this particular case, the lock screen will not, causing a small discrepancy between lockscreen/app.

[andiaut]

http://stackoverflow.com/questions/18702565/find-uialertview-without-having-reference-to-it-ios-7

look here. It's really annoying how apple treats UIAlertViews now!

[rolandleth]

Wonder how inconvenient adding a kAlertViewTag constant would be to developers using this library. Then tag all your AV/AS' with this one.
What if you need to custom tag it, though? But this accepted answer kinda holds true, a lot of developers abuse AVs, and having a single tag for all AVs should be enough: http://stackoverflow.com/questions/19530424/dismissing-a-uialertview-in-ios-7-not-working

This comment was funny and sad:
I modified all my code and kept reference to alert views and now they are working fine.. iOS/OS X developer style, yeah!

[andiaut]

It will be inconvenient but still a lot better than nothing... And it's not very difficult to do for a developer either.
I'd go for it atm!

Yeah I read that too, quite sad haha :(

[rolandleth]

Those answer say AV/AS aren't added to any window, but if you NSLog the keyWindow with an AV/AS open you get a private window, _UIModalItemHostingWindow and you can add stuff to it, as explained above, it just doesn't work as expected. NSLoging [UIApplication sharedApplication].keyWindow.subviews clearly shows the lock screen view in there. I suspect all this delay when displaying it in this scenario is due to how Apple displays AV/AS when going background/coming foreground :(
You can't find it in [UIApplication sharedApplication].windows, either, though. So I think we'll have to dismiss AV/AS manually. I will post a question on SO today, nonetheless.

[andiaut]

Wouldn't apple reject an app that is accessing the private window? What do you plan to do now?

It would be great if you could hide the _UIModalItemHostingWindow until the user has entered the passcode und display it afterwards. But that's probably impossible

[rolandleth]

That would be indeed a good approach for the user, but it's still accessing a private method. I don't have any important bugs to solve, I might try it, just to see if it gets approved.

As for the AV/AS not being added to any window, they are right: while there's a reference to _UIModalItemHostingWindow, which has 2 subviews, no reference to the AV/AS itself is to be found anywhere. Meaning the global kAlertViewTag idea just dropped. The only way is to keep a reference to the AV/AS yourself :(

[andiaut]

Ok that would be great! It's quite a strange behavior because there should be an option to present something above everything else

[rolandleth]

Well, you can, as I explained above. I can add the lock screen on top of this window's stack, but it will appear on top of the status bar as well and with a delay, caused by how Apple displays its AV/AS. Here's what I came up with, further proving they have a weird way of doing this, which causes the aforementioned delay:

Inside showLockscreenWithoutAnimation change keyWindow to UIWindow *mainWindow = [UIApplication sharedApplication].windows[0]; which translates into keyWindow when no AV/AS is displayed, and into the "default" window when one is displayed. I changed all the self.navigationController.view occurrences to mainWindow for proper positioning.
And then inside applicationWillResignActive I did

if ([[UIApplication sharedApplication].keyWindow isKindOfClass: NSClassFromString(@"_UIModalItemHostingWindow")]) {
    [UIApplication sharedApplication].keyWindow.hidden = YES;
}

And the funny part? The lock screen is displayed properly, it appears as it should on the multitasking view, the AV/AS window gets hidden, and then it is displayed again automatically as if the AV/AS was called right then (with the zooming in/popping animation, the background darkening and all!), without me doing anything. dafuq? Is Apple testing if the _UIModalItemHostingWindow gets hidden and automatically calls their '[alertView show]` method again??

Edit: and to make things weirder, calling [UIApplication sharedApplication].keyWindow removeFromSuperview]; instead of hiding it doesn't do anything: it will still animate when coming back to foreground.

[andiaut]

I just tried it out... REALLY strange and it is actually something I experienced myself earlier and wondered if I did something wrong. No matter what I do, the AVs seem to return :/

[rolandleth]

I tried manually making [UIApplication sharedApplication].windows[0] the new keyWindow and to create a new window, but no matter what I try, the AV/AS still runs, as you said. And on top of everything else, too :(

I'll go ahead and write that SO question now :)

[andiaut]

Well okay hopefully someone comes up with an idea... Please post the link to the question when you're finished with writing :)

[rolandleth]

http://stackoverflow.com/questions/19816142/uialertviews-uiactionsheets-keywindow-and-me

Suggestions on how to improve the question are welcome.

[andiaut]

were you able to solve the problem?

[rolandleth]

Well, part of, which is found in the latest commit: the positioning is correct, but any av/as present before going to background/displaying the lock screen will appear on top when coming back to foreground.

It was the best compromise I could find; in case you read the SO question, you saw the difficulties I encountered with the UIWindow and the keyboard.

[andiaut]

yeah I read it but wondered if you found out anything new. That's totally okay, thanks :)