Symbian OS Communications (779884), страница 46
Текст из файла (страница 46)
In later versions ofETel ISV the need for data calls was deprecated in favour of clients usingmore obvious and convenient data transfer methods such as GPRS.With the advent of platform security in v9.1, it was possible to restrictaccess to sensitive parts of the MultiMode ETel APIs. As a result, theyare now published in the UI platform SDKs. However, the ETel ISV APIremains, both for backwards compatibility, and because it is much easierto use than the extreme feature-rich, but complicated, MultiMode ETelAPIs.If you do wish to use the MultiMode ETel APIs directly, please beaware that each method can be policed by different capabilities. Somecalls may not require any capabilities at all, for example GetFlightMode(). However, many calls require at least one of the followingthree – ReadUserData, ReadDeviceData or NetworkServices.Please see the Symbian OS Library for more details.In Figure 7.3 we show the capabilities required to use the functionalityon the ETel ISV API.Initially in v9.1, some functionality was protected by higher capabilitiesthan shown in Figure 7.3.
However, in order to allow some of the use212TELEPHONY IN SYMBIAN OSGetPhoneId(i), GetFlightMode, GetIndicator,GetBatteryInfo, GetSignalStrength, GetLineStatus,GetCallDynamicCaps, GetCallStatus,NoneGetNetworkRegistrationStatus,GetCurrentNetworkName(ii), GetOperatorName(iii),GetIdentityServiceStatusDialNewCall, Hold Resume, Swap, Hangup,AnswerIncomingCall, SendDTMFTonesNetworkServicesGetCallForwardingStatus, GetCallBarringStatusGetCallWaitingStatusGetSubscriberId, GetLockInfo,ReadDeviceDataGetCurrentNetworkInfo(iv),GetCallInfoFigure 7.3ReadUserDataCapabilities required for different operations on ETel ISV APIGetPhoneIdReadDeviceDataGetCurrentNetworkNameReadUserDataGetOperatorNameLocationGetCurrentNetworkInfoReadDeviceDataReadUserDataLocationFigure 7.4 Capabilities required for certain operations in early v9.1-based devicescases described in this chapter, the capabilities required to access someinformation were reduced.
However, some early v9.1 phones will policeaccess using the old capabilities as described in Figure 7.4.As some phones have already been shipped with the old capabilities itmay be necessary to ensure you have the old set of capabilities in orderfor your application to work on all v9.1-based devices. However, theother option is to ask users to upgrade their firmware to a more recentrelease which will only perform policing based on the new requirements.This concerns mainly S60 phones as very few UIQ phones would havebeen shipped with the old capabilities.7.3.2 Dialling a CallIn order to dial a call, a number string needs to be entered into the phoneand passed into the Dial() method.RESTRICTIONS AND CONSIDERATIONS213Emergency callsPlease be aware that if you intend to write any code that affectsthe ability of the device to make phone calls then you need tobe exceptionally careful to ensure emergency calls will still alwayssucceed. CTelephony is designed to allow an application to manageits own calls without interfering with calls from other applications, soby using CTelephony to access telephony functionality you fulfil thisrequirement.7.3.3 Answering a CallAll Symbian OS-based phones have a built-in phone application thatenables the user to make, receive and manage voice, and possiblyvideo, calls.When an incoming call is received the built-in phone application willget an incoming call notification, and will perform various actions suchas displaying the caller’s number, or name if they exist in the contactsdatabase, present options to answer or reject the call, and, dependingon the current settings, play the ringtone.
Most phones will incorporatesome form of audio policy manager that ensures the ringtone belonging tothe built-in phone application will override any other audio output. Thismeans that any system that attempts to override the built-in ringtone, suchas a video ringtone application will need to interface with UI platformspecific APIs in order to disable the built-in ringtone. On S60, this wouldbe the Profile Engine Wrapper API, documented in the S60 3rd editionFeature Pack 1 SDK, and available starting from that release.
On UIQ, thisis manufacturer specific: Sony-Ericsson will mix your sound with a beeping alert, Motorola will not allow built in ring tones to be disabled at all.7.3.4 NotificationsIf you wish to get notified of an event change you can use CTelephony::NotifyChange(), passing as one argument the request statusand the other the correctly packaged notification object descriptor thatwill contain the result on completion.You can have as many different outstanding notifications as youhave active objects handling them.
ETel 3rd Party can manage severaloutstanding notifications concurrently provided they are for differentevents. Using our classic design for ETel 3rd party asynchronous requests,we need an Active Object for each type of notification requested andhandle each RunL with the appropriate type.7.3.5 Video CallsVideo calls are not supported by the ETel ISV APIs. On UIQ you can useDNL (Direct Navigational Link) which will call into the phone application,214TELEPHONY IN SYMBIAN OSfrom the QPhoneAppExternalInterface.h.
This can also be usedfor placing voice calls. S60 has no public interface for creating videocalls.7.4 SummaryIn this chapter we have learnt how to:• access the telephony subsystem through the interfaces provided todevelopers• place outgoing calls• listen for, and answer if required, incoming calls• monitor the network status, including current cell ID and network• retrieve information about the handset and ICC in use – in particularthe IMEI and IMSI.Section IIIHigh-level Technologyand Frameworks8Receiving MessagesSymbian OS-based phones typically provide support for several differentmessaging technologies – built-in applications allow users to send andreceive email, SMS and MMS messages. It is possible for third-partyapplications to use and extend this messaging functionality in orderto add new and innovative features.
Some possible messaging-awareapplications might include:• an email management application that filters and arranges receivedemail messages• a subscription service that receives a news report over MMS andrenders it using a custom application• a multiplayer game that uses a messaging transport (such as SMS) tosend moves between handsets• a video SMS ringtone application which plays a movie clip every timean SMS message is received.This chapter explains how to use the messaging functionality inSymbian OS-based devices. It introduces the key messaging conceptsin Symbian OS and covers the following:• The Symbian OS message store• The message server and the associated client APIs• Listing messages in the message store• Extracting summary information from received messages (e.g., thesender and subject)218RECEIVING MESSAGES• Waiting for new received email and SMS messages to appear in theinbox• Intercepting SMS messages before they reach the inbox.Using the SendAs functionality, which builds on top of the messagingframework, is covered in Chapter 9.
Chapter 9 also covers extending themessaging framework with a new set of Message Type Modules (MTMs)to add a new type of transport for SendAs.Figure 8.1The summary screen application in action8.1 Example Application – Summary ScreenThe summary screen application (as seen in Figure 8.1) is used toillustrate the techniques discussed in this chapter, it provides the followingfunctionality.• Displays the details of the most recent email1 and SMS messages, i.e.,the sender and subject text.1In order to keep the example code simple, we only check the first POP3 account, ifpresent.EXAMPLE APPLICATION – SUMMARY SCREEN219• Interprets special ‘Weather Report’ SMS messages and displays theappropriate text. These messages are intercepted before they reachthe messaging inbox.Figure 8.2 illustrates the class structure of the summary screen exampleapplication.The following lists the responsibilities of the main classes in thesummary screen application:• CSummaryScreenUI – implements a very simple text-based UI.
Thisclass does not use any messaging APIs directly.• CMessageSummaryEngine – the main engine class. It creates theappropriate messaging client objects but does not actually generatethe message summaries.• CMessageSummaryGenerator – generates and stores the messagesummaries for a specified message type. There are two instances ofthis class, one for SMS and one for email. The same CMessageSummaryGenerator class can be used for both SMS and email becausethe Symbian OS APIs for retrieving basic message attributes are thesame for all message types.• CWeatherReportWatcher – waits for special weather report textmessages.
It accomplishes this by registering for notification of any textmessage starting with the prefix ‘‘Weather:’’. When a weather reportCSummaryScreenUICWeatherReportWatcher1111CMessageSummaryEngine1-Email summary generator1CMessageSummaryGenerator11-SMS summary generatorFigure 8.2 Structure of the summary screen example application220RECEIVING MESSAGESis received, it is decoded and the UI is notified via a callback. Notethat this class will intercept the SMS message before it reaches themessage server and the inbox, in order to prevent a user notificationbeing triggered. Therefore all message server APIs are bypassed forweather reports.8.2 The Message Server8.2.1 Message Server ArchitectureSymbian OS includes support for a number of messaging-related technologies such as POP3, IMAP4 and SMTP email transports, and SMS.These messaging-related features are usually accessed via the messageserver.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
