On top of having to understand
threading, HTTP, and XML you must now also be aware of network details
about how data will be sent and then choose the right transport for the
application. Each transport has strengths and weaknesses such that there
is no single right way to send data over the network. Additionally, as a
developer, you have to determine which transports are available and
then choose which one is the best choice to use for sending data.
There are six types of
transports that are available on a BlackBerry. Each of them can be
specified through one or more connection string directives and all can
be used to carry HTTP data.
Any transport can be used to
send data, but each one has its own set of concerns and restrictions.
The default connection type depends on how your device is configured,
but generally, the default is a good place to start. However, you should
also understand each connection type as well.
Direct TCP/IP
All of the examples that we've done so far have used the Direct TCP/IP
transport. This is because this transport is the easiest to understand
and implement. Using this transport you ignore any servers or gateways
that might be provided by other parties and make the connection by using
standard TCP/IP networking right from the handheld. There is no
additional security or encryption and you can only access servers that
are available publicly on the Internet.
However, because there are no
servers or gateways to get in the way, making this connection should be
the easiest to use. For most carriers, direct TCP/IP traffic is
considered normal data and part of your data plan. There are some
carriers that do not though.
You can force a connection to be made using Direct TCP/IP by specifying deviceside=true in the connection string.
MDS/BES
These two acronyms stand for Mobile Data Services and BlackBerry Enterprise Server.
The BES is a server that is typically installed inside the data center
of a large organization and provides the tight integration with your
corporate e-mail system. If you have a company-issued BlackBerry and you
get company e-mail on it, then chances are good that your company has a
BES installed. The MDS is a component of the BES and is used to route
network traffic through the same secure channel that is used to transfer
messages. You can't really have a BES without with an MDS server as
well, so while they are separate components, for this example, it means
the same thing. If your device is configured to use a BES then the
MDS/BES transport will be the default transport.
When using the MDS
connection to route network traffic you are using the same encrypted and
secure channel that e-mail messages travel on. This secure channel can
be very appealing if the data being transferred needs to be protected.
Also, as the MDS is a component inside your corporate data center, you
can also use this transport to access other services inside your company
network such as application servers or an intranet. This transport is
the only transport that can be used to access internal servers.
Not everyone has a
handheld that works like this. If you purchased your handheld from a
carrier directly, or if you use it to receive messages from a public
service such as Yahoo mail or Gmail, then you probably are using BlackBerry Internet Service
(BIS) instead of BES. BIS is provided by carriers directly and
therefore, does not provide all of the same advantages. The BIS server
also has an MDS component to it so using this transport will be
encrypted and secure to the destination but, in this case, the
destination is the carrier's network center.
You can force a connection to use the MDS transport by specifying deviceside=false
in the connection string. In order to debug an application that uses
the MDS transport you must also be running the MDS simulator. That will
be covered in the next section in more detail.
BIS-B
The BIS-B
transport is mentioned here only for the sake of completeness. It is
the same transport that is used by your carrier's version of the browser
on your handheld and every carrier is required to support it. In order
to use this transport though, you must be a BlackBerry Alliance partner,
which costs a lot of money and requires some high-level agreements with
Research In Motion. In short, it isn't something done by a beginner. If
these requirements are not a hurdle, then using BIS-B is the best
approach, but otherwise, you have to use one of these other types.
Wi-Fi
Some handhelds have Wi-Fi
capabilities and can connect to Wi-Fi hotspots. This feature is highly
desirable for applications which do a lot of network communications
because data sent through Wi-Fi is faster and cheaper than data sent
over the carrier's network.
The downside is that there are a
lot of uncertainties about what the capabilities are of the Wi-Fi
hotspot that you are using. It might be a public Wi-Fi that is not
protected and all of the data being sent or received is therefore
unencrypted and insecure. It might be a hotspot provided by your company
that is secure and has access to the internal networks of your company;
you just don't know and there is no way to find out.
Because of this
uncertainty and the inability to gather this information, Wi-Fi should
be used only when the data needs are high and when there are no concerns
for security of the data. Things such as streaming audio or video are
well-suited for this.
You can force a connection to be made using Wi-Fi hotspot by adding interface=wifi to the connection string. You can use the interface parameter along with the deviceside parameter in the connection string together. This will succeed only if the destination (if deviceside=true) or the MDS Server (if deviceside=false) can be reached successfully through the Wi-Fi hotspot.
WAP
WAP stands for Wireless Application Protocol
and there are actually two versions of WAP to be concerned about. Using
the WAP transport causes the network traffic to be routed through a WAP
gateway that is part of your carrier's network.
WAP 1.X
Version 1.0 and 1.1 are likely to
be the most common transports available on BlackBerry handhelds, but it
does not support all of the connection types such as https.
Furthermore, a host of carrier-specific values must be added to the
connection string. These include gateway address, port, and sometimes
even username and password information. There is no way to get these
values programmatically either. You must know them in advance or prompt
the user for them, and chances are that the user doesn't know them. Even
if you get all of this right, the carrier still might not allow it. WAP
is really intended to be used with WML so the WAP gateway at the
carrier may try to filter out content that is not WML. Because of these
issues, this transport is generally avoided.
WAP 2.0
WAP 2.0 simplifies
things greatly. It still might not be provisioned on the device, but
this can be detected through programming. The WAP 2.0 connection
information is stored in a service book.
This solves the problem of requiring the user to enter a lot of data
that they probably don't know anyway. It is also required to allow
non-WML content through it so that shouldn't be an issue either.
Using WAP 2.0 requires a little code to find the right service book and then the connection string must include ConnectionUID=<uid> as part of the connection string. The<uid>
is a value similar to a GUID and must be found by querying the service
book. The specific value will be different for each user.
