#1223 feature: sorting key maps

[maksimowiczm]

I've made some progress on the sorting feature.

I've created a simple UI where users can choose the field priority and sort order of the fields, which are applied to the home key maps list. I don't think a bottom sheet is a good idea for this especially with the drag interactions, but I couldn't think of a better alternative. (I replaced help button 😅)

Sorting preferences are stored in PreferenceRepository. I think it would be annoying to have to apply sorting every time the app is launched.

I'm unsure about using sorting in ListKeyMapsUseCaseImpl. Currently, key maps are sorted every time, which might result in a poor user experience if someone has a large number of key maps. I think it might be a good idea to create a separate screen for searching, where key maps could be sorted.

It might also be a good idea to implement sorting with SQL for better performance.

Additionally, there doesn't seem to be an obvious way to sort triggers and options, so I need some help with that.

[GfEW]

That's great news! I can't currently test PRs, but I'm not really into coding, anyway. Hope @sds100 finds time time to take a closer look.

I can, however, comment on the UI/UX side of things. Some remarks:

1. persistency

Sorting preferences are stored

Makes sense, sort/filter prefs should indeed persist until changed or reset by the user. To keep forgetful users from missing something, it's important to clearly indicate (e. g. by the filter icon) whether the current listing is filtered.

2. sort delay, main vs. separate list

Currently, key maps are sorted every time, which might result in a poor user experience if someone has a large number of key maps. I think it might be a good idea to create a separate screen for searching, where key maps could be sorted.

Is this really an issue? Could you give some figures of the expected sort delays with 30, 100 and 300 mappings, or estimates thereof?

Sorting and filtering would be much more beneficial in the main listing than only in a separate search screen with limited functionality. To justify the inferior, latter option, the performance difference between the two would have to exceed 1.5 s with 30 mappings, or 3 s with 100 mappings (which already is a lot, but would mainly affect the relatively small fraction of users who know they are stretching the limits).

I think it's reasonable to assume only very few will end up using more than a few hundreds mappings. And if done right, sorting a list of a few hundreds items shouldn't take more than one to two seconds, even on ageing hardware (for a relevant example, see the apps list in AppManager).

3. sorting triggers or options

there doesn't seem to be an obvious way to sort triggers and options

Ideally, sorting by triggers would be consistent with their exact name strings as they are presented to the user (including Left/Right, parentheses etc.), e. g.
"Shift Right (Any device * Do not remap) + Delete"

Sorting by options is trivial for mappings that have either no or exactly one option enabled. (As with every key, "no option enabled" should come before all possibly enabled options, as the empty string is the smallest possible value.)

The case of multiple options being enabled is a bit awkward, because their presentation order currently doesn't follow an obvious scheme. However, sorting according to the presented string would be the best we could do here, too, e. g.
"Vibrate * Show an on-screen message"

p. s. Nice PR ID.

p. p. s. I've visually improved the sorted list example in #1223, to make it easier to comprehend.

[sds100]

First I'm going to complete version 2.7 and then I will work on this.

[maksimowiczm]

I worked on it a bit.

---

@GfEW

2. sort delay, main vs. separate list

I might have underestimated the performance of modern devices. I don't think it will be an issue with such a "small" list.

---

I applied your suggestions. @sds100

---

Current sort order for each field:

• Trigger

1. Keys are sorted one by one until one trigger runs out of keys (different size of keys list)

   Keys are sorted by

   1. Code
   2. Click type (short, long, double)
   3. Device
   4. "Do not remap" option

2. Keys' length - the shorter the better

3. Trigger mode (sequence, parallel)

• Constraints
  Sorted by their name. If names are identical, they are sorted by their value (e.g., package name, Bluetooth address, etc.).

• Actions
  Sorted by their name (e.g., all Launch app actions are treated as the same name). I am currently working on sorting them by their value, similar to constraints.

• Options are not sorted at all. Not sure where to find all options in the code I need some help with that. @sds100

---

I think users should be able to choose sorting options and arrange them according to their needs. For now, I’ve implemented a very basic UI with all field.

24-11-17-17-47-26.mp4

---

What's next?

• I will finish sorting actions by their value
• I will try to sort options
• Think about user interface

[maksimowiczm]

Everything except the UI is done. Additionally, this commit 11e736f somehow broke part of the multi-select menu functionality. If reverted, it works fine.

[maksimowiczm]

So, I did some research and I came up with a solution where the sort fields are displayed as chips in a scrollable row. It could also wrap, but at this width, it looks awkward because one element will jump between the first and second row.

The bottom sheet could also be used with filters, where it would be added below the sorting feature.

This is a similar solution to the one used by TikTok.