ev-map/EVMap

Android Automotive: Limit to eight entrys on any list

Closed this issue · 7 comments

I've noticed that AAOS only allows 8 rows in a list on any screen, dictated by the constraintManager. This means there are 3 filter settings missing and also only 8 filter profiles can be displayed.

The showcase demo app adds a "more"-button to the top right when a list contains more than 8 rows and pushes a new screen to display a new page. I understand that AAOS limits the top right Actions to two. Since those two slots are occupied by other actions it is not possible to add any actions to that area of the screen.

I would suggest to use one row int the EditFiltersScreen to go to a second page to make all filters accessible.

This would be my suggestion:

    private fun buildFiltersList(filters: List<FilterWithValue<out FilterValue>>): ItemList {
        var subtractor = 0
        var sub_filters = filters

        // check if list fits on screen
        if (filters.size - start_index > maxRows) {
            subtractor = 1
            sub_filters = filters.subList(start_index, start_index + maxRows - subractor - 1)
        }
        return ItemList.Builder().apply {
            if (subtractor > 0) {
                // if it does not fit, insert button for next page
                addItem(Row.Builder().apply {
                    setTitle("More Filters")
                    // Insert forward Icon here
                    setOnClickListener {
                        screenManager.push(EditFiltersScreen(getCarContext(), start_index + maxRows - subtractor) )
                    }
                })
            }
            sub_filters.forEach {
            //...

EditFiltersScreen would get a new argument to specify where to start if it is another page:

class EditFiltersScreen(ctx: CarContext, start_index: int = 0) : Screen(ctx) {

I can't test the code myself currently so I don't know if it works at all. Also I have next to no Kotlin experience. But it should show my train of tought.

Showing more than 8 filter profiles would propably be more complex as it is a selection list. Right now if you save a new profile others get pushed out. They are saved but not selectable and there is no info to the user about this happening.

The problem is that not only the number of items in the list is limited (not always 8 items, that depends on the specific car), but also the number of screens we can push (= number of hierarchy levels) https://developer.android.com/training/cars/apps#template-restrictions
Effectively, this means we can only go up to four levels deep (or five in case the last template is a PaneTemplate or MessageTemplate). The current filter flow already fully utilizes this:

MapScreen -> FilterScreen -> EditFiltersScreen -> MultipleChoiceFilterScreen

So we can‘t easily add another page.

One workaround would be to ensure that the filters on the second page are only Boolean filters (which don’t need an extra level of navigation) or Slider filters (which use a PaneTemplate). Maybe that would work…

Alternatively, it might be possible to push a dummy screen (e.g. MessageTemplate showing a loading message) that then immediately pops back to the EditFiltersScreen. I have seen that this sometimes makes it possible to refresh the contents of the screen (e.g. to show the second page) without affecting the limit.

I see, I overlooked that.
How about rearranging the filters in a way so that multiple choice filters are always on the first page?
If I counted correctly there are currently four multiple choice filters (connector types, operators, providers and categorys). Those would fit on one page and there would be 3 more slots for possible future multiple choice filters.

And another idea: Since the search is going to be moved on the map screen you could move the delete button down one layer freeing up space for one more filter on the first page:

MapScreen -> FilterScreen (Actions: Delete, Edit) -> EditFiltersScreen (Actions: Save, More) -> MultipleChoiceFilterScreen
                                                                                             -> EditFilterScreen (without MultipleCoice)
          -> Settings ...
          -> Search ...

Edit: I completely overread that one paragraph where you essentially say exactly that ... 🙈

I have two more thoughts about this Topic. One would be a larger restructuring of the UI. I've tried to visualise it a bit in the attachments. It would also increase the number of usabele filter profiles.

Layout_1
Layout_2

Another idea came to me while looking at media apps on AAOS. Many of them use regular android UIs for settings. Those are of course not distraction optimised and will be disabled while driving. So technically it should be possible to use the standard phone app UI for the filter settings just making them not available while driving. This might bring more issues than it solves and I dont know how it interferes with Android Auto, but it would grant the largest flexibility for the filter settings.

Oh and sorry for all the spam, just getting into this whole topic while waiting for my Polestar 🙃 I will try to set up those API-keys and maybe tinker a bit on my own as well.

I have two more thoughts about this Topic. One would be a larger restructuring of the UI. I've tried to visualise it a bit in the attachments. It would also increase the number of usabele filter profiles.

Hm, yes, this would increase the number of usable filter profiles - but on the other hand add an additional tap for switching between the saved profiles (which is probably much more commonly used while driving than editing or deleting saved profiles)... So not sure if it is the best solution.

You have probably also already seen https://issuetracker.google.com/issues/179648622 - so Google is also working on relaxing those limits, but it may take a longer time as it needs to be negotiated with the manufacturers and adapted to regional restrictions.

Another idea came to me while looking at media apps on AAOS. Many of them use regular android UIs for settings. Those are of course not distraction optimised and will be disabled while driving.

Yeah, that might be a way - technically it should be possible on AAOS, however I don't know whether it's allowed for POI apps since Google only has documentation for that in the media apps section. Also that would not work on Android Auto, so we would still need to maintain the templated UI for that (or drop the filter editing functionality on Android Auto, where it is not as crucial as filters can be edited on the phone).

Oh and sorry for all the spam, just getting into this whole topic while waiting for my Polestar 🙃 I will try to set up those API-keys and maybe tinker a bit on my own as well.

Absolutely no problem, it's great to have discussions here and, as I saw in your email, even people checking out the code and testing improvements. And congrats on your Polestar! 🙃

Hm, yes, this would increase the number of usable filter profiles - but on the other hand add an additional tap for switching between the saved profiles (which is probably much more commonly used while driving than editing or deleting saved profiles)... So not sure if it is the best solution.

You have probably also already seen https://issuetracker.google.com/issues/179648622 - so Google is also working on relaxing those limits, but it may take a longer time as it needs to be negotiated with the manufacturers and adapted to regional restrictions.

Yes, you are propably right. I've created a Pull request with my changes if you want to have a look at it. It would also be nice to have seperate limits on distraction otimized and non-optimized sections of an app, lfiting the limit on non-optimized completely.

Yeah, that might be a way - technically it should be possible on AAOS, however I don't know whether it's allowed for POI apps since Google only has documentation for that in the media apps section. Also that would not work on Android Auto, so we would still need to maintain the templated UI for that (or drop the filter editing functionality on Android Auto, where it is not as crucial as filters can be edited on the phone).

I could personally not think of a reason, why this should not be allowed. But yes, who knows what google thinks about that 😂

Since this pull request #251 is now merged I guess this issue is done, right?

Yep, thanks!