Question

I can follow most of Apple's WiTap sample, but am sort of stumped on this bit in the send method:

- (void) send:(const uint8_t)message
{
if (_outStream && [_outStream hasSpaceAvailable])
    if([_outStream write:(const uint8_t *)&message maxLength:sizeof(const uint8_t)] == -1)
        [self _showAlert:@"Failed sending data to peer"];
 }

 - (void) activateView:(TapView*)view
{
    NSLog(@"ACTIVATE TAG: %d", [view tag]); 
    //[self send:[view tag] | 0x80];
    [self send:[view tag]];
 }

 - (void) deactivateView:(TapView*)view
 {
    NSLog(@"DEACTIVATE TAG: %d", [view tag]); 
    //[self send:[view tag] & 0x7f];
    [self send:[view tag]];

 }

Note that I have changed the send: argument to just the tag of the views, which are numbered 1-9. Originally the code had the bitwise AND and OR adjustments.

WHY?

I get the fact that the send method needs a uint8_t, but is that why the bitwise stuff is there? To turn a NSInteger into a unint8_t?

The code doesn't work with my changes above. It will log fine and visually the client will function correctly, but the messages aren't being sent/received correctly from client to client.

Can someone explain in small words what the bitwise stuff is doing? Or am I correct?

Thanks! This is my first question to SO so please be kind.


thanks for the response. I am still puzzled a bit. Get it?

Basically, why?

Is this just a geeky way of passing an identifier? Each of those views have a tag #, why not just pass that, and toggle the state (up/down) from the view class?

Is this just a case of "this is how the person who wrote it did it", or am I missing a crucial piece of the puzzle in that this is how I should also be structuring my code.

I would just want to pass a tag # and then have that tag decide what to do in a clearly readable function like toggleUpOrDownState or something.

This bitwise stuff always makes me feel stupid I guess, unless it is necessary, etc. Then I feel stupid but manage to muddle through somehow anyway. : )

Was it helpful?

Solution

Basically, [view tag] | 0x80 is setting the high bit in that value (so 00010011 would become 10010011) and [view tag] & 0x7f is removing it (10010011 -> 00010011).

Take a look at the [AppController stream:handleEvent:] method. You'll see this code:

        //We received a remote tap update, forward it to the appropriate view
    if(b & 0x80)
        [(TapView*)[_window viewWithTag:b & 0x7f] touchDown:YES];
    else
        [(TapView*)[_window viewWithTag:b] touchUp:YES];

So, the receiver of the stream is checking for that high bit.

OTHER TIPS

I believe the reason why is that the high-order bit is another piece of the data passed from one peer to the other. It specifies whether the message is for the "start" of the tap or the "end" of the tap.

Based on that bit, the receiver either activates the tap view or deactivates it.

So in essence, they are putting two pieces of information in that single unsigned integer - which square was tapped (the low bits), and were the touches beginning or ending (the high bit).

I think it's possible for messages to get dropped, or arrive in a different order. So if you don't say if it's a tap down or tap up, it's possible that toggling would get thrown off.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top