Forgotten states after going back

[hh]

Settings

When you go to a scrollable settings page like "General", scroll down, go to a deeper page like "Remote Controls" and go back one level, the previous scroll position isn't remembered, but reset. This is irritating.

Queue

When you are in the queue, pages above/below the currently played track, and you remove an item by swiping it to the side, the played track is scrolled into view. This is annoying when you want to further inspect the queue to see what tracks to swipe away also (I know of the long-press route). In my book, there's no need at all for this automatic scrolling after performing said action.

Library (1)

Go to "Library > Album Artists > [some artist]", scroll down so that the header shrinks, and visit an album. When you go one level up again, the scroll position correctly is the previous one while the header is incorrectly at its full, unshrunken size. This is annoying.

Library (2)

Go to "Library > Album Artists > [some artist]", tap on mini-player at the bottom to visit "Now Playing" and go back to the library via navigation drawer. You're not in the album artists view with the previous scroll position anymore, as I'd expect, but one level up.

Previous scroll positions should also be restored when using the long-press menu on the cover in "Now Playing" to go back to, e.g., the album artist. (For "Folder", this already works.) And if your last visit of, e.g., an album artist was via a pinned smart playlist that groups by album artist, the aforementioned long-press menu items (in this case "Album Artist") should bring you back to the smart playlist as you last viewed it. To be clearer: When doing "Library > [smart playlist] > [album artist] > [album] > Play > Now Playing", both long-press menu items "Album Artist" and "Album" should bring you back to the respective breadcrumbs from the trail including scroll position and header shrinkage.

When you, over time, repeatedly visit artists via search, it'd also be nice if previous scroll positions were restored, so you can continue the exploration of the artist were you left off.

[GoneMAD]

"When you go to a scrollable settings page like "General", scroll down, go to a deeper page like "Remote Controls" and go back one level, the previous scroll position isn't remembered, but reset. This is irritating."

Settings UI is part of the android SDK. Its fed a general xml file filled with all the settings and it manages all the navigation and display. I dont have any control over it saving the state or not

"When you are in the queue, pages above/below the currently played track, and you remove an item by swiping it to the side, the played track is scrolled into view. This is annoying when you want to further inspect the queue to see what tracks to swipe away also (I know of the long-press route). In my book, there's no need at all for this automatic scrolling after performing said action."

Unfortunately the way all the lists are designed is that they are backed by the database and automatically update when the backing database changes (which is what removing something from the queue does). Part of that refresh logic is to center on the playing track (id have to check the code but i believe that is because the playing track needs to be set in the list since its position could change based off what was deleted). I agree that would be annoying trying to delete multiple items out of view. You have to also understand that this isnt me coding "delete track -> move queue back to the playing back", its "queue update (due to many possible reasons), lets make sure the playing track is properly selected"

"Library (1)"

Yeah that would be annoying, i dont recall that happening whenever i use it but i can look into it

"Library (2)"

Now Playing -> Jump to any artist/albumartist/album/etc will not restore any state as its creating a new view. It does not dig through the stack of previous views to see if one happens to be an album artist view AND it matches the actual album artist loaded. Thats just not feasible to do. Furthermore when viewing an artist/album via a smart playlist, it could be a filtered based off the smart playlist rules. Now playing -> jump to X has always intended on showing the unfiltered view of X. Example. I go genre -> artist, so im only viewing the songs from that artist thats a specific genre. I go to now playing, then jump to artist. Showing only the songs from that artist of a specific genre is NOT what 'Jump to Artist' is supposed to display and would be confusing to the user.

"Go to "Library > Album Artists > [some artist]", tap on mini-player at the bottom to visit "Now Playing" and go back to the library via navigation drawer. You're not in the album artists view with the previous scroll position anymore, as I'd expect, but one level up."

The Library is the top level view. Details views are not the "library", but their own independent views.

In general it sounds like you may like GoneMAD Music Player Classic better as all the details view were embedded in the single "library view" and the state is kept in the way it seems you want it. This was insanely difficult to maintain code wise which is why 3.x went a different direction when I rewrote everything.

edit: Just a general note, there will most likely not be any updates for a long time due to google play changing their policies and forcing scoped storage / SAF on all future updates. Google did not provide an adequate replacement for their direct file access api (which is what is no longer allowed unless explicit approval by google.. which im trying to get), so a bunch of functionality is essentially broken using scoped storage in GMMP, with no real viable workaround. In short, a good portion of the app will need to be rewritten in order to update and I only get a handful of hours a week to do android development

[hh]

Settings

Settings UI is part of the android SDK. Its fed a general xml file filled with all the settings and it manages all the navigation and display. I dont have any control over it saving the state or not

You'd think other people already saw this as a problem. I couldn't find a resprective issue here; but it's also a bit overwhelming and I'm not sure about the best keywords.

Queue

Unfortunately the way all the lists are designed is that they are backed by the database and automatically update when the backing database changes (which is what removing something from the queue does). Part of that refresh logic is to center on the playing track (id have to check the code but i believe that is because the playing track needs to be set in the list since its position could change based off what was deleted). I agree that would be annoying trying to delete multiple items out of view. You have to also understand that this isnt me coding "delete track -> move queue back to the playing back", its "queue update (due to many possible reasons), lets make sure the playing track is properly selected"

Can't data be passed through, so the refreshing/updating code gets to know the intention and background info it can use to do its work more intelligently? In the Windows API, functions often have an argument for user data that is passed through. E.g., EnumWindows() has an argument, described: "An application-defined value to be passed to the callback function." Then, the application-defined callback in the form of EnumWindowsProc() has the argument: "The application-defined value given in EnumWindows or EnumDesktopWindows."

Library (2)

You wouldn't need to dig through views. Whenever browsing through the library, you'd need to save representations of the breadcrumbs including scroll positions, which "Now Playing" would refer to. It could be according to a user setting whether the app goes back to smart-playlist views. And there could even be additional menu entries like "Jump to Album Artist (Smart)", only if you previously had visited the album artist via a smart playlist. Then, there wouldn't be anything confusing.

---

In general it sounds like you may like GoneMAD Music Player Classic better as all the details view were embedded in the single "library view" and the state is kept in the way it seems you want it. This was insanely difficult to maintain code wise which is why 3.x went a different direction when I rewrote everything.

I have no intention of being stuck on old software versions.

[GoneMAD]

"Can't data be passed through, so the refreshing/updating code gets to know the intention and background info it can use to do its work more intelligently? In the Windows API, functions often have an argument for user data that is passed through. E.g., EnumWindows() has an argument, described: "An application-defined value to be passed to the callback function." Then, the application-defined callback in the form of EnumWindowsProc() has the argument: "The application-defined value given in EnumWindows or EnumDesktopWindows.""

nope. the UI has no idea why its being updated other than something has changed. Again this is an android sdk thing (or well in this case its Android Room which is built on top of sqlite.. still an android api). As a developer im limited in what the android apis allow

"You wouldn't need to dig through views. Whenever browsing through the library, you'd need to save representations of the breadcrumbs including scroll positions, which "Now Playing" would refer to. It could be according to a user setting whether the app goes back to smart-playlist views. And there could even be additional menu entries like "Jump to Album Artist (Smart)", only if you previously had visited the album artist via a smart playlist. Then, there wouldn't be anything confusing."

There are no "breadcrumbs". There is a backstack which is what im referring to that it would have to dig through. You clearly have some development knowledge but regardless of what you think is possible, doesnt mean its anything easy to do with 1) the android apis and 2) how the app is designed. I shouldnt say things are not possible, but simply i am not rewriting / architecting a good portion of the app for one minor thing that is requested. My responses are trying to be polite, but when pushed i can simply just say its not going to happen and be done with it.

"I have no intention of being stuck on old software versions."

Then accept 3.x might not go in the direction you want it to. Classic is end of life so will not be changing

Im glad you are giving feedback but you have to realize I make like.. less than minimum wage on this app. My priorities are on things I want to work on (or things that are heavily requested), not to cater to every users requests (ironically gmmp classic is the end result of 7 years of catering to every single request.. which became a nightmare to maintain).

I did verify the library (1) thing you mentioned and added this to the bug list: trello.com/c/y0LPVtUY/1941-look-into-restoring-art-state-when-returning-to-details-view

[hh]

This Android SDK really seems to be quite limited. I already got that impression when I learned that an app can't just switch to a different language. Data files are just read at the start of the app and that's it. A bit disappointing here and there about Google's design decisions.

I shouldnt say things are not possible, but simply i am not rewriting / architecting a good portion of the app for one minor thing that is requested. My responses are trying to be polite, but when pushed i can simply just say its not going to happen and be done with it.

I understand. You will, of course, consider the implications for the development process. In my mind, the things I request can well be things beneficial to many. I'm just trying my luck whether you can view it that way also. Sometimes, it sounds like you think in a different direction and I want to resolve residual aspects. But I'm not trying to push things onto you!

Then accept 3.x might not go in the direction you want it to.

I do. I consider this topic to be sorted out.

BTW: I made notes and began my feedback with the topics most important to me. If you can't do it for different reasons, ¯\_(ツ)_/¯ I'll live with it (but did already learn about alternatives to better live with the limitations). Some things I at least want you to have heard.

[GoneMAD]

"This Android SDK really seems to be quite limited. I already got that impression when I learned that an app can't just switch to a different language. Data files are just read at the start of the app and that's it. A bit disappointing here and there about Google's design decisions."

The android sdk is very limited, confusing, and constantly changes and deprecates things every few years. Its insanely frustrating

[MotleyGord]

Feb 4, 2022 10:05:04 GMT -5 GoneMAD said:

The android sdk is very limited, confusing, and constantly changes and deprecates things every few years. Its insanely frustrating

Google is going further down the (locked) path that Apple took, after building their base on doing things differently.