📄 ch33.htm
字号:
<html>
<head>
<title>Chapter 33 -- Design Considerations for Integrated Communications Applications</title>
<meta NAME="GENERATOR" CONTENT="Microsoft FrontPage 3.0">
</head>
<body TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<!-- Spidersoft WebZIP Ad Banner Insert -->
<!-- End of Spidersoft WebZIP Ad Banner Insert-->
<h1><font COLOR="#FF0000">Chapter 33</font></h1>
<h1><b><font SIZE="5" COLOR="#FF0000">Design Considerations for Integrated Communications
Applications</font></b> </h1>
<hr WIDTH="100%">
<h3 ALIGN="CENTER"><font SIZE="+2" COLOR="#000000">CONTENTS<a NAME="CONTENTS"></a> </font></h3>
<ul>
<li><a HREF="#Introduction">Introduction</a> </li>
<li><a HREF="#GeneralConsiderations">General Considerations</a> <ul>
<li><a HREF="#RulesofComplexity">Rules of Complexity</a> </li>
<li><a HREF="#NativeAPIversusHighLevelTools">Native API versus High-Level Tools</a> </li>
<li><a HREF="#StandaloneversusExtensionsandAddins">Standalone versus Extensions and Add-ins</a>
</li>
</ul>
</li>
<li><a HREF="#MAPIversusCommAPI">MAPI versus Comm API</a> </li>
<li><a HREF="#AssistedTAPIversusFullTAPI">Assisted TAPI versus Full TAPI</a> </li>
<li><a HREF="#WhentoUsetheSpeechAPI">When to Use the Speech API</a> </li>
<li><a HREF="#Summary">Summary</a> </li>
</ul>
<hr>
<h2><a NAME="Introduction"><b><font SIZE="5" COLOR="#FF0000">Introduction</font></b></a> </h2>
<p>Now that you have had experience with the three Windows communications extensions
(MAPI, SAPI, and TAPI), you're ready to tackle the task of producing programs that
integrate these API sets into a single application. But before you leap into the dark
waters of multi-API application development, it's a good idea to take some time to test
the depth of your ideas and review the pros and cons of using one or more of the API sets
covered in this book. </p>
<p>As you've learned throughout this book, there are several places where these three API
sets provide overlapping services. This chapter shows you how to determine when each of
the three API sets covered in this book should be added to your program. You'll also learn
how to best implement each of the services depending on the Windows operating system and
programming tools available to you. </p>
<p>There are a number of things to consider when building an application that combines
multiple services. This chapter will cover the following main points:
<ul>
<li><i>General considerations</i>-Some general rules of thumb regarding complexity, mixing
of API sets, and the advantages and disadvantages of using native API calls vs. high-level
third-party tools. This section wraps up with a discussion of the pros and cons of
building standalone applications vs. creating extensions or add-ins for existing desktop
applications. </li>
<li><i>MAPI versus Comm API</i>-This section covers some things to consider when building
applications that will perform file transfers. Depending on the client and destination, it
may be wise to use the Comm API to create a custom file transfer application instead of
using MAPI services. </li>
<li><i>Assisted TAPI versus Full TAPI</i>-Much of Part IV was spent discussing the
possibilities of full TAPI. Is it always needed? Often Assisted TAPI provides all the
capability you need to implement TAPI services for your applications. </li>
<li><i>When to use the Speech API</i>-SAPI services are still quite new. Often you can use
recorded WAV files to meet most of your human speech output needs. However, there are
times when SAPI is the best answer. This section goes through some checklists to help you
decide if the Speech API is the best route for your application. </li>
</ul>
<p>When you finish this chapter, you should have a pretty good idea of how to evaluate
your application needs and recognize how each of the Windows extension services fits into
your application's design and implementation plans. </p>
<h2><a NAME="GeneralConsiderations"><b><font SIZE="5" COLOR="#FF0000">General
Considerations</font></b></a></h2>
<p>When first beginning the design phase of an application, ideas about what users need
and how they will interact with the system are purposefully vague. The general flow of a
software system and the interface needed to support that flow are only hinted at. Once it
comes time to actually build the application, however, things are different. Now all the
promises and hopes of the design group rest on the few brave souls who have the task of
implementing the design. </p>
<p>As Windows services become more common and familiar to users, the minimum requirement
for new applications is constantly being increased. A few years ago users were pleased to
get friendly screens that beeped at the moment they entered invalid data instead of
waiting until the batch was completed and the error report printed. Now users expect to
see drop-down list boxes, context-sensitive help, and "wizards" and
"assistants" that will tell them ahead of time what data they should be
entering! And they often get just that. </p>
<p>It is very common for users to expect e-mail to be an integral part of every
application. Now users are learning the possibilities of linking telephones to their
systems, too. And where telephones appear, speech processing cannot be far behind. The
hardest thing to keep in mind is that not all applications need all the extensions. And
even the ones that do need extension services can often get by with less than a full plate
of service options. </p>
<p>Adding features and services without taking the time to think about how they will
interact can lead to major headaches. This section covers some general rules to keep in
mind when designing and implementing multiservice apps. </p>
<h3><a NAME="RulesofComplexity"><b>Rules of Complexity</b></a> </h3>
<p>The first thing to keep in mind is that each new service you add to your system adds
complexity. And this complexity increases by orders of magnitude. When you decide to add
one of these services, think long and hard. And if you still want (or need) to add the
service, prepare for additional time to redesign, code, and test your application. Despite
what anyone tells you, adding e-mail or telephony or speech services to an application is
no simple matter. </p>
<p>For example, adding e-mail to a system doesn't just mean you need to add a few menu
items to the screens to allow users to send documents. You now have to deal with users
attempting to format documents for printers <i>and</i> for e-mail messages. Now users will
want to send multiple copies of the same message, possibly to someone halfway around the
world. And that person probably uses a different e-mail format, too! While good e-mail
service models (like MAPI) will mask much of this detail, you can still end up with
requests for features that push the limits of your system. </p>
<p>Now consider adding telephony or speech services to the same program. While the
possible applications of new technologies are exciting, the possible collisions of APIs
can be daunting. For this reason, it is always a good idea to limit the feature sets you
build into an application. While users will often ask for (and get) the latest
technological breakthroughs, they don't often use them to their fullest potential. It is
important to keep a clear head about just which "bells and whistles" are <i>required</i>
and which are <i>desired</i>. Each new service extension adds a level of complexity to the
system-for designers, programmers, and users. It is a good idea to do your best to limit
the extension sets that are added to any single application. Usually this can be done
without sacrificing features. </p>
<h3><a NAME="NativeAPIversusHighLevelTools"><b>Native API versus High-Level Tools</b></a></h3>
<p>Once you decide on just what services you will include in your application you need to
decide on how you will deliver these services. Often the first inclination is to acquire
the latest API/COM specification documents and begin coding function and class libraries
to encapsulate the desired services. While this is good, it may be unnecessary. Often
there is a very good high-level toolkit that you can use to gain access to the service.
And these high-level tools come with support and documentation already built. </p>
<p>Visual Basic programmers tend to think first of third-party add-ons. This is because
they usually live in a programming universe that is inundated with OLE, OCX, and VBX
solutions to problems most of them never knew existed! But even C++ programmers can find
more high-level tools on the market today-especially MFC libraries that encapsulate
complex APIs. It pays to look around before you start any "deep coding" of the
API set. </p>
<p>Of course, there are drawbacks to using high-level third-party tools. Sometimes they
are limited in their performance. Sometimes, they even turn out to be buggy. While the
latter is a rarity, the former is often the case. Most third-party tools are designed to
solve a particular set of problems. If you attempt to use the tool to solve problems
outside the original scope of the tool, you can easily become frustrated and disappointed.
It's a good idea to thoroughly test controls and libraries before adding them to a
production application. </p>
<p>Finally, using home-grown libraries or native API calls means that you will need to
keep up with the latest bug lists and upgrades for the underlying API. This, too, can be a
big job. Often, it is easier to spend the time shopping for a good tool and keep current
on its upgrades. (Assuming, of course, that the product you purchase actually keeps up
with the latest releases. Nothing is more annoying than discovering that the product you
based your whole system upon is no longer in release!) </p>
<h3><a NAME="StandaloneversusExtensionsandAddins"><b>Standalone versus Extensions and
Add-ins</b></a></h3>
<p>The last thing to keep in mind when designing and implementing applications that take
advantage of the new Windows services is the standalone versus extensions/add-ins debate.
Is it better to write your own standalone voice-activated e-mail client or to create
extensions or add-ins to existing clients already on the desktop (such as Windows
Messaging or Microsoft Mail clients)? </p>
<p>Often it is easier to build your own standalone versions of common applications. It
takes very little time to build a working e-mail client using the MAPI client interface.
This allows you to add whatever features you need without concern for generating conflicts
or confusion when adding features to existing products. </p>
<p>The advantage of extensions and add-ins is that you don't have to reinvent major
portions of your application. Most of the primary desktop tools (e-mail, databases,
spreadsheets, word-processors, and so on) are easier than ever to program. Most of the
Microsoft Office applications are able to host the Visual Basic language, and even ones
that do not will allow simple API calls into predefined "hooks" inside the
target application. With a bit of reading and lot of experimentation, you can get your
extensions to coexist comfortably with the desktop application. </p>
<p>The general rule to use in deciding whether to go the standalone or extensions/add-ins
route is: Check your client base. If most clients have the targeted desktop application
(and they are likely to keep it), then go the extension route. However, if most of your
users have a mix of client applications, or no client applications at all, you would be
better to build your own standalone application (based on the pertinent Windows extension
service). Then you can deploy it among a wider collection of workstations without having
to battle different hosting applications, and so on. </p>
<h2><a NAME="MAPIversusCommAPI"><b><font SIZE="5" COLOR="#FF0000">MAPI versus Comm API</font></b></a></h2>
<p>A common dilemma for programmers is whether to use MAPI services or Comm API services
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -