Change to `MediaPlayer` API to allow waiting for the player to be in a ready state.
This is needed in order to perform some tasks (e.g. read the media duration, seek) after changing the media file.
* Iterate design on Settings screen:
- Set new icons provided by design.
- Replace `PreferenceText` usages with `ListItem`.
- Add missing icons, and a new way to group them for previews.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
<!-- Please read [CONTRIBUTING.md](https://github.com/vector-im/element-x-android/blob/develop/CONTRIBUTING.md) before submitting your pull request -->
## Type of change
- [ ] Feature
- [x] Bugfix
- [ ] Technical
- [ ] Other :
## Content
Code now checks whether the mx uri is invalid and handles the error condition properly.
## Motivation and context
https://github.com/vector-im/element-x-android/pull/1748#discussion_r1384557443
## Screenshots / GIFs
<!--
We have screenshot tests in the project, so attaching screenshots to a PR is not mandatory, as far as there
is a Composable Preview covering the changes. In this case, the change will appear in the file diff.
Note that all the UI composables should be covered by a Composable Preview.
Providing a video of the change is still very useful for the reviewer and for the history of the project.
You can use a table like this to show screenshots comparison.
Uncomment this markdown table below and edit the last line `|||`:
|copy screenshot of before here|copy screenshot of after here|
|Before|After|
|-|-|
|||
-->
## Tests
<!-- Explain how you tested your development -->
- Step 1
- Step 2
- Step ...
## Tested devices
- [ ] Physical
- [ ] Emulator
- OS version(s):
## Checklist
<!-- Depending on the Pull Request content, it can be acceptable if some of the following checkboxes stay unchecked. -->
- [ ] Changes have been tested on an Android device or Android emulator with API 23
- [ ] UI change has been tested on both light and dark themes
- [ ] Accessibility has been taken into account. See https://github.com/vector-im/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
- [ ] Pull request is based on the develop branch
- [ ] Pull request includes a new file under ./changelog.d. See https://github.com/vector-im/element-x-android/blob/develop/CONTRIBUTING.md#changelog
- [ ] Pull request includes screenshots or videos if containing UI changes
- [ ] Pull request includes a [sign off](https://matrix-org.github.io/synapse/latest/development/contributing_guide.html#sign-off)
- [ ] You've made a self review of your PR
* Replace suffix for PreviewsDayNight annotation
* Rename Preview, since its filename was way too long
* Update screenshots
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
As a workaround, disable seeking within the waveform so that it does
not interfere with the long press menu.
Seeking behaviour is already suboptimal given that there is no spoken
feedback about the current seek position. No core functionality is
lost as voice messages can be played using a screen reader.
* Show voice message preview player progress
* Update screenshots
* Fix test
* Some nits over mediaplayer stuff
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
Co-authored-by: Marco Romano <marcor@element.io>
Currently, for compatibility reasons, we implement MSC3245v1 which puts the voice data inside an audio message type. Though at times it seems impractical to deal with a single message type which effectively represents 2 different kinds of messages.
This PR creates a new message type called `VoiceMessageType` which is used whenever we receive an event with `"msgtype": "m.audio"` which also has the `"org.matrix.msc3245.voice": {}` field. This makes it easier to process voice messages as different entities throughout the rest of the codebase.
[MSC3246](https://github.com/matrix-org/matrix-spec-proposals/pull/3246) specifies the waveform as a list of ints because:
> Because floating point numbers are not allowed in Matrix events
Though DSP on audio data is almost always done using their floating point representation.
This PR brings the float<->int rescaling in the `matrix` module so that the application code can always work with float waveform samples.
* Initial support for member suggestion (search and UI)
* Add custom `BottomSheetScaffold` implementation to workaround several scrolling bugs
* Start searching as soon as `@` is typed, add UI following initial designs
* Extract suggestion processing code
* Extract component, add previews, fix tests
* Add tests
* Add exception from kover to the forked bottom sheet code
* Add a feature flag for mentions
- Extract composer & mention suggestions to their composable.
- Extract mentions suggestions processing to its own class.
- Add `MatrixRoom.canTriggerRoomNotification` function.
- Update strings and conditions for displaying the `@room` mention.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
Shows voice messages in the room summary.
Shows voice messages in the reply context menu and composer.
Show replies to voice messages in the timeline.
(before this PR voice messages were shown the same as audio messages)
Story: https://github.com/vector-im/element-meta/issues/2106
- New `AudioLevelCalculator` that outputs dB0v rescaled to the [0;1] range.
- `VoiceRecorder` now stores the audio levels sampled while recording, then resamples them to 100 samples to use as waveform preview.
- Waveform data is carried all the way as a `List<Float>` and converted to `List<Int>` in the [0;1024] range as per matrix spec only before sending it.
* Update the chat screen UI using `RoomInfo`.
This is specially useful for getting live values for `hasRoomCall`.
* Ensure the first `MatrixRoomInfo` is emitted ASAP
* Try excluding `*Present$present$*` inner functions from kover as separate entities
* Update strings
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
This is in preparation of further changes to the way the audio level is computed and to allow recording and sending of the waveform. The main reasoning behind the change is twofold:
1) We don't need the precision of Double in our context (we just need a rough indication of the changes in audio level to successfully draw a level meter or a waveform in our UI).
2) Performance: It is true that on 64 bit CPUs single operations involving Floats or Doubles take the same amount of time (i.e one clock cycle). But there are other aspects here that vouch in favor of Floats:
- A float takes half the space in memory compared to a double, so when storing long lists of them this can add up.
- On Android O and greater the ART runtime can "vectorize" certain operations on lists and make use of the CPU's SIMD registers which are generally 128 bits. So by using floats 4 of them can fit and be computed at the same time whilst with doubles only 2 will fit halving the throughput.
References:
- https://source.android.com/docs/core/runtime/improvements
- https://www.slideshare.net/linaroorg/automatic-vectorization-in-art-android-runtime-sfo17216
jonnyandrew