Today was a sort of impromptu meeting with Evan to finally finish the rest of the issues with the login screen. This was a lot faster than usual since we were both there and able to debug on both the client and server sides, whereas on my own I usually have to wait to find Evan and let him know what issues were appearing on the client side due to issues with talking to the server and he would eventually fiddle with it on his end.

While Evan fiddled with getting the create user command to actually function on the server side, I fiddled with the interface so I wouldn’t disturb the implementation changes he was doing. I removed the obsolete iPhone link option and realigned everything else to fit again.

We also fixed it so that the return button no longer needed to be clicked to actually update the field. This was due to a misunderstanding when I initially did it, where I had the processing inside of the textFieldShouldReturn function.

As it turns out, this function is really only meant to return the behavior when the return button is actually pressed, not when the input itself is just returned. The code was simply moved into the actual cell generation code, so that it will be called anytime the field returns and updates the cell.

Another change within both the UI and implementation was changing all of the fields so that all user data can be entered. This was part of a whole explosion of changes to both the server and client to resolve the many issues.

For example, there was a disconnect between the passwords being sent and received, because of differences in the encryption and decryption methods.

With all of those and other issues out of the way, the login and create user functionality is finally complete with the network communications now working and necessary.

After this was another big chunk of time spent looking at how the iOS keychain works. We needed to use this in order to store the user’s authenticated information so that they won’t have to login every single time they start up the Wine Agent.

In the User tab, you might remember the two functionless options for linking and logging out. I removed the linking option since its login page counterpart has also been removed.

The logging out simply performs a reverse of the keychain manipulation, removing the user’s entry and regenerating the modal login screen over itself.

After all of that was done, I went back and tested the functions a lot more thoroughly, trying to find all of the corner cases we might have missed and fix them.

One of these was that if the user or password fields were blank, the application would crash due to manipulation of the strings within the conversions before the network communication. A blank string would turn into a null object when translated into the network compatible string, and so an access error would result in the commdelegate.

This was easy to fix by adding an error message about it.

Another annoying issue I ran into was how the text fields for everything kept trying to autocorrect everything, with capitalization. This was resolved by simply changing the autocorrection property of the text field. (text.autocorrectionType = UITextAutocorrectionTypeNo;)

The last major issue that I found was where an invalid login would make all future ones invalid as well, even if it should have been valid. The responses were as expected, but the processing was somehow going wrong.

I immediately suspected that it was caching the previous entry of the fields or the invalid response somewhere, and tried to do testing to figure out which one.

To see if it was the first, I tried to use blank or cleared fields as well as additional clearing of the fields to be sure that nothing was being cached, but this didn’t seem to help.

More suspicious was the OWLInstance, since it caused so many problems before. However, I tried to test this by releasing it after each attempt, which had no effect.

At this point I went back to Evan to try to see what he thought. After a whole lot of breakpointing and stepping through everything, we figured out that it was, in fact, due to the OWLInstance not clearing itself properly.

My check hadn’t discovered this because although it was releasing the individual instance object, it was not clearing the singleton dictionary that actually holds all of the instance data.

Finally, we got it so that the previous responses are cleared each time, and the login interface is now completely fixed, including all of the corner cases that I could think of.

The only remaining issue related to the login screen is that the Personal Info is yet again incomplete, as the login of the user only writes the username and password to the object, not the first name, last name, foaf file, or e-mail.

Next will either be fixing up Personal Info again or going back to taking a look at View Recommendations.