-
-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support trending links #3908
Support trending links #3908
Conversation
Ready for "trendingposts" and "trendinglinks"
…TrendingTagsFragment.kt
# Conflicts: # app/src/main/java/com/keylesspalace/tusky/TabPreferenceActivity.kt
Some screenshots: When added as a tab As part of the activity |
I'm adding trending posts in another PR. |
…-rename # Conflicts: # app/src/main/java/com/keylesspalace/tusky/di/FragmentBuildersModule.kt
# Conflicts: # app/src/main/java/com/keylesspalace/tusky/di/FragmentBuildersModule.kt # app/src/main/java/com/keylesspalace/tusky/util/ThrowableExtensions.kt
(Must this be updated somehow: it still shows the changes from the merged rename PR.) ((But also that PR is not shown under "closed PRs"...)) |
…-links # Conflicts: # app/src/main/java/com/keylesspalace/tusky/MainActivity.kt # app/src/main/java/com/keylesspalace/tusky/TabData.kt # app/src/main/java/com/keylesspalace/tusky/TabPreferenceActivity.kt # app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingActivity.kt # app/src/main/java/com/keylesspalace/tusky/di/FragmentBuildersModule.kt # app/src/main/java/com/keylesspalace/tusky/di/ViewModelFactory.kt # app/src/main/res/layout/fragment_trending.xml # app/src/main/res/layout/fragment_trending_links.xml # app/src/main/res/layout/fragment_trending_tags.xml
Yes. Done.
Weird. It shows for me. Note that the list of PRs is default-sorted by "When was the PR opened?", so a PR that was opened several weeks back, but was closed an hour ago, could easily show up on page 2 or 3 of the PR page. |
app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingLinkViewHolder.kt
Outdated
Show resolved
Hide resolved
|
||
val cardImageShape = ShapeAppearanceModel.Builder() | ||
|
||
if (statusDisplayOptions.mediaPreviewEnabled && !link.image.isNullOrBlank()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does all this do (comment?)?
It seems to adapt layout dynamically but to what end?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two preview layout types.
One puts the preview image above the link title and description (e.g., see the screenshots in the second comment on this PR).
The other puts the preview to the left of the title and description. As the previous comment notes, this is out of StatusBaseViewHolder, and might be moved somewhere common later if it needs reusing again.
This is to follow what I call the rule-of-three for refactoring (see also https://en.wikipedia.org/wiki/Don%27t_repeat_yourself#AHA).
- You don't need to refactor code that's only used once into a common function, because you don't have the necessary knowledge to know what parts of the code should be governed by parameters (you have zero examples of reuse).
- You don't need to refactor code that's only used twice in to a common function, because you still don't have the necessary knowledge to know what parts of the code should be governed by parameters (you have one example of reuse, which is not enough).
- When you've copy pasted the same code in to the three different places... now is the time to start looking at refactoring in to common function, because you've three distinct use cases that you can learn from (you have two examples of reuse, which is starting to become useful).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two preview layout types.
One puts the preview image above the link title and description (e.g., see the screenshots in the second comment on this PR).
The other puts the preview to the left of the title and description. As the previous comment notes, this is out of StatusBaseViewHolder, and might be moved somewhere common later if it needs reusing again.
These might be the code comment(s) I was looking for.
app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingLinksFragment.kt
Show resolved
Hide resolved
app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingLinksFragment.kt
Show resolved
Hide resolved
app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingLinksRepository.kt
Show resolved
Hide resolved
@@ -98,6 +100,12 @@ fun createTabDataFromId(id: String, arguments: List<String> = emptyList()): TabD | |||
icon = R.drawable.ic_trending_up_24px, | |||
fragment = { TrendingTagsFragment.newInstance() } | |||
) | |||
TRENDING_LINKS -> TabData( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would make sense to only have that "trending activity view with tabs" you'll get from the side drawer.
So the (only) tab here would show that as well.
(Consistent and removes clutter from this tab list, this is especially relevant for the following PR when this gets three tabs here.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would put a set of tabs (trending tags, links, posts) inside another set of tabs.
That's possible (Material3 calls them "secondary tabs") but it's a departure from how we've done things so far. I also think it's reasonable for a user to only want one or two of them and not all three (e.g., I'd use links and posts, but have no interest in trending hashtags).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok...
I see (secondary tabs).
But it would still be (quite) inconsistent:
- One location with a combined view (from side drawer)
- And one location where I would need to make a choice; and/or add 3 things seperately to get the same thing I get from the side drawer
:beard_scratch:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Lakoja Yes, so let's think about two typical users.
User A occasionally checks the trending info, but not habitually. Maybe a few times a week to see if there's anything new. They don't have a need to focus on one of the three (soon to be four) types of thing that can trend, so getting to it from the nav menu when they want to, and tapping through the different tabs to see what's new is fine for them.
User B is much more interested in trending links, they want to check regularly as part of their normal Mastodon experience. So much so that they want to make it a tab. They're not interested in posts or hashtags, just links. For them, adding a tab with just trending links is fine.
If they added a tab that contained all the trending items they would have to tap that tab once to choose "trending", and then tap again to choose which trending item they're interested in. That's suboptimal UX for an activity that User B is going to want to do a lot.
That's why I think the UX in this PR is the way to go.
There's a third user, User C, who are like User B, but they want to check all the trending tabs. They're not well served at the moment, because of the 5-tab limit, but I think that should be removed (see discussion in "Tusky General" channel).
@@ -98,6 +100,12 @@ fun createTabDataFromId(id: String, arguments: List<String> = emptyList()): TabD | |||
icon = R.drawable.ic_trending_up_24px, | |||
fragment = { TrendingTagsFragment.newInstance() } | |||
) | |||
TRENDING_LINKS -> TabData( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would put a set of tabs (trending tags, links, posts) inside another set of tabs.
That's possible (Material3 calls them "secondary tabs") but it's a departure from how we've done things so far. I also think it's reasonable for a user to only want one or two of them and not all three (e.g., I'd use links and posts, but have no interest in trending hashtags).
|
||
val cardImageShape = ShapeAppearanceModel.Builder() | ||
|
||
if (statusDisplayOptions.mediaPreviewEnabled && !link.image.isNullOrBlank()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two preview layout types.
One puts the preview image above the link title and description (e.g., see the screenshots in the second comment on this PR).
The other puts the preview to the left of the title and description. As the previous comment notes, this is out of StatusBaseViewHolder, and might be moved somewhere common later if it needs reusing again.
This is to follow what I call the rule-of-three for refactoring (see also https://en.wikipedia.org/wiki/Don%27t_repeat_yourself#AHA).
- You don't need to refactor code that's only used once into a common function, because you don't have the necessary knowledge to know what parts of the code should be governed by parameters (you have zero examples of reuse).
- You don't need to refactor code that's only used twice in to a common function, because you still don't have the necessary knowledge to know what parts of the code should be governed by parameters (you have one example of reuse, which is not enough).
- When you've copy pasted the same code in to the three different places... now is the time to start looking at refactoring in to common function, because you've three distinct use cases that you can learn from (you have two examples of reuse, which is starting to become useful).
app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingLinksRepository.kt
Show resolved
Hide resolved
app/src/main/java/com/keylesspalace/tusky/components/trending/TrendingLinkViewHolder.kt
Outdated
Show resolved
Hide resolved
@Lakoja Please continue to ask questions, but please mark the ones that I've answered and you've understood as "Resolved", so it's easy for me to see whatever's new. Thanks. |
Unfortunately, I cannot do resolve them (or reopen, non-contributor?). Otherwise I would've done it.. |
Huh. Today I learned, I guess. OK, please just add a comment to any of the ones that can be resolved. |
Yeah. I was wondering about that. |
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#resolving-conversations says you should be able to resolve comments on the PRs that you have opened. |
Add "Trending posts" (statuses) feed. This feed is a good source of interesting accounts to follow and, personally, a sort of "Front page of the Fediverse". Since #3908 and #3910 (which would provide a more thorough, albeit complex, access to trending things) won't get merged, I'd like to address this missing feed by simply adding another tab/feed. ~~If desired, I can move the second commit (fixing lint) to another PR.~~ ## Screenshots ### Tab <img src="https://github.com/tuskyapp/Tusky/assets/1063155/6a71a97e-673e-44c7-b67d-9b1df0bed4f5" width=320 /> <img src="https://github.com/tuskyapp/Tusky/assets/1063155/9bf60b23-d2f3-4dd8-8af6-e96647b02121" width=320 /> ### Activity <img src="https://github.com/tuskyapp/Tusky/assets/1063155/4e07dea3-d97f-42c6-8551-492a3116fcfa" width=320 /> <img src="https://github.com/tuskyapp/Tusky/assets/1063155/ad00a134-d622-43f4-8305-84cfa7fed706" width=320 />
Expand the "trending" support to include trending links.
Main changes:
TrendingActivity
can now host multiple trending fragments in a viewpager, and swipe between themTrendingLinks
suite (Fragment
,ViewModel
,Adapter
,Repository
, etc) to get and display the data