This is a change to previous behavior! Now the SDK by default shows the user data UI and subsequent compose UI always modally to ensure proper functionality on all scenarios the feedback viewer can be presented.
The new property `showFirstRequiredPresentationModal` in `BITFeedbackManager` can be set to `NO` if the previous behavior of pushing the UI and Compose view onto the stack, when those are being forced to be shown on the first presentation of the feedback UI. Especially if you present the UI in a popover, you should NOT change this property!
- Added SFHFKeyChainUtils with BIT prefix
- Save username, email or userid (if provided by the app or the user) in the keychain instead of user defaults or property files
- Only adjust the status bar style, if the navigation bar style is the default one
- Fix a bug not resetting the status bar style correctly when presenting the update view in a navigation bar stack
If the required manual user data is missing and the feedback list view appears the user detail view is automatically pushed. Now if the user cancels and goes back to the feedback list, it gets pushed again and so the user can never exit. Instead push this at maximum once. When providing feedback it will ask the missing user details again anyway.
If the userName and userEmail delegates are implemented and the requireUserEmail or requireUserName are changed after that, then the user interface is shown even though the delegates define the values and the user shouldn't be able to change that.
- This now requires the testing of this feature to be done on an actual device, since it returns always empty strings on the simulator
- Once there is a better solution to get unit test targets build without problems this should be changed again, so testing of this feature is also possible using the simulator
The previously shows [] as part of [TODO], since PLCrashReporter didn't fill them out. Having the incident identifier showing a [ or ] char made it impossible to drag it into the Organizer to get it symbolicated in there
if the BITFeedbackListViewController is presented
modally (via a UINavigationController) the action sheet
should show in that view.
Basically search for the root- or topmost presented view
controller.
if the BITFeedbackListViewController's view is contained in
a scrollview, the UIActionSheet if offset by the contentOffset
when presented. But as the action sheet is presented in
a separate window, that offset moves it out of the view.
Instead, show the action sheet in the window's
rootViewController's view.
If PLCrashReporter wrote a crash report, that could not be read, no delegate was fired. That could make the app stay in the start up maintenance screen, if it handles crashes on startup.
Though there was no report this ever happened, there is the theoretical chance this could.
