-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
preferredInterfaceOrientationForPresentation crash when displaying in app notification #54
Comments
Hi @ldiqual, Here is our orientation-related code for in-app message: The default values for the
In the in-app message's view controller:
Please note that for the method Could you give us more information about how you use in-app message? Do you set the Please let me know if you want any more information about code in Appboy. Thanks, |
@Wenzhi Thanks for the followup.
Agreed, that shouldn't matter here.
We don't do anything else other than integrating with segment with the Appboy integration enabled (using Segment-Appboy). We don't set
This is where it gets tough. We don't know for sure that it is due to Appboy inapp notifications, however:
However there is no reference to Appboy in the stacktrace (which is not surprising, it's probably showing a view controller and that call is on the next runloop event). We also can't reproduce the crash (by sending inapp modals to our devices by holding our device in landscape mode). Would you recommend setting the supported orientation modes manually? Also, why does your documentation indicate "In-app messages will normally support the orientations specified in the app settings" while it seems that they are hardcoded? |
Hi @ldiqual, About Your Question
Our in-app messages follow the app's orientation settings, even with the default values which support all orientations. Per Apple's
And In
Regarding setting the orientation modes manually, it shouldn't make a difference in your case (IAMs will only ever show in portrait). That said, absent any other strong leads at this point, you might try setting that value. About The IssueAlso - we display an in-app message with a UIWindow on top of the app's window and remove it after the in-app message is dismissed. Are you using any customized UIWIndow, too? It's also possible this is a Swift-only issue. We'll investigate that avenue further. Finally, if you have any information about the Devices/OSes that you're seeing this on, any info there would be useful. Please let me know if you get more information about the crash, and/or if you have any follow-up comments/questions. Thanks, |
Hey @Wenzhi,
Will do this in our next version and report back.
We're using a couple libraries that might use their own UIWindow to display content: I'll take a look at their source code to see if there's something wrong there.
Our 3 affected users: Full stacktrace: Thanks for tackling this. I'll get back to you if we find more info on this. |
Doesn't seem to be happening in our new version. Closing for now. |
Hi We have a crash on In-App messaging for large number of users related to preferredInterfaceOrientationForPresentation. Fatal Exception: UIApplicationInvalidInterfaceOrientation Our app supports only Portrait and mentioned in the info.plist as “UIInterfaceOrientationPortrait” under UISupportedInterfaceOrientations I managed to reproduce the issue and explained below
When I debugged, I found that “preferredInterfaceOrientationForPresentation” function of “ABKInAppMessageWindowController” class returns unsupported interface orientation type on resuming the app from background PS: We are using Appboy version 3.3.1 |
We're noticing crashes when displaying inapp notifications:
We only support portrait orientation.
A quick search in our workspace found this: https://github.com/Appboy/appboy-ios-sdk/blob/master/AppboyKit/headers/AppboyKitLibrary/ABKInAppMessageController.h#L31-L40
It's unclear from the documentation whether orientations are automatically detected
or if all of them are returned by default
Would you mind clarifying the actual behavior and/or sharing the underlying code?
Side note: this is why #44 is important to us.
The text was updated successfully, but these errors were encountered: