TBog
On Enter, wait for filter to complete, then start first app
Description
Whenever I want to start an app, I type in 2 letters and press Enter on the keyboard. I know beforehand which app is the first (well, visually the last) in the result list and as such should be started when pressing Enter.
However, I find that if the list reorganizing is still busy (I'm not sure of the reason, perhaps because of the animation, perhaps because of the filtering process itself) when I press Enter, another app starts.
As an alternative explanation, it might also be that the filter misses out on the first letter I type, immediately after the keyboard shows, but I think that's less likely.
Steps to Reproduce
To reproduce the behavior:
- Optionally turn on Battery Saver to slow down the device a bit
- Go to Search
- Type in a few letters and press Enter quickly after
- See another app started, instead of the app that should be started according to the result list
Expected behavior
The first result (visually last in the list) should be started consistently.
Device info
OS: Android 11 TinyBit Launcher version: 7.4 (and I believe 7.3 as well)
If the animation started the list has already changed so pressing enter will start according to the new list. I think a better fix would be to let the user disable the animation. Do you agree?
No? I don't think animations should in any way influence how the query works, which in turn means that that they shouldn't have to be disabled to have a reliably working filter process.
I'm not sure how you expect me to fix this? At what point during the animation do you expect to switch from the previous result list to the new one?
I don't really care about the animation in this case. The thing that's bugging me isn't the animation at all: I just think that the action "pressing Enter" should reliably use the result list based on all the letters typed before pressing Enter, no matter in what phase the animation might be.
If the animation is somehow intertwined with the filter process, so that it can't reliably offer the same result every time when pressing Enter, then - while I would say this is a design mistake - I'd rather see the animation get the time to finish before the Enter press is processed.
I have misunderstood. What you expect is to wait for the search to finish before launching the result.
Exactly.
So, imagine I type ab [Enter] really fast (and I have a slow device and/or Battery Saver is turned on).
The result is somehow that TBLauncher doesn't open the first entry from the result list for ab, but instead the first entry from the result list for a.
This looks like the somehow [Enter] is processerd before b, or at least before the query for b has finished.
I'm not sure if I can leave the fix as is. I'm thinking of adding a check to see if the time between the [Enter] and the launch is too long.
I'm not sure if I can leave the fix as is. I'm thinking of adding a check to see if the time between the
[Enter]and the launch is too long.
The time between [Enter] and the launch is not relevant to this problem. During this time, the search results shouldn't have changed, and if they were (e.g. ab [Enter] c), then the newer search result should not matter for what app is launched.
My thoughts would be, simply put:
Key pressed: a =>
currentResultsQuery = false- Do the search
currentResultsQuery = "a"
Key pressed: b =>
currentResultsQuery = false- Do the search
currentResultsQuery = "ab"
Key pressed: [Enter] =>
launchFirstQuery = currentSearchFieldValueIf (launchFirstQuery = currentResultsQuery) return launch(resultsList[0])ElsecurrentResultsQuery = false- search(launchFirstQuery)
currentResultsQuery = launchFirstQueryIf (currentResultsQuery = launchFirstQuery) launch(resultsList[0])
ab [Enter] c This should not happen or else the app that's launching would be unexpected. You should not be able to add search parameters after pressing Enter.
The current implementation will cancel the ab search without getting the results (even if you've pressed Enter) and start a new search for abc This is because searching is a CPU and memory intensive operation and you don't want to do it if you don't intend to use the results
ab [Enter] c This should not happen or else the app that's launching would be unexpected. You should not be able to add search parameters after pressing Enter.
Yeah, I assumed this shouldn't happen, which is why my pseudocode didn't account for it either, but I only brought it up because you said there could be something going on in
the time between the [Enter] and the launch
I guess I still don't understand what could happen in that time frame then, and why you'd need to check this.
The current implementation will cancel the ab search without getting the results (even if you've pressed Enter) and start a new search for abc This is because searching is a CPU and memory intensive operation and you don't want to do it if you don't intend to use the results
That makes sense, of course, but I think the issue at hand can only occur in the following situations:
- Somehow the search for the incomplete string isn't canceled and gets used when pressing
[Enter] - The first letter of the query isn't registered, so instead of
ab, the search is only forb.
the time between the [Enter] and the launch
I guess I still don't understand what could happen in that time frame then, and why you'd need to check this.
I was talking about the wait I added.
Let's say you search for ab and then press [Enter] but because the phone is slow it takes a second. In the mean time you get impatient and put the phone on the table. When the search finishes the app (video/music app) opens and loud music fills the room.
I think in that unlikely scenario, the only reason the app maybe shouldn't start is if the user turned off the screen. And actually I would still want it to. In the specific situation you're describing I would most definitely still expect the app to be launched. In summary, I wouldn't complicate the code with any timeout for that.