Errata for Making Service Requests, page 476


#1

At the bottom of page 476, where we are sending the postInformationToServer message in the netServiceDidResolveAddress method, the following code is shown:

- (void)netServiceDidResolveAddress:(NSNetService *)sender { [statusLabel setText:@"Resolved service..."]; server = sender; [self postInformationToServer]; }

One oddity to note is that the server = sender line is not really mentioned, nor is it bold (as in “this is new code”). But more importantly, it won’t build that way, because we’re doing an assignment to a variable that has not been declared anywhere. I think the correct variable name is desktopServer, since this is what we’ve declared in the header file as the instance variable for the NSNetService.

It does indeed build, and function with the following code:

- (void)netServiceDidResolveAddress:(NSNetService *)sender { [statusLabel setText:@"Resolved service..."]; desktopServer = sender; [self postInformationToServer]; }

thanks


#2

Correct. We had some variable name issues. Make sure you read the errata in the Push Notifications chapter forum when you get there.


#3

Did anybody else find this problem?

On page 477-8, we test: if ([[requestURL absoluteString] isEqualToString:@"/register"]) requestWasOkay = [self handleRegister:request];
But [requestURL aboluteString] is always going to be a complete, absolute URL, of the form "http://192.168.1.221:57071/register," so the test against equality with “/register” is always going to fail. Or did I drop a line of code somewhere that chops the string up?

Changing the test from the absoluteString to the relativeString:

        if ([[requestURL relativeString] isEqualToString:@"/register"]) 
            requestWasOkay = [self handleRegister:request];

runs properly.


#4

Is this in the simulator? I believe the return value of this method actually changed on Lion.

I think -[NSURL resourceSpecifier] is actually what I fixed it up to be once I saw this… try that one out?


#5

I kept the absolute string and used stringWithSuffix instead. I believe that is mentioned in the forums elsewhere, as well.


#6

[quote=“JoeConway”]Is this in the simulator? I believe the return value of this method actually changed on Lion.

I think -[NSURL resourceSpecifier] is actually what I fixed it up to be once I saw this… try that one out?[/quote]

This was on an iPad running 4.3.5, with the current Xcode, 4.1 build 4B110, and the current release of Lion (the code is on the server side).

The documentation seems pretty clear about the difference between relativeString and absoluteString, though I suppose that could be a recent revision.


#7

I can also confirm the absoluteString vs. relativeString issue babasyzygy mentioned on the very last line on page 477. Specifically:

if ([[requestURL absoluteString] isEqualToString:@"/register"]) { requestWasOkay = [self handleRegister:request]; }
should instead be:

if ([[requestURL relativeString] isEqualToString:@"/register"]) { requestWasOkay = [self handleRegister:request]; }
I found that [requestURL absoluteString] returns the full URL running on the simulator whereas [requestURL relativeString] just returns the portion we’re looking for: @"/register".

I’m running Xcode 4.1 (build 4B110) on Lion 10.7.1.

Thanks for an excellent book, guys. This one is staying firmly on my desk within easy reach at all times – at least until the third edition comes out! :smiley:

-Buxley