Yuito-app-android/app/src/main/res/layout/fragment_view_thread.xml

58 lines
2.4 KiB
XML
Raw Normal View History

<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<com.google.android.material.progressindicator.LinearProgressIndicator
android:id="@+id/threadProgressBar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:visibility="gone"
android:indeterminate="true"
android:contentDescription="@string/a11y_label_loading_thread" />
<androidx.swiperefreshlayout.widget.SwipeRefreshLayout
android:id="@+id/swipeRefreshLayout"
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="1"
app:layout_behavior="com.google.android.material.appbar.AppBarLayout$ScrollingViewBehavior">
<FrameLayout
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
android:layout_width="match_parent"
android:layout_height="match_parent">
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="?android:attr/colorBackground"
android:scrollbars="vertical" />
<com.keylesspalace.tusky.view.BackgroundMessageView
android:id="@+id/statusView"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_gravity="center"
android:visibility="gone" />
</FrameLayout>
</androidx.swiperefreshlayout.widget.SwipeRefreshLayout>
</LinearLayout>
<ProgressBar
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
android:id="@+id/initialProgressBar"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
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
android:visibility="gone"
android:indeterminate="true"
android:layout_gravity="center"
android:contentDescription="@string/a11y_label_loading_thread" />
</androidx.coordinatorlayout.widget.CoordinatorLayout>