Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Give feed rows an artwork placeholder instead of a prepared first frame

Open
  • Is something wrong?
#28 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
android, kotlin
Domain
documentation, mobile

Research direction

Start with PlayerPool (#12) and the demo's FeedScreen, which allocates a player per visible row, and with MediaRequest.artworkUri in the core model. Read ADR-0006 rule 2 before deciding where anything goes, since the issue rules out an image loader in superplayer-core. The work is a written recipe for a pooled feed row, and whether a superplayer-ui composable is needed is still open, so confirm the scope with a maintainer first. Done means the recipe states the decoder and network cost of a prepared row and non-playing rows show artworkUri.

Written by the indexing model from the issue text.

Description

enhancement

Parent

Part of #1. Follows #12, which built the pool this is about.

The gap

PlayerPool (#12) bounds how many players a feed may hold, but says nothing about what a row shows
when it has no player — and the demo's FeedScreen currently answers that question the expensive
way on purpose, which is not the answer a production feed should copy.

Media3 settles half of this already: a paused, prepared player shows the first decoded video
frame, never artwork. PlayerView's artwork path is gated on hasSelectedVideoTrack() /
hasSelectedImageTrack() being false, so setUseArtwork and setDefaultArtwork do nothing for
video content whatever the playback state. Artwork in PlayerView is for audio-only media.

A real feed therefore does not use players for its non-playing rows at all. In YouTube's feed, the
active row has a player — video frame, captions, mute and CC controls, a progress bar — and every
other row is an ImageView showing the uploader's designed thumbnail: title text baked in, a
duration badge, a chosen frame. The difference in cost is an order of magnitude:

Artwork row Prepared-and-paused row
Network one cached image fetch manifest + init segment + first media segment
Decoder none one of a device's scarce concurrent instances
Picture the image the uploader chose frame zero, usually a fade or a slate

And it is spent on rows the viewer may scroll straight past.

What to build

A documented, production-shaped recipe for a pooled feed row, and whatever library support it turns
out to need:

  • The active row plays; its immediate neighbours may be prepared and paused so a scroll starts
    instantly; every other row shows MediaRequest.artworkUri.
  • MediaRequest already carries artworkUri and documents it as what everything outside the app
    displays — this is the first consumer of it inside the app.
  • SuperPlayer should almost certainly not load images itself. An image loader is a consumer's
    choice, and a playback library that picked Coil or Glide for them would be choosing a dependency
    the way ADR-0006 rule 2 says it must not choose storage. The likely shape is documentation plus,
    if anything, a superplayer-ui composable that pairs a pooled player with a caller-supplied
    placeholder slot — which puts it in phase 6, not phase 1.

Why the demo is not simply fixed

FeedScreen takes a player per visible row deliberately: that is what drives the pool to its bound
where a viewer can watch the counter stop, and a feed built the right way would never show that.
Whether the demo gains a second, production-shaped feed screen or the existing one is converted is
part of this issue. Converting it needs an image loader as a demo dependency, with its
THIRD_PARTY.md row.

Acceptance criteria

  • The recipe is written down where a consumer will find it, with the decoder and network cost
    of a prepared row stated
  • MediaRequest.artworkUri is what a non-playing row displays
  • Any library support added carries no image-loading dependency into superplayer-core
  • FeedScreen's KDoc no longer needs to explain that it is deliberately greedier than a real feed
Dominant language
Kotlin
Stars
1
Forks
0
Avg merge
1h 20m
Merged PRs (30d)
172

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ramesh130/superplayer

All issues in ramesh130/superplayer

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.