MSDN Magazine - December 2008 - (Page 113)

MarCus PerryMan GoinG Places How Connection Manager Connects I remember it was day three of the conference. I was again sitting in an icy blast of air-conditioning, my mind slightly fuzzy from two previous days of information overload—and maybe being a little too late leaving the bar the night before—listening to the lead PM expound the wonders of the all-new Connection Manager technology. I came out thinking, what’s the point of all that? I mean, who needs a technology that tells me if my device is connected? At the time, connectivity was only possible via umbilical cables or colossal appendages that required a PhD in network protocol analysis and unending patience to operate: if the users didn’t know that the device was connected, they weren’t qualified to own it! Thankfully technology has moved on, and today the average mobile phone offers such a plethora of exotic radio technologies it could fry the contents of your lunch box at 40 paces. Windows Mobile devices occupy the more generous end of this scale, and married with the Windows CE preemptive multitasking kernel, the foresight of the Connection Manager team has become very evident. Without Connection Manager, for all but the simplest network environments, the only way an application could choose a connection would be by presenting the user with a list and asking him to select one—which puts you back to requiring a PhD in network protocol analysis. Connection Manager neatly moves this problem away from the user—who, after all, just wants the application to work—and makes it the mobile operator and OEM’s problem, reasoning that if they can’t figure it out, the poor user has no hope. There are two main reasons why the correct use of Connection Manager is vital when a Windows Mobile application requires network data. First, it’s not just your code that needs to connect. Many of today’s applications are connected or at least offer some form of online ability to download updates or additional features. This increases the likelihood that two applications will contend for connectivity at some point on the device. For enterprise users using push or poll e-mail solutions, this is almost a certainty. Second, Windows Mobile devices are sold and used around the world. An application that successfully appeals to a global market must navigate any network configuration a mobile operator might con- using Connection Manager correctly is absolutely vital when a Windows Mobile app requires network data. ceivably dream up—and in my experience mobile operators have active imaginations when it comes to network topology! I’m a firm believer that better understanding leads to better use. In this column, I want to pull up the hood and shine a light on some of Connection Manager’s inner workings, specifically looking at how it adds value and removes complexity when connecting over wide-area cell phone networks. This might appear more relevant for C++ developers who commonly call Connection Manager APIs directly. Managed code developers have many classes, such as HttpWebRequest, that use Connection Manager without the developer being directly involved. However, even for .NET developers, understanding how the managed code is powered by Connection Manager hidden under the surface can be useful for resolving complex connection issues. Much of the network complexity is because mobile operators must tread a narrow path among three competing requirements. First, they have customer demand to match the blistering pace of change in radio network technologies. Second, they provide radio coverage to huge geographical regions through a vast infrastructure. And third, they try not to break the bank for their shareholders. One area that highlights the challenge and directly affects software developers is related to Packet Data Protocol (PDP) contexts. A PDP context describes an agreement between a phone handset and the Global System for Mobile Communication (GSM) network and contains important information, such as the Access Point Name (APN) and IP address. This agreement is immutable—once created, it can’t be changed. (A more complete explanation can be found at en.wikipedia.org/wiki/PDP_context.) Before any application can send and receive data, the device must first establish a PDP context by making a request to the base station, sending the name of the desired APN. The request is typically Send your questions and comments to goplaces@microsoft.com. Code download: code.msdn.microsoft.com/mag200812GoingPlaces. December 2008 113 PDP Contexts http://en.wikipedia.org/wiki/PDP_context http://code.msdn.microsoft.com/mag200812GoingPlaces

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.