2021-06-11 20:15:40 +02: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
|
|
|
|
|
|
|
|
import android.os.Bundle
|
|
|
|
import android.util.Log
|
|
|
|
import android.view.LayoutInflater
|
|
|
|
import android.view.View
|
|
|
|
import android.view.ViewGroup
|
|
|
|
import android.view.accessibility.AccessibilityManager
|
|
|
|
import androidx.core.content.ContextCompat
|
|
|
|
import androidx.lifecycle.Lifecycle
|
2022-01-11 19:00:29 +01:00
|
|
|
import androidx.lifecycle.ViewModelProvider
|
|
|
|
import androidx.lifecycle.lifecycleScope
|
|
|
|
import androidx.paging.LoadState
|
2021-06-11 20:15:40 +02:00
|
|
|
import androidx.preference.PreferenceManager
|
2021-06-28 21:13:24 +02:00
|
|
|
import androidx.recyclerview.widget.DividerItemDecoration
|
|
|
|
import androidx.recyclerview.widget.LinearLayoutManager
|
|
|
|
import androidx.recyclerview.widget.RecyclerView
|
|
|
|
import androidx.recyclerview.widget.SimpleItemAnimator
|
2021-06-11 20:15:40 +02:00
|
|
|
import androidx.swiperefreshlayout.widget.SwipeRefreshLayout.OnRefreshListener
|
|
|
|
import at.connyduck.sparkbutton.helpers.Utils
|
|
|
|
import autodispose2.androidx.lifecycle.autoDispose
|
|
|
|
import com.keylesspalace.tusky.AccountListActivity
|
|
|
|
import com.keylesspalace.tusky.AccountListActivity.Companion.newIntent
|
|
|
|
import com.keylesspalace.tusky.BaseActivity
|
|
|
|
import com.keylesspalace.tusky.R
|
2022-02-25 18:57:40 +01:00
|
|
|
import com.keylesspalace.tusky.adapter.StatusBaseViewHolder
|
2021-06-11 20:15:40 +02:00
|
|
|
import com.keylesspalace.tusky.appstore.EventHub
|
|
|
|
import com.keylesspalace.tusky.appstore.PreferenceChangedEvent
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.appstore.StatusComposedEvent
|
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
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.components.timeline.viewmodel.CachedTimelineViewModel
|
|
|
|
import com.keylesspalace.tusky.components.timeline.viewmodel.NetworkTimelineViewModel
|
|
|
|
import com.keylesspalace.tusky.components.timeline.viewmodel.TimelineViewModel
|
2021-06-11 20:15:40 +02:00
|
|
|
import com.keylesspalace.tusky.databinding.FragmentTimelineBinding
|
|
|
|
import com.keylesspalace.tusky.di.Injectable
|
|
|
|
import com.keylesspalace.tusky.di.ViewModelFactory
|
2022-01-11 19:00:29 +01:00
|
|
|
import com.keylesspalace.tusky.entity.Status
|
2021-06-11 20:15:40 +02:00
|
|
|
import com.keylesspalace.tusky.fragment.SFragment
|
|
|
|
import com.keylesspalace.tusky.interfaces.ActionButtonActivity
|
|
|
|
import com.keylesspalace.tusky.interfaces.RefreshableFragment
|
|
|
|
import com.keylesspalace.tusky.interfaces.ReselectableFragment
|
|
|
|
import com.keylesspalace.tusky.interfaces.StatusActionListener
|
|
|
|
import com.keylesspalace.tusky.settings.PrefKeys
|
2021-06-28 21:13:24 +02:00
|
|
|
import com.keylesspalace.tusky.util.CardViewMode
|
|
|
|
import com.keylesspalace.tusky.util.ListStatusAccessibilityDelegate
|
|
|
|
import com.keylesspalace.tusky.util.StatusDisplayOptions
|
|
|
|
import com.keylesspalace.tusky.util.hide
|
|
|
|
import com.keylesspalace.tusky.util.show
|
|
|
|
import com.keylesspalace.tusky.util.viewBinding
|
2021-06-11 20:15:40 +02:00
|
|
|
import com.keylesspalace.tusky.viewdata.AttachmentViewData
|
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.viewdata.StatusViewData
|
2021-06-11 20:15:40 +02:00
|
|
|
import io.reactivex.rxjava3.android.schedulers.AndroidSchedulers
|
|
|
|
import io.reactivex.rxjava3.core.Observable
|
2022-01-11 19:00:29 +01:00
|
|
|
import kotlinx.coroutines.flow.collectLatest
|
|
|
|
import kotlinx.coroutines.launch
|
|
|
|
import java.io.IOException
|
2021-06-11 20:15:40 +02:00
|
|
|
import java.util.concurrent.TimeUnit
|
|
|
|
import javax.inject.Inject
|
|
|
|
|
2021-06-28 21:13:24 +02:00
|
|
|
class TimelineFragment :
|
|
|
|
SFragment(),
|
|
|
|
OnRefreshListener,
|
|
|
|
StatusActionListener,
|
|
|
|
Injectable,
|
|
|
|
ReselectableFragment,
|
|
|
|
RefreshableFragment {
|
2021-06-11 20:15:40 +02:00
|
|
|
|
|
|
|
@Inject
|
|
|
|
lateinit var viewModelFactory: ViewModelFactory
|
|
|
|
|
|
|
|
@Inject
|
|
|
|
lateinit var eventHub: EventHub
|
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
private val viewModel: TimelineViewModel by lazy {
|
|
|
|
if (kind == TimelineViewModel.Kind.HOME) {
|
2022-03-09 20:50:23 +01:00
|
|
|
ViewModelProvider(this, viewModelFactory)[CachedTimelineViewModel::class.java]
|
2022-01-11 19:00:29 +01:00
|
|
|
} else {
|
2022-03-09 20:50:23 +01:00
|
|
|
ViewModelProvider(this, viewModelFactory)[NetworkTimelineViewModel::class.java]
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
2021-06-11 20:15:40 +02:00
|
|
|
|
|
|
|
private val binding by viewBinding(FragmentTimelineBinding::bind)
|
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
private lateinit var kind: TimelineViewModel.Kind
|
|
|
|
|
|
|
|
private lateinit var adapter: TimelinePagingAdapter
|
2021-06-11 20:15:40 +02:00
|
|
|
|
|
|
|
private var isSwipeToRefreshEnabled = true
|
|
|
|
private var hideFab = false
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Adapter position of the placeholder that was most recently clicked to "Load more". If null
|
|
|
|
* then there is no active "Load more" operation
|
|
|
|
*/
|
|
|
|
private var loadMorePosition: Int? = null
|
|
|
|
|
|
|
|
/** ID of the status immediately below the most recent "Load more" placeholder click */
|
|
|
|
// The Paging library assumes that the user will be scrolling down a list of items,
|
|
|
|
// and if new items are loaded but not visible then it's reasonable to scroll to the top
|
|
|
|
// of the inserted items. It does not seem to be possible to disable that behaviour.
|
|
|
|
//
|
|
|
|
// That behaviour should depend on the user's preferred reading order. If they prefer to
|
|
|
|
// read oldest first then the list should be scrolled to the bottom of the freshly
|
|
|
|
// inserted statuses.
|
|
|
|
//
|
|
|
|
// To do this:
|
|
|
|
//
|
|
|
|
// 1. When "Load more" is clicked (onLoadMore()):
|
|
|
|
// a. Remember the adapter position of the "Load more" item in loadMorePosition
|
|
|
|
// b. Remember the ID of the status immediately below the "Load more" item in
|
|
|
|
// statusIdBelowLoadMore
|
|
|
|
// 2. After the new items have been inserted, search the adapter for the position of the
|
|
|
|
// status with id == statusIdBelowLoadMore.
|
|
|
|
// 3. If this position is still visible on screen then do nothing, otherwise, scroll the view
|
|
|
|
// so that the status is visible.
|
|
|
|
//
|
|
|
|
// The user can then scroll up to read the new statuses.
|
|
|
|
private var statusIdBelowLoadMore: String? = null
|
|
|
|
|
|
|
|
/** The user's preferred reading order */
|
|
|
|
private lateinit var readingOrder: ReadingOrder
|
|
|
|
|
2021-06-11 20:15:40 +02:00
|
|
|
override fun onCreate(savedInstanceState: Bundle?) {
|
|
|
|
super.onCreate(savedInstanceState)
|
|
|
|
|
|
|
|
val arguments = requireArguments()
|
2022-01-11 19:00:29 +01:00
|
|
|
kind = TimelineViewModel.Kind.valueOf(arguments.getString(KIND_ARG)!!)
|
2021-06-11 20:15:40 +02:00
|
|
|
val id: String? = if (kind == TimelineViewModel.Kind.USER ||
|
|
|
|
kind == TimelineViewModel.Kind.USER_PINNED ||
|
|
|
|
kind == TimelineViewModel.Kind.USER_WITH_REPLIES ||
|
|
|
|
kind == TimelineViewModel.Kind.LIST
|
|
|
|
) {
|
|
|
|
arguments.getString(ID_ARG)!!
|
|
|
|
} else {
|
|
|
|
null
|
|
|
|
}
|
|
|
|
|
|
|
|
val tags = if (kind == TimelineViewModel.Kind.TAG) {
|
|
|
|
arguments.getStringArrayList(HASHTAGS_ARG)!!
|
|
|
|
} else {
|
|
|
|
listOf()
|
|
|
|
}
|
|
|
|
viewModel.init(
|
|
|
|
kind,
|
|
|
|
id,
|
|
|
|
tags,
|
|
|
|
)
|
|
|
|
|
|
|
|
isSwipeToRefreshEnabled = arguments.getBoolean(ARG_ENABLE_SWIPE_TO_REFRESH, true)
|
|
|
|
|
2022-03-09 20:50:23 +01:00
|
|
|
val preferences = PreferenceManager.getDefaultSharedPreferences(requireContext())
|
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
|
|
|
readingOrder = ReadingOrder.from(preferences.getString(PrefKeys.READING_ORDER, null))
|
|
|
|
|
2021-06-11 20:15:40 +02:00
|
|
|
val statusDisplayOptions = StatusDisplayOptions(
|
|
|
|
animateAvatars = preferences.getBoolean(PrefKeys.ANIMATE_GIF_AVATARS, false),
|
|
|
|
mediaPreviewEnabled = accountManager.activeAccount!!.mediaPreviewEnabled,
|
|
|
|
useAbsoluteTime = preferences.getBoolean(PrefKeys.ABSOLUTE_TIME_VIEW, false),
|
|
|
|
showBotOverlay = preferences.getBoolean(PrefKeys.SHOW_BOT_OVERLAY, true),
|
|
|
|
useBlurhash = preferences.getBoolean(PrefKeys.USE_BLURHASH, true),
|
|
|
|
cardViewMode = if (preferences.getBoolean(
|
|
|
|
PrefKeys.SHOW_CARDS_IN_TIMELINES,
|
|
|
|
false
|
|
|
|
)
|
|
|
|
) CardViewMode.INDENTED else CardViewMode.NONE,
|
|
|
|
confirmReblogs = preferences.getBoolean(PrefKeys.CONFIRM_REBLOGS, true),
|
2021-12-29 13:44:00 +01:00
|
|
|
confirmFavourites = preferences.getBoolean(PrefKeys.CONFIRM_FAVOURITES, false),
|
2021-06-11 20:15:40 +02:00
|
|
|
hideStats = preferences.getBoolean(PrefKeys.WELLBEING_HIDE_STATS_POSTS, false),
|
|
|
|
animateEmojis = preferences.getBoolean(PrefKeys.ANIMATE_CUSTOM_EMOJIS, false)
|
|
|
|
)
|
2022-01-11 19:00:29 +01:00
|
|
|
adapter = TimelinePagingAdapter(
|
2021-06-11 20:15:40 +02:00
|
|
|
statusDisplayOptions,
|
|
|
|
this
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onCreateView(
|
|
|
|
inflater: LayoutInflater,
|
|
|
|
container: ViewGroup?,
|
|
|
|
savedInstanceState: Bundle?
|
|
|
|
): View? {
|
|
|
|
return inflater.inflate(R.layout.fragment_timeline, container, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
|
|
|
|
setupSwipeRefreshLayout()
|
|
|
|
setupRecyclerView()
|
2022-01-11 19:00:29 +01:00
|
|
|
|
|
|
|
adapter.addLoadStateListener { loadState ->
|
2022-04-30 08:09:59 +02:00
|
|
|
if (loadState.refresh != LoadState.Loading && loadState.source.refresh != LoadState.Loading) {
|
2022-01-11 19:00:29 +01:00
|
|
|
binding.swipeRefreshLayout.isRefreshing = false
|
|
|
|
}
|
|
|
|
|
|
|
|
binding.statusView.hide()
|
|
|
|
binding.progressBar.hide()
|
|
|
|
|
|
|
|
if (adapter.itemCount == 0) {
|
|
|
|
when (loadState.refresh) {
|
|
|
|
is LoadState.NotLoading -> {
|
2022-03-12 09:38:59 +01:00
|
|
|
if (loadState.append is LoadState.NotLoading && loadState.source.refresh is LoadState.NotLoading) {
|
2022-01-11 19:00:29 +01:00
|
|
|
binding.statusView.show()
|
|
|
|
binding.statusView.setup(R.drawable.elephant_friend_empty, R.string.message_empty, null)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
is LoadState.Error -> {
|
|
|
|
binding.statusView.show()
|
|
|
|
|
|
|
|
if ((loadState.refresh as LoadState.Error).error is IOException) {
|
|
|
|
binding.statusView.setup(R.drawable.elephant_offline, R.string.error_network, null)
|
|
|
|
} else {
|
|
|
|
binding.statusView.setup(R.drawable.elephant_error, R.string.error_generic, null)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
is LoadState.Loading -> {
|
|
|
|
binding.progressBar.show()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
adapter.registerAdapterDataObserver(object : RecyclerView.AdapterDataObserver() {
|
|
|
|
override fun onItemRangeInserted(positionStart: Int, itemCount: Int) {
|
|
|
|
if (positionStart == 0 && adapter.itemCount != itemCount) {
|
|
|
|
binding.recyclerView.post {
|
2022-02-07 20:04:40 +01:00
|
|
|
if (getView() != null) {
|
|
|
|
if (isSwipeToRefreshEnabled) {
|
|
|
|
binding.recyclerView.scrollBy(0, Utils.dpToPx(requireContext(), -30))
|
|
|
|
} else binding.recyclerView.scrollToPosition(0)
|
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
}
|
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
|
|
|
if (readingOrder == ReadingOrder.OLDEST_FIRST) {
|
|
|
|
updateReadingPositionForOldestFirst()
|
|
|
|
}
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
|
|
|
})
|
|
|
|
|
2022-03-06 17:40:24 +01:00
|
|
|
viewLifecycleOwner.lifecycleScope.launch {
|
2022-01-11 19:00:29 +01:00
|
|
|
viewModel.statuses.collectLatest { pagingData ->
|
|
|
|
adapter.submitData(pagingData)
|
|
|
|
}
|
|
|
|
}
|
2021-06-11 20:15:40 +02:00
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
if (actionButtonPresent()) {
|
2022-03-09 20:50:23 +01:00
|
|
|
val preferences = PreferenceManager.getDefaultSharedPreferences(requireContext())
|
2021-06-11 20:15:40 +02:00
|
|
|
hideFab = preferences.getBoolean("fabHide", false)
|
2022-05-29 19:23:08 +02:00
|
|
|
binding.recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
|
2021-06-11 20:15:40 +02:00
|
|
|
override fun onScrolled(view: RecyclerView, dx: Int, dy: Int) {
|
|
|
|
val composeButton = (activity as ActionButtonActivity).actionButton
|
|
|
|
if (composeButton != null) {
|
|
|
|
if (hideFab) {
|
|
|
|
if (dy > 0 && composeButton.isShown) {
|
|
|
|
composeButton.hide() // hides the button if we're scrolling down
|
|
|
|
} else if (dy < 0 && !composeButton.isShown) {
|
|
|
|
composeButton.show() // shows it if we are scrolling up
|
|
|
|
}
|
|
|
|
} else if (!composeButton.isShown) {
|
|
|
|
composeButton.show()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2022-05-29 19:23:08 +02:00
|
|
|
})
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
2022-02-25 18:56:58 +01:00
|
|
|
eventHub.events
|
|
|
|
.observeOn(AndroidSchedulers.mainThread())
|
|
|
|
.autoDispose(this, Lifecycle.Event.ON_DESTROY)
|
|
|
|
.subscribe { event ->
|
|
|
|
when (event) {
|
|
|
|
is PreferenceChangedEvent -> {
|
|
|
|
onPreferenceChanged(event.preferenceKey)
|
|
|
|
}
|
|
|
|
is StatusComposedEvent -> {
|
|
|
|
val status = event.status
|
|
|
|
handleStatusComposeEvent(status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
}
|
2022-02-25 18:56:58 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Set the correct reading position in the timeline after the user clicked "Load more",
|
|
|
|
* assuming the reading position should be below the freshly-loaded statuses.
|
|
|
|
*/
|
|
|
|
// Note: The positionStart parameter to onItemRangeInserted() does not always
|
|
|
|
// match the adapter position where data was inserted (which is why loadMorePosition
|
|
|
|
// is tracked manually, see this bug report for another example:
|
|
|
|
// https://github.com/android/architecture-components-samples/issues/726).
|
|
|
|
private fun updateReadingPositionForOldestFirst() {
|
|
|
|
var position = loadMorePosition ?: return
|
|
|
|
val statusIdBelowLoadMore = statusIdBelowLoadMore ?: return
|
|
|
|
|
|
|
|
var status: StatusViewData?
|
|
|
|
while (adapter.peek(position).let { status = it; it != null }) {
|
|
|
|
if (status?.id == statusIdBelowLoadMore) {
|
|
|
|
val lastVisiblePosition =
|
|
|
|
(binding.recyclerView.layoutManager as LinearLayoutManager).findLastVisibleItemPosition()
|
|
|
|
if (position > lastVisiblePosition) {
|
|
|
|
binding.recyclerView.scrollToPosition(position)
|
|
|
|
}
|
|
|
|
break
|
|
|
|
}
|
|
|
|
position++
|
|
|
|
}
|
|
|
|
loadMorePosition = null
|
|
|
|
}
|
|
|
|
|
2022-02-25 18:56:58 +01:00
|
|
|
private fun setupSwipeRefreshLayout() {
|
|
|
|
binding.swipeRefreshLayout.isEnabled = isSwipeToRefreshEnabled
|
|
|
|
binding.swipeRefreshLayout.setOnRefreshListener(this)
|
|
|
|
binding.swipeRefreshLayout.setColorSchemeResources(R.color.tusky_blue)
|
|
|
|
}
|
|
|
|
|
|
|
|
private fun setupRecyclerView() {
|
|
|
|
binding.recyclerView.setAccessibilityDelegateCompat(
|
|
|
|
ListStatusAccessibilityDelegate(binding.recyclerView, this) { pos ->
|
2022-03-06 17:40:24 +01:00
|
|
|
if (pos in 0 until adapter.itemCount) {
|
|
|
|
adapter.peek(pos)
|
|
|
|
} else {
|
|
|
|
null
|
|
|
|
}
|
2022-02-25 18:56:58 +01:00
|
|
|
}
|
|
|
|
)
|
|
|
|
binding.recyclerView.setHasFixedSize(true)
|
2022-05-29 19:23:08 +02:00
|
|
|
binding.recyclerView.layoutManager = LinearLayoutManager(context)
|
2022-02-25 18:56:58 +01:00
|
|
|
val divider = DividerItemDecoration(context, RecyclerView.VERTICAL)
|
|
|
|
binding.recyclerView.addItemDecoration(divider)
|
|
|
|
|
|
|
|
// CWs are expanded without animation, buttons animate itself, we don't need it basically
|
|
|
|
(binding.recyclerView.itemAnimator as SimpleItemAnimator).supportsChangeAnimations = false
|
|
|
|
binding.recyclerView.adapter = adapter
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onRefresh() {
|
|
|
|
binding.statusView.hide()
|
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
adapter.refresh()
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onReply(position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
2021-06-11 20:15:40 +02:00
|
|
|
super.reply(status.status)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onReblog(reblog: Boolean, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.reblog(reblog, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onFavourite(favourite: Boolean, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.favorite(favourite, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onBookmark(bookmark: Boolean, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.bookmark(bookmark, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onVoteInPoll(position: Int, choices: List<Int>) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.voteInPoll(choices, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onMore(view: View, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
super.more(status.status, view, position)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onOpenReblog(position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
super.openReblog(status.status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onExpandedChange(expanded: Boolean, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.changeExpanded(expanded, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onContentHiddenChange(isShowing: Boolean, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.changeContentShowing(isShowing, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onShowReblogs(position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val statusId = adapter.peek(position)?.asStatusOrNull()?.id ?: return
|
2021-06-11 20:15:40 +02:00
|
|
|
val intent = newIntent(requireContext(), AccountListActivity.Type.REBLOGGED, statusId)
|
|
|
|
(activity as BaseActivity).startActivityWithSlideInAnimation(intent)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onShowFavs(position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val statusId = adapter.peek(position)?.asStatusOrNull()?.id ?: return
|
2021-06-11 20:15:40 +02:00
|
|
|
val intent = newIntent(requireContext(), AccountListActivity.Type.FAVOURITED, statusId)
|
|
|
|
(activity as BaseActivity).startActivityWithSlideInAnimation(intent)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onLoadMore(position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val placeholder = adapter.peek(position)?.asPlaceholderOrNull() ?: return
|
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
|
|
|
loadMorePosition = position
|
|
|
|
statusIdBelowLoadMore = adapter.peek(position + 1)?.id
|
2022-01-11 19:00:29 +01:00
|
|
|
viewModel.loadMore(placeholder.id)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onContentCollapsedChange(isCollapsed: Boolean, position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.changeContentCollapsed(isCollapsed, status)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewMedia(position: Int, attachmentIndex: Int, view: View?) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
2021-06-11 20:15:40 +02:00
|
|
|
super.viewMedia(
|
|
|
|
attachmentIndex,
|
|
|
|
AttachmentViewData.list(status.actionable),
|
|
|
|
view
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewThread(position: Int) {
|
2022-01-11 19:00:29 +01:00
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
2021-06-11 20:15:40 +02:00
|
|
|
super.viewThread(status.actionable.id, status.actionable.url)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewTag(tag: String) {
|
|
|
|
if (viewModel.kind == TimelineViewModel.Kind.TAG && viewModel.tags.size == 1 &&
|
|
|
|
viewModel.tags.contains(tag)
|
|
|
|
) {
|
|
|
|
// If already viewing a tag page, then ignore any request to view that tag again.
|
|
|
|
return
|
|
|
|
}
|
|
|
|
super.viewTag(tag)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewAccount(id: String) {
|
2021-06-28 21:13:24 +02:00
|
|
|
if ((
|
|
|
|
viewModel.kind == TimelineViewModel.Kind.USER ||
|
|
|
|
viewModel.kind == TimelineViewModel.Kind.USER_WITH_REPLIES
|
|
|
|
) &&
|
2021-06-11 20:15:40 +02:00
|
|
|
viewModel.id == id
|
|
|
|
) {
|
|
|
|
/* If already viewing an account page, then any requests to view that account page
|
|
|
|
* should be ignored. */
|
|
|
|
return
|
|
|
|
}
|
|
|
|
super.viewAccount(id)
|
|
|
|
}
|
|
|
|
|
|
|
|
private fun onPreferenceChanged(key: String) {
|
2022-03-09 20:50:23 +01:00
|
|
|
val sharedPreferences = PreferenceManager.getDefaultSharedPreferences(requireContext())
|
2021-06-11 20:15:40 +02:00
|
|
|
when (key) {
|
|
|
|
PrefKeys.FAB_HIDE -> {
|
|
|
|
hideFab = sharedPreferences.getBoolean(PrefKeys.FAB_HIDE, false)
|
|
|
|
}
|
|
|
|
PrefKeys.MEDIA_PREVIEW_ENABLED -> {
|
|
|
|
val enabled = accountManager.activeAccount!!.mediaPreviewEnabled
|
|
|
|
val oldMediaPreviewEnabled = adapter.mediaPreviewEnabled
|
|
|
|
if (enabled != oldMediaPreviewEnabled) {
|
|
|
|
adapter.mediaPreviewEnabled = enabled
|
2022-02-25 18:57:40 +01:00
|
|
|
adapter.notifyItemRangeChanged(0, adapter.itemCount)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
}
|
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
|
|
|
PrefKeys.READING_ORDER -> {
|
|
|
|
readingOrder = ReadingOrder.from(
|
|
|
|
sharedPreferences.getString(PrefKeys.READING_ORDER, null)
|
|
|
|
)
|
|
|
|
}
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
private fun handleStatusComposeEvent(status: Status) {
|
|
|
|
when (kind) {
|
|
|
|
TimelineViewModel.Kind.HOME,
|
|
|
|
TimelineViewModel.Kind.PUBLIC_FEDERATED,
|
|
|
|
TimelineViewModel.Kind.PUBLIC_LOCAL -> adapter.refresh()
|
|
|
|
TimelineViewModel.Kind.USER,
|
|
|
|
TimelineViewModel.Kind.USER_WITH_REPLIES -> if (status.account.id == viewModel.id) {
|
|
|
|
adapter.refresh()
|
|
|
|
}
|
|
|
|
TimelineViewModel.Kind.TAG,
|
|
|
|
TimelineViewModel.Kind.FAVOURITES,
|
|
|
|
TimelineViewModel.Kind.LIST,
|
|
|
|
TimelineViewModel.Kind.BOOKMARKS,
|
|
|
|
TimelineViewModel.Kind.USER_PINNED -> return
|
|
|
|
}
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
2022-01-11 19:00:29 +01:00
|
|
|
public override fun removeItem(position: Int) {
|
|
|
|
val status = adapter.peek(position)?.asStatusOrNull() ?: return
|
|
|
|
viewModel.removeStatusWithId(status.id)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private fun actionButtonPresent(): Boolean {
|
|
|
|
return viewModel.kind != TimelineViewModel.Kind.TAG &&
|
2021-06-28 21:13:24 +02:00
|
|
|
viewModel.kind != TimelineViewModel.Kind.FAVOURITES &&
|
|
|
|
viewModel.kind != TimelineViewModel.Kind.BOOKMARKS &&
|
|
|
|
activity is ActionButtonActivity
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private var talkBackWasEnabled = false
|
|
|
|
|
|
|
|
override fun onResume() {
|
|
|
|
super.onResume()
|
|
|
|
val a11yManager =
|
|
|
|
ContextCompat.getSystemService(requireContext(), AccessibilityManager::class.java)
|
|
|
|
|
|
|
|
val wasEnabled = talkBackWasEnabled
|
|
|
|
talkBackWasEnabled = a11yManager?.isEnabled == true
|
|
|
|
Log.d(TAG, "talkback was enabled: $wasEnabled, now $talkBackWasEnabled")
|
|
|
|
if (talkBackWasEnabled && !wasEnabled) {
|
2022-02-25 18:57:40 +01:00
|
|
|
adapter.notifyItemRangeChanged(0, adapter.itemCount)
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
startUpdateTimestamp()
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Start to update adapter every minute to refresh timestamp
|
|
|
|
* If setting absoluteTimeView is false
|
|
|
|
* Auto dispose observable on pause
|
|
|
|
*/
|
|
|
|
private fun startUpdateTimestamp() {
|
2022-03-09 20:50:23 +01:00
|
|
|
val preferences = PreferenceManager.getDefaultSharedPreferences(requireContext())
|
2021-06-11 20:15:40 +02:00
|
|
|
val useAbsoluteTime = preferences.getBoolean(PrefKeys.ABSOLUTE_TIME_VIEW, false)
|
|
|
|
if (!useAbsoluteTime) {
|
2022-05-27 18:43:10 +02:00
|
|
|
Observable.interval(0, 1, TimeUnit.MINUTES)
|
2021-06-11 20:15:40 +02:00
|
|
|
.observeOn(AndroidSchedulers.mainThread())
|
|
|
|
.autoDispose(this, Lifecycle.Event.ON_PAUSE)
|
2022-01-11 19:00:29 +01:00
|
|
|
.subscribe {
|
2022-02-25 18:57:40 +01:00
|
|
|
adapter.notifyItemRangeChanged(0, adapter.itemCount, listOf(StatusBaseViewHolder.Key.KEY_CREATED))
|
2022-01-11 19:00:29 +01:00
|
|
|
}
|
2021-06-11 20:15:40 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onReselect() {
|
|
|
|
if (isAdded) {
|
2022-05-29 19:23:08 +02:00
|
|
|
binding.recyclerView.layoutManager?.scrollToPosition(0)
|
2021-06-11 20:15:40 +02:00
|
|
|
binding.recyclerView.stopScroll()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun refreshContent() {
|
|
|
|
onRefresh()
|
|
|
|
}
|
|
|
|
|
|
|
|
companion object {
|
|
|
|
private const val TAG = "TimelineF" // logging tag
|
|
|
|
private const val KIND_ARG = "kind"
|
|
|
|
private const val ID_ARG = "id"
|
|
|
|
private const val HASHTAGS_ARG = "hashtags"
|
|
|
|
private const val ARG_ENABLE_SWIPE_TO_REFRESH = "enableSwipeToRefresh"
|
|
|
|
|
|
|
|
fun newInstance(
|
|
|
|
kind: TimelineViewModel.Kind,
|
|
|
|
hashtagOrId: String? = null,
|
|
|
|
enableSwipeToRefresh: Boolean = true
|
|
|
|
): TimelineFragment {
|
|
|
|
val fragment = TimelineFragment()
|
|
|
|
val arguments = Bundle(3)
|
|
|
|
arguments.putString(KIND_ARG, kind.name)
|
|
|
|
arguments.putString(ID_ARG, hashtagOrId)
|
|
|
|
arguments.putBoolean(ARG_ENABLE_SWIPE_TO_REFRESH, enableSwipeToRefresh)
|
|
|
|
fragment.arguments = arguments
|
|
|
|
return fragment
|
|
|
|
}
|
|
|
|
|
|
|
|
@JvmStatic
|
|
|
|
fun newHashtagInstance(hashtags: List<String>): TimelineFragment {
|
|
|
|
val fragment = TimelineFragment()
|
|
|
|
val arguments = Bundle(3)
|
|
|
|
arguments.putString(KIND_ARG, TimelineViewModel.Kind.TAG.name)
|
|
|
|
arguments.putStringArrayList(HASHTAGS_ARG, ArrayList(hashtags))
|
|
|
|
arguments.putBoolean(ARG_ENABLE_SWIPE_TO_REFRESH, true)
|
|
|
|
fragment.arguments = arguments
|
|
|
|
return fragment
|
|
|
|
}
|
|
|
|
}
|
2021-06-28 21:13:24 +02:00
|
|
|
}
|