Settings page refactor

[tvillega]

Hi there!

I use Tempus as my main music player and, despite my limited knowledge on Android development, I've done my best to contribute back to it. One thing that I'd like to contribute with is the current settings page.

The hardest part about narrowing down bugs is changing the settings. When testing the issue with transcoding, I realized that sections UI, Data, and Transcoding+Transcoding Download contain a great number of items, making difficult to scroll down to an item that is at least below one of those sections.

I propose the following refactor for the settings page:

- General
  \_ ...
- Interface
  \_ ...
-  Data
- Transcoding
  \_ ...
  \_ Downloads
      \_ (Transcoding Download items)
- Miscellaneous
  \_ Playlist
      \_ ... 
  \_ Replay Again
  \_ Rating
  \_ Scrobble
  \_ Share
  \_ Syncing
- About

The goal is to group all similar settings together, this way we reduce the trial-and-error scroll trying to find the spot where a setting was, specially since average users wouldn't be using this page frequently enough to remember where everything is.

This order is logic for me but not necessarily for everybody, reason why I decided to open a discussion rather than going straight for the PR.

P.S. Data section is quite miscellaneous, I think it would be the best to just group it as it is since it mixes cache, offline mode, data efficiency and other misc stuff.

[eddyizm]

Yup, the settings has been a pain point me for a long time.
I was actually looking at how https://github.com/jocmp/capyreader does the settings and I found that a much better experience. It is similar in layout as to what you proposed so we are on the same page.

2 things I thought about as well. One, have a search right at the top so you can filter and find quickly and two, possibly moving the about or at least version somewhere easier to see quickly. The latter may just be a me thing because I am updating and testing all the time so I want to see and validate that I am deploying and working on the version I think I am working on and scrolling to the bottom sucks, lol. But the search, I feel is a must.

[tvillega]

Nice! My reference is NewPipe, they have way too many settings.

You are right, fuzzy search is something I've seen implemented in One UI (Samsung) and ZUI (Lenovo) for Android settings. Also, I know two techniques to leave the info version more at hand rather than inside settings:

1. To put it next to the logo. This would be arranged the following way:

[Logo] [Stylized 'Tempus' string] [Stylized 'Version' string]

2. To put it at the top of the hamburger menu, right below the logo.

Since Tempus doesn't make use of a hamburger menu, the first option looks the most fitting. You could also include as an 'Easter Egg' that long-pressing the logo opens a little dialog with verbose info a developer would need.

A doubt I have is, does the three-dots button next to the search lead to something else besides the settings? I have an ungoogled device, so I have no idea if the other version makes use of it for listing additional items like Android Auto or Google Casting.

[eddyizm]

My plans for the 3 dot location, where settings currently lives, would be to add another value there for a offline mode toggle, and perhaps an about, so I had already had that in mind. I do want to keep that one light in general. Although your logo idea is not half bad. Might be a little too much info. But there is also a new logo I have yet to implement along with that adaptive setting.

[tvillega]

I like your idea for the 3 dot menu, it's less disruptive and quite handy to be honest. Yeah, I saw #225 and it would be better to point my suggestion on a dedicated issue/discussion about UI to get more opinions.

[tvillega]

I noticed something interesting. Checking how capyreader and NewPipe implement the settings, they have a dedicated activity for it and for each section/subpage there is a fragment. On the other hand, Tempus has a single activity and the settings are just one fragment more from it.

I didn't understand why it kept crashing on me every time I tried adding a new page, turns out I was trying to add a fragment within a fragment. I was editing the navbar for another issue when I realized that the main screen of settings is (and behaves like) a fragment, that's why it is not straightforward to include settings subpages in the current implementation.

Should we create a new activity for settings to make Tempus follow this "common practice" and simplify development?

[eddyizm]

I would not spend too much time on this until we decide on the way forward.

I think as an initial step, because you noticed, everything is in one page vs those other apps, it might be easier to keep everything on one page but make those regions collapsible, akin to the accordion layout in web dev.
That would at least make it more manageable and we could force only one section to be open at a time (i think)

Then implement a search bar on top of that.

I did not get past this idea stage but that was my thought as the easiest path forward.

I think full tear down and refactor along the lines that you mention would definitely more time and more planning as to how we wanted to implement it. I really don't want you to go down that route unless we are on the same page, as I would hate for you to put in so much time and effort and not get it merged in. Let me know what you think about that.

[tvillega]

Okay, I see it was a good thing to speak my mind first.

The accordion layout you mention is implemented by the settings page of jtxBoard, so I agree with you that is the easiest path forward. I'm still exploring the overall code of Tempus, so I'll leave this on the back burner for now until I learn how to handle better the UI elements in Android.

[tvillega]

An update on this.

I just pushed 52cfd36 to add a back button on settings and now the new layout looks like this:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.appbar.MaterialToolbar
        android:id="@+id/settings_toolbar"
        android:layout_width="match_parent"
        android:layout_height="?attr/actionBarSize"
        android:background="?attr/colorSurface"
        app:layout_collapseMode="pin"
        app:navigationIcon="@drawable/ic_arrow_back" />

    <FrameLayout
        android:id="@+id/settings_container"
        android:layout_width="match_parent"
        android:layout_height="0dp"
        android:layout_weight="1"/>
</LinearLayout>

During testing I realized that settings_container is swapable. Edit: upon further reading I understood that, in general, this is how Android manages dynamic content.