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.