Issue in entering the text in tokenise field

[mobiniuspabitraranjan]

Using the latest version 'com.splitwise:tokenautocomplete:3.0.1@aar' in my application.

And used below method for the edit field

• fieldView.performBestGuess(false);
• fieldView.allowCollapse(true);
• fieldView.preventFreeFormText(false);
• fieldView.setTokenizer(new CharacterTokenizer(Arrays.asList(' '), ""));
• fieldView.setThreshold(1);
• fieldView.setAdapter(hintEmailAdapter);
• fieldView.setSingleLine(false);
• fieldView.setTokenClickStyle(TokenCompleteTextView.TokenClickStyle.Delete);
• fieldView.setTokenLimit(1);

But It is having some issues in Samsung and OnePlus Android devices, which are given below. Issue No 1. - This issue produced by below steps:-

• First I have entered email like "pabitra@gmail.com" which is available in suggestion adapter and it created token.
• then I have removed above email "pabitra@gmail.com" and tried to add the "pabi@gmail.com" which is not available in the suggestion adapter. But here it is not allowing to enter the "pabi", it is resetting to the first letter "p" only.

Issue No 2. - There is another issue like it is allowing to enter the text from keyboard after created one token (as it should not allow, because - fieldView.setTokenLimit(1) is applied to the field. And entered text is shown the keyboard suggestions, not in the tokenise field.) So there is issue for deleting/removing the tokenise field.

can you reply the solution or make a new release with the fixes? Thanks.

[mgod]

I'm surprised it's working at all - when creating a CharacterTokenizer, you must set a non-empty token terminator and you're using "". I would recommend setting that to "," or ";". I think this will resolve issue 1.

I'm not sure what you're describing in the second issue. The tokenizer does allow the user to continue to type in the field if the token limit is met because otherwise you would not be able to delete tokens. I'm pretty confused by your configuration in general. What input are you trying to get from the user? It looks like maybe you're trying to get a single email address?

[micaelomota]

I've got the same first issue. And I've just realized what is causing that, I left a comment there https://github.com/splitwise/TokenAutoComplete/commit/554cd7bb6cbc2b72c02dc2f69ea01e10388f6f02#r34016492

@mgod I couldn't understand your explanation of the reason why you have added that code. Now for me, the fix is only to remove that piece. Please tell me how I can get the same replacement error so I can try to fix both bugs.

[mgod]

@micaelomota are you also setting the empty string as the terminator in your CharacterTokenizer?

The text you've commented out prevents an issue where some keyboards would keep the text for the previous token search text in memory and when you start adding the next token, would insert all of the previous text as well. The problem only happens when the text that the token replacement uses is the exact same length as the text typed in to search for it.

The issue you're having is actually a related bug. When the keyboard you are using is entering text for typing in "max", it's not providing "m", then "a", then "x" as input, it's providing "m" and "ma" and "max" as input. I assume you're typing in "ma" as your search term to find the "marshall@example.com" token? If you type "mar", you should not be able to reproduce the bug for the input "max".

Probably the real fix would be to clear the last token completion text after the keyboard adds one letter?

I don't think you can reproduce the original bug with the example as-is, but if you use a character tokenizer with "" as the termination in the example and type out the full email address before selecting the same token, you might be able to see the text re-appear on the next token typed out.

Actually, given the new bug you're seeing, you might be able to put some breakpoints in the code where you commented out the text and watch what input you get from the keyboard when you type a single letter after selecting a token. This might make things more clear than my explanations.

[micaelomota]

@mgod

No, I'm not setting the empty string as the terminator in my CharacterTokenizer.

This is what I'm doing: 1- Select marshal@example.com 2- Write max

You are right about how my keyboard is working, it is providing "m", "ma" and then "max"

Actually, it has worse behavior and may be related to that. On the example in the master branch, if you erase the preselected emails and press backspace a few times, then start writing something, the app is joining the prefix string to the written text.

Look at the last image.

[micaelomota]

I gonna try to clear the last token completion text

[micaelomota]

Doing this we solve the "max" issue. But the "Tom" is still there, so its not related.

 @Override
    protected void onTextChanged(CharSequence text, int start, int lengthBefore, int lengthAfter) {
        super.onTextChanged(text, start, lengthBefore, lengthAfter);
        lastCompletionText = null;
    }

[mgod]

Thanks for the fix! I have an unrelated fix I need to put in, but I should be able to wrap both up this weekend and put out a new version. I am super confused by the "Tom" issue. I assume you're keyboard is supplying the string "Tom" as the input and not that we're accidentally taking the input "m" and sticking it in the prefix?

[micaelomota]

I'm trying to figure out what is really happening. But I'm just pressing backspace and the prefix appears as I had written it.

[mgod]

I've tried to prevent it as much as possible, but there are some cases where the prefix can get deleted and need to be restored. I might try adding some logging to the onTextChanged for the view and see if you are able to delete parts of the prefix.

[mgod]

First issue should be resolved in 3.0.2. Second issue is probably not something that will be fixed in this library. I'm still confused about the use case (it seems like you should just use a regular autocomplete field?), but if you want to follow-up on that, please open a new issue.

Same for the "Tom" bug, which I have been able to reproduce, but seems like an edge case race condition I'm unlikely to be able to address without more reliable reproduction or test case steps.