mgod
commented
9 years ago I'm not a huge fan of this feature because managing input for this library is pretty complex and this kind of change makes testing (which needs to be manually run on several devices with different custom inputs) more time consuming. It also seems like if a user is presented with a field full of tokens, making some them removable and some not is pretty strange. Maybe you should just add tokens to the prefix? What's your use case?
I'm happy to add this with some changes:
- don't make this dependent on setting a listener. Add a method to the TokenCompleteTextView class called something like
isTokenRemovablethat returns true in the default implementation. Have people override this method for custom behavior - don't add any additional instance variables
- when determining if a delete keypress can go through, figure this out from the current location of the cursor rather than just comparing the text length to the expected length of the token objects. Note that the trailing space after a token must be kept if you keep the token
- allow non-removable tokens with all selections styles instead of making a new one.
For all that I seem skeptical on this, I'm really happy to see this PR! Most of these suggested changes are aimed at reducing the code paths that need testing as much as possible and making maintenance more straightforward. It looks like there are some common patterns like rotating the view, custom input keyboards and moving the cursor to the middle of the field that you haven't tested yet and these changes should fix most issues with those.
sweggersen
These extensions allows the field to have some fixed tokens that cannot be removed by the user. This is useful if you have some tokens that are pre filled, and you only allow the user to make additions of the tokens available.