Skip to content
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

Closed
wants to merge 29 commits into from
Closed

Support trending links #3908

wants to merge 29 commits into from

Conversation

nikclayton
Copy link
Contributor

@nikclayton nikclayton commented Aug 1, 2023

Expand the "trending" support to include trending links.

Main changes:

  • TrendingActivity can now host multiple trending fragments in a viewpager, and swipe between them
  • Implement a TrendingLinks suite (Fragment, ViewModel, Adapter, Repository, etc) to get and display the data
  • Always show "Trending" on the left-nav menu
  • Support adding trending links as a dedicated tab

@nikclayton
Copy link
Contributor Author

nikclayton commented Aug 1, 2023

This includes the changes in #3906, which are mechanical renames. This PR will be easier to review if you review that one first.

Some screenshots:

When added as a tab

As part of the activity

@nikclayton
Copy link
Contributor Author

I'm adding trending posts in another PR.

@nikclayton nikclayton changed the title Implement support for trending links #1 Implement support for trending links Aug 1, 2023
@nikclayton nikclayton changed the title Implement support for trending links Support trending links Aug 1, 2023
# Conflicts:
#	app/src/main/java/com/keylesspalace/tusky/di/FragmentBuildersModule.kt
#	app/src/main/java/com/keylesspalace/tusky/util/ThrowableExtensions.kt
@Lakoja
Copy link
Collaborator

Lakoja commented Aug 19, 2023

(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
@nikclayton nikclayton requested a review from Lakoja August 19, 2023 16:02
@nikclayton
Copy link
Contributor Author

(Must this be updated somehow: it still shows the changes from the merged rename PR.)

Yes. Done.

((But also that PR is not shown under "closed PRs"...))

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.

@nikclayton nikclayton requested a review from Lakoja August 20, 2023 08:56

val cardImageShape = ShapeAppearanceModel.Builder()

if (statusDisplayOptions.mediaPreviewEnabled && !link.image.isNullOrBlank()) {
Copy link
Collaborator

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?

Copy link
Contributor Author

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).

  1. 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).
  2. 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).
  3. 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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One way to see the other layout is to disable downloading media, then it looks like this:

Copy link
Collaborator

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.

@@ -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(
Copy link
Collaborator

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.)

Copy link
Contributor Author

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).

Copy link
Collaborator

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:

Copy link
Contributor Author

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(
Copy link
Contributor Author

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()) {
Copy link
Contributor Author

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).

  1. 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).
  2. 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).
  3. 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).

@nikclayton nikclayton requested a review from Lakoja August 20, 2023 21:01
@nikclayton
Copy link
Contributor Author

@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.

@Lakoja
Copy link
Collaborator

Lakoja commented Aug 22, 2023

@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..

@nikclayton
Copy link
Contributor Author

@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.

@Lakoja
Copy link
Collaborator

Lakoja commented Aug 22, 2023

@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.
At least my own i would like to resolve or open...

@nikclayton
Copy link
Contributor Author

Yeah. I was wondering about that. At least my own i would like to resolve or open...

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.

@nikclayton nikclayton closed this by deleting the head repository Aug 27, 2023
Tak pushed a commit that referenced this pull request Sep 14, 2023
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 />
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants