From: "odc" <matthewf@msexchange2k.closedtest.intra>
To: <matthewf@msexchange2k.closedtest.intra>
Subject: test7
Date: Sun, 23 May 2004 17:03:24 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002B_01C440E7.DC075E70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C440E7.DC075E70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


------=_NextPart_000_002B_01C440E7.DC075E70
Content-Type: text/plain;
	name="5kb.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="5kb.txt"

Internet access on the Nokia 9200 Series Communicator is necessarily =
limited by the speed of the phone's GSM connection. As a consequence, =
testing and debugging Internet-based applications on hardware can be =
both expensive and tedious. The RAS IAP application alleviates this =
problem by enabling you to connect to the Internet over a much faster =
serial connection, via your PCThe application demonstrates how the =
Symbian OS Communications database (CommDb) API may be used to configure =
an Internet Access Point (IAP). To some extent it also shows the common =
paradigm for using most DBMS derived APIs.An Internet Access Point =
defines ISP, modem, charge card and location records that can be used =
together to make an Internet connection. The IAP for the RAS connection =
specifies an ISP and modem record (charge card and location records are =
required for this type of IAP). The CommDb is a standard DBMS database. =
Modems, ISPs, charge cards, locations, IAPs etc are all stored in their =
own tables within the database. There may be a number of records within =
each table (e.g., there may be a number of IAPs, modems, ISPs, etc.). As =
described in the preceding section, each IAP record defines the set of =
ISP, modem, charge card, and location that can be used together. In =
other words, an IAP record defines a set of records the other tables.The =
implication of the above statement is that sets of CommDb records are =
accessed through their associated table. The other implication is that =
you cannot create an IAP record until you have already created the other =
records. Finally, the fact that there may be many records in a table =
implies that each record must be uniquely identified.2. Copy an existing =
CommDb that has a correctly configured IAP. This method "works", but has =
several problems. Firstly, Symbian does not guarantee that the CommDb =
will be binary compatible between releases. In practice this has not =
been an issue, but it is something to keep in mind. Secondly, while you =
are using your RAS IAP, you don't have access to IAPs you configured in =
the "real" CommDb. Finally, and most importantly, CommDb configuration =
should be targeted to the platform; The CommDb that you use for RAS =
connections may well disable some of your other phone services.. Add an =
IAP to your existing (proven) CommDb using RAS IAP. The advantage of =
this method is that you get to retain the CommDb that your manufacturer =
put onto the phone, and therefore can expect the device to continue to =
work with the new IAP! Also, the CommDb API is binary compatible between =
releases, so you can rely on this method as you change phone. It is also =
by far the simplest method! Rather than coding the application from =
first principles, I used the standard Minimal Eikon Application =
Developer (MEAD) and Menu Builder tools to create an application that I =
could easily customize. I then modified the engine to write to the =
CommDb, and the UI to call the engine as appropriate. Each of these =
exports calls non-exported functions to actually implement the creation =
and deletion of the components of the IAP. The purpose of each function =
is documented in source, and the code itself is fairly self-documenting. =
Therefore rather than exhaustively re-describing the code, the following =
description discusses the main paradigms that you will see.First of all, =
there are two sequence diagrams present. The first one captures the =
course of events that takesplace when a digit button is pressed. The =
second captures what happens when the user pushes the =91send=92button =
in order to make a call. At the top of each diagram we see the =
rectangles that represent objects. Asin collaboration diagrams, the =
names of the objects are underlined to distinguish them from classes. =
Alsothe object name is separated from the class name by a colon. Some =
objects, like the Dialer, have noparticular object name, so the colon =
precedes the class name without an object name in front of it.objects =
that they are connected to are in existence. In Figure 2, we cannot see =
the full extent of thelifelines; they extend from the very top of the =
diagram to the very bottom. This implies that the objectsportrayed in =
this diagram are in existence before the start of time in the diagram =
and remain in existencebeyond the end of the diagram.The arrows between =
the lifelines represent messages being sent between the objects. =
Sequence umbers, algorithm.Here again we see two sequence diagrams. In =
these diagrams the activation ectangles have been omittedfor clarity4. =
The top diagram shows the normal course of events hen the cellular phone =
receives a call.The CellularRadio object detects the incoming call and =
sounds the ringer. It also tells the Dialler objectthat a call is coming =
in. This puts the Dialler in a special state. When the Send button is =
pushed while theDialler is in this special state, the Dialler sends the =
Answer message to the CellularRadio; thus connectingthe call.
------=_NextPart_000_002B_01C440E7.DC075E70
Content-Type: image/bmp;
	name="beck.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="beck.bmp"

[encoded data, 9804 characters]

------=_NextPart_000_002B_01C440E7.DC075E70--
