Gesture data screen

[Helium314]

@the-eclectic-dyslexic intends to work on a native gesture typing library (#668), ideally usable as a drop-in replacement for the AOSP / HeliBoard native library (could be used similar to the Google library, but no need since it will be open source with a compatible license).
For understanding current handing of gesture typing in the closed source Google library, @the-eclectic-dyslexic asked me to add a screen where users can simply gesture type a word, and the target word plus all available data will be stored.
Data can then be sent via email.

Getting and storing the gesture typing data already works in the current state of the PR, but what data exactly should be stored is not finalized.
The UI... works but should be better.

When sending data via mail, the data file is currently not attached for some reason, possibly an issue with the provider.

@the-eclectic-dyslexic if you want to test it, do you compile it yourself, or should I upload the current state as APK?

[the-eclectic-dyslexic]

I will build it and take a look on Monday! Thanks for your work on this @Helium314. I will build it and see what I can think of with regards to the UX of gathering gesture data. I may makes some changes and see what you think before we add it to the apk. Just want to make sure things work as seamlessly as they can before we let people play with it, so that we don't turn anyone off of helping generate data.

[Helium314]

I may makes some changes and see what you think

Sure, we should both agree on the UX and the data (what is included and how it's structured) before merging.

[the-eclectic-dyslexic]

Okay! I took a look at it. There are a few things to change for sure, but it should be doable.

I think the reason the file isn't attaching has something to do with what the provider thinks the file is. I was able to attach it to one email client on my phone, but not another. In the one where I was able to attach the file, it automatically gave it a .bin extension... even though it was definitely a zip file. I was able to open it after downloading the email. The data was all there! So, it could be that your email client was rejecting files with no extensions or something silly? I will see if I can figure this out.

We should also include the email address by default in the sender field of the email. Though, we may want to obfuscate it in the code of heliboard, so it doesn't get crawled and subsequently spammed into oblivion.

I think we could make a few little changes. Instead of generating a uid for the user, generate one for the gesture. We can talk about this more later! These would only be very small changes.

I think also maybe we should add the heliboard version string to each gesture, in case they generate data across multiple versions of heliboard. The data is in the shared preferences right? so that will carry over between versions. This would also come in handy for separating our gesture data from the google library gesture data if we want to keep allowing people to submit data after we distribute our own gesture typing. We can just say data before version x is google lib, and after is us, because we probably won't be using the google lib once we distribute ours right? if we are, we may also want to include the gesture library in the version string somehow.

I think we should create a cutoff that forces a reentering of a gesture. If a word doesn't show up at all in the suggestions for a gesture, we can assume it isn't correct. I think what we could do is add some kind of indication to the user that we think the input they have given is fine. This will take a little bit of changing the UI, but I think I can figure this out.

I still need to think a little about the text box. I think it would possibly be better to hide what their gesture resolves to, and only ask them to do well enough that the gesture could reasonably be what we are looking for. I don't want them to be trying to get the exact right gesture, because then all we are doing is optimising for how people work around the failures in gesture recognition, instead of optimising for how they expect it to work intuitively. Basically, we would likely only be able to do as well as the google library with that data... not better. We want them to treat it as effortless, not a metric to game. I will think about this more and see what I come up with.

I hope all of that made sense. I am going to play with this a bit, but I think this is most of the way there!

[Helium314]

So, it could be that your email client was rejecting files with no extensions or something silly? I will see if I can figure this out.

Good point, maybe I just need to change the name in the content URI of the provider.

We should also include the email address by default in the sender field of the email. Though, we may want to obfuscate it in the code of heliboard, so it doesn't get crawled and subsequently spammed into oblivion.

Definitiely there should be a prefilled address. Maybe having a dedicated address and automatic processing is doable, then spam should be less of an issue.

heliboard version string

done

if we are, we may also want to include the gesture library in the version string somehow.

The gesture library sha256 should already be in shared preferences, we could use this to identify the known versions (currently only 1 for each of arm / arm64 / x86 / x86_64).
I added this now, but could also be done differently.

I think what we could do is add some kind of indication to the user that we think the input they have given is fine. This will take a little bit of changing the UI, but I think I can figure this out.

Would be good to have some ideas, because currently I don't (but it's still early morning...).

I don't want them to be trying to get the exact right gesture, because then all we are doing is optimising for how people work around the failures in gesture recognition

That would require force-disabling the floating preview setting while in this screen. Technically no problem, but might be unexpected for users who are used to it. Though there is no preview for the final word anyway.

[Helium314]

Good point, maybe I just need to change the name in the content URI of the provider.

No change after appending .zip to the URI (using K9 on Android 9)