2022-08-15 11:00:18 +02:00
|
|
|
/* Copyright 2022 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.viewthread
|
|
|
|
|
|
|
|
import android.os.Bundle
|
|
|
|
import android.util.Log
|
|
|
|
import android.view.LayoutInflater
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
import android.view.Menu
|
|
|
|
import android.view.MenuInflater
|
|
|
|
import android.view.MenuItem
|
2022-08-15 11:00:18 +02:00
|
|
|
import android.view.View
|
|
|
|
import android.view.ViewGroup
|
|
|
|
import android.widget.LinearLayout
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
import androidx.annotation.CheckResult
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
import androidx.core.view.MenuProvider
|
2023-01-02 14:09:18 +01:00
|
|
|
import androidx.fragment.app.commit
|
2022-08-15 11:00:18 +02:00
|
|
|
import androidx.fragment.app.viewModels
|
2023-02-03 19:21:21 +01:00
|
|
|
import androidx.lifecycle.Lifecycle
|
2022-08-15 11:00:18 +02:00
|
|
|
import androidx.lifecycle.lifecycleScope
|
|
|
|
import androidx.preference.PreferenceManager
|
|
|
|
import androidx.recyclerview.widget.DividerItemDecoration
|
|
|
|
import androidx.recyclerview.widget.LinearLayoutManager
|
|
|
|
import androidx.recyclerview.widget.SimpleItemAnimator
|
|
|
|
import androidx.swiperefreshlayout.widget.SwipeRefreshLayout.OnRefreshListener
|
|
|
|
import com.google.android.material.snackbar.Snackbar
|
|
|
|
import com.keylesspalace.tusky.BaseActivity
|
|
|
|
import com.keylesspalace.tusky.R
|
2023-02-04 20:29:13 +01:00
|
|
|
import com.keylesspalace.tusky.components.accountlist.AccountListActivity
|
|
|
|
import com.keylesspalace.tusky.components.accountlist.AccountListActivity.Companion.newIntent
|
2023-01-02 14:09:18 +01:00
|
|
|
import com.keylesspalace.tusky.components.viewthread.edits.ViewEditsFragment
|
2022-08-15 11:00:18 +02:00
|
|
|
import com.keylesspalace.tusky.databinding.FragmentViewThreadBinding
|
|
|
|
import com.keylesspalace.tusky.di.Injectable
|
|
|
|
import com.keylesspalace.tusky.di.ViewModelFactory
|
|
|
|
import com.keylesspalace.tusky.fragment.SFragment
|
|
|
|
import com.keylesspalace.tusky.interfaces.StatusActionListener
|
|
|
|
import com.keylesspalace.tusky.settings.PrefKeys
|
|
|
|
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.openLink
|
|
|
|
import com.keylesspalace.tusky.util.show
|
|
|
|
import com.keylesspalace.tusky.util.viewBinding
|
|
|
|
import com.keylesspalace.tusky.viewdata.AttachmentViewData.Companion.list
|
|
|
|
import com.keylesspalace.tusky.viewdata.StatusViewData
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
import kotlinx.coroutines.CoroutineStart
|
|
|
|
import kotlinx.coroutines.awaitCancellation
|
|
|
|
import kotlinx.coroutines.delay
|
2022-08-15 11:00:18 +02:00
|
|
|
import kotlinx.coroutines.launch
|
|
|
|
import java.io.IOException
|
|
|
|
import javax.inject.Inject
|
|
|
|
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
class ViewThreadFragment :
|
|
|
|
SFragment(),
|
|
|
|
OnRefreshListener,
|
|
|
|
StatusActionListener,
|
|
|
|
MenuProvider,
|
|
|
|
Injectable {
|
2022-08-15 11:00:18 +02:00
|
|
|
|
|
|
|
@Inject
|
|
|
|
lateinit var viewModelFactory: ViewModelFactory
|
|
|
|
|
|
|
|
private val viewModel: ViewThreadViewModel by viewModels { viewModelFactory }
|
|
|
|
|
|
|
|
private val binding by viewBinding(FragmentViewThreadBinding::bind)
|
|
|
|
|
|
|
|
private lateinit var adapter: ThreadAdapter
|
|
|
|
private lateinit var thisThreadsStatusId: String
|
|
|
|
|
|
|
|
private var alwaysShowSensitiveMedia = false
|
|
|
|
private var alwaysOpenSpoiler = false
|
|
|
|
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
/**
|
|
|
|
* State of the "reveal" menu item that shows/hides content that is behind a content
|
|
|
|
* warning. Setting this invalidates the menu to redraw the menu item.
|
|
|
|
*/
|
|
|
|
private var revealButtonState = RevealButtonState.NO_BUTTON
|
|
|
|
set(value) {
|
|
|
|
field = value
|
|
|
|
requireActivity().invalidateMenu()
|
|
|
|
}
|
|
|
|
|
2022-08-15 11:00:18 +02:00
|
|
|
override fun onCreate(savedInstanceState: Bundle?) {
|
|
|
|
super.onCreate(savedInstanceState)
|
|
|
|
thisThreadsStatusId = requireArguments().getString(ID_EXTRA)!!
|
|
|
|
val preferences = PreferenceManager.getDefaultSharedPreferences(requireContext())
|
|
|
|
|
|
|
|
val statusDisplayOptions = StatusDisplayOptions(
|
|
|
|
animateAvatars = preferences.getBoolean("animateGifAvatars", false),
|
|
|
|
mediaPreviewEnabled = accountManager.activeAccount!!.mediaPreviewEnabled,
|
|
|
|
useAbsoluteTime = preferences.getBoolean("absoluteTimeView", false),
|
|
|
|
showBotOverlay = preferences.getBoolean("showBotOverlay", true),
|
|
|
|
useBlurhash = preferences.getBoolean("useBlurhash", true),
|
|
|
|
cardViewMode = if (preferences.getBoolean("showCardsInTimelines", false)) {
|
|
|
|
CardViewMode.INDENTED
|
|
|
|
} else {
|
|
|
|
CardViewMode.NONE
|
|
|
|
},
|
|
|
|
confirmReblogs = preferences.getBoolean("confirmReblogs", true),
|
|
|
|
confirmFavourites = preferences.getBoolean("confirmFavourites", false),
|
|
|
|
hideStats = preferences.getBoolean(PrefKeys.WELLBEING_HIDE_STATS_POSTS, false),
|
|
|
|
animateEmojis = preferences.getBoolean(PrefKeys.ANIMATE_CUSTOM_EMOJIS, false)
|
|
|
|
)
|
|
|
|
adapter = ThreadAdapter(statusDisplayOptions, this)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onCreateView(
|
|
|
|
inflater: LayoutInflater,
|
|
|
|
container: ViewGroup?,
|
|
|
|
savedInstanceState: Bundle?
|
|
|
|
): View? {
|
|
|
|
return inflater.inflate(R.layout.fragment_view_thread, container, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
requireActivity().addMenuProvider(this, viewLifecycleOwner, Lifecycle.State.RESUMED)
|
2022-08-15 11:00:18 +02:00
|
|
|
|
|
|
|
binding.swipeRefreshLayout.setOnRefreshListener(this)
|
|
|
|
binding.swipeRefreshLayout.setColorSchemeResources(R.color.tusky_blue)
|
|
|
|
|
|
|
|
binding.recyclerView.setHasFixedSize(true)
|
|
|
|
binding.recyclerView.layoutManager = LinearLayoutManager(context)
|
|
|
|
binding.recyclerView.setAccessibilityDelegateCompat(
|
|
|
|
ListStatusAccessibilityDelegate(
|
|
|
|
binding.recyclerView,
|
|
|
|
this
|
|
|
|
) { index -> adapter.currentList.getOrNull(index) }
|
|
|
|
)
|
|
|
|
val divider = DividerItemDecoration(context, LinearLayout.VERTICAL)
|
|
|
|
binding.recyclerView.addItemDecoration(divider)
|
|
|
|
binding.recyclerView.addItemDecoration(ConversationLineItemDecoration(requireContext()))
|
|
|
|
alwaysShowSensitiveMedia = accountManager.activeAccount!!.alwaysShowSensitiveMedia
|
|
|
|
alwaysOpenSpoiler = accountManager.activeAccount!!.alwaysOpenSpoiler
|
|
|
|
|
|
|
|
binding.recyclerView.adapter = adapter
|
|
|
|
|
|
|
|
(binding.recyclerView.itemAnimator as SimpleItemAnimator).supportsChangeAnimations = false
|
|
|
|
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
var initialProgressBar = getProgressBarJob(binding.initialProgressBar, 500)
|
|
|
|
var threadProgressBar = getProgressBarJob(binding.threadProgressBar, 500)
|
|
|
|
|
2022-08-15 11:00:18 +02:00
|
|
|
viewLifecycleOwner.lifecycleScope.launch {
|
|
|
|
viewModel.uiState.collect { uiState ->
|
|
|
|
when (uiState) {
|
|
|
|
is ThreadUiState.Loading -> {
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
revealButtonState = RevealButtonState.NO_BUTTON
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
|
2022-08-15 11:00:18 +02:00
|
|
|
binding.recyclerView.hide()
|
|
|
|
binding.statusView.hide()
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
|
|
|
|
initialProgressBar = getProgressBarJob(binding.initialProgressBar, 500)
|
|
|
|
initialProgressBar.start()
|
|
|
|
}
|
|
|
|
is ThreadUiState.LoadingThread -> {
|
|
|
|
if (uiState.statusViewDatum == null) {
|
|
|
|
// no detailed statuses available, e.g. because author is blocked
|
|
|
|
activity?.finish()
|
|
|
|
return@collect
|
|
|
|
}
|
|
|
|
|
|
|
|
initialProgressBar.cancel()
|
|
|
|
threadProgressBar = getProgressBarJob(binding.threadProgressBar, 500)
|
|
|
|
threadProgressBar.start()
|
|
|
|
|
|
|
|
adapter.submitList(listOf(uiState.statusViewDatum))
|
|
|
|
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
revealButtonState = uiState.revealButton
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
binding.swipeRefreshLayout.isRefreshing = false
|
|
|
|
|
|
|
|
binding.recyclerView.show()
|
|
|
|
binding.statusView.hide()
|
2022-08-15 11:00:18 +02:00
|
|
|
}
|
|
|
|
is ThreadUiState.Error -> {
|
|
|
|
Log.w(TAG, "failed to load status", uiState.throwable)
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
initialProgressBar.cancel()
|
|
|
|
threadProgressBar.cancel()
|
2022-08-15 11:00:18 +02:00
|
|
|
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
revealButtonState = RevealButtonState.NO_BUTTON
|
2022-08-15 11:00:18 +02:00
|
|
|
binding.swipeRefreshLayout.isRefreshing = false
|
|
|
|
|
|
|
|
binding.recyclerView.hide()
|
|
|
|
binding.statusView.show()
|
|
|
|
|
|
|
|
if (uiState.throwable is IOException) {
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
binding.statusView.setup(
|
|
|
|
R.drawable.elephant_offline,
|
|
|
|
R.string.error_network
|
|
|
|
) {
|
2022-08-15 11:00:18 +02:00
|
|
|
viewModel.retry(thisThreadsStatusId)
|
|
|
|
}
|
|
|
|
} else {
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
binding.statusView.setup(
|
|
|
|
R.drawable.elephant_error,
|
|
|
|
R.string.error_generic
|
|
|
|
) {
|
2022-08-15 11:00:18 +02:00
|
|
|
viewModel.retry(thisThreadsStatusId)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
is ThreadUiState.Success -> {
|
2023-01-12 19:41:07 +01:00
|
|
|
if (uiState.statusViewData.none { viewData -> viewData.isDetailed }) {
|
|
|
|
// no detailed statuses available, e.g. because author is blocked
|
|
|
|
activity?.finish()
|
|
|
|
return@collect
|
|
|
|
}
|
|
|
|
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
threadProgressBar.cancel()
|
2022-12-05 14:44:52 +01:00
|
|
|
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
adapter.submitList(uiState.statusViewData) {
|
2023-02-03 19:21:21 +01:00
|
|
|
if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED) && viewModel.isInitialLoad) {
|
2023-01-12 19:41:07 +01:00
|
|
|
viewModel.isInitialLoad = false
|
|
|
|
|
|
|
|
// Ensure the top of the status is visible
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
(binding.recyclerView.layoutManager as LinearLayoutManager).scrollToPositionWithOffset(
|
|
|
|
uiState.detailedStatusPosition,
|
|
|
|
0
|
|
|
|
)
|
2023-01-12 19:41:07 +01:00
|
|
|
}
|
2022-08-15 11:00:18 +02:00
|
|
|
}
|
|
|
|
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
revealButtonState = uiState.revealButton
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
binding.swipeRefreshLayout.isRefreshing = false
|
2022-08-15 11:00:18 +02:00
|
|
|
|
|
|
|
binding.recyclerView.show()
|
|
|
|
binding.statusView.hide()
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
}
|
|
|
|
is ThreadUiState.Refreshing -> {
|
|
|
|
threadProgressBar.cancel()
|
2022-08-15 11:00:18 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
lifecycleScope.launch {
|
|
|
|
viewModel.errors.collect { throwable ->
|
|
|
|
Log.w(TAG, "failed to load status context", throwable)
|
|
|
|
Snackbar.make(binding.root, R.string.error_generic, Snackbar.LENGTH_SHORT)
|
|
|
|
.setAction(R.string.action_retry) {
|
|
|
|
viewModel.retry(thisThreadsStatusId)
|
|
|
|
}
|
|
|
|
.show()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
viewModel.loadThread(thisThreadsStatusId)
|
|
|
|
}
|
|
|
|
|
Add "Refresh" accessibility menu (#3121)
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
2023-03-01 19:58:18 +01:00
|
|
|
override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
|
|
|
|
menuInflater.inflate(R.menu.fragment_view_thread, menu)
|
|
|
|
val actionReveal = menu.findItem(R.id.action_reveal)
|
|
|
|
actionReveal.isVisible = revealButtonState != RevealButtonState.NO_BUTTON
|
|
|
|
actionReveal.setIcon(
|
|
|
|
when (revealButtonState) {
|
|
|
|
RevealButtonState.REVEAL -> R.drawable.ic_eye_24dp
|
|
|
|
else -> R.drawable.ic_hide_media_24dp
|
|
|
|
}
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
|
|
|
|
return when (menuItem.itemId) {
|
|
|
|
R.id.action_reveal -> {
|
|
|
|
viewModel.toggleRevealButton()
|
|
|
|
true
|
|
|
|
}
|
|
|
|
R.id.action_open_in_web -> {
|
|
|
|
context?.openLink(requireArguments().getString(URL_EXTRA)!!)
|
|
|
|
true
|
|
|
|
}
|
|
|
|
R.id.action_refresh -> {
|
|
|
|
onRefresh()
|
|
|
|
true
|
|
|
|
}
|
|
|
|
else -> false
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onResume() {
|
|
|
|
super.onResume()
|
|
|
|
requireActivity().title = getString(R.string.title_view_thread)
|
|
|
|
}
|
|
|
|
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
/**
|
|
|
|
* Create a job to implement a delayed-visible progress bar.
|
|
|
|
*
|
|
|
|
* Delaying the visibility of the progress bar can improve user perception of UI speed because
|
|
|
|
* fewer UI elements are appearing and disappearing.
|
|
|
|
*
|
|
|
|
* When started the job will wait `delayMs` then show `view`. If the job is cancelled at
|
|
|
|
* any time `view` is hidden.
|
|
|
|
*/
|
2023-02-20 19:58:37 +01:00
|
|
|
@CheckResult
|
Improve the actual and perceived speed of thread loading (#3118)
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
2023-01-09 21:31:31 +01:00
|
|
|
private fun getProgressBarJob(view: View, delayMs: Long) = viewLifecycleOwner.lifecycleScope.launch(
|
|
|
|
start = CoroutineStart.LAZY
|
|
|
|
) {
|
|
|
|
try {
|
|
|
|
delay(delayMs)
|
|
|
|
view.show()
|
|
|
|
awaitCancellation()
|
|
|
|
} finally {
|
|
|
|
view.hide()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-08-15 11:00:18 +02:00
|
|
|
override fun onRefresh() {
|
|
|
|
viewModel.refresh(thisThreadsStatusId)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onReply(position: Int) {
|
|
|
|
super.reply(adapter.currentList[position].status)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onReblog(reblog: Boolean, position: Int) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
viewModel.reblog(reblog, status)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onFavourite(favourite: Boolean, position: Int) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
viewModel.favorite(favourite, status)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onBookmark(bookmark: Boolean, position: Int) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
viewModel.bookmark(bookmark, status)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onMore(view: View, position: Int) {
|
|
|
|
super.more(adapter.currentList[position].status, view, position)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewMedia(position: Int, attachmentIndex: Int, view: View?) {
|
|
|
|
val status = adapter.currentList[position].status
|
|
|
|
super.viewMedia(attachmentIndex, list(status), view)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewThread(position: Int) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
if (thisThreadsStatusId == status.id) {
|
|
|
|
// If already viewing this thread, don't reopen it.
|
|
|
|
return
|
|
|
|
}
|
|
|
|
super.viewThread(status.actionableId, status.actionable.url)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewUrl(url: String) {
|
|
|
|
val status: StatusViewData.Concrete? = viewModel.detailedStatus()
|
|
|
|
if (status != null && status.status.url == url) {
|
|
|
|
// already viewing the status with this url
|
|
|
|
// probably just a preview federated and the user is clicking again to view more -> open the browser
|
|
|
|
// this can happen with some friendica statuses
|
|
|
|
requireContext().openLink(url)
|
|
|
|
return
|
|
|
|
}
|
|
|
|
super.onViewUrl(url)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onOpenReblog(position: Int) {
|
|
|
|
// there are no reblogs in threads
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onExpandedChange(expanded: Boolean, position: Int) {
|
|
|
|
viewModel.changeExpanded(expanded, adapter.currentList[position])
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onContentHiddenChange(isShowing: Boolean, position: Int) {
|
|
|
|
viewModel.changeContentShowing(isShowing, adapter.currentList[position])
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onLoadMore(position: Int) {
|
|
|
|
// only used in timelines
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onShowReblogs(position: Int) {
|
|
|
|
val statusId = adapter.currentList[position].id
|
|
|
|
val intent = newIntent(requireContext(), AccountListActivity.Type.REBLOGGED, statusId)
|
|
|
|
(requireActivity() as BaseActivity).startActivityWithSlideInAnimation(intent)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onShowFavs(position: Int) {
|
|
|
|
val statusId = adapter.currentList[position].id
|
|
|
|
val intent = newIntent(requireContext(), AccountListActivity.Type.FAVOURITED, statusId)
|
|
|
|
(requireActivity() as BaseActivity).startActivityWithSlideInAnimation(intent)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onContentCollapsedChange(isCollapsed: Boolean, position: Int) {
|
|
|
|
viewModel.changeContentCollapsed(isCollapsed, adapter.currentList[position])
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewTag(tag: String) {
|
|
|
|
super.viewTag(tag)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onViewAccount(id: String) {
|
|
|
|
super.viewAccount(id)
|
|
|
|
}
|
|
|
|
|
|
|
|
public override fun removeItem(position: Int) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
if (status.isDetailed) {
|
|
|
|
// the main status we are viewing is being removed, finish the activity
|
|
|
|
activity?.finish()
|
|
|
|
return
|
|
|
|
}
|
|
|
|
viewModel.removeStatus(status)
|
|
|
|
}
|
|
|
|
|
|
|
|
override fun onVoteInPoll(position: Int, choices: List<Int>) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
viewModel.voteInPoll(choices, status)
|
|
|
|
}
|
|
|
|
|
2023-01-02 14:09:18 +01:00
|
|
|
override fun onShowEdits(position: Int) {
|
|
|
|
val status = adapter.currentList[position]
|
|
|
|
val viewEditsFragment = ViewEditsFragment.newInstance(status.actionableId)
|
|
|
|
|
|
|
|
parentFragmentManager.commit {
|
|
|
|
setCustomAnimations(R.anim.slide_from_right, R.anim.slide_to_left, R.anim.slide_from_left, R.anim.slide_to_right)
|
|
|
|
replace(R.id.fragment_container, viewEditsFragment, "ViewEditsFragment_$id")
|
|
|
|
addToBackStack(null)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-08-15 11:00:18 +02:00
|
|
|
companion object {
|
|
|
|
private const val TAG = "ViewThreadFragment"
|
|
|
|
|
|
|
|
private const val ID_EXTRA = "id"
|
|
|
|
private const val URL_EXTRA = "url"
|
|
|
|
|
|
|
|
fun newInstance(id: String, url: String): ViewThreadFragment {
|
|
|
|
val arguments = Bundle(2)
|
|
|
|
val fragment = ViewThreadFragment()
|
|
|
|
arguments.putString(ID_EXTRA, id)
|
|
|
|
arguments.putString(URL_EXTRA, url)
|
|
|
|
fragment.arguments = arguments
|
|
|
|
return fragment
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|