Last week, I expected that I would spend the week writing a phone app. It would be rather easy, in the current state of the AT daemon, to write an app capable of making a call. However, after thinking about how I would actually go about implementing an interface for receiving calls, I realized that the I hadn't actually implemented the necessary features into the AT daemon to do so. While it could detect incoming calls using URCs, it didn't pull in any extra information (like the phone number) necessary for a call handling program. Moreover, it had no mechanism to detect if the person on the other end hung up or answered a call. There is however an AT command which yields information about all calls in any state: AT+CLCC.
To solve this, whenever a URC or IRC issued, we send AT+CLCC and parse the response. Then the daemon compares the response with the previous response, sending updates to the call handler if something has changed. A client can register to receive call change events, and will be sent updates if the state changes. My application of an AT daemon only requires one external program (the call handler) to worry about call updates, so for now (and maybe forever), only one program can be registered to receive call events at a time.
One of the problems that I'm running into now as socket communication gets more
complex is finding the best way to serialize data for transmission over the socket.
Right now, I'm essentially writing serialization code by hand which is
very error prone, but not too painful, given how little data we send. I think for
now, the best way to progress is probably just to extract all the serialization code,
and at least have a common base to use for other programs that communicate with atd.
Hopefully next week we can return to demos with visible progress.