UAirship.InAppMessaging.DisplayMessage Display Issues
Closed this issue · 6 comments
I've noticed a couple of issues when using the DisplayMessage functionality on UAirship.InAppMessaging.
First:
If a keyboard is present at the time of calling DisplayMessage, the message is swallowed. My UAInAppMessageControllerDelegate never gets a call to View(UAInAppMessage message, UIView parentView) and thus no message is ever displayed.
Second:
If there are multiple windows being used in the app, it appears that InAppMessaging is using the first Window in the hierarchy for determining the parent view to display from, rather than the Key Window. This is causing messages to display underneath my presented content.
Keyboard issue: So the not displaying when the keyboard is shown is actually by design. Banners have a duration, so we do not want them to be covered up the entire time while the keyboard is up. Ideally we would return a result if we failed to display or not. For now you can check if the keyboard is up before calling that method.
Window Issue: The key window is normally not what you want to use as it use to include the keyboard and I believe still includes any system dialog prompts. We will select the app delegate's window property if its set, then fallback to the first window in the windows array. I wonder if you could utilize that property to fix your issue for now.
Keyboard issue: For my custom view, we were displaying at the top of the screen, meaning it wouldn't be covered up.
Window Issue: We wanted a bit more robustness, the ability for the message to follow the user through the app so I went ahead and rolled my own solution. I would take into consideration the possibility of an app utilizing multiple windows in the future though.
@benfrye We are in the middle of making significant changes to our iam framework. It will allow more control over how an in-app message is displayed. It will not be out for another month or two.
Could you describe how you are using multiple windows? I want to make sure we consider your use cases. Thanks
@rlepinski So our use case centers around a bug in iOS actually. If you have a UISplitViewController with the Master view set to slideout rather than always be present, if you present modal views from it in portrait orientation it will actually present the modal between the Master view and the Detail view. Since we want these modals to present over top of both Master and Detail views, we create a new Window to present these modals in and then cleanup that Window once everything is dismissed.