Thus far, we have the concept of autocomplete, the data source API, and
callbacks where we would be showing and hiding the table view so far.
Definitely more work to complete it, but this is a good checkpoint.

This is still a work in progress, but the table view will actually
render in the appropriate location now. At some point I appear to have
broken the VENTokenField resizing, and actually taking an auto complete
suggestion is still not supported. Just another checkpoint in the
implementation.

By adding the table to the active window rather than to the
tokenField’s super view, I’m avoiding a bug where the frame  of the
token field is reset when it should be growing. This should also help
make sure the table view is on top of any other views that happen to
exist in the super view.

I made the decision that autocomplete is just a typing accelerator,
meaning that there is no dedicated callback for selecting an
autocompleted value, instead the actual value selected is sent back
just as if it was typed manually. I may change this before everything
is complete, as this pushes more (potential) verification on the client
without a lot saved for us.

Instead of having an API that involves handing over a full array (that
may be thousands of items long) I switched over to one more similar to
a table view. I also broke out all of the autocomplete stuff to a
separate protocol instead of expanding the current data source.

Rather than making the client distinguish whether the entered text came
from a suggestion or not, we now have a delegate method for having
selected a suggestion. This is fired in addition to
tokenField:didEnterText: in order to allow users to opt in or to simply
enable autocomplete and use the same delegate methods as before.

autocomplete has a bad connotation, and isn’t really what we’re looking
for in this case. This is really just a suggestion engine.

Xcode dropped them in the wrong folder and I didn’t notice that until
now. Fixing it…

XCTest runners test in what appears to be alphabetical order, or
something close to it. Because of the naming, this test runs after
resignFirstResponder, which leaves the system in a state where that
test’s preconditions aren’t met - the keyboard is not up and ready to
input in the text field. By changing from assuming the first responder
to entering into the known good field, we stop worrying about order. I
also applied this fix to the testBasicFlow test, which had to be broken
into two steps due to the token field clearing properties.

We need to translate the frame of the tokenView into our destination
view’s(the window) coordinates to keep the view properly aligned.
Luckily, convertRect:toView: exists and does this hard work for us!

in real use, tokenField:didSelectSuggestion: didn’t provide the
necessary information to map back to a list of full data objects
without a lot of inefficient searching. This adds some information back
to allow easy indexing into an underlying data store to avoid this
pitfall.