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.