* Remove `SessionData.needsVerification` as the source of truth for session verification status.
- Use the Rust SDK `EncryptionService.verificationState()` instead, but always waiting for the first 'known' result (either verified or not, discarding 'unknown').
- Add a workaround in the super rare case when reading this value gets stuck somehow. We'll assume the user is not verified in that case.
- Make `DefaultFtueService.getNextStep` and dependent checks `suspend`.
- Make the `skip` button use a value in the session preferences instead.
* Log exception when the verification status can't be loaded
Co-authored-by: Benoit Marty <benoit@matrix.org>
* Fix review comments
---------
Co-authored-by: Benoit Marty <benoit@matrix.org>
* Improve enter recovery key screen UI
* Add instructions to reset the encryption of the logged in account.
* Update screenshots
* Fix maestro flow
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Add `SessionData.needsVerification`:
- Allows us to add a skip button for debug builds.
- We can have the verification state almost instantly.
- It doesn't depend on network availability to know the verification state and display the UI.
* Add DB migration.
- Make the skip button in the verification flow skip the whole flow including the completed screen.
- Save the session as verified in `RustEncryptionService.recover(recoveryKey)`.
* Enforce session verification for existing users too.
* Fix verification confirmed screen subtitle (typo in id, was using the wrong string)
* Update screenshots
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Move session verification to the FTUE
* Allow session verification flow to be restarted
* Use `EncryptionService` to display session verification faster
* Remove session verification item from settings
* Remove session verification banner from room list
* Remove 'verification needed' variant from the `TimelineEncryptedHistoryBanner`
* Improve verification flow UI and UX
* Remove 'verification successful' snackbar message
* Only register push provider after the session has been verified
* Hide room list while the session hasn't been verified
* Prevent deep links from changing the navigation if the session isn't verified
* Update screenshots
* Renamed `FtueState` to `FtueService`, created an actual `FtueState`.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
Update Compound to `v0.0.5`:
- Make sure we fix all the breaking changes.
- Update some icons to use the compound version instead.
-Replace icons with their Compound counterparts when possible.
- Clean up unused icons.
- Fix issues with incorrect icons or sizes being used after replacing the temporary icons with the Compound ones.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Rename migration bg drawable and add night variant
* Move `migration` package from `ftue` to `messages:impl` module
* Update `SunsetPage` with light and dark modes
* Fix bloom colors when nested theme is used
* Integrate the migration screen in the room list
* Fix `WaitListView` cancel button color
* Clear migration store when removing the app's cache
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
Lambda parameters in a @Composable that are referenced directly inside of restarting effects can cause issues or unpredictable behavior.
If restarting the effect is ok, you can add the reference to this parameter as a key in that effect, so when the parameter changes, a new effect is created.
However, if the effect is not to be restarted, you will need to use `rememberUpdatedState` on the parameter and use its result in the effect.
See https://mrmans0n.github.io/compose-rules/rules/#be-mindful-of-the-arguments-you-use-inside-of-a-restarting-effect for more information. [LambdaParameterInRestartableEffect]
Jorge Martin Espinosa