The solution I came up with for this was to implement a category on UINavigationBar and UIToolbar, and overriding drawRect: with a method that does absolutely nothing. Then I can place my own textures behind the bar, and they’ll be seen, instead of the default bar background.

@interface UINavigationBar (TransparentAdditions)
@end
@implementation UINavigationBar (TransparentAdditions)
- (void)drawRect:(CGRect)rect {
    // Do nothing!
}
@end

For UIToolBar, if you’re using it within a UINavigationController, you’ll want to also override drawLayer:inContext:, as this appears to be used instead of drawRect: when used within a navigation controller, for some weird reason.

Note that this method will affect all bars in your app. If you only want some bars to be transparent, you’ll need to do a little objc-hocus-pocus. Thanks to Mike Ash for this solution on method replacement (read that article for the whys and hows). This technique replaces the default methods as before, but keeps track of the defaults. If you now set the tintColor of the bar to [UIColor clearColor], the bar will have a transparent background. Otherwise, it’ll just look the same as usual.

For UIToolbar (same principle for UINavigationBar):

#import <objc/runtime.h>
 
// Keep track of default implementation
static void (*_origDrawRect)(id, SEL, CGRect);
static void (*_origDrawLayerInContext)(id, SEL, CALayer*, CGContextRef);
 
// Override for drawRect:
static void OverrideDrawRect(UIToolbar *self, SEL _cmd, CGRect r) {
    if ( [[self tintColor] isEqual:[UIColor clearColor]] ) {
        // Do nothing
    } else {
        // Call default method
        _origDrawRect(self, _cmd, r);
    }
}
 
// Override for drawLayer:inContext:
static void OverrideDrawLayerInContext(UIToolbar *self, SEL _cmd, CALayer *layer, CGContextRef context) {
    if ( [[self tintColor] isEqual:[UIColor clearColor]] ) {
        // Do nothing
    } else {
        // Call default method
        _origDrawLayerInContext(self, _cmd, layer, context);
    }
}
 
 
@implementation UIToolbar (TransparentAdditions)
 
+ (void)load {
    // Replace methods, keeping originals
    Method origMethod = class_getInstanceMethod(self, @selector(drawRect:));
    _origDrawRect = (void *)method_getImplementation(origMethod);
 
    if(!class_addMethod(self, @selector(drawRect:), (IMP)OverrideDrawRect, method_getTypeEncoding(origMethod)))
        method_setImplementation(origMethod, (IMP)OverrideDrawRect);
 
    origMethod = class_getInstanceMethod(self, @selector(drawLayer:inContext:));
    _origDrawLayerInContext = (void *)method_getImplementation(origMethod);
 
    if(!class_addMethod(self, @selector(drawLayer:inContext:), (IMP)OverrideDrawLayerInContext, method_getTypeEncoding(origMethod)))
        method_setImplementation(origMethod, (IMP)OverrideDrawLayerInContext);
}
 
@end

You can now add background texture to the bars in a number of ways. These are two I’ve used:

• By adding a CALayer to [bar layer] — but note that UINavigationBar will try to add elements at index 0, underneath your background. To make this work, I provided a subclassed CALayer (and overrode UINavigationBar’s +layer method) which only lets you insert layers at index 0, via a custom method, and override insertLayer:atIndex: method, setting index to 1 if it’s 0. UIToolbar doesn’t require this.
• Or, by adding a CALayer to your view layer. Note that the view’s bounds do not cover the UINavigationBar; I had to offset the layer by the height of the bar in question (navigationBarLayer.frame = CGRectMake(0, -self.navigationController.navigationBar.frame.size.height, [barImage size].width, [barImage size].height);, for example), and set self.view.clipsToBounds = NO to allow the layer to be seen.

Of course, you can also draw the texture in drawRect:, instead. It’s entirely up to you. The advantage in using a CALayer is that it can overlap the view boundary, for effects like drop shadows.

• Implementing iBooks page curling using a conical deformation algorithm Excellent summary of how to implement a convincing page turn animation in OpenGL
• Multiplottr.com — Plot, save and share multiple locations on your own customized maps. Batch plot multiple addresses
• gmaps.kaeding.name :: Plot multiple locations on Google Maps Enter addresses, one per line, to plot all entries on a map at once
• Free iPhone App Marketing — Online and iPhone Marketing Includes a useful list of review sites, blogs, etc.

Talkie is my newest product, a Walkie Talkie for iPhone and Mac.

In Part 1 of this series, I wrote about basic broadcasting. This works fine with one network device, but it’s worth discussing how to send through all devices, so you can communicate with others connected via, say, Ethernet and WiFi simultaneously.

So, in Part 2 I’ll write about the approach I took in Talkie for broadcasting from all network devices (a.k.a. network interfaces), so that one can communicate with others connected via WiFi, Ethernet (on a Mac), and any other network devices simultaneously.

Bind them

From Part 1, we have a working broadcast mechanism, but it will only send through the default interface — whatever you’re connected to the network via. This is often sufficient, but if you have more than one device that you communicate through, like Ethernet and WiFi, then you will find that it only works with one.

In order to send through all your connected network interfaces, we need to create one socket for each interface, and bind the socket to its corresponding interface.

Here’s how:

First, we need to obtain a list of all network interfaces with getifaddrs.

#include <ifaddrs.h>
...
struct ifaddrs *addrs;
int result = getifaddrs(&addrs);
if ( result < 0 ) {
  // Error occurred
  return 0;
}

Now, addrs is a list of interfaces that we can iterate over. We now do so, picking out those devices that support broadcasting, and that aren’t loopback or point-to-point devices — loopback is an internal interface that is provided for your computer’s inner dialogue, and point-to-point (ppp) devices include dialup interfaces, 3G modems and the like. We can exclude those guys.

const struct ifaddrs *cursor = addrs;
while ( cursor != NULL ) {
  if ( cursor->ifa_addr->sa_family == AF_INET 
          && !(cursor->ifa_flags & IFF_LOOPBACK) 
          && !(cursor->ifa_flags & IFF_POINTOPOINT) 
          &&  (cursor->ifa_flags & IFF_BROADCAST) ) {
 
    // We will do some stuff in here
 
  }
  cursor = cursor->ifa_next;
}

Now, for each interface that meets our criteria, we create a socket (which we covered in Part 1), then bind the socket to the network interface, to force transmission from that particular device. Finally, as we did in Part 1, we enable broadcasting using setsockopt with SO_BROADCAST.

We want to store the sockets we create in an array, so we can access them later. If we assume a maximum number of interfaces we will support (lets call it kMaxSockets), we can just use an array of that length. So, putting it together:

#define kMaxSockets 16
...
int sock_fds[kMaxSockets];
int number_sockets = 0;
 
while ( cursor != NULL && number_sockets < kMaxSockets ) {
  if ( cursor->ifa_addr->sa_family == AF_INET 
          && !(cursor->ifa_flags & IFF_LOOPBACK) 
          && !(cursor->ifa_flags & IFF_POINTOPOINT) 
          &&  (cursor->ifa_flags & IFF_BROADCAST) ) {
 
    // Create socket
    sock_fds[number_sockets] = socket(AF_INET, SOCK_DGRAM, 0);
    if ( sock_fds[number_sockets] == -1 ) {
      // Error occurred
      return 0;
    }
 
    // Create address from which we want to send, and bind it
    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr = ((struct sockaddr_in *)cursor->ifa_addr)->sin_addr;
    addr.sin_port = htons(0);
 
    int result = bind(sock_fds[number_sockets], (struct sockaddr*)&addr, sizeof(addr));
    if ( result < 0 ) {
      // Error occurred
      return 0;
    }
 
    // Enable broadcast
    int flag = 1;
    result = setsockopt(sock_fds[number_sockets], SOL_SOCKET, SO_BROADCAST, &flag, sizeof(flag));
    if ( result != 0 ) {
      // Error occurred
      return 0;
    }
 
    number_sockets++;
  }
  cursor = cursor->ifa_next;
}

Finally, as before, we can setup a broadcast address to send to, and use sendto to broadcast, this time for each socket we created:

// Initialise broadcast address
struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_BROADCAST;
addr.sin_port = htons(kPortNumber);
 
// Send through each interface
int i;
for ( i=0; i<number_sockets; i++ ) {
  int result = sendto(sock_fds[i], data, length, 0, (struct sockaddr*)&addr, sizeof(addr));
  if ( result < 0 ) {
    // Error occurred
    return 0;
  }
}

Note that the receive routine only needs a single socket, as we can receive on any interface when we use INADDR_ANY. So, the receive routine needs no changes from the single-interface version we saw in Part 1.

Here’s the test app with the above modification: broadcast_sample_all_interfaces.c

Again, compile by opening Terminal, and typing make broadcast_sample_all_interfaces or cc -o broadcast_sample_all_interfaces broadcast_sample_all_interfaces.c, then run it with ./broadcast_sample_all_interfaces "Message to send" to send, or just ./broadcast_sample_all_interfaces with no arguments to listen.

You may notice that multiple messages may be received: These have probably arrived via multiple network interfaces, virtual or otherwise. It’s usually a good idea to check for duplicate messages, if this is an issue for program operation, by including a sequence number into the message — this will be discussed in Part 3.

It also may be a good idea to ignore your own messages, which may find their way back to you. One way to accomplish this is to examine the source address (addr in the example above) and compare it with your local interface addresses (stored in addrs, above). If you get a match, the message came from you, and you can drop it.

Multicast

Broadcast is fine when everyone on the local network is interested in what you have to say. If this isn’t the case, though (lets face it, those Chuck Norris jokes aren’t for everyone), effort is wasted delivering to those who aren’t particularly interested.

Multicast works by using a specific address that one ‘subscribes’ to in order to receive messages sent to that address. So, it’s opt-in, allowing for better efficiency and one day, Internet-wide support for ‘to-many’ communications.

Well, in theory. Actually, multicast is still quite new, and for the most part — from what I understand — it behaves pretty much like broadcast on a local area network. However, support can only increase, and given that many services already use it — Multicast DNS (mDNS), also known as Bonjour, being one of the most well-known examples — it seems a good idea to follow their lead. Note also that IPv6, the successor to IP as we know it, and our saviour-to-be from our little Internet overpopulation problem (among other things), doesn’t even have broadcast provisions — the future is all multicast.

So, for these reasons, Talkie speaks multicast, instead of plain ol’ broadcast.

Making use of multicast is relatively straightforward: To receive, you join a multicast group using setsockopt with IP_ADD_MEMBERSHIP, and the address of the multicast group, which is in the range 224.0.0.0-239.255.255.255 (for IPv4, of course). To send, you just use sendto to transmit data to a multicast group address.

Using multicast on all network interfaces is just a little more complicated. Here’s how it’s done with Talkie:

Sending

The send routine is very similar to the one above, using broadcast. However, instead of using bind to specify the outgoing network interface and enabling broadcast, we assign a multicast interface using setsockopt with IP_MULTICAST_IF. And, instead of transmitting to the broadcast address, we transmit to the multicast group address.

Again, we loop through all network interfaces. This time, we pick out those that support multicast (ifa_flags & IFF_MULTICAST):

const struct ifaddrs *cursor = addrs;
while ( cursor != NULL ) {
  if ( cursor->ifa_addr->sa_family == AF_INET 
          && !(cursor->ifa_flags & IFF_LOOPBACK) 
          && !(cursor->ifa_flags & IFF_POINTOPOINT) 
          &&  (cursor->ifa_flags & IFF_MULTICAST) ) {
 
    // We will do some stuff in here
 
  }
  cursor = cursor->ifa_next;
}

And, after creating the socket, we assign the interface:

if ( setsockopt(sock_fds[number_sockets], IPPROTO_IP, IP_MULTICAST_IF, &((struct sockaddr_in *)cursor->ifa_addr)->sin_addr, sizeof(struct in_addr)) != 0  ) {
  // Error occurred
  return 0;
}

Finally, as a nicety, we can disable loopback so that we don’t receive our own messages. This isn’t 100% reliable, as certain network conditions can result in the local machine still receiving its outgoing messages, but it can improve efficiency:

u_char loop = 0;
if ( setsockopt(sock_fds[number_sockets], IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop)) != 0 ) {
  // Error occurred
  return 0;
}

Now that our sockets are set up, we can prepare to send to the multicast address:

#define kMulticastAddress "224.0.0.123"
...
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr(kMulticastAddress);
addr.sin_port = htons(kPortNumber);

And, as before, we send through each of the sockets we created:

int i;
for ( i=0; i<number_sockets; i++ ) {
  if ( sendto(sock_fds[i], data, length, 0, (struct sockaddr*)&addr, sizeof(addr)) < 0 ) {
    // Error occurred
    return 0;
  }
}

Receiving

Receiving messages from a multicast group on several network interfaces is a little more involved than doing so with broadcast: We need to subscribe to the multicast group from each network interface, explicitly. If we were to just specify no device in particular, the system would choose a single interface for us, neglecting the others.

Joining the multicast group for each interface takes place in a now-familiar loop:

const struct ifaddrs *cursor = addrs;
while ( cursor != NULL ) {
  if ( cursor->ifa_addr->sa_family == AF_INET 
          && !(cursor->ifa_flags & IFF_LOOPBACK) 
          && !(cursor->ifa_flags & IFF_POINTOPOINT) 
          &&  (cursor->ifa_flags & IFF_MULTICAST) ) {
 
    // We will do some stuff in here
 
  }
  cursor = cursor->ifa_next;
}

For each network device, we use the IP_ADD_MEMBERSHIP property with setsockopt to join — thereby subscribing to any messages sent to the multicast group address that reach that network interface.

First, we prepare the join request structure. This provides the multicast group address, and the network interface:

struct ip_mreq multicast_req;
memset(&multicast_req, 0, sizeof(multicast_req));
multicast_req.imr_multiaddr.s_addr = inet_addr(kMulticastAddress);
multicast_req.imr_interface = ((struct sockaddr_in *)cursor->ifa_addr)->sin_addr;

Now we use this structure to join the group:

if ( setsockopt(sock_fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &multicast_req, sizeof(multicast_req)) < 0 ) {
  // Error occurred
  return 0;
}

Now, a caveat: While it’s perfectly legal to join the same multicast group on more than one network interface, and up to 20 memberships may be added to the same socket (see ip(4)), for some reason, OS X spews ‘Address already in use’ errors when we actually attempt it.

As a workaround, we can ‘drop’ the membership first, which would normally have no effect, as we have not yet joined on this interface. However, it enables us to perform the subsequent join, without dropping prior memberships.

So, before we perform the above IP_ADD_MEMBERSHIP, we do a IP_DROP_MEMBERSHIP first:

setsockopt(sock_fd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &multicast_req, sizeof(multicast_req));

This sets up our socket to receive messages sent to the multicast group that are received via any interface.

Here it is all put together: multicast_sample.c

Compile by opening Terminal, and typing make multicast_sample or cc -o multicast_sample multicast_sample .c, then run it with ./multicast_sample "Message to send" to send, or just ./multicast_sample with no arguments to listen.

Still to come

So, now we mostly have networking covered. There’s one obvious omission, though, for an iPhone app: Bluetooth. In Part 3, I’ll discuss how to perform communications over Bluetooth on the iPhone, in a way that’s compatible with the above generic network communications. I’ll also talk about how to connect to other devices automatically, without user intervention — This is one particularly popular feature of Talkie that allows it to behave more like a real walkie-talkie.

I promised in Part 1 that I’d talk about packet formats. We’ve covered a lot of ground in Part 2, however, so it shall be postponed to Part 3 — I’ll discuss how to ensure you get messages in the correct order by using sequence numbers, as well as providing for versioning and a few other bits and pieces.

I couldn’t figure out how to easily open up my databases, other than manually creating a managed object model, then a persistent store coordinator, then a managed object context on the console. I couldn’t find any existing tools, and I wanted a quick workflow for opening up my databases, so I put together a script that prompts for the application bundle or .xcdatamodel data model file, then prompts for the XML (.xml), binary (.binary) or SQLite (.sql or anything else) database file, and opens up the inspector.

I wrote it as an Applescript that just calls upon F-Script to evaluate the script, and saved it in an application bundle so I can pull it up quickly.

Here it is:

Core Data Browser.app

It just needs the F-Script app to be available.

Upon opening, the managed object context is available on the console as “context“. So, aside from using F-Script’s object browser, you can also do things like:

> request := (NSFetchRequest alloc) init
> request setEntity:(NSEntityDescription entityForName:'MyEntity' inManagedObjectContext:context)
> request setPredicate:(NSPredicate predicateWithFormat:'type = 3')
> result := context executeFetchRequest:request error:nil
> result
_PFArray {<NSManagedObject: 0x2006cf740> (entity: MyEntity; id: 0x20064c9e0 <x-coredata://BAC82A67-CC41-48C2-8A96-693B67A501D6/MyEntity/p1> ; data: <fault>), 
<NSManagedObject: 0x2006bdc80> (entity: MyEntity; id: 0x20064c9c0 <x-coredata://BAC82A67-CC41-48C2-8A96-693B67A501D6/MyEntity/p2> ; data: <fault>), 
<NSManagedObject: 0x2006bc680> (entity: MyEntity; id: 0x200651180 <x-coredata://BAC82A67-CC41-48C2-8A96-693B67A501D6/MyEntity/p3> ; data: <fault>)
...

Update: Now has better error reporting, and the option to load classes from a bundle.

For those interested, here’s the original F-Script:

panel := NSOpenPanel openPanel.
panel setAllowedFileTypes:{'xcdatamodel', 'app', 'framework'};setTitle:'Data model';setMessage:'Select a data model file or bundle containing a data model'.
classesButton := (NSButton alloc) initWithFrame:(0<>0 extent:200<>30).
classesButton setTitle:'Load classes in bundle';setButtonType:NSSwitchButton.
panel setAccessoryView:classesButton.
model := nil.
[model == nil] whileTrue:[
	error := FSPointer objectPointer.
	(panel runModal = NSFileHandlingPanelCancelButton) ifTrue:[ (NSException exceptionWithName:'CancelException' reason:'Cancelled' userInfo:nil) raise ] .
	(((panel URL) absoluteString) hasSuffix:'xcdatamodel') ifTrue:[
		model := ((NSManagedObjectModel alloc) initWithContentsOfURL:(panel URL))
	] ifFalse:[
		bundle := (NSBundle bundleWithURL:(panel URL)).
		(bundle == nil) ifFalse:[
			model := (NSManagedObjectModel mergedModelFromBundles:{bundle}).
			(model ~~ nil & (FSBoolean booleanWithBool:(classesButton state) = NSOnState)) ifTrue:[
				(FSBoolean booleanWithBool:(bundle loadAndReturnError:error)) ifFalse:[
					model := nil.
					(NSAlert alertWithMessageText:'Could not load bundle' defaultButton:'OK' alternateButton:nil otherButton:nil informativeTextWithFormat:((error at:0) localizedDescription)) runModal
				]
			]
		]
	].
	(model == nil & ((error at:0) == nil)) ifTrue:[ (NSAlert alertWithMessageText:'Could not load model from file or bundle' defaultButton:'OK' alternateButton:nil otherButton:nil informativeTextWithFormat:'') runModal ]
].
panel setAccessoryView:nil.
store := ((NSPersistentStoreCoordinator alloc) initWithManagedObjectModel:model).
panel setAllowedFileTypes:nil; setTitle:'Database file';setMessage:'Select Core Data SQLite database'.
opened := nil.
[opened == nil] whileTrue:[
	(panel runModal = NSFileHandlingPanelCancelButton) ifTrue:[ (NSException exceptionWithName:'CancelException' reason:'Cancelled' userInfo:nil) raise ] .
	type := NSSQLiteStoreType.
	((((panel URL) absoluteString) lowercaseString) hasSuffix:'xml') ifTrue:[type := NSXMLStoreType].
	((((panel URL) absoluteString) lowercaseString) hasSuffix:'binary') ifTrue:[type := NSBinaryStoreType].
	error := FSPointer objectPointer.
	opened := (store addPersistentStoreWithType:type configuration:nil URL:(panel URL) options:nil error:error).
	(opened == nil) ifTrue:[ (NSAlert alertWithMessageText:'Could not load database' defaultButton:'OK' alternateButton:nil otherButton:nil informativeTextWithFormat:((error at:0) localizedDescription)) runModal ]
].
context := ((NSManagedObjectContext alloc) init).
context setPersistentStoreCoordinator:store.
context inspectWithSystem:sys

cell.imageView.layer.masksToBounds = YES;
cell.imageView.layer.cornerRadius = 5.0;

Set this up when you create the cell (make sure you #import <QuartzCore/QuartzCore.h> at the top, of course). It would appear the UIImageView control creates sublayers to display the actual image content, which is why we use the masksToBounds property to then clip any sublayers.

I noticed a lot of people are seeking answers to the silly behaviour of UITableView with the grouped (UITableViewStyleGrouped) style and images:

Images don’t get clipped to the rounded cell border, which looks nasty. This technique is one way to remedy that:

One caveat – due to the inexplicable way the image view within the table view cell scales image content, there’s not really a simple, sensible way to provide an inset margin from the table view cell boundary to complement this rounded border effect.

I tried setting the frame property of the UIImageView itself (cell.imageView.frame), as well as setting the frame of the image view’s layer. I also tried applying a scale transform to the layer, with strangely inconsistent results: Setting scale to, say, 50%, made the image view 40x40px, only a pixel or two smaller than the full size. This may be because another entity (the table view cell?) performs scaling of the content, instead of the actual image view; given that my original image was 80×80, a 50% scale would result in 40×40.

My solution was to steer clear of that nonsense and just provide appropriately scaled images straight to the image view. Here’s a simple category on UIImage to scale an image:

@interface UIImage (TPAdditions)
- (UIImage*)imageScaledToSize:(CGSize)size;
@end
 
@implementation UIImage (TPAdditions)
- (UIImage*)imageScaledToSize:(CGSize)size {
    UIGraphicsBeginImageContext(size);
    [self drawInRect:CGRectMake(0, 0, size.width, size.height)];
    UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
    return image;
}
@end

So, then I just do something like this in the UITableView data provider:

UIImage *image = account.image;
if ( image ) {
   cell.image = [image imageScaledToSize:CGSizeMake(38, 38)];
}

Sorted.

Talkie is my newest product, the result of a collaboration with a good designer friend, Tim Churchward, who did the user interface.

Talkie is a little different from many of the other walkie talkie applications on the App Store (aside from the fact that much of it was written by me from our motorhome in Tunisia!), and I thought I’d write a little about some of the tech underpinning the app, and some of the choices we made. Along the way it may get a little tutorial-esque.

• This first part will introduce our initial motivations, and will talk about basic broadcast communications — the broadcast communications part may be very familiar to some, in which case it may be worth skipping to the next instalment.
• In the second part, I’ll continue the theme of networking, and will talk about what I ended up with for Talkie’s network code after addressing a couple of things, including switching to multicast.
• Finally, I’ll talk audio, dual platform development, and anything else I think of along the way (Actually, I’m aching to talk about one particular upcoming feature that had me jumping up and down when I first thought of it, but for now, mum’s the word on that one.)## Inspiration

Right from the start, we wanted a product that brought back the fun walkie talkie experience we remember from our childhoods. I’m talking colourful plastic, whip antennas and hiding in tree-houses. This was mostly Tim’s domain, so I shall leave it to him to discuss how he found that in the user interface.

It also meant stepping back from traditional voice chat, with manual call initialisation and termination and simple one-to-one calls. We wanted to mimic a radio, so that meant broadcasting as soon as you hit “Talk” — whereupon anyone in the neighbourhood would hear you.

Basically, we wanted to get as close to the real thing as was practical. This included the addition of a prominent ‘morse code’ button, of course, as well as a ‘squelch’ control for ‘fine tuning’, which simulated the static of bad reception.

Going dual-platform

Soon after I started developing Talkie, I realised I wanted a version for the Mac too.

Having Talkie both on the iPhone and on the Mac made sense, as we envisioned that a fairly common usage pattern would involve communication between a desktop and a handheld — say, someone wandering a campus with the iPhone in their pocket, staying in touch with friends at their desks.

We wanted to offer good value with Talkie, which is why we made Talkie for Mac available for free, when it’s used with Talkie for iPhone.

One of the very convenient things about developing for both iPhone and Mac is that the platforms are so similar, porting code is usually effortless. So, going dual-platform was an easy decision.

Finding common ground

The result of all of this was the need to develop or find a communication protocol and codec that would work across the iPhone and the Mac, over both Bluetooth for iPhone-iPhone communication, and Wifi, for communication between iPhones and iPhones, and iPhones and Macs.

Version 3.0 of the iPhone SDK introduced the GameKit framework and as part of it, GKVoiceChatService, which provides two person voice chat straight out of the box. Immediately it was clear that it wouldn’t serve our purposes — two person is not broadcast. I was also keen to provide a Mac version of Talkie, and given that GameKit is iPhone-only, it was time to go off the beaten track.

There are a variety of voice communication protocols out there, with varying licences and varying complexity and feature sets. I could’ve spent a week or two researching the options and evaluating them against our need for broadcast functionality, figuring out compilation and linking on the iPhone, resolving any compatibility or performance issues that arose, etc.

Or, I could spend a day putting together a few big building blocks provided by Apple (and the underlying Unix system) and have an easily tweakable working solution that precisely meets our needs and provides for future features.

It may not have been the most scientific approach, but the core of Talkie’s functionality was up and running on our home wi-fi network within about four hours, and it was working well.

Getting from a to b (and c, d, e, and f)

For those unfamiliar with the ins and outs of TCP/IP (the most common communication protocol — or rather, set of protocols — between computers, and the fundamental building block of the Internet), communication between computers can be connection-oriented, or connectionless.

Connection-oriented (a.k.a. ‘reliable’) communications are most common: They’re used when you open up a website, connect to iChat, or check your email. This is the TCP part of TCP/IP, and includes niceties like built-in guaranteed delivery via retransmission (providing your cat hasn’t eaten your network cable, of course) and packet ordering so you receive the messages in the right order. This only works between two computers, though – you and the server.

Connectionless (or ‘unreliable’) communications are much more open — it’s basically just a spray of messages: The data isn’t carefully ushered along, it’s just spat out and left to fend for itself. This is UDP, and is commonly used for time-sensitive applications like audio communication, network gaming, etc., where once a packet arrives late, it’s useless: No point mucking about re-sending lost data that’s going to be past its use-by date by the time it arrives. The other thing about UDP is that, because there’s no co-operation required from the destination (to acknowledge receipt, etc.), it lends itself to one-to-many communications — broadcast.

Just what we’re after.

So, we use connectionless communications (UDP) to send messages containing the audio, and anyone who receives them unpackages and plays the audio within.

The basic mechanics of this are fairly simple, once you get past the arguably cryptic C syntax.

Here’s how it works.

Sending

On the transmission end, on startup, you create a socket using the socket call:

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
...
int sock_fd = socket(AF_INET, SOCK_DGRAM, 0);
if ( sock_fd < 0 ) {
   // Error occurred
}

The socket, identified by sock_fd, will be created using the IPv4 domain (AF_INET), a ‘datagram’ type (SOCK_DFRAM: that’s connectionless communication — if we wanted connection-oriented, we could put in SOCK_STREAM here instead), using protocol 0, which is IP.

Then, we enable broadcasting:

int flag = 1;
int result = setsockopt(sock_fd, SOL_SOCKET, SO_BROADCAST, &flag, sizeof(flag));
if ( result < 0 ) {
   // Error occurred
}

That is, we set the SO_BROADCAST option at the SOL_SOCKET level to 1 (via the flag variable, which we pass in as a pointer), thereby requesting permission from the operating system kernel to broadcast.

Now we have the carrier pigeon coop at our disposal, we can start dispatching pigeons. First, we fill out the address:

#define kPortNumber 1234
...
struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_BROADCAST;
addr.sin_port = htons(kPortNumber);

(Note, htons converts kPortNumber into a format that can be understood by any computer, regardless of the way it represents numbers internally.)

Now, send:

NSData *dataToSend;
result = sendto(sock_fd, [data bytes], [data length], 0, (struct sockaddr*)&addr, sizeof(addr));
if ( result < 0 ) {
   // Error occurred
}

Receiving

That takes care of outgoing messages. To receive them, we want another socket:

int sock_fd = socket(AF_INET, SOCK_DGRAM, 0);
if ( sock_fd < 0 ) {
   // Error occurred
}

Now we specify where we want to receive messages from, by ‘binding’ the socket:

struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_port = htons(kPortNumber);
result = bind(sock_fd, (struct sockaddr*)&addr, sizeof(addr));
if ( result < 0 ) {
  // Error occurred
}

And we pass a buffer to recvfrom to fill up with tasty morsels of data:

#define kBufferSize 1024
...
char buffer[kBufferSize];
int addr_len = sizeof(addr);
int bytes_received = recvfrom(sock_fd, buffer, kBufferSize, 0, (struck sockaddr*)&addr, &addr_len);
if ( bytes_received < 0 ) {
   // Error occurred
}

Voila, we have bytes_received bytes sitting in buffer for us to do something with. Note also that addr now also contains the address of the sender. Now we can loop and continue to receive data as it comes in, passing the data off to some other part of the application to deal with.

We can put it all together into a simple test app: broadcast_sample.c

Compile it by opening up Terminal, and typing make broadcast_sample (or cc -o broadcast_sample broadcast_sample.c, if you like), then run it with ./broadcast_sample "Message to send", or just ./broadcast_sample to listen.

$ ./broadcast_sample 
Listening...
Hello world!

$ ./broadcast_sample 'Hello world!'
"Hello world!" transmitted.

Coming next

This will work happily between computers with just one network interface. But, if you have more than one (say, wireless, and an Ethernet connection too), you’ll notice that it will only communicate through one of the interfaces. That’s because just the default interface is used. You have to explicitly attend to each interface, to broadcast out of each one, and listen on each one.

In the next part of this series, I’ll write about how I addressed that, and about multicast, which is used in things like Bonjour (MDNS). I’ll also write about designing packet formats.

Thanks for reading!

• GPS Visualizer: Draw a map from a GPS data file Batch map plotter using GPS co-ordinates
• Map multiple locations by address Very well-implemented free batch geocoder; accepts only address data, no GPS co-ordinates, but still excellent for some applications
• iPhone: Custom font loading
• Implementing Your Own Cocoa Bindings « Tom Dalling

I just got coverage working too, thanks to a useful article at SuperMegaUltraGroovy on how to use code coverage with XCode. There were a couple of caveats that I thought I’d share, though.So, to repeat SMUG’s instructions:

1. Set up unit testing
2. Create a new build configuration (‘Coverage’), duplicated from the ‘Debug’ configuration
3. Open up build settings for the main target, make sure your new configuration is selected, and:
   • Enable “Generate Test Coverage Files”
   • Enable “Instrument Program Flow”
   • Add “-lgcov” to “Other Linker Flags”

SMUG proposes some commands to append to the “Run Script” build phase of the unit test target, in order to generate the coverage report and output a summary to the build results (see the original article). I made some modifications to aid readability. So, instead, I added the following to the “Run Script” phase of the unit test target:

# Run gcov on the framework getting tested
if [ "${CONFIGURATION}" = 'Coverage' ]; then
     TARGET_NAME="My Application"
     OBJ_DIR=${OBJROOT}/${TARGET_NAME}.build/${CONFIGURATION}/${TARGET_NAME}.build/Objects-normal/${CURRENT_ARCH}
     mkdir -p Coverage
     pushd Coverage
     find "${OBJROOT}" -name *.gcda -exec gcov -o "${OBJ_DIR}" {} \; 2>/tmp/gconv-stderr | egrep "^File|^Lines" | sed -E "s@File '$SRCROOT/@@;s@(\.[a-zA-Z])'@\1: @;s@Lines executed:([0-9.%]+) of ([0-9]+)@\1 (\2)@" | paste -d" " - - | egrep -v "^File '" | sed -E "s@^([^:]+):([^(]*)(\([^)]+\))@\2:\1\3@" | sort -n | sed -E "s@^([^:]+):([^(]*)(\([^)]+\))@\2:\1\3@"; cat /tmp/gconv-stderr | grep -v "version.*, prefer.*"; rm /tmp/gconv-stderr
     popd
fi

This orders the results by coverage percentage, reformats the output to be a bit terser and more readable, and suppresses some unnecessary warnings about GCC 4.0 (see below).

Finally, using XCode 3.2 on Snow Leopard (Mac OS X 10.6), I found that there were a few issues. Using any SDK other than 10.6 results in build errors:

“vproc_transaction_begin”, referenced from:
__gcov_init in libgcov.a(_gcov.o)
_vproc_transaction_begin$non_lazy_ptr in libgcov.a(_gcov.o)
“_vproc_transaction_end”, referenced from:
_gcov_exit in libgcov.a(_gcov.o)
_vproc_transaction_end$non_lazy_ptr in libgcov.a(_gcov.o)
ld: symbol(s) not found

The solution I found in the Apple lists archives is to use the same SDK as the OS: 10.6 (Project menu, Set Active SDK, 10.6).

After fixing this, I was getting dubious-looking results – mostly 0.00% code coverage except for a few random files. The suggestion for this was to use GCC 4.0 instead of the default 4.2 (edit build settings for the main target, and probably the unit test target too, and select “GCC 4.0″ under “C/C++ Compiler Version”).

After a clean and rebuild, I’m getting proper results.

Phew.

• Ten logo design tips from the field | Logo Design Love
• 10 astonishing CSS hacks and techniques
• Adaptive CSS-Layouts: New Era In Fluid Layouts? effective techniques to create 100%-functional adaptive CSS-layouts
• WordPress Theme Development Frameworks If you build and develop WordPress themes often, you will probably be fed up of all the repetitive code writing, the constantly checking of your mark-up and all you really want to do is focus on the design and the project-specific features. The answer is a WordPress development framework
• How to Draw Pixel-Perfect iPhone Toolbar Icons Using OmniGraffle

• 49 Decent Virtual Assistant & Personal Outsourcing Resources
• PHP: Display Adobe PSD files on a web page "Any webdesigner know the PSD filetype, which is the Adobe Photoshop format. PSDs have a lot of great features, as such as layers, but they can’t being read by a browser. Unless you use this great PHP class!"
• Iconfinder – Icon Search Made Easy
• Typetester – Compare fonts for the screen
• KNAppGuide KNAppGuide is a Cocoa framework for embedding “guides” into your application, visually inspired by Apple Guide from the System 7 and 8 era

• XSD Schema XML Validator A XSD Schema validator in Java, provides lots of useful information; use it with a schema and an xml instance
• Three20 Three20 is a collection of iPhone UI classes, like a photo viewer, and general utilities, like an HTTP disk cache. Three20 is derived from the Facebook iPhone app, which is one of the most downloaded iPhone apps ever.
• CSS Decorative Gallery …How to decorate your images and photo galleries without editing the source images. The trick is very simple. All you need is an extra <span> tag and apply a background image to create the overlaying effect.
• Comet (programming) – Wikipedia, the free encyclopedia Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it
• Cocoa Is My Girlfriend » Cocoa Tutorial: awakeFromNib vs applicationDidFinishLaunching A very good overview of the 'startup' procedure for objects stored in IB nib/xibs.

For example:

This is a PHP framework that uses the common GD library to manipulate images.

It’s main interface is a content filter – give it HTML, containing images, and it will return the same HTML modified so that the images are now the converted versions, according to their ‘class’ attributes, with appropriate width/height attributes, etc. This makes it super easy to work with.

It stands alone, but it is also going to be a WordPress plugin (as you can see on this site, it’s already operational), a Joomla plugin, and I’m considering establishing a web service too, so those who don’t have adequate software on their server can still use it.

It has a plugin-based architecture so anyone can add new ‘themes’ (props to my partner Katherine for that beautiful wooden frame, by the way). I’m going to also implement a simple XML-based plugin schema, and possibly an interface to it, so that it’s easy to do so. I’m planning a ‘community’ style directory site to host contributed styles.

The base frame rendering code is such that it is trivially easy to add a new ‘theme’. It extracts segments from a single frame image, and handles seamless tiling to make the frame the right dimensions, so you don’t even have to worry about overlapping regions.

I will release it soon, after adding a little more content – keep your eyes peeled.

For now, check out the Michaelangelo showcase, which gives an idea of the different styles, and contains an interactive sampler to play with styles (IE users should stop being IE users to view this).

Doing my bit to beautify the web.

imagecopy($image, $frame, 
          ($x=max($width-$this->topRightCap[kCapWidth], $this->topLeftCap[kCapWidth])), // Destination x
          0,  // Destination y
          $x,  // Source x
          0,  // Source y
          min($this->topRightCap[kCapWidth], $width-$this->topLeftCap[kCapWidth]),  // Source width
          $this->topRightCap[kCapHeight]); // Source height

The only thing is, it looks terrible and is very hard to read. I usually carefully insert spaces before the comments so they line up, but that’s really hard to maintain.

I use Textmate, and found an ‘Align Assignments’ script by Chris Poirier which applies very nice formatting to a block of assignments.

Some trivial modifications resulted in a similar script to align comments. Hit Ctrl-Option-Command-/, and:

imagecopy($image, $frame, 
          ($x=max($width-$this->topRightCap[kCapWidth], $this->topLeftCap[kCapWidth])), // Destination x
          0,                                                                            // Destination y
          $x,                                                                           // Source x
          0,                                                                            // Source y
          min($this->topRightCap[kCapWidth], $width-$this->topLeftCap[kCapWidth]),      // Source width
          $this->topRightCap[kCapHeight]);                                              // Source height

Here it is:

Align Comments.tmCommand.zip

• CSS Code Snippets : 15 Wicked Tricks Some useful CSS tricks; of particular interest: cross-platform min-height, a trick to clear floats (without needing a 'clearing' div), and page breaks
• 45+ New jQuery Techniques For Good User Experience Here are over 45 impressive jQuery plug-ins and techniques that have been recently created and that could make the development of your next website an easier and more interesting experience than the last.
• How to Create a Disk Image Installer for Apple Mac OS X
• Cocoa: Sidebar with Badges, Take 2 'Source list'-esque sidebar with support for badges
• soultravelers3 A family of three from Santa Cruz, California on an epic odyssey: open-ended, years long slow trip around the world as a family adventure, unschool, spiritual journey and lifestyle.

Highlights from this interview include: From UIView to OpenGL: the seven different implementations it took to finalize its unique — and Best App Ever award-nominated — UI. From audio-queues to Remote IO: the four different architectural approaches he tried before finalizing audio subsystems. The travails of trying to implement echo cancelation. The business of making a living off of a $10 app

Listen to it here, or subscribe in iTunes (30 min.)