Implement Chat ViewController

[trane]

Not sure how you want to handle this one, but we should keep the state of all chats so when someone leaves the chat view and then goes back it is in the same state as it was (except in the case that the person(s) they are chatting with have added messages).

[basepi]

Ummm, I think we need multiple controllers. I think we need a ChatViewGridController and a ChatViewController -- unless you're just using the ServerViewController to control the grid view.

[basepi]

Wow, I'm an idiot, ignore my last comment, I see now that we have both ChatViewController and ChannelViewController. Party.

[trane]

Not sure if this is because we are on a deadline, but the CSChatViewController is not right. I just setup the delegate chain for creating the chat view, and I see that you are only creating one view from within the CSChatViewController. The viewDidLoad should not be using a instance variable, as that allows for only one view. I have the whole structure setup for you to start up a CSChatView now with a new CSChatViewControllerDelegate method called createChannel:fromServer:.

I've implemented most of this for you. There is a delegate mixup, which gives a warning. But, it's late and I want to go to sleep, so we can fix that later.

All you need to do is write the code to make the servertableviewcontroller go away and have the chat view come up.

[basepi]

Just FYI, inline code snippets only need a single grave character surrounding them.

In any case, I only thought we needed one view.....I figured every time they went back to the server view, we'd just release that chat view, at least for now, until we have the ability to switch between channels without going back to the server. There's no point in having a chat view instantiated for each and every channel or whatever.....I don't know, that's just how I thought about it. But thanks for setting up that delegate, you're the man.

The code to make the CSServerTableViewController go away needs to be implemented within the controller itself. If you have a method which hits when a channel is touched, then I can put the code in there. Just point it out to me when you get the chance.

[basepi]

Fixed your warning, by the way. Just pull from dev. Basically, you never actually said that CSChatViewController implemented the protocol (you have to put it in angle brackets after the inheritance declaration for the class)

Party.

[trane]

We talked about the idea that chat views should be stateful, when a user leaves a chat view and then reenters it later the chat should remain in the same state and include any new messages. The only way, other than plists and some hackery, to get that is to maintain all of the views in the controller. There is no point to have a controller if you only have one view, the view in that case is the controller and you're just wasting function calls.

[trane]

P.S. The chat views will not be stateful across program executions, so once the user leaves the states are gone.

[trane]

Also, thanks for fixing the protocol error. It is sometimes difficult to see the obvious when you're dead tired from moving and stressed about not having time to study for a final.

[basepi]

No problem on the fix.

But you do have a slightly skewed idea of what a view controller is. View controllers should be used even when there is only one view, because it adds the functionality for navigation controller communication and the like. You can't push a view to a navigation controller -- you push a view controller.

I guess I just kind of assumed we'd retrieve the scrollback for each channel as we entered that channel. Both methods are viable, however, and since you've already set up the framework, we're good.