Spotify: screen usage optimization in 'now playing' view - consideration of splitscreen status

[rtrrbtr]

Hi!

when scrolling through the 'now playing' list in Spotfiy in my BMW F36 with Nav Professional, the song or podcast titles are often cut off due to lack of remaining screen width. This makes it sometimes hard to find the right entry in case they are using longer names. With the iDrive screen in splitscreen mode, this makes absolutely sense and can hardly be avoided because there is just no more space left.

Unfortunately, when disabling the splitscreen mode, the gained additional screen size is not being used for displaying the list of entries over the full width of the screen. The entire splitscreen area on the right side just remains black, the view is still limited to the screen size of the main screen without splitscreen. I've added a photo to visualize this.

Therefore, I'm wondering if it would be possible to either

• detect the splitscreen status and tell the app to use the full width of the screen, if disabled
• or to provide a setting in AAIdrive where users can define if widescreen should be used in this view

to not cut off the titles unnecessarily and improve the user experience when searching for specific titles in a playlist?

Additional thought:
The padding/margin on the left side of every list entry (left of the cover picture) looks also a bit big and could be optimized to cut off a few less characters at the end?

If you need any details regarding my specific screen resolution or other logs or if I can test something in the code on my own, let me know.

PS: Thanks for the great work. I enjoy using AAIdrive nearly every day :)

[hufman]

Thank you so much for the kind compliments and the excellently-detailed feature request!

As you can tell, the car app is built on top of reverse-engineered resources of other car apps. This particular screen being used for the queue is already configured somehow so that the list does not expand to the full width of the display. You can see the width of the list with the width of the selection cursor. The list column widths are configured to auto-expand, but there may be some other setting somewhere to expand the list itself.

The left column is where the checkmark indicates the current track, and there isn't much room for it to shrink.

I'll keep this request open until a solution is figured out, there are other screens that I'd like to have positioned better too. However, the current understanding is limited and I don't know how to solve this currently.

[rtrrbtr]

Thank you for your feedback and for pointing out the relevant section in the code!

[hufman]

Welp I spent the last two days trying to figure this out and am stumped! I am not sure why some screens (like the Notifications List) are wide screen and the various lists in the Music app are not. In particular, the Music App Switcher List is the exact same layout as the Notifications List, same properties and widgets and everything, but I can not figure out the difference, even with modifying the code to set them up the same way.

[rtrrbtr]

Hi,
thanks for putting so much effort in the investigation!
Sorry to hear that it seems not easily possible to implement this, even with your knowledge!

I've played around with the RHMIProperties (with my very limited understanding) and have set

• the columnwidth of the column where the songMetaDataText is located to a fixed value (1040) which would 'force' it to use nearly the entire screen width (so also the part where usually the splitscreen is located)
• ROW_LINE_MAX_LENGTH to 48 to not cut off the titles/artists earlier than needed
  just to see what happens - if the whole table gets expanded etc.

Result (also see pictures):

• Song metadata uses 'splitscreen area' and is better readable
• Cursor remains cut off
• scrollbar stays at the same location (where splitscreen area would begin)

during scrolling:

I know that that's definetely not a solution for all users (especially since I used fixed values which may only work with my 1280 screen resolution :) - and it for sure looks kind of improvised with the scrollbar touching the text and the cursor only half way), but for me personally it's still an improvement and I will keep these setting for now - just because I often listen to podcasts which tend to use long song titles :)

When having splitscreen mode active, it looks also ok (not perfect, but ok):

One additional observation & question:
When jumping into the 'now playing' view (or also the 'browse page' view), there is a placeholder mobile phone symbol shown in the right area of the screen.
This looks a bit like this area is not really "unused" like I thought in the first place. Can it be the case that this space is usually defined (in the ui_description xml for Media?) to show coverart? And this prevents the table with song metadata to extend to fullscreen?

Once you first scroll through the list, the image placeholder disappears magically :)
Is that element created by your code somehow? Or does it come from the ui_description.xml or somewhere else?

[hufman]

Wow, this is great! Thanks for continuing to experiment!
I was focused on trying to figure out the difference in the screens to see why the Notification List behaves differently than the Music Lists. I hadn't thought to just force the list columns wider, neat!
Inspired by your approach, just now I also tried forcing the widget itself to be wider (listComponent.setProperty(RHMIProperty.PropertyId.WIDTH, 2000)) but it just made all the rows collapse and draw on top of each other. Something else will need to be found. The classic Analyzer app has this WIDTH (and also CURSOR_WIDTH) specified in its UI Description, but perhaps the statically-defined width behaves differently? The only other unexpected property I found on any lists is in the classic Twitter app with an unknown 43 property, having a value of -1, but it didn't seem to change anything for me when I tried. (more notes about properties)

ROW_LINE_MAX_LENGTH is used because the car would wrap the first line into the second line, which would overwrite any desired subtitle we'd have. Your last screenshot shows this, with untergehen being wrapped onto the second line and overwriting the artist subtitle. By setting the column widths wide enough, this doesn't matter. You could probably even go all the way to 5000 pixels and the text will just fall off the edge of the screen, but that's probably fine.

That area with the mobile phone symbol is indeed confusing to me. It is not mentioned in the ui_description, and these HMI States are identical (besides various IDs) between notifications and music, which is what is confusing me the most. I believe this is the preview widget, similar to how official car lists like the Radio and internal car apps show a preview in that area before you click into them. Notably, that same mobile phone image is used as the preview for the various main entry buttons into these phone apps, but I'm not sure why it would be used internally in the apps too. The protocol supports specifying it, but only the UI Description for BMW Connected itself is enabled to do so, and AAIdrive does not have any code to affect this area.

Since you have the project checked out and compiling, you can explore the ui_description.xml files found in app/src/main/assets/carapplications. The protocol does not let you modify them, however, but maybe you'll find some more clues to try out!

[rtrrbtr]

Hey,
thanks for your reply!

I've experimented a bit with the different properties - but unfortunately did not yet find any working combination. I've mainy used

• WIDTH
• HEIGHT
• POSITION_X
• POSITION_Y
• OFFSET_X
• OFFSET_Y
• CURSOR_WIDTH
• LIST_COLUMNWIDTH

and different combinations of it.

Like you already mentioned, setting the width of the whole list to a static value somehow changes the behaviour of the list. All elements are displayed on top of each other, the dynamic scrolling through all list entries underneath each other somehow get's lost. The cursor stays always at the same place.

The positioning of the list element is also being lost when changing to static width or height. (Song List moves to the top where queueImageComponent, titleLabelComponent and subtitleLabelComponent are already located).

A few examples:

... increasing the widget height as well:

... positioning the widget using the POSITION_* properties

Regarding the unknown 43 property you mentioned in your latest comment (Twitter app):
From what I would interpret from the enum names in com.bmwgroup.connected.internal.ui.RhmiPropertyType, it seems like properties 42 and 43 are only used to change behaviour of 'richtext-lists':

• 42 = LIST_RICHTEXT_MAX_ROWCOUNT
• 43 = LIST_RICHTEXT_LAST_LINE_WITH_THREE_DOTS

I would assume these settings only have effect when using 'Richtext' lists (possible value for 'modelType' in 'raListModel', correct?).
However, those properties do not really sound like they would help in our case regarding widget width behaviour or dynamic scrolling through the list. Do you agree?

Btw: besides those two, there seem to be also some other properties defined which are not yet mentioned in your component properties table:
BACKGROUND 39
TABSTOPOFFSET 38
TERMINALUI_DEREGISTER_INPUTEVENT 41
TERMINALUI_REGISTER_INPUTEVENT 40
TERMINALUI_SET_BRIGHTNESS 45
TERMINALUI_SET_COLOR 46
Is there a reason why you left them out there?
I did not test them since they also sound not really related to the current challenge, but wanted to mention it.

Additional question:

• Do you know what HMISTATE_TABLELAYOUT and HMISTATE_TABLETYPE can be used for and which values are allowed?

[hufman]

Wow, excellent sleuthing! I have no idea why I left those properties out of the table, I see that they are even in the original BMW Classic! I'll update the docs with these properties and any example values I find.
richtext is indeed a model type of lists, and is configured for the message view body in the Notifications app. I'm not sure what the richtext part means, about whether it can change the text formatting at all and I haven't found any hints about such functionality, but it is the only list that allows a row height taller than 2.

HMISTATE_TABLELAYOUT and HMISTATE_TABLETYPE are the most promising properties, I think. The only use I've found so far is to force the custom map window to be wide screen, otherwise it only slides in 2/3rd of the way from the right. From my collection of app resources, I see the following values, most commonly specified are 3 and 1,0,7 and usually on a toolbarHmiState:

<property id="24" value="1" />
<property id="24" value="3"/>
<property id="26" value="0,7"/>
<property id="26" value="1,0,7"/>
<property id="26" value="3,6" />

I wasn't able to notice a difference when experimenting with them, but please feel free to try them out!

Personally, I found the reverse engineering the most exciting part of the project, and I'm happy you're sharing this excitement :)