2022-01-11 19:00:29 +01:00
|
|
|
/* Copyright 2021 Tusky Contributors
|
|
|
|
*
|
|
|
|
* This file is a part of Tusky.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it under the terms of the
|
|
|
|
* GNU General Public License as published by the Free Software Foundation; either version 3 of the
|
|
|
|
* License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* Tusky is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
|
|
|
|
* the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
|
|
|
|
* Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with Tusky; if not,
|
|
|
|
* see <http://www.gnu.org/licenses>. */
|
|
|
|
|
|
|
|
package com.keylesspalace.tusky.components.timeline.viewmodel
|
|
|
|
|
|
|
|
import android.content.SharedPreferences
|
|
|
|
import android.util.Log
|
|
|
|
import androidx.lifecycle.viewModelScope
|
|
|
|
import androidx.paging.ExperimentalPagingApi
|
|
|
|
import androidx.paging.Pager
|
|
|
|
import androidx.paging.PagingConfig
|
2022-05-29 19:22:59 +02:00
|
|
|
import androidx.paging.PagingSource
|
2022-01-11 19:00:29 +01:00
|
|
|
import androidx.paging.cachedIn
|
|
|
|
import androidx.paging.filter
|
|
|
|
import androidx.paging.map
|
|
|
|
import androidx.room.withTransaction
|
2024-03-09 16:12:18 +01:00
|
|
|
import at.connyduck.calladapter.networkresult.NetworkResult
|
|
|
|
import at.connyduck.calladapter.networkresult.map
|
|
|
|
import at.connyduck.calladapter.networkresult.onFailure
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.google.gson.Gson
|
|
|
|
import com.keylesspalace.tusky.appstore.EventHub
|
Keep scroll position when loading missing statuses (#3000)
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
2023-01-13 19:26:24 +01:00
|
|
|
import com.keylesspalace.tusky.components.preference.PreferencesFragment.ReadingOrder.NEWEST_FIRST
|
|
|
|
import com.keylesspalace.tusky.components.preference.PreferencesFragment.ReadingOrder.OLDEST_FIRST
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.components.timeline.Placeholder
|
|
|
|
import com.keylesspalace.tusky.components.timeline.toEntity
|
|
|
|
import com.keylesspalace.tusky.components.timeline.toViewData
|
2022-03-08 21:39:59 +01:00
|
|
|
import com.keylesspalace.tusky.components.timeline.util.ifExpected
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.db.AccountManager
|
|
|
|
import com.keylesspalace.tusky.db.AppDatabase
|
2022-05-29 19:22:59 +02:00
|
|
|
import com.keylesspalace.tusky.db.TimelineStatusWithAccount
|
2023-03-11 13:12:50 +01:00
|
|
|
import com.keylesspalace.tusky.entity.Filter
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.entity.Poll
|
2023-09-26 09:08:58 +02:00
|
|
|
import com.keylesspalace.tusky.entity.Status
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.network.FilterModel
|
|
|
|
import com.keylesspalace.tusky.network.MastodonApi
|
2022-06-20 16:45:54 +02:00
|
|
|
import com.keylesspalace.tusky.usecase.TimelineCases
|
2022-11-22 20:36:07 +01:00
|
|
|
import com.keylesspalace.tusky.util.EmptyPagingSource
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.viewdata.StatusViewData
|
2024-03-09 16:12:18 +01:00
|
|
|
import com.keylesspalace.tusky.viewdata.TranslationViewData
|
2024-01-04 17:00:55 +01:00
|
|
|
import javax.inject.Inject
|
2022-04-15 13:20:27 +02:00
|
|
|
import kotlinx.coroutines.Dispatchers
|
|
|
|
import kotlinx.coroutines.asExecutor
|
2024-03-09 16:12:18 +01:00
|
|
|
import kotlinx.coroutines.flow.MutableStateFlow
|
|
|
|
import kotlinx.coroutines.flow.combine
|
2022-04-15 13:20:27 +02:00
|
|
|
import kotlinx.coroutines.flow.flowOn
|
2022-01-11 19:00:29 +01:00
|
|
|
import kotlinx.coroutines.launch
|
|
|
|
import retrofit2.HttpException
|
|
|
|
|
|
|
|
/**
|
|
|
|
* TimelineViewModel that caches all statuses in a local database
|
|
|
|
*/
|
|
|
|
class CachedTimelineViewModel @Inject constructor(
|
|
|
|
timelineCases: TimelineCases,
|
|
|
|
private val api: MastodonApi,
|
|
|
|
eventHub: EventHub,
|
|
|
|
accountManager: AccountManager,
|
|
|
|
sharedPreferences: SharedPreferences,
|
|
|
|
filterModel: FilterModel,
|
|
|
|
private val db: AppDatabase,
|
|
|
|
private val gson: Gson
|
2022-05-29 19:22:59 +02:00
|
|
|
) : TimelineViewModel(
|
|
|
|
timelineCases,
|
|
|
|
api,
|
|
|
|
eventHub,
|
|
|
|
accountManager,
|
|
|
|
sharedPreferences,
|
|
|
|
filterModel
|
|
|
|
) {
|
|
|
|
|
|
|
|
private var currentPagingSource: PagingSource<Int, TimelineStatusWithAccount>? = null
|
2022-01-11 19:00:29 +01:00
|
|
|
|
2024-03-09 16:12:18 +01:00
|
|
|
/** Map from status id to translation. */
|
|
|
|
private val translations = MutableStateFlow(mapOf<String, TranslationViewData>())
|
|
|
|
|
2022-01-20 21:10:32 +01:00
|
|
|
@OptIn(ExperimentalPagingApi::class)
|
2022-01-11 19:00:29 +01:00
|
|
|
override val statuses = Pager(
|
|
|
|
config = PagingConfig(pageSize = LOAD_AT_ONCE),
|
|
|
|
remoteMediator = CachedTimelineRemoteMediator(accountManager, api, db, gson),
|
2022-03-06 17:40:24 +01:00
|
|
|
pagingSourceFactory = {
|
|
|
|
val activeAccount = accountManager.activeAccount
|
|
|
|
if (activeAccount == null) {
|
2022-11-22 20:36:07 +01:00
|
|
|
EmptyPagingSource()
|
2022-03-06 17:40:24 +01:00
|
|
|
} else {
|
|
|
|
db.timelineDao().getStatuses(activeAccount.id)
|
2022-05-29 19:22:59 +02:00
|
|
|
}.also { newPagingSource ->
|
|
|
|
this.currentPagingSource = newPagingSource
|
2022-03-06 17:40:24 +01:00
|
|
|
}
|
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
).flow
|
2024-03-09 16:12:18 +01:00
|
|
|
// Apply cachedIn() early to be able to combine with translation flow.
|
|
|
|
// This will not cache ViewData's but practically we don't need this.
|
|
|
|
// If you notice that this flow is used in more than once place consider
|
|
|
|
// adding another cachedIn() for the overall result.
|
|
|
|
.cachedIn(viewModelScope)
|
|
|
|
.combine(translations) { pagingData, translations ->
|
2022-04-15 13:20:27 +02:00
|
|
|
pagingData.map(Dispatchers.Default.asExecutor()) { timelineStatus ->
|
2024-03-09 16:12:18 +01:00
|
|
|
val translation = translations[timelineStatus.status.serverId]
|
|
|
|
timelineStatus.toViewData(
|
|
|
|
gson,
|
|
|
|
isDetailed = false,
|
|
|
|
translation = translation
|
|
|
|
)
|
2022-04-15 13:20:27 +02:00
|
|
|
}.filter(Dispatchers.Default.asExecutor()) { statusViewData ->
|
2023-03-11 13:12:50 +01:00
|
|
|
shouldFilterStatus(statusViewData) != Filter.Action.HIDE
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
2022-04-15 13:20:27 +02:00
|
|
|
.flowOn(Dispatchers.Default)
|
2022-01-11 19:00:29 +01:00
|
|
|
|
|
|
|
override fun updatePoll(newPoll: Poll, status: StatusViewData.Concrete) {
|
|
|
|
// handled by CacheUpdater
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun changeExpanded(expanded: Boolean, status: StatusViewData.Concrete) {
|
|
|
|
viewModelScope.launch {
|
|
|
|
db.timelineDao().setExpanded(accountManager.activeAccount!!.id, status.id, expanded)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun changeContentShowing(isShowing: Boolean, status: StatusViewData.Concrete) {
|
|
|
|
viewModelScope.launch {
|
2022-05-29 19:22:59 +02:00
|
|
|
db.timelineDao()
|
|
|
|
.setContentShowing(accountManager.activeAccount!!.id, status.id, isShowing)
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun changeContentCollapsed(isCollapsed: Boolean, status: StatusViewData.Concrete) {
|
|
|
|
viewModelScope.launch {
|
2022-05-29 19:22:59 +02:00
|
|
|
db.timelineDao()
|
|
|
|
.setContentCollapsed(accountManager.activeAccount!!.id, status.id, isCollapsed)
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun removeAllByAccountId(accountId: String) {
|
|
|
|
viewModelScope.launch {
|
|
|
|
db.timelineDao().removeAllByUser(accountManager.activeAccount!!.id, accountId)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun removeAllByInstance(instance: String) {
|
|
|
|
viewModelScope.launch {
|
|
|
|
db.timelineDao().deleteAllFromInstance(accountManager.activeAccount!!.id, instance)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-03-11 13:12:50 +01:00
|
|
|
override fun clearWarning(status: StatusViewData.Concrete) {
|
|
|
|
viewModelScope.launch {
|
|
|
|
db.timelineDao().clearWarning(accountManager.activeAccount!!.id, status.actionableId)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
override fun removeStatusWithId(id: String) {
|
|
|
|
// handled by CacheUpdater
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun loadMore(placeholderId: String) {
|
|
|
|
viewModelScope.launch {
|
|
|
|
try {
|
|
|
|
val timelineDao = db.timelineDao()
|
|
|
|
|
|
|
|
val activeAccount = accountManager.activeAccount!!
|
|
|
|
|
2022-05-29 19:22:59 +02:00
|
|
|
timelineDao.insertStatus(
|
|
|
|
Placeholder(placeholderId, loading = true).toEntity(
|
|
|
|
activeAccount.id
|
|
|
|
)
|
|
|
|
)
|
2022-01-11 19:00:29 +01:00
|
|
|
|
2022-03-28 18:39:16 +02:00
|
|
|
val response = db.withTransaction {
|
|
|
|
val idAbovePlaceholder = timelineDao.getIdAbove(activeAccount.id, placeholderId)
|
Keep scroll position when loading missing statuses (#3000)
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
2023-01-13 19:26:24 +01:00
|
|
|
val idBelowPlaceholder = timelineDao.getIdBelow(activeAccount.id, placeholderId)
|
|
|
|
when (readingOrder) {
|
|
|
|
// Using minId, loads up to LOAD_AT_ONCE statuses with IDs immediately
|
|
|
|
// after minId and no larger than maxId
|
|
|
|
OLDEST_FIRST -> api.homeTimeline(
|
|
|
|
maxId = idAbovePlaceholder,
|
|
|
|
minId = idBelowPlaceholder,
|
|
|
|
limit = LOAD_AT_ONCE
|
|
|
|
)
|
|
|
|
// Using sinceId, loads up to LOAD_AT_ONCE statuses immediately before
|
|
|
|
// maxId, and no smaller than minId.
|
|
|
|
NEWEST_FIRST -> api.homeTimeline(
|
|
|
|
maxId = idAbovePlaceholder,
|
|
|
|
sinceId = idBelowPlaceholder,
|
|
|
|
limit = LOAD_AT_ONCE
|
|
|
|
)
|
|
|
|
}
|
2022-09-13 19:47:55 +02:00
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
|
|
|
|
val statuses = response.body()
|
|
|
|
if (!response.isSuccessful || statuses == null) {
|
|
|
|
loadMoreFailed(placeholderId, HttpException(response))
|
|
|
|
return@launch
|
|
|
|
}
|
|
|
|
|
|
|
|
db.withTransaction {
|
|
|
|
timelineDao.delete(activeAccount.id, placeholderId)
|
|
|
|
|
|
|
|
val overlappedStatuses = if (statuses.isNotEmpty()) {
|
2022-05-29 19:22:59 +02:00
|
|
|
timelineDao.deleteRange(
|
|
|
|
activeAccount.id,
|
|
|
|
statuses.last().id,
|
|
|
|
statuses.first().id
|
|
|
|
)
|
2022-01-11 19:00:29 +01:00
|
|
|
} else {
|
|
|
|
0
|
|
|
|
}
|
|
|
|
|
|
|
|
for (status in statuses) {
|
|
|
|
timelineDao.insertAccount(status.account.toEntity(activeAccount.id, gson))
|
2022-05-29 19:22:59 +02:00
|
|
|
status.reblog?.account?.toEntity(activeAccount.id, gson)
|
|
|
|
?.let { rebloggedAccount ->
|
|
|
|
timelineDao.insertAccount(rebloggedAccount)
|
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
timelineDao.insertStatus(
|
|
|
|
status.toEntity(
|
|
|
|
timelineUserId = activeAccount.id,
|
|
|
|
gson = gson,
|
|
|
|
expanded = activeAccount.alwaysOpenSpoiler,
|
|
|
|
contentShowing = activeAccount.alwaysShowSensitiveMedia || !status.actionableStatus.sensitive,
|
|
|
|
contentCollapsed = true
|
|
|
|
)
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
2022-03-28 18:39:16 +02:00
|
|
|
/* In case we loaded a whole page and there was no overlap with existing statuses,
|
|
|
|
we insert a placeholder because there might be even more unknown statuses */
|
|
|
|
if (overlappedStatuses == 0 && statuses.size == LOAD_AT_ONCE) {
|
Keep scroll position when loading missing statuses (#3000)
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
2023-01-13 19:26:24 +01:00
|
|
|
/* This overrides the first/last of the newly loaded statuses with a placeholder
|
2022-03-28 18:39:16 +02:00
|
|
|
to guarantee the placeholder has an id that exists on the server as not all
|
|
|
|
servers handle client generated ids as expected */
|
Keep scroll position when loading missing statuses (#3000)
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
2023-01-13 19:26:24 +01:00
|
|
|
val idToConvert = when (readingOrder) {
|
|
|
|
OLDEST_FIRST -> statuses.first().id
|
|
|
|
NEWEST_FIRST -> statuses.last().id
|
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
timelineDao.insertStatus(
|
2022-05-29 19:22:59 +02:00
|
|
|
Placeholder(
|
Keep scroll position when loading missing statuses (#3000)
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
2023-01-13 19:26:24 +01:00
|
|
|
idToConvert,
|
2022-05-29 19:22:59 +02:00
|
|
|
loading = false
|
|
|
|
).toEntity(activeAccount.id)
|
2022-01-11 19:00:29 +01:00
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
2022-02-02 18:29:59 +01:00
|
|
|
} catch (e: Exception) {
|
2022-03-08 21:39:59 +01:00
|
|
|
ifExpected(e) {
|
|
|
|
loadMoreFailed(placeholderId, e)
|
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private suspend fun loadMoreFailed(placeholderId: String, e: Exception) {
|
|
|
|
Log.w("CachedTimelineVM", "failed loading statuses", e)
|
|
|
|
val activeAccount = accountManager.activeAccount!!
|
2022-05-29 19:22:59 +02:00
|
|
|
db.timelineDao()
|
|
|
|
.insertStatus(Placeholder(placeholderId, loading = false).toEntity(activeAccount.id))
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
|
2023-09-26 09:08:58 +02:00
|
|
|
override fun handleStatusChangedEvent(status: Status) {
|
2022-01-11 19:00:29 +01:00
|
|
|
// handled by CacheUpdater
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun fullReload() {
|
|
|
|
viewModelScope.launch {
|
|
|
|
val activeAccount = accountManager.activeAccount!!
|
2022-03-02 20:40:06 +01:00
|
|
|
db.timelineDao().removeAll(activeAccount.id)
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
2022-02-21 19:33:10 +01:00
|
|
|
|
2023-05-08 13:57:17 +02:00
|
|
|
override fun saveReadingPosition(statusId: String) {
|
|
|
|
accountManager.activeAccount?.let { account ->
|
|
|
|
Log.d(TAG, "Saving position at: $statusId")
|
|
|
|
account.lastVisibleHomeTimelineStatusId = statusId
|
|
|
|
accountManager.saveAccount(account)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-20 16:11:30 +02:00
|
|
|
override suspend fun invalidate() {
|
|
|
|
// invalidating when we don't have statuses yet can cause empty timelines because it cancels the network load
|
|
|
|
if (db.timelineDao().getStatusCount(accountManager.activeAccount!!.id) > 0) {
|
|
|
|
currentPagingSource?.invalidate()
|
|
|
|
}
|
2022-05-29 19:22:59 +02:00
|
|
|
}
|
|
|
|
|
2024-03-09 16:12:18 +01:00
|
|
|
override suspend fun translate(status: StatusViewData.Concrete): NetworkResult<Unit> {
|
|
|
|
translations.value = translations.value + (status.id to TranslationViewData.Loading)
|
|
|
|
return timelineCases.translate(status.actionableId)
|
|
|
|
.map { translation ->
|
|
|
|
translations.value =
|
|
|
|
translations.value + (status.id to TranslationViewData.Loaded(translation))
|
|
|
|
}
|
|
|
|
.onFailure {
|
|
|
|
translations.value = translations.value - status.id
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun untranslate(status: StatusViewData.Concrete) {
|
|
|
|
translations.value = translations.value - status.id
|
|
|
|
}
|
|
|
|
|
2022-02-21 19:33:10 +01:00
|
|
|
companion object {
|
2023-05-08 13:57:17 +02:00
|
|
|
private const val TAG = "CachedTimelineViewModel"
|
2022-02-21 19:33:10 +01:00
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|