Archive for April, 2011

Today was another sort of short impromptu meeting where I just sort of caught up with Evan about some of the new issues resulting from this afternoon’s test by Digimarc. One of the big issues resulting from that was that apparently the new version of Pellet is hating on our ontologies, resulting in all of the reasoning breaking down. Sort of bad. The rollback to an older version of Pellet fixed this but also broke a bunch of the other libraries until they too were updated.

Another change that Evan did was to initialize some test data for the recommendation manager. This means that one of my changes from a while ago to the View Recommendations controller could now be tested. To my surprise, it actually displayed the recommendation!

There are still some issues with it because I adapted another class to list the recommendations, resulting in it trying to find linked recommendations when an item is clicked. Since this is its own view right now, there isn’t actually anything to pull recommendations from, in connection to, so it fails. Interestingly, this can be resolved by simply viewing a restaurant menu. This causes the server to pull in the restaurant data which the recommendation view can now compare against, and results will appear if an item is clicked.

Of course, this in turn led to another server-side issue because the restaurant data being pulled isn’t actually cleared after leaving the restaurant view. This means that if multiple menus are viewed, the total union of items being compared against just keeps growing. Although not screenshotted, a test with this managed to get a listing of both the test item, the items for a previously viewed restaurant, and items from the currently viewed restaurant.

There was also a weird bug where the Is A for the item showed a blank node instead of the item name. Server explosions all around, but luckily nothing that crashes the application right now (after a round of fixes, anyhow).

After testing with the recommendation view, I went back to fiddling with some bugs with the login screen that were encountered during the test. One issue was that during the test, Evan noticed a null session being passed all of a sudden, which isn’t very noticeable right now, but needs to be addressed. We looked through the code for a while, and Evan realized that the reason was probably that the tester switched from their iPad to the iPhone, but had the same data synced to both through iTunes. This meant that the keychain had a cached login but no session ID, since that is separate, and so ‘logged in’ without one.

Another issue was that if the user hits log out then terminates the program, they still seem to be logged in when they start up again. Since this was something I was sure I had addressed, I went searching through the code, placing a bunch of NSLogs around. Finally, I noticed that Evan had changed the getter of theUser to automatically initialize it if it is nil. Since I had based the login scheme around comparisons of the current User singleton with nil, this sort of broke my code. Unfortunately, he had made this change because of a crash resulting BECAUSE the User could be nil at the start. Oops!

I resolved this by changing my login scheme to check, not for a nil User, but for a User with a nil session ID. This is also a change that will also be consistent with the fix to the other session ID problem.

That fix for session ID will involve setting up a verification system for the session ID, where the program needs to grab a session ID if it is nil but they have a user login cached, or verify that their current session ID is valid, since the server may have restarted and lost all of the session data.

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.

I’m still working on the communication from the login/create user functions. I added all of the CommDelegate calls for both of the screens, but issues continue to pop up. Unfortunately, no screenshots since all of the work this time was nonvisible (and still not done).

During last week’s meeting, I had talked with Evan about my approach to try to get the response data back from the server, and I left thinking that once I added the reading of the parsed response data into the OWLInstance object, I would be able to quickly clean up the rest of the functionality.

Unfortunately, the curse of network communication still hates me.

After adding all of the CommDelegate calls and placing a bunch of NSLogs around to try to figure out what response I was getting, I was disappointed to find out that it was apparently returning nothing in the OWLInstance object.

I began to step through the code carefully, thinking that there were just some mistaken calls to the wrong parser. After fixing these, it still didn’t work, and after continuing to step through everything I finally realized that the parser itself…didn’t actually save anything. The populate function meant to send all of the parsed data out to the OWL objects didn’t have anything in it.

It took me a while to fix this, beginning by trying to base it off the old parser, before seeing that I could just reuse another part of the new parser as the base. As it turns out, I should have just gone the lazy route and copy/pasted it, but I went and overthought why they were different functions. Oops.

Finally, I had it so that the OWLInstance was retrieving the response from the server correctly. Unfortunately, my original curse of network communication still holds, and I get command errors from the create user communication and errors logging in because I can’t create a user.

The creating of the user was apparently due to the server software being out of date, so after that gets fixed I should be able to get everything working…finally. I’ll just need to set up the checking for the appropriate responses and build in the behaviors for both when the login screen should dismiss itself and getting the login data to write into the user object.

As I noted in an earlier post, the All-Hands meetings are now monthly, and also include a review of what everyone has been up to for the last month, so here’s mine in blog form.

At the beginning of the month, I had just swapped back from working on our reasoner back to my regular iOS work. I fixed a few remaining issues with rotation and some of the views being skewed on the iPad. I also completed my work on implementing the preferences view, making sure that adding, editing, and removing each of the entered preferences were enabled and working correctly.

After finishing all of the debugging and implementation completion from previous work was done, I worked on creating the functionality for the Personal Info option in the Users view. It now pops up a modal screen view that allows the user to see and edit their current name, e-mail, and password information. This went through a few different approaches, ending up at the above interface.

Due to it being marked as critical, I began work on the View Recommendations interface, but this was quickly stalled because of the more pressing issue of creating the login screen, which was also a more logical next step after doing the Personal Info screen, which at the time just used a dummy user since there was no login yet.

I am currently working on the said login view. The UI itself was already created for iPhone, but was disabled a long time ago. I added some code to reapply the same layout, although it is called as a modal screen view instead of the previous method, which had it as a separate view controller that preceded what is now the starting view. After reactivating it, I went through and removed all of the old code to stop the page from crashing, and worked on making the view work on all iOS devices, instead of just being hardcoded for iPhone. This resulted in the above view.

Most recently, I’ve been working on the Create User functionality. It now successfully writes to a user object when the modal fields are filled in, and ‘logs in’ the user. Because of network issues, I haven’t been able to make this work with the actual server yet, but the Personal Info view pulls on the same object and so it at least acts the same as it will when complete with connectivity (just without the persistence between sessions…).

Next, I need to resolve my network issues and then implement the actual network calls and checking of the responses in order to add the full functionality to the Create User option as well as the Login option, which currently sends the request, but ‘logs in’ without checking the response. This is again since I cannot get an actual response from the server right now. I’ll also need to extend the same functionality to the Personal Info view, for when the user edits their account successfully.

Worked a bit more on the login screen today, after installing the new Xcode 4. I was kind of worried at first, when I started it up it kept crashing, but it worked fine after a few tries so I think it was just having issues trying to reopen some of the files and such before it adjusted or something. The middle window seems to have vanished, at least from the default view, which was kind of weird since I’m used to that, but using the more organized tree sidebar is probably better anyhow.

Some interesting things I noted was that gdb automatically opens, as well as some stack info, which is pretty useful since the way I arrange my screen the gdb button used to be covered, and also happens to leave the new gdb window in a spot that’s easy to read. Another thing I like is how the build and run errors now load in the sidebar instead of in another window. All of these changes seem to work together to keep everything in the single window so I have less windows open at once, which is really helpful, both in working and in getting back to work next time.

So the first thing I did was to finish up some of the layout stuff, resizing it to a more squarelike version like I said I wanted to try. I had hoped to get a similarly neat effect that the modal windows have, without actually doing it as a sheet modal view, and it worked, I think. Also note that I finally got the iPhone link thing to be placed nicely.

Continuing, I worked on the login functionality, which started off with a mysterious crash with the LoginCommDelegate. Using breakpoints, I narrowed down the access error to what seemed to be between two functions, where the breakpoint was reaching the end of one but crashing before it got to the other one somehow. This turned out to be an issue with a double release on a string. I didn’t notice this because the first release was actually within one of the calls to NSString, which used an autorelease on its result.

This didn’t actually result in any real functionality yet, and I still need to implement the actual setting of the user object upon a successful login (as well as preventing a login if the server response shows it failed). However, to do this I need to see what the results are like so I can figure out what the response looks like to know what to pull out of the response into the user object.

Since I am still having issues with the network, I’ll probably look at this with Evan on Wednesday. The network has always been a big problem for me, since it means I can’t test a lot of things successfully like this.

Since I couldn’t get any further with the login functionality, I switched gears and worked on the counterpart user creation functionality. I adapted my work from creating the personal info page to implement the controller for this, and also generated it as a sheet modal view over the login full-screen modal view. You can see from the screenshot how it’ll work.

Along with these changes, I linked both the personal info edit screen as well as this user creation screen to the same singleton user object for the application, and will incorporate the login to this as well. This will keep the user’s information consistent between them.

The main issue is that none of the three functions actually have any network communication right now, since I’ve been having problems with that. This means that although all of the functions appear to work, they can’t create a permanent account for the user nor can it actually authenticate the user’s login right now.

Currently, the login screen lets the user in no matter what they put in, and it doesn’t write the login data to the user object since I want to get this working ASAP and didn’t bother with the dummy stuff since I’ll have to remove it later anyhow. Once I get the network working, I’ll have to do the user object initialization off the response.

The user creation actually does initialize the user object, so that later uses of the personal info window can edit it correctly. This will just need the addition of the network communication later, with a note to the user if it doesn’t go through that they are on a temporary account.

One thing that will have to be decided is whether the user creation automatically logs them in with that info, or just makes the account but makes the user have to login with it before letting them in. Currently it just appears to let the user in, and I think this will be how the complete version will work too. Less clicks makes for happier users, and there’s no real reason to do it otherwise that I can think of.

Will hopefully get the network stuff done on Wednesday, and with the integration of that the login screen will be complete. Oh! Except that iPhone link thing, I STILL have no idea what that thing is for. Another thing to talk to Evan about.