MS-154 camera permission improvement

[luhmirin-s]

Added an extra state in "LiveFeedbackFragment" to ask for permission if not granted before.

PS. The old version with the separate alert screen has been scrapped as overly complex.

[luhmirin-s]

The coverage is as good as it gets since the "uncovered" lines should have been excluded in the first place.

[alexandr-simprints]

Would it be possible to record a video of how the permission handling currently looks like? Considering that these changes aim to improve UI, I'd like us to handle both Deny and Deny, Don't ask again states individually. For that matter, utilizing the already existing PermissionStatus enum comes in handy. By using it, it becomes possible to render the screen content depending on its value.

Figma example:

The state of the permission response can be summarized in the following way:

• Granted: proceed with the camera preview
• Deny: display the action button and show the rationale to the user, explaining that the camera access is required in order to render preview. When the button is pressed, it displays the system permission dialog once again.
• Deny, don't ask again: display the action button and show the rationale to the user, explaining that they need to provide the camera access in settings. When the button is pressed, it navigates the user to the app's settings page.

[luhmirin-s]

For now, I just replicated our flow in the fingerprint connection with the fullscreen alert in case the initial dialog is rejected. There is a lot of room for improvement.

Screen_recording_20240425_142527.mp4

[BurningAXE]

For now, I just replicated our flow in the fingerprint connection with the fullscreen alert in case the initial dialog is rejected. There is a lot of room for improvement.

Screen_recording_20240425_142527.mp4

In Fingerprint the alert is dismissed when you tap the settings button so when you come back you don't have to press retry. Permissions are checked in the Fragment's onResume() so if user didn't grant the permission, alert would be displayed again. Not a big deal but nice to have.

[BurningAXE]

So much boilerplate needed to add a new alert :(

[BurningAXE]

Should this be deleted?

[luhmirin-s]

So much boilerplate needed to add a new alert :(

In this case, the boilerplate is more due to the navigation to the settings (i.e. out of the app) and the camera lifecycle handling.

[alexandr-simprints]

Could you please verify that the following scenarios would not disturb the UX:

1. Access granted
2. Access Denied, Retry is clicked
3. Access Denied, Don't Ask Again is selected, Retry is clicked
4. Access Denied, Don't Ask Again is selected, Open Settings is clicked, User returns without giving the permissions
5. Access Denied, Don't Ask Again is selected, Open Settings is clicked, User returns with providing the permissions

[luhmirin-s]

Simple deny/allow permission flow:

Screen_recording_20240523_144111.mp4

Flow with "Don't ask again" and closing settings with and without providing permission:

Screen_recording_20240523_144232.mp4

As you can the alert is shown the first time the screen is opened without permission and with the "Don't ask again" flag. Once the alert if permission is not provided, the exit form will be shown on the next retry. This allows us to force the user into either giving permission or explicitly exiting the flow, IMO this is the clearest way to handle it.

[alexandr-simprints]

Once the alert if permission is not provided, the exit form will be shown on the next retry.

This doesn't seem like the best user experience decision. I was incredibly confused while watching the video and seeing the exit form displayed after hitting the Retry button. I've realized it was intentional only after reading the comment afterward.

As mentioned above, I'm still in favor of simplifying the flow for users by using the same screen with a single permission button and rationale text.

I find the current solution unnecessary visually complex.

[BurningAXE]

I agree with Alex that showing the exit form without user requesting it might be confusing. I'd keep the user on the same screen asking for permissions until they either give permissions or press the back button to explicitly go to the exit form. IMO this is handled pretty well for fingerprint and we should copy the behaviour to face.

[luhmirin-s]

@alexandr-simprints @BurningAXE Redid the screen with significant simplification. No more separate alert screens and juggling navigation.

[sonarqubecloud]

Quality Gate failed

Failed conditions
61.9% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[alexandr-simprints]

@luhmirin-s could you please share a video similar to how you did it last time?

[luhmirin-s]

Screen_recording_20240606_165721.mp4