Dr. Dobb's Journal September 2001
Bluetooth is an always-on, short-range radio hookup that resides on a microchip. It was initially developed by Swedish mobile-phone maker Ericsson in 1994 as a way to let laptop computers make calls over a mobile phone. Since then, several thousand companies have signed on to make Bluetooth the low-power, short-range wireless standard for a wide range of devices. Industry observers expect Bluetooth to be installed in billions of devices by 2005. The concept behind Bluetooth is to provide a universal short-range wireless capability. Using the 2.4-GHz band, available globally for unlicensed low-power uses, two Bluetooth devices within 10 meters of each other can share up to 720 Kbps of capacity. Bluetooth is intended to support an open-ended list of applications, including data (schedules, telephone numbers, and the like), audio, graphics, and even video. For example, audio devices can include headsets, cordless and standard phones, home stereos, and digital MP3 players.
The Bluetooth Standards present a formidable bulk — well over 1500 pages, divided into core and profile. The core specifications describe the details of the various layers of the Bluetooth protocol architecture, from the radio interface to link control. Related topics are covered, such as interoperability with related technologies, testing requirements, and a definition of various Bluetooth timers and their associated values. The profile specifications are concerned with the use of Bluetooth technology to support various applications. Each profile specification discusses the use of the technology defined in the core specifications to implement a particular usage model.
All three of these recent books — Bluetooth: Connect Without Cables, by Jennifer Bray and Charles Sturman; Bluetooth Revealed, by Brent Miller and Chatschik Bisdikian; and Bluetooth Demystified, by Nathan Muller — attempt to demystify Bluetooth, revealing the technical details of the Bluetooth specifications, and showing how this technology allows user devices to connect without cables. All three are quite technical, as opposed to management oriented. The perspectives of the three books are somewhat influenced by the backgrounds of the authors: Bray and Sturman both are designers working for companies developing Bluetooth products, Miller and Bisdikian were key contributors to the Bluetooth specification, and Muller is a consultant and technical writer.
The three books provide you with a choice in emphasis. The most technically detailed, and the only hardback book, is that of Bray and Sturman. This book spends over 250 pages on the core specifications, with only about 25 on the profiles. The book provides good explanations of the low-level radio interface, including the modulation and frequency hopping schemes. It also covers packet and timing issues in detail as well as link-level issues. In addition, Bray and Sturman include a section on what they refer to as "cross-layer functions," including security, low-power operation, quality of service, and overall device management.
Muller devotes about 100 pages to the core specifications and over 100 to the profile. The usage profile section goes into considerable detail on the protocols required for each application area, and configuration and implementation requirements. The profiles covered include those for intercom, cordless telephony, headset, fax, and LAN access. Miller and Bisdikian devote about 150 pages to the core specifications and over 70 to the profiles. This division more closely reflects the level of detail in the specifications than the other two books.
An important aspect of Bluetooth is security, and Bluetooth includes a lengthy specification that deals with encryption, authentication, and key management. Both the book by Bray and Sturman and that by Muller provide an excellent chapter explaining the key issues. The treatment in Miller's and Bisdikian's is more cursory.
All of these books are clearly written, aimed at a technical audience, and up to date. If you wish to consult just one, your choice will depend on how much interest you have in the core versus the profile aspect of Bluetooth.
— W.S.
You'd be hard pressed to name a programming language, technology, architecture, or whatever C# is that has as much baggage at its debut. Between Sun and Microsoft's long-running spat over Java, and Redmond's continued jousting with the U.S. Department of Justice, there's far more than just the typical interest in this new programming language. Add to that mix Microsoft's excellent track record of getting developers to adopt its tools, the industry's recognition of our irrational exuberance for Java when it was introduced, and our caution about Microsoft's vast .NET scheme, and you have more than enough plots to keep Agatha Christie scribbling for months.
Beyond all this intrigue is the matter of the C# language itself and the chore we programmers face in educating ourselves about it so we can rationally assess how it meets our needs. One of the traditional avenues for that self-education is books, and the first wave of C# titles is beginning to appear. At this point, Eric Gunnerson's A Programmer's Introduction to C# (hereafter APIC) is the first book on this subject I've seen in final form.
Just about anyone who's the least bit interested in C# has heard the one-line summary: It's a Windows-specific version of Java. This isn't strictly true, for numerous obvious reasons, but the two languages are close enough to be first cousins, if not identical twins. Gunnerson recognizes this and does the obvious comparison of C# to other languages, including C/C++, Java, and Visual Basic 6.
Gunnerson, who works at Microsoft and was one of the C# designers, provides mostly the expected material for this kind of book. His 35 chapters cover topics such as the .NET run time, object-oriented programming, and details about the syntax and semantics of C#.
A notable strength of the book is its frequent switch from a descriptive to a normative mode. Gunnerson often talks about design guidelines, and offers suggestions about how to use a language that obviously has no evolved idioms yet, simply because it's new. Similarly, he devotes a chapter to defensive programming and using C#'s unique "conditional methods" feature, as well as asserts and support for tracing. If anything, I found myself wishing for a bit more of this kind of material because it adds an extra and very valuable dimension to the book's content.
While Gunnerson never explicitly says, "Pay attention — this is an area where C# differs from Java," he does give such areas reasonably thorough treatment, for the most part. For example, he devotes individual chapters to structs (basically very lightweight classes); conversions between numeric types and classes; properties; events; delegates; and operator overloading, perhaps the most often requested addition to Java. Unfortunately, he all but ignores unsafe pointers, a C# topic that's received a lot of attention.
The biggest single problem with APIC is one of pedagogy; if anything, it reads too much like a book written by someone who was intimately associated with the C# project and had long ago forgotten what it was like not to know anything about the language. There are many places throughout the book where Gunnerson presents a code sample or issue, then fails to explain it in enough detail to satisfy the obvious questions a newcomer will ask. For example, on page 67 he presents a code sample related to static member functions, then says, "Because it is a static member function, it is called using the name of the class rather than the name of an instance of the class." Is this merely a stylistic issue (meaning you could use the name of an instance of the class instead of the class name), or is it a requirement (using an instance name would be illegal)? The author could have clarified this with slightly different wording or just one or two more sentences, but instead you're left to wonder. This sounds like nitpicking, but it happens so often in the book that it becomes tiring. You often have no choice but to reread code samples and their sparse explanations several times to divine some minor but important detail that shouldn't require nearly that much effort.
A related issue is the overall layout and balance of the book. The basic flow of execution features of C# are left until Chapter 12, long after exception handling, structs, interfaces, and a great deal of object-oriented material have been covered. Similarly, the discussion of basic operators is left until Chapter 14, and the explanation of a program's main() function is in Chapter 26. If Gunnerson felt this material was important, it seems these chapters should have come much earlier in the book; if he felt that experienced programmers wouldn't need this level of hand holding, then the material should have been in an appendix instead of stranded near the middle of the book.
Other oddities include Chapter 13, "Local Variable Scoping," and Chapter 29, "Interop" (by which Gunnerson means calling functions in COM libraries and DLLs), each of which is barely more than one full page of text and code. The "Interop" chapter is particularly bothersome, as Gunnerson gives the process of calling COM-based code no more than one moderate-size paragraph plus one sentence, all very generalized, with no worthwhile detail, code sample, or pointers to other references. That's a disturbingly big topic to wave off in this type of book.
Is A Programmer's Introduction to C# worth your time and money? As economists like to say, it depends. If you have a pressing need to get up to speed with C#, then by all means buy and use the book, but expect to work unusually hard as you climb the learning curve. If you're mildly interested in this new language and want to learn about it more for recreational or general horizon-broadening reasons, wait until some of the other C# books arrive and then do a side-by-side comparison.
— L.G.
DDJ