element-hq / element-hq/element-ios
Rework `RecentsViewControllerDataReadyNotification` to something more solid
- Dominant language
- Swift
- Stars
- 1.8k
- Forks
- 544
- PR merge metrics
- PR metrics pending
Description
### Your use case
The `RecentsViewControllerDataReadyNotification` is used to trigger the end of the initial sync spinner, as it is trusted to notify when the data is actually ready.
Currently having the `RecentsViewControllerDataReadyNotification` actually sent is tied to having sections inside the presented tableView within the RecentsViewController.
While this is always the case in Element-iOS, some fork could, for example, deactivate the Home screen and therefore have the Favorites as the first screen shown in the application. This particular setup would result in any user that actually don't have any favorites to have an infinite initial sync spinner.
See RecentsViewController's ```- (void)dataSource:(MXKDataSource *)dataSource didCellChange:(id)changes``` and RecentsDataSource's ```- (void)recentsListServiceDidChangeData:(id)service forSection:(RecentsListServiceSection)section totalCountsChanged:(BOOL)totalCountsChanged```
### Have you considered any alternatives?
No
### Additional context
None
Contributor guide
Research direction
Start with RecentsViewController's dataSource:didCellChange: and RecentsDataSource's recentsListServiceDidChangeData:forSection:totalCountsChanged: to trace when RecentsViewControllerDataReadyNotification is sent. Rework that trigger so readiness does not depend on sections being present, and verify that an empty Favorites-first setup can finish the initial sync spinner.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- mobile-dev
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100