- Fix the case where the order for `start` and `end` is reversed.
- Fix the case where `start` or `end` may be outside the editable's range (`0..length`).
* Add code to help debugging the saved nav state graph: this would help us diagnose the `TransactionTooLargeException` reports we've been seeing for months.
* Create `PushRequest` in push history DB: this will be used to store requests for push notifications, either pending or completed ones.
* Rename `WorkManagerRequest` to `WorkManagerRequestBuilder`: make its `build` method return a list of `WorkManagerRequestWrapper`, which can be used to enqueue normal or unique workers.
* Rename `PerformDatabaseVacuumRequestBuilder` and adapt it to the new API.
* Adjust other components using `WorkManagerRequest`.
* Replace `SyncNotificationWorkManagerRequestBuilder` with `SyncPendingNotificationsRequestBuilder` and `FetchNotificationsWorker` with `FetchPendingNotificationsWorker`: this new pair of request builder and worker allow enqueuing requests for a session id and, once the worker runs, retrieve all the pending request data and use it to fetch the associated events. This simplifies quite a bit how this data had to be passed or grouped, since it's no longer necessary to do so
* Add new methods to `PushHistoryService` to modify the `PushDatabase`:
- insertOrUpdatePushRequest
- insertOrUpdatePushRequests
- getPendingPushRequests
- removeOldPushRequests
* Make `PushHandler` just handle incoming pushes: those will be inserted into the pending push request table in DB, then handled by the new worker. Once the process finished, a new `NotificationResultProcessor` will handle the results and what needs to be done with them (call ringing, displaying notifications, etc.)
* Add `requestType` optional parameter to `WorkManagerScheduler.cancel` so we can decide to only cancel some kinds of requests.
* Add migration to remove existing work manager requests for fetching notifications, since the previous worker class no longer exists.
* Update metro to v0.11.2
* Bind push tests to the right scope .Add a comment so we don't forget to do it for future ones.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
* Make 'room list catch-up' analytics transaction network aware.
* Add `RoomListService.isInitialSyncDone`. Use this to simplify `DefaultAnalyticsRoomListStateWatcher`'s logic.
- Added `MediaSource.safeUrl` property replacing `withCleanUrl` method.
- Made `url` private so it can't be used externally.
- Reverted code in `CoilMediaFetcher`
- Also add tests
We've seen some MXC urls in the wild having some `mxc://foo/bar#auto` fragment suffix, which is invalid, but the URL before that fragment part is valid and can be displayed
* Use floating toolbar on homepage
* Fix deprecation issue
* Create HorizontalFloatingToolbar wrapper in our components.
* Fix Konsist test.
* Fix compilation issue after rebase.
* Fix lint issue. `floatingActionButton` must be the last parameter.
* Add Preview for the case empty space.
* Fix navigation bar overlapping buttons in empty space view.
* Increase content padding, and apply it to the space tab too.
* Update screenshots
---------
Co-authored-by: chelsea <git@cdhildit.ch>
Co-authored-by: ElementBot <android@element.io>
* Update metro to v0.11.0
* Fix `@AssistedInject` usages
Now the injected variables in the factories must match the names in the constructors
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
* Add `NetworkMonitor.isNetworkBlocked()`, use it to check if Doze prevented us from loading notifications
* Only check if network is blocked after checking if we have a network available, otherwise it's always `true`
* Extract `NetworkBlockedChecker` to handle deprecations more carefully
* Set a maximum journal size limit (WAL file size) of 25MB
The previous value was null, which meant unlimited growth. This can affect performance, since the WAL file performance as a cache will worsen the larger it is
* When scheduling the vacuum task, make sure the user has enough free disk storage, since vacuuming can duplicate the DB sizes in disk
* Add extra analytics for notification performance
Add technical spans to track how long a notification fetching work request takes to run, then how long it takes to actually fetch the events for the notifications
* Remove `withContext(io)` for `FetchNotificationsWorker`
The default `Dispatchers.Default` dispatcher used should be good enough and more performant
* Add network check span
* Disable the cross-process lock in the SDK
We don't use multiple process as iOS does, so we don't need it. It should improve DB performance a bit and overall waste less resources.
