The Lyrics Source#

Syncing with Your Music#

I used the Mediacontroller API to get current song playback info from the notification manager. It was quite finicky at first but after many iterations its stable and reliable now. The logic is wrapped in a Medialistener object and suspend functions are exposed to pause/resume playback or skip to previous/next track. Also, the ability to set playabck to a particluar timestamp by just tapping at a line in the UI. This was added by bartoostveen, This contribution really opened up my mind as I was just a begginer at that time. A very miniscule change that significantly increased the possibilities. I suddenly became aware there is so much more possible with the Android APIs.

SIDETRACK

I really like the concept of objects in kotlin, not to be confused by the runtime objects created from classes. Object is a dedicated keyword in kotlin to encapsulate logic and methods. Objects are all only created once over the lifetime of the app, So I don’t need to worry about creating duplicate objects or any conflicts.

The Mediacontroller API requires notification access permission to be granted for the app. Which is a super sensitive permission to be granted to a 3rd party app. For this reason, many OEMs put a 10-second disclaimer whenever the user is prompted to allow this permission. This can make a lot of users to stop using Rush due to mistrust. Thankfully, Rush is FOSS and I will keep it that way. Users can audit easily what the app does with the permission and with the help of LLMs it’s much easier now.

I think the Mediacontroller API can be decoupled from NotificationManager and kept as a separate permission.

Rush Mode#

The whole point of FastLyrics is to get the lyrics for your current playing song quickly. And it’s pretty good at it. I borrowed this concept for Rush Mode, except the fast part. Being fast is not the priority, It’s being accurate and providing the best experience possible. Imagine you are listening to an album, after each track you don’t want to manually search for it and continue, In Rush Mode, the app listens for changes in the playing song. When changed, automatically fetches lyrics for it.

The Mediacontroller API provides callbacks when song metadata changes. Using that I set up a flow to trigger a fetch. It’s pretty simple but very convenient.

The Database#

Rush uses a simple SQLite database using ROOM, All the tracks are uniquely identified by their ID, which is obtained from their corresponding Genius ID. It’s just a simple table. I had to migrate it twice while adding columns for synced and syllable-synced lyrics. With the help of schemas and Migration Tests, Its become pretty easy to manage it. I have implemented a way to export or import the database of saved lyrics through a JSON file. Just serializing and deserializing the contents of the database.

Building the UI#

It’s all Jetpack Compose following MVI (Model-View-Intent) principles. All screens consist of a simple composable that only take a state to render UI, making previews and tests easier. The screens are pretty simple except the Lyrics Screen. Users can customize their lyrics experience in great detail.

1
data class LyricsPageState(
2
    // ...
3
    // All the appearance settings
4
    val blurSyncedLyrics: Boolean = true,
5
    val textPrefs: TextPrefs = TextPrefs(),
6
    val cardColors: CardColors = CardColors.MUTED,
7
    val lyricsBackground: LyricsBackground = LyricsBackground.SOLID_COLOR,
8
    val maxLines: Int = 6,
9
    val mCardBackground: Int = Color.DarkGray.toArgb(),
10
    val mCardContent: Int = Color.White.toArgb(),
11
    val fullscreen: Boolean = false,
12
)
13

14
// All the text settings
15
data class TextPrefs(
16
    val fontSize: Float = 28f,
17
    val lineHeight: Float = 32f,
18
    val letterSpacing: Float = 0f,
19
    val lyricsAlignment: LyricsAlignment = LyricsAlignment.CENTER,
20
)

• blurSyncedLyrics : Toggle to blur the non-focused lines while displaying synced lyrics. Blurring gives it a more dream-like experience.
• textPrefs : Parameters for controlling text. Users can customize the fontSize, lineHeight, letterSpacing, lyricsAlignment, etc. To make it look exactly as they want.
• cardColors : Users can select between MUTED, VIBRANT and CUSTOM. MUTED and VIBRANT colors are extracted form the Album Art of the track using Kmpalette. While the custom option lets the user choose their own background and content colors. Using colorpicker-compose. The custom colors are stored in mCardBackground and mCardContent
• lyricsBackground : This is the background style for the lyrics. There are many options to choose from. The animated backgrounds were made possible because of Bodya. They made an entire module wrapping up the Android Visualizer API into an easy to use compose state.

1
enum class LyricsBackground {
2
    HYPNOTIC, // Uses shaders to make an animated flow effect
3
    ALBUM_ART, // Uses a blurred and scaled version of the album art, like Apple Music
4
    SOLID_COLOR, // Solid Color. duh
5

6
    // Animated with music
7
    WAVE, // A wave like pattern
8
    GRADIENT, // A subtle soft gradient
9
    CURVE, // A set of horizontal lines that curve and thicken
10
}

• maxLines : The maximum no. of lines allowed to be selected for sharing.
• fullscreen : Toggle for hiding navigation and status bars in lyrics page.

All together, This allows for a highly customizable Lyrics Screen for each User. I have some doubts about allowing this level of customization. As now, There isn’t really a standard design that Rush will be known for. Like Spotify or Apple Music have their own designs that anybody can look and recognize. But ultimately, I feel like this was the best approach.

The Share Cards#

I wanted this to be the highlight feature of Rush. But it turned out to be the least used feature. At least I use It enough to justify maintaining it. I have put a lot of effort into building this.

Initially, I just used the rememberGraphicsLayer() function to create a scoped graphics layer and drew the composable into it to convert it into an image. It was working fine on my devices and emulators, So I pushed it to production. Then I tested the app on my friends phone, who uses very high display size and text. The image was all over the place, It didn’t look like I had intended it to. The text was large and out of proportion, the corners looked out of place. It was just an ugly mess.

Jetpack Compose is not built with pixel perfect UI in mind. It was built from the ground to be as adaptive as possible, meaning it would adapt to the device’s pixel density and dimensions to give the best possible render of the UI. It cleared a very fundamental misconception I had about it.

The units of measurement in compose like Dp, Sp, etc. Are calculated based on the display of the device and user preferences and will produce different results in different devices.

Thankfully there are functions like toDp() and toSp() to convert px measurements. This allowed for the card dimensions to be exactly the same in all screens.

1
@Composable
2
fun pxToSp(px: Int): TextUnit {
3
    val density = LocalDensity.current
4
    return with(density) { px.toSp() }
5
}
6

7
@Composable
8
fun pxToDp(px: Int): Dp {
9
    val density = LocalDensity.current
10
    return with(density) { px.toDp() }
11
}
12

13
@Composable
14
fun TextStyle.fromPx(
15
    fontSize: Int,
16
    letterSpacing: Int,
17
    lineHeight: Int,
18
    fontWeight: FontWeight = FontWeight.Normal,
19
): TextStyle {
20
    return copy(
21
        fontSize = pxToSp(fontSize),
22
        letterSpacing = pxToSp(letterSpacing),
23
        lineHeight = pxToSp(lineHeight),
24
        fontWeight = fontWeight,
25
    )
26
}

There are a large variety of cards available with customizable feature on each one. I really want to explain each one here, but It would be boring. It’ll be better if you download Rush and explore the options yourself!

Distribution#

Rush is available on the Play Store, F-Droid and IzzyOnDroid. The links can be found in the GitHub repository. I have set up CI actions to automatically build and release the apk on GitHub on every commit starting with [release] from there the F-droid and IzzyOnDroid servers detect the release and add it to their listings. F-Droid builds and signs the apk in their own servers, confirming reproducibility. Play store releases are manual as they are made with a separate applicationId and need to be aabs. There are services like tramline for automated playstore releases, but I am too paranoid to try them.