It would probably be a good idea to refactor all interaction with the server into its own object. One reason is simple modularity. Another would be hide the complexity of an implementation that allows the UI to remain accessible during network operations -- in particular, sometimes when the LJ server is slow, the program will look strangely blank until the server finally comes back. The idea is to have singleton object that would handle all interaction. Although it could run requests in a different thread, it would still run each request one at a time, in sequence.
There doesn't appear to be a Journal entry data structure, which in this program would be the "Model" of a MVC design pattern. Even if this program never deals with more than one entry at a time, it would be a good parameter to pass around to various functions. Once it is in place, we could add features like a synching and backup.
If I were to put my money where my mouth is, I'd do the Journal entry thing first, because it's simpler (I'm just starting to learn Objective C) and also would appear in the interface of the server interaction manager object.
